Опитвам се да започна да работя с XC8, но ме дразни факта че когато флашвам с PicKit3 отнема мн време(около 1-2 мин.).
Поразрових и видях причината слага няколко байта в началото на флаша
и после започва да пълни отдолунагоре, демек от 0хFFFF към 0. Решението което намерих е да кажа на компилатора че флаша му е по малък от реалното(--ROM=0-1ff). Това ми вади като обобщение.
Въпроса е, мога ли да накарам линкера, да разполага нещата от 0 към края на флаша а не обратно както е сега.

--------------------------------NORMAL | Pro mode |--ROM=0-1ff


Legend:
- = Unused memory
F = Filled ROM
S = Stored serial code
A = Stored ASCII string
R = Reserved for checksum
C = Stored checksum result
T = Trailing code
& = Find & replace opcode
X = Find & delete opcode
1 = dist/default/production\CAN.X.production.hex
00000000: 1111------------------------------------------------------------
00000080: ------------------------------------------------------------1111
000000C0: 1111111111111111111111111111111111111111111111111111111111111111
00000100: 1111111111111111111111111111111111111111111111111111111111111111
00000140: 1111111111111111111111111111111111111111111111111111111111111111
00000180: 1111111111111111111111111111111111111111111111111111111111111111
00200000: 11111111--------------------------------------------------------
00300000: 11111111111111--------------------------------------------------

Не ти препоръчвам да изнасилваш нещата, за да не ти излязат проблеми с пойнтърите - ако имаш такива, които могат да сочат както към РАМ, така и към РОМ обекти. Това важи за по-стартите 16-ки и 18-ките. В тези случаи, ако XC-то види, че имаш такива пойнтъри, при наличие на достатъчно флаш, кода ще бъде разположен на адреси над последния адрес на РАМ-а (например за модел с ~1.5 kB RAM, кода ще започва от адрес 0х600). Така програмата ти ще знае рънтайм даден пойнтър към какъв вид памет сочи, оттам и достъпа ще се генерира с правилните инструкции.
Гледам, че при новите 16-ки (enhanced midrange) са емулирали линейно адресно пространство при индиректен достъп, и там такива проблеми не би трябвало да има.

Звучи разумно, но за сега това ми единствения вариянт. Когато напрявя накаква работеща версия ще го върна на дефулт.
Интересното е че другите компилатори с който опитах да билдна не се държат по този начин. C18 и CCS си линкват нормално.
Възможно ли е аз да съм разбъзикал някоя настройка? Но трябва да отбележа че съм го правил и на нови инсталации, на разл. компютри.

Не знам дали тук е възможно, би трябвало да е:
Дефинираш код сегмент с малка дължина (която увеличаваш ,когато програмата ти го прехвърли) и твое си име, и начален адрес - в малките адреси. И някъде в сорса или линкера указваш ,че искаш да се ползва този сегмент.

Хъъъм, аз май точно това правя. Не съм мн запознат.

Правилно си ограничил горния адрес. Едва ли си има смисъл от други гимнастики.

Решение е до някаква степен. Но гадното е, че това е пач, а не истинското решение на проблема. Интересно ми е дали има настройка която да накара линкера да започне да пълни от 0 към 0xFFFF.

?
http://electronics.stackexchange.com/qu ... mplabx-xc8

Не видях да има специална опция за целта. Има "Format hex file for download" - това има ли ефект?
А за кой модел пик, версия и режим (free, pro) на XC-то става дума?

PIC18F26K80
MPLAB X IDE v3.35
XC8 v1.38
Mode - Pro
"Format hex file for download" не мога да го намеря къде е.

Project settings-> linker options

"Format hex file for download" това излезе.
Леле а колко съм бил забил, че да не го видя.

00000000: 11111111FFFFFFFF------------------------------------------------
0000FEC0: ------------------------------------------------FFFFFFFFFFFF1111
0000FF00: 1111111111111111111111111111111111111111111111111111111111111111
0000FF40: 1111111111111111111111111111111111111111111111111111111111111111
0000FF80: 1111111111111111111111111111111111111111111111111111111111111111
0000FFC0: 1111111111111111111111111111111111111111111111111111111111111111
00200000: 11111111--------------------------------------------------------
00300000: 11111111111111--------------------------------------------------

Ми по принцип е така. То май и на старите компилатори пълни отдолу нагоре. Но доколкото съм забелязал F-овете се прескачат бързо. И ми се струва че проблема е някъде другаде. Имаше опция "Fast Programming" поне при PICkit2. И какъв е този пик, толкова ли флаш има ? Със XC8 се пише за 16ки и 18ки както казаха. Де се вика и на бавна скорост трябва да се пълни отгоре до долу доста по-бързо.

Да се знае!
Намерих половинчат отговор.
А именно, че ако в mein-а има Interrupt реагира така:
HEX File Usage Map:

Legend:
- = Unused memory
F = Filled ROM
S = Stored serial code
A = Stored ASCII string
R = Reserved for checksum
C = Stored checksum result
T = Trailing code
& = Find & replace opcode
X = Find & delete opcode
1 = dist/default/production\CANTX.X.production.hex
00000000: 1111----11111111111111111111111111111111111111111111111111111111
00000040: 1111111111111111111111111111111111111111111111111111111111111111
00000080: 1111111111111111111111111111111111111111111111111111111111111111
000000C0: 1111111111111111111111111111111111111111111111111111111111111111
00000100: 1111111111111111111111111111111111111111111111111111111111111111
00000140: 1111111111111111111111111111111111111111111111111111111111111111
00000180: 1111111111111111111111111111111111111111111111111111111111111111
000001C0: 1111111111111111111111111111111111111111111111111111111111111111
00000200: 1111111111111111111111111111111111111111111111111111111111111111
00000240: 1111111111------------------------------------------------------
00200000: 11111111--------------------------------------------------------
00300000: 11111111111111--------------------------------------------------

Ако в mein-а няма Interrupt реагира така:
00000000: 1111------------------------------------------------------------
0000FDC0: ------------1111111111111111111111111111111111111111111111111111
0000FE00: 1111111111111111111111111111111111111111111111111111111111111111
0000FE40: 1111111111111111111111111111111111111111111111111111111111111111
0000FE80: 1111111111111111111111111111111111111111111111111111111111111111
0000FEC0: 1111111111111111111111111111111111111111111111111111111111111111
0000FF00: 1111111111111111111111111111111111111111111111111111111111111111
0000FF40: 1111111111111111111111111111111111111111111111111111111111111111
0000FF80: 1111111111111111111111111111111111111111111111111111111111111111
0000FFC0: 1111111111111111111111111111111111111111111111111111111111111111
00200000: 11111111--------------------------------------------------------
00300000: 11111111111111--------------------------------------------------