Привет на всички!
Въпроса ми е следния - трябва да се направи обновяване на програмната памет на микроконтролер, примерно pic32, stm32, pic18 през интернет. Искам да ви попитам за компетентно мнение как да подходя. Смятам да използвам сървър, на който ще е качен Centos 7 със компилатор g++ за код на C++, откъдето чрез TCP протокол ще се взима новият firmware на микроконтролера. Като цяло предаването ще става на части чрез препрограмиране на страници на програмната памет. Като цяло смятам ъпдейта да се извършва чрез bootloader, като той не се пипа и е отговорен да се свърже със DHCP сървъра. Всякакви мнения, критики, архитектури,подходи и материали приемам . Проблема ми е как трябва да бъде организиран bootloader и как когато компилирам новият firmware да знам кой полета трябва да се подновят .

Ами много зависи и от хардуера около контролера. Ключовият въпрос тук е да гарантираш свалянето на новия фърмуер изцяло и без грешки. За целта е необходима памет, в която да го свалиш и да го провериш, преди да префлашваш. Може би FTP ще е по-подходящ протокол - качваш новия фърмуер на FTP-сървър и даваш команда на устройствата да се ъпдейтнат. Аз това използвам, където е необходима FOTA, но при мен това е през ГПРС, а и в пометта на ГСМ имам достатъчно място за всякакви файлове. В самата команда за ъпдейт се дават адреса на FTP-сървъра и параметрите за достъп, та няма привързване към конкретен сървър.

Разгледай esp8266 ota: https://www.google.bg/search?num=100&ei ... d=cr&dcr=0 как го правят и направо можеш да ползваш готовото им решение.

Да със esp8266 гледах като цяло , но как ще стане със PIC18,PIC32 И STM32F ?

Може би бутлоадера на контролера да има функция да връща хекса обратно и по интернет като го получиш да го сравниш

Проца трябва сам да си провери новия фърмуер. CRC ми звучи несериозно. MD5 да речем...

Защо му е такъв протокол за предпазване от грешки, като една проверка (verify) ще даде почти 100 % сигурност. Все пак не е 1 терабайт тоя хекс
Слагаш му един бутлоадер на пика, слагаш и една RS232 комуникация към сървъра и така. Евентуално и 1-2 пина за влизане в ъпдейт/четен режими или ги правиш с команда по UART-a

А как трябва да бъде организиран bootloader, има ли някаква методика или patterns ? Може би един MD5 звучи доста добре, понеже го ползват при доста андроид устройства при recovery конзолата

Всеки метод за откриване на грешки е най-добър за определен тип среда. Тъй като много типове данни, разбирай различни комбинации от байтове могат да дадът една и съща контролна сума, то е възможно да възникне такава грешка която да генерира същата чексума и да не се открие грешката. Всеки метод набляга на най-вероятните типове грешки които възникват в средата. Например в CD-ROM се използва CRC 32, при RFID се ползва контрол по четност. Варианта със обратното връщане на хекса и сравняване с оригинала е един вид пълна конролна сума (некомпресирана). Вероятността да възникнат грешки които при обратното връщане да се компенсират от други и да се получи оригиналния файл е почти нулева. Т.е. имаш почти 100 % надежност. Пък и да не забравяме, че е най-лесният вариант за софтуерна реализация. Но не казвам, че другите варианти са лоши...
За бутлоадера не зная как се пише.

Нещо не ми се вързват FOTA и RS232, а и това връщане kа хекса към сървъра... Сървъра намира грешка или не намира - какво следва. Аз затова предложих FTP. Но всичко е заровено в конкретиката...

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

FOTA и RS232 си пасват идеално. Просто трябва жицата за 232 да е опъната във въздуха.

Сега загрях... А ако жицата е пусната у реката, тогава Firmware Over-The-Water ли ще е?

Firmware Under-The-Water