RTV forum PL | NewsGroups PL

Protokół dla bootloadera

NOWY TEMAT

elektroda.net NewsGroups Forum Index - Elektronika Polska - Protokół dla bootloadera

Goto page 1, 2  Next

Bool
Guest

Sat Feb 10, 2018 1:35 pm   



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?

Marek Wodzinski
Guest

Mon Feb 12, 2018 10:56 am   



On Sat, 10 Feb 2018, Bool wrote:

Quote:
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?

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...'.



(*) https://github.com/majekw/xeboot


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

Marek
Guest

Mon Feb 12, 2018 3:56 pm   



On Mon, 12 Feb 2018 10:56:30 +0100, Marek Wodzinski
<majek_at_ODSPAMIACZ.mamy.to> wrote:
Quote:
Sam kiedyś napisałem bootloader z xmodemem (*) i na dłuższą metę
okazał
się dosyć upierdliwy, a na pewno jest problem z powiedzeniem


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ć. .

--
Marek

Piotr Gałka
Guest

Mon Feb 12, 2018 4:26 pm   



W dniu 2018-02-10 o 13:35, Bool pisze:
Quote:
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?

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.

Bool
Guest

Mon Feb 12, 2018 5:23 pm   



W dniu 2018-02-12 o 16:26, Piotr Gałka pisze:
Quote:
W dniu 2018-02-10 o 13:35, Bool pisze:
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?

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.

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.

Bool
Guest

Mon Feb 12, 2018 5:25 pm   



W dniu 2018-02-12 o 10:56, Marek Wodzinski pisze:
Quote:
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...'.
(*) https://github.com/majekw/xeboot

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ć?

Bool
Guest

Mon Feb 12, 2018 5:29 pm   



W dniu 2018-02-12 o 15:56, Marek pisze:
Quote:
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ć. .

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

Jakub Rakus
Guest

Mon Feb 12, 2018 5:47 pm   



W dniu 12.02.2018 o 17:23, Bool pisze:
Quote:
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.

Doczytaj:
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
Funkcja 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.

--
Pozdrawiam
Jakub Rakus

Piotr Gałka
Guest

Mon Feb 12, 2018 6:11 pm   



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

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.

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.

Marek
Guest

Mon Feb 12, 2018 6:17 pm   



On Mon, 12 Feb 2018 17:29:13 +0100, Bool <no_at_no.com> wrote:
Quote:
Zgoda, tylko że mój mikrokontroler to prosty LPC z Cortex-M0. Do
komunikacji ze światem jest tylko
UART, a dokładnie RS-485.

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

--
Marek

Bool
Guest

Mon Feb 12, 2018 6:44 pm   



W dniu 2018-02-12 o 18:17, Marek pisze:
Quote:
On Mon, 12 Feb 2018 17:29:13 +0100, Bool <no_at_no.com> wrote:
Zgoda, tylko że mój mikrokontroler to prosty LPC z Cortex-M0. Do komunikacji ze światem jest tylko
UART, a dokładnie RS-485.

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

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?

Bool
Guest

Mon Feb 12, 2018 6:47 pm   



W dniu 2018-02-12 o 17:47, Jakub Rakus pisze:
Quote:
W dniu 12.02.2018 o 17:23, Bool 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.

Doczytaj:
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
Funkcja 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.

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...

Marek
Guest

Mon Feb 12, 2018 8:26 pm   



On Mon, 12 Feb 2018 18:44:27 +0100, Bool <no_at_no.com> wrote:
Quote:
Możesz skrótowo napisać jak robiłeś to w przypadku z modemem GSM?

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.

--
Marek

Marek
Guest

Mon Feb 12, 2018 8:33 pm   



On Mon, 12 Feb 2018 18:11:48 +0100, Piotr
Gałka<piotr.galka_at_cutthismicromade.pl> wrote:
Quote:
Dla mnie przesyłanie pliku upgrade to przesyłanie go po kawałku aby
nie
przerywać normalnej pracy urządzenia.

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

--
Marek

Piotr Gałka
Guest

Tue Feb 13, 2018 9:29 am   



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

Quote:
Dla mnie przesyłanie pliku upgrade to przesyłanie go po kawałku aby
nie przerywać normalnej pracy urządzenia.

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


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

Goto page 1, 2  Next

elektroda.net NewsGroups Forum Index - Elektronika Polska - Protokół dla bootloadera

NOWY TEMAT

RTV map News map