Идеята е следната:
Иска ми се вече да си направя напълно собствен боотлоадер за определени нужди. Имам вече достатъчно опит с разни боотлоадери, за да разбера принципите и конкретните реализации. Не ми е ясно обаче следното:

Ако аз сам си натворя код на С, мога ли да уговоря по някакъв начин компилатора да ми сложи определени функции на определено място. Що ми е това? Ами защото искам да си разделя програмата на 2 части константна - която няма да се променя и променлива - която потребителя ще може да обновява в бъдеще.
Константната част трябва да съдържа функции за екран, клавиатура интерфейс и БООТЛОАДЕР, който вече няма да е БООТ а само ЛОАДЕР.
Променливата част - всичко останало.
Променливата част трябва да може да ползва функции от константната. Обратното не е наложително.

Всичкото това да е една програма - в която константната част ще си е все една и съща. Ще се наложи да има и някаква клиентска част за Windows примерно - но това не е проблем толкова.

Основния въпрос е - мога ли да оговарям компилатора дс сложи функции там - където искам - и ако може как?
Приемам и принципни концепции също!

По принцип може с HI-TECH да стане това, но е много шибано, поне от моя гледна точка. Някога опитах да направя това, което ти искаш на пик18-ка и се сблъсках с големите "удобства" на хай-теч. Питах в няколко форума, как да стане това, четох документацията на хай-теч и... нищо. Накрая попитах във форума на хай-теч и там ме светнаха как става, след което се отказах от този компилатор . Пише се един дъъълъг команден ред на линкера, за да укажа началния адрес само на една функция. Ами за повече!?
Информацията обаче ми е стара, защото от доста време не пиша за пик18, а от още по-рано на HI-TECH. Ама не ми се вярва, да се е променило нещо в по-новите версии на компилатора.

Налага се да прехвърля код от ByteCraft към Hi-Tech ( боза към боза ), искам едни масиви с константи да ги разположа на фиксирани адреси в програмната памет на контролера, т.е. дефиницията им е нещо такова:



Как да накарам това чудо на техническата мисъл, Hi-Tech, да ги разположи на нужните адреси ?? Намирам само разни неща за асемблера, ама искам да е в C-то ...

Е това е приблизителния солюшън Приблизителен, защото, доколкото си спомням, не стана точно така, или пък не си спомням...


Дано да помогне!

Здравейте!
Явно - решил съм проблема и съответно съм заебал темата.
Резултата:
Имаме си абсолютна реализация на първоначалната идея. Постигнахме даже повече от колкото си представяхме. На HI-TECH може да се направи абсолютно всичко и хората са си го описали в PDF-а - стига да има кой да чете. Спокойно можеш да си сложиш функция където си искаш и изобщо не съм видял до сега някакви ограничения - дето да идват от компилатора сякаш.
Та имаме си напълно функциониращ и вече доста пъти изпробван боотлоадер за 18-та серия, който може да се вика и при стартирани - и от главната програма и чрез съобщение отвън - бе всякак. То е според нуждите явно. Боотлоадера е писан на чисто С. Никакъв асемблер, и заедно с почти 2 картинки за дисплея /които са около 800-900 байта/ - целият е 2КБ. То толкова е и т.н. BOOT сегмент от паметта на 18-ката с която сме го направили - 2620.
Имаше и някои особенности - примерно наложи се си направим собствени функции за писане във флаша и еепрома, защото тия от библиотеките са някак много всеобхватни и доста раздути - ама то се очакваше и да си е така.
Ако някой има подобен проблем - ще се радвам да помогна.

А бе стана, след дълго ровене намерих един пример в някакъв форум, но общо взето тъпичко направено. По принцип не съм фен на Hi-Tech, прекалено много са се вживявали като са правили компилатора си, уж да изглежда по професионално, но е станало обратното.

Много голям тоз bootloader, 1.1-1.2kb ми се струва прекалено голям. Преди време преработих един стар код на Microchip, добавих нужните неща, събра се на < 400 байта, използвам директно терминална програма, след ресет контролера чака 2 секудни да получи стартов сигнал от терминалната програма, ако получи влиза в режим на bootloader, ако не получи проверява има ли читава потребителска програма, ако има я стартира, ако не си стои в bootloader режим. Използването на терминална програма вместо специализиран PC софтуер е голямо, каквато и ОС да има стартирана на PC-то, все ще се намери терминална програма, която да свърши работа. Тествал съм го на 18F252/452/458/4580 и още на двама-трима, но не ги помня. Ще видя тия дни до му понапиша малко документация и ще го кача тук.

Боотлоадера е голям, щото то не е само боотлоадер, а има вътре и миди парсер, код за поддръжка на дисплей + шрифта, дешифратор на тайния ни код с който го наливаме и още разни други работи. Един вид то си е някаква самостоятелна програма все едно. А иначе даже е направен да работи по MIDI а не по сериен порт - и трансфера става чрез MIDI спецификация - което си е шибана работа малко по принцип. Въпроса е, че удовлетворява специфичните изисквания. А иначе Tiny боотлоадера си е супер и е само 100 думи.

Иначе явно съм доста разсеян и не съм видял питането...

Точно така се прави при HI-TECH както е показал Gogo.
Принципа е следния:
Правиш си отделен собствен сегмент /разбирай и отделен файл/- който онаследява типа на някой от стандартните сегменти на компилатора. Слагаш в тоя файл каквото трябва и след това указваш къде да се разположи сегмента и работата е готова.
По тоя начин може да разположиш не само променливи, константи, че дори и функции. Готиното е, че ако имаш боотлоадер, който има определени функции, които ти се иска да ги ползваш и от потребителската програма - знаейки адреса на функциите, можеш да ги ползваш и от нея - чрез указатели естествено. Бе тарикатска работа. Според мене ич не им е лош компилатора на тия HI-Tech. Те явно и Микрочепа за това ги купиха. Ще видим де...

Hi-Tech са направили прекалено сложно някои неща, все пак става дума за микроконтролери, а не за Intel32 архитектура. Примерно при CCS & MCC18 става къде къде по-лесно да зададеш адреса на която да се разположи променливата или функцията ( #ORG или #pragma code .... ), освен това се прави директно в кода, след време като четеш кода веднага се вижда кое на кой адрес е.

Bootloader е само това, което практически зарежда новите програми. Всичко останало е потребителски код.

Tiny не ми хареса поради това, че няма верификация на това което зарежда в програмната памет, пише там нещо, но дали е записано вярно, не е много ясно, отделно задължително трие блока памет, който ще записва, не е кой знае колко сложно да се направи една проверка дали паметта е чиста. 100 думи като се каже на първо слушане звучи като 100 байта, но инак си е 200 байта . Спомням си и друго за Tiny, май се разполагаше върху векторите на прекъсване, и не ми стана ясно как потребителска програма заредена с Tiny може да използва прекъсванията. Не знам дали използваш прекъсвания в заредена потребителска програма, ако използваш, как го правиш ? Те ще се запишат върху самия bootloader, а той не прави май проверка дали потребителския код няма да се запише върху него. А бе то за това и името му е Tiny, ама щом ти върши работа бива.

Е.. то Tiny боотлоадера не е за крайно устройство направен - или аз поне с такова впечатление съм останал. То си е точно за това - нещо бързо малко и вършещо работа при развой - да се не мотаеш а да си мислиш върху кода. Обема му е малък, защото ползват собствена програма за пълнене - която леко преработва HEX файла който се зарежда. Tiny е направен така, че се разполага винаги в края на паметта и записва стартовия вектор със своя адрес. Векторите на прекъсванията не ги закача и са си свободни. Самия боотлоадер е направен в Polling моде и не ползва прекъсвания. Като пълниш обаче - тяхната пълнеща програма преправя малко адресите които реално се записват във флаша - а той изпълнява на "сляпо".
Какво се получава в същност:
1. Реално не записва стартовия вектор - тоест оставя си го да сочи към боотлоадера, а после той си вика потребителската програма.
2. Стартовия адрес на потребителската програма - който е бил записан в хекс файла и не е записан в стартовия вектор, се запомня в 2 свободни клетки вътре в самия боотлоадер, който боотлоадера пази спецялно за тая цел. Като се стартира и като си свърши работата - то тогава отива на адреса записан в тия клетки и става същото все едно стартовия вектор е бил записан със истинския адрес на потребителската програма.
3. Както казах вече, векторите на прекъсванията са свободни и си се ползват нативно от главната програма.

В нашия случай подхода беше малко по различен.
Нашия боотлоадер се разполага в началото на паметта - тоест върху всички вектори в началото - стартов - прекъсвания и т.н. На главната програма и се задава тотално отместване - с големината на боотлоадера. Всички нейни адреси вече са реално отместени със зададена стойност назад. Тоест стартовия и сектор започва от някакъв адрес, след това следват прекъсванията и т.н. Изобщо има общо отместване назад. При стартиране - боотлоадера си върши каквото ще върши и скача на адреса на главната програма - като знае колко е голям и реално знае и къде започва главната програма. Самия боотлоадер не ползва прекъсвания, а на векторите е записано прескачане на адрес = на отместването на главната програма + стандартното отместване на векторите, защото те са си със същото относително отместване спрямо вече отместения стартовия сектор. С една дума скача се от вектора на прекъсване на боотлоадера - на вектора на прекъсване на главната програма - от където вече се скача към реалния код на прекъсването. Лошото на тоя подход е, че се добавя още един CALL, и в крайна сметка го преправихме така, че вектора на прекъсването на боотлоадера не сочи към вектора на главната програма - а направо там дето сочи тоя вектор - демек към кода на прекъсването. Всичко си заспа...

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

Въпроса беше за Tiny bootloader-а, 200 байта ама като няма верификация на записаното за нищо не става. Според мен си губи смисъла да използвам един bootloader за развой, и ако се наложи да пусна изделието да търся друг bootloader, най-малкото ще се наложи да се бърника пак по програмата. А това което обясняваш, че сте направили е преправен Tiny, така че като се добавят нужните неща кода набъбва и няма как да е 200 байта По принцип при PIC18 има boot block който е в началото на паметта, той може да се заключва, така че е логично както сте направили да преместите кода на bootloader-а в началото на паметта, а приложението да е след това, ремапването на адресите на прекъсванията и ресет вектора не е проблем, два цикъла закъснения при изпълнението на прекъсването на приложението не би трябвало да е проблем. А при Tiny е направено точно наопаки. Всъщност ако се разгледа от друг ъгъл, може да се приеме, че при Microchip е направено наопаки

При мен екстрата за потребителя е изписването на точки на екрана на терминалната програма след поредния успешно записан блок, като навремето в ДОС-овските програми, ако възникне грешка печата Error, като зареди програмата печата Ok и това е. А, има и 3 кода на грешки които печата, но те са по-скоро за мен, а не за потребителя. Плюса е, че не се нуждая от приложна програма на PC-то, на всяка OS, за всяко PC ще се намери подходяща терминална програма, само се настройва UART-а и пращаш hex файла, bootloader-а си обработва сам редовете на hex файла.