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?

do góry

On Sat, 10 Feb 2018, Bool wrote:

> 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

do góry

On Mon, 12 Feb 2018 10:56:30 +0100, Marek Wodzinski
<m...@O...mamy.to> wrote:
> 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

do góry

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

do góry

W dniu 2018-02-12 o 16:26, Piotr Gałka pisze:
> 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.

do góry

W dniu 2018-02-12 o 10:56, Marek Wodzinski pisze:
> 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ć?

do góry

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

do góry

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_Protoc
ol_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

do góry

W dniu 2018-02-12 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.

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.

do góry

On Mon, 12 Feb 2018 17:29:13 +0100, Bool <n...@n...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
;) (robiłem kiedys takiego overrkilla, da się :)

--
Marek

do góry