Ами това е проблем, който няма еднозначно решение. BIN имиджа винаги си е колкото си е цялата памет. HEX-а в случай на малко код е по-изгоден, ама в случай на много код - става безумие.

Аз лично гледам винаги да работя с BIN файлове по причина, че работиш с worst case и не можеш да си самопредизвикаш изненади. Поради същата причина не компресирам/декомпресирам в устройството, щото в общия случай нивото на компресия е непредсказуемо и пак може да си самопредизвикам изненада.

А що ти е да сторваш имиджа междинно във външен флаш? Записвай докато идва по линията в реално време. Аз така правя - на блокове там по 256, 1024 или както ти е удобно. Когато работиш с BIN това е лесно за организация. Може да е малко по-зле оптимизирано като скорост, ама това е ъпдейт на фирмуер, приказката за бързата кучка я знаеш.

По-скоро не . Стартираш буутлоадера , и е активен дикато презапише основния фърмуер.
Проблемите са - какво става, ако по-средата натъпи ресет.

Ами тоя проблем аз го решавам с контролната сума на фирмуера. Нея я шибвам накрая на флеша за юзерски код. При ъпдейт първо изтриваш контролната сума и после почваш ъпдейта. Съответно накрая се записва и новата контролна сума (ако процеса стигне до там). При начално стартиране, преди да стартира юзерския фирмуер, бутлоадера проверява контролната сума на фирмуера. Ако е валидна - пуска юзерския код, ако не, седи и чак нов ъпдейт. Така си гарантираш, че ако спреш по средата на ъпдейта, няма да работиш с полвинчат фирмуер (нещо което е потенциално опасно), юзера ъпдейтва докато не сполучи.

Неудобството на тоя подход е, че винаги записваш целия възможен флеш, даже и половината да е празен. Ама както казах, това е ъпдейт, бърза работа няма.

Удобството е, че можеш да ползваш бутлоадера всеки път да прави проверка на консистентността на юзерския флеш и ако се е самозатрил някой бит с времето, ще го гепиш. Е това при по големи памети може да коства време за първоначален бут, но при мен го искат по правилник, така, че избор няма.

Между бутлоудъра и апликейшъна имам един блок флаш (в зависимост от модела контролер), в който пиша всякаква необходима информация за апликейшъна: чексума, дата на флашване и каквото още ми е нужно. Тоя блок се записва накрая на флашването, след като апликейшъна е валидиран успешно (т.е. чексумата да излиза, а в случая с кортексите и валидация на първите 2 думи в началото на имиджа - стек пойнтър и стартов адрес).
Съответно в началото на флашването тоя блок се забърсва първи.

А как новия имидж пристига при устройството? На някакъв сменяем носител ли или по друг начин?

Е нали ти каза, че ще е по USB? Това предполага, че от другата страна имаш компютър/таблет, на който седи имиджа (имиджите).

За момента наливам само през ПЦ и серийни интерфейси.

Цецо, въпроса ми беше към колегата tolstolob и той отговори че го налива по сериен интерфейс.

За моя случай трябва да е USB, така че става по-сложно... Освен това ще имам криптиране - така че нещата отиват към писане на буутлоадър (първо) и после на всичко останало.

Е поне вече знаеш, че задачата не е тривиална

Даааа - очертава се предварителна работа с месеци преди да се започне същинската работа! Ама няма лошо - ще науча много нови неща и най-важното е че ще натрупам опит

Под серийни интерфейси имах предвид и USB.
Интерфейса няма голямо значение, то контролерския софтуер като цяло е по-лесната задача, мисли как ще направиш хоста, там ще е Голямото настъпване на греди

Това пък защо?
BIN-а си е толкова, колкото го направиш... Единствената причина да е по-голям е че заради криптирането е по-лесно да го закръглиш предварително на размера на блока.


Това е полезно, стига да има външна памет/карта.
Първо за разлика от буутстрапа, приложението може да поддържа повече интерфейси (gprs/ethernet..), второ може да поддържа повече протоколи (примерно ъпдейта може да идва по заявка от някакъв отдалечен сървър със странен протокол). Трето свалянето на фърмуера може и да не е успешно, няма смисъл да се почва флашването без да си сигурен че ще има с какво да го завършиш. Четвърто външната памет позволява повече от една версия, т.е. сваляш нова, флашваш, но ако не стане може да върнеш предишната.
Така че приложението спокойно може да си сваля фърмуери и когато реши, че може да се ъпдейтва, просто слага маркер в RAM-a и рестартира. Буутстрапа така или иначе е желателно да си чеква причината за ресет/рестарт и ако е софтуерен рестарт и си намери маркерчето - флашва каквтото трябва...

И аз го правя точно както Миро го е описал с външна памет и винаги преобразувам до бин файл за да е ясен размера, но пазя и адресите. Външната памет винаги ми е голяма колкото флаша на контролера, а заради боотлоадера ъпдейта няма как да е по-голям от целия флаш минус големината на боотлодера та винаги имам място и за адресите.

Напротив - на PC-то се работи с USB през стандартни API-та, които са писани от Microsoft и са тествани от милиони разработчици по цял свят и там всичко е известно.

При микроконтролера или ще трябва да си пиша аз всичко от нулата или ще предпочета да ползвам някаква готова библиотека, с която може да възникнат какви ли не случки. Ако тя е универсална - може да не е предвидена за някои особености на моя контролер и да има големи проблеми докато се настрои. Ако е писана от производителя на контролерите - най-вероятно ще е писана от един човек (двама-трима в най-добрия случай) за да се покажат че имат и библиотека за USB, ще е супер бъглива, почти нетествана и т.н.

Очаквам най-големите дървета да излязат от страната на микроконтролера.

Е те тука вече си личи кой за какво ползва ъпдейта. Когато започнах да пиша софтуер в тази област, първите ми контролери въобще не подържаха ъпдейт. Т.е. не бяха флеш въобще де Първия дивайс съм му писал фирмуера половин година, от които поне 3 месеца са били тестове. Говорим за нещо което се побира в 16к и поне 30% бяха свободни (много бях горд, че се събрах в заданието като памет), т.е. не за кой знае колко много код. Тези дивайси работят с този фирмуер вече 15 години без ъпдейти

Днес правя устройство, чиито фирмуер компилиран в момента е към 257к (от които поне 2/3 вътрешнофирмен), писан е пак за 6 месеца и вече имаме барем 5 ъпдейта на полето при клиента. Отделно, че поне 30% от функционалността въобще не е готова, ама това не пречи да се продава...

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