Protokół dla bootloadera

Zastanawiam się nad wyborem protokołu dla bootloadera po UART. Ma to być prosty protokół, obsługiwany przez terminale pod Windows i Linux. Wstępnie wybrałem xmodem. Czy warto zainteresować się jeszcze jakimś innym protokołem?

Reply to
Bool
Loading thread data ...

Zależy co na tym chcesz zbudować, jaki to procek, kto będzie z tego korzystał i w jakim środowisku.

W ekosystemie Arduino/AVR warto zobaczyć jakie protokoły obsługuje Avrdude. I jakich nie obsługuje (w tym xmodem).

Sam kiedyś napisałem bootloader z xmodemem (*) i na dłuższą metę okazał się dosyć upierdliwy, a na pewno jest problem z powiedzeniem użytkownikowi końcowemu 'odpal minicoma, wciśnij cośtam, odpal lsz...'.

(*)

formatting link

Pozdrawiam

Marek

Reply to
Marek Wodzinski

Bardzo wysokie słusznie, też szybko się wyleczyłem z takiego bootloadera. Standardem jest teraz przez USB, jeszcze lepiej nośnik USB, a jeszcze lepiej gdy sam się aktualizuje przez sieć. .

Reply to
Marek

W dniu 2018-02-10 o 13:35, Bool pisze:

Jeśli urządzenie w normalnej pracy komunikuje się jakoś ze światem stosując w tym celu jakiś protokół to nie widzę powodów dlaczego upgrade miałby posługiwać się innym protokołem. Ale tego nie wiemy o tym urządzeniu. P.G.

Reply to
Piotr Gałka

W dniu 2018-02-12 o 16:26, Piotr Gałka pisze:

Urządzenie obsługuje Modbus RTU. Z tego co wiem to Modbus nie ma funkcji zapisu pliku. Biblioteka Modbus której używam nie ma jej na pewno.

Reply to
Bool

W dniu 2018-02-12 o 10:56, Marek Wodzinski pisze:

Dzięki, zerknę. A czym się objawiała ta "upierdliwość", poza tym że użytkownikowi trzeba było tłumaczyć co i jak ma robić?

Reply to
Bool

W dniu 2018-02-12 o 15:56, Marek pisze:

Zgoda, tylko że mój mikrokontroler to prosty LPC z Cortex-M0. Do komunikacji ze światem jest tylko UART, a dokładnie RS-485.

Reply to
Bool

W dniu 12.02.2018 o 17:23, Bool pisze:

Doczytaj:

formatting link
20 Read File Record i 21 Write File Record - od strony 32 w pdfie z linka. A ponadto możesz dodać własną funkcję z kodem od 65 do 72 albo 100 do 110 i dowolnie sobie zdefiniujesz zawartość ramki.

Biblioteki która to będzie obsługiwać nie znajdziesz darmowej, trzeba sobie dopisać obsługę tych funkcji samemu, ale to nie jest jakieś rocket science.

Reply to
Jakub Rakus

W dniu 2018-02-12 o 17:23, Bool pisze:

Nie znam standardów upgrade - znam tylko to, co my sami sobie kilkanaście lat temu wymyśliliśmy i zaczynam podejrzewać, że jakoś inaczej rozumiem upgrade.

Dla mnie przesyłanie pliku upgrade to przesyłanie go po kawałku aby nie przerywać normalnej pracy urządzenia. A jak rozumiem Ty myślisz o przesłaniu całości jakąś jedną funkcją. Odpadam - niepotrzebnie się odzywałem. P.G.

Reply to
Piotr Gałka

Nie przeszkadza, dodaj mu moduł GSM że stosem tcp, będziesz miał OTA ;) (robiłem kiedys takiego overrkilla, da się :)

Reply to
Marek

Ale to podniesie koszt mojego urządzenia o co najmniej 100% :)

U mnie w kolejce czeka właśnie projekt z możliwością aktualizacji firmwaeru po GSM i prawdę mówiąc chciałem upiec dwie pieczenie na jednym ogniu. Zaimplementować taki sam protokół dla obu urządzeń. Możesz skrótowo napisać jak robiłeś to w przypadku z modemem GSM?

Reply to
Bool

W dniu 2018-02-12 o 17:47, Jakub Rakus pisze:

Faktycznie jest :)

Jedynie co mnie boli to konieczność napisania Mastera Modbus z obsługą tej funkcji pod Windows i Linuxa. Dlatego wstępnie wybrałem protokół z gotowymi programami od strony PC. Oczywiście jest to do zrobienia, ale czasu brakuje...

Reply to
Bool

Mcu przez stos tcpip modemu GSM pobiera sobie binarny plik obrazu firmware'u z serwera www. Stos większości modemów gsm umożliwia prostą komunikacje przez polecenia AT. Modem zestawia połączenie a mcu komendami AT wymienia sobie dane , można kawałeczkami pobrać sobie dowolnie duży plik. Kod pobierający nowy soft nie jest częścią bootloadera (bo byłby za duży) ale częścią softu użytkowego. W związku z tym, że soft użytkowy nie może się sam nadpisać (no, byłoby to klopotliwe, szczególnie gdyby np. połączenie zostało przerwane) to tymczasowo zapisuje pobrany obraz firmware'u w wolnym za sobą obszarze flash mcu (z pewnym marginesem) . Po wygraniu, robi reset po którym startuje bootloader, który sprawdza czy pod odpowiednim adresem jest obraz, jeśli jest kopiuje go pod docelowy adres nadpisując poprzedni firmware (i usuwa znacznik w tymczasowym obrazie by po kolejnym uruchomieniu nie kopiować ponownie). Tak w skrócie. Pominąłem takie szczegóły jak, to że pobierany firmware jest zaszyfrowany (klucz ma tylko bootloader i on deszyfruje dopiero przy docelowym nadpisywaniu), w trakcie pierwszego kopiowania do flash pod adres tymczasowy jest sprawdzane crc obrazu, by nie dopuścić do uruchomienia nieprawidlowego kodu itp. Aktualizacja ok 90kB obrazu pobieranego 256 bajtowymi paczkami po

9600bps uarcie mcu-modem trwa ok 4 min. Sama aktualizacja jest inicjowana smsem, komunikacja zwrotna w przypadku problemów z pobraniem pliku itp też jest smsem. Jeśli chodzi o szczegóły komunikacji to już to jest zależne od implementacji obsługi stosu w danym modemie, ja to ćwiczyłem na modułach G510.
Reply to
Marek

A czemu nie przerywać? Ostatnie 20 lat "rozwoju" oprogramowania wychowalo pokolenie "proszę czekać". Dlaczego nie może być "proszę czekać, trwa aktualizacja"? :) Większość przyjmuje to, że zrozumieniem.

Reply to
Marek

W dniu 2018-02-12 o 20:33, Marek pisze:

Alarm. Żołnierze lecą do magazynu uzbrojenia a system kontroli dostępu: "Proszę czekać, trwa aktualizacja" :) P.G.

Reply to
Piotr Gałka

Bleh, nie takie rzeczy już bywały. Przypominam sprawę unieruchomienia okrętów podwodnych USA z powodu aktualizacji ich układów sterowania opratych o windows (końcówka lat 90 u.w.)

Reply to
Marek

W dniu 2018-02-12 o 18:11, Piotr Gałka pisze:

U mnie upgrade wygląda tak że ładuję cały plik do flasha i weryfikuję go. Jeśli weryfikacja przebiegnie OK to ustawiam flagę we flashu i robię reset. Bootloader sprawdza zawsze flagę przy starcie i jeśli jest ustawiona to rozpoczyna proces aktualizacji. Wtedy mam pewność że załaduję zawsze poprawny firmware.

Reply to
Bool

W dniu 2018-02-13 o 14:43, Bool pisze:

Dokładnie takie działanie miałem na myśli (tylko flaga w EEPROMie :) ).

Masz też pewność, że urządzenie nigdy nie zostanie bez działającego programu niezależnie kiedy zabierze mu się napięcie. Aby w ogóle uniknąć niedoprogramowanego flasha procesor jeszcze dostaje przerwanie "wyłącz wszystko, aby energii w kondensatorach starczyło na dokończenie rozpoczętego procesu programowania." P.G.

Reply to
Piotr Gałka

Ja się podepnę z pytanianiem:

Nie jestem jeszcze superbiegły w STM32 i bootloaderach.

Czy jest możliwe aby w np. STM32F103 jakoś tak przygotować/zbudować bootloader aby mozna było zaciągać obraz flasha(fragmentu) z karty SD z pliku obraz.bin (z FATu). Oczywiście obsługę FAT mam ogarniętą. Plik obraz.bin to skompilowany wsad który normalnie wpalam STLinkiem. Pytanie chyba raczej dotyczy tego czy bootloader moze być na tyle pojemny aby ogarnąć ten FAT i inne prymitywy niezbędne do gadania z SD card.

jp

Reply to
jacek pozniak

Ale rozumiem, że musisz mieć ponad 2x więcej flasha niż rozmiar wgrywanego kodu?

jp

Reply to
jacek pozniak

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.