W dniu 2018-02-12 o 18:17, Marek pisze:
> 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ę :)

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?

do góry

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

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

do góry

On Mon, 12 Feb 2018 18:44:27 +0100, Bool <n...@n...com> wrote:
> 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

do góry

On Mon, 12 Feb 2018 18:11:48 +0100, Piotr
Gałka<p...@c...pl> wrote:
> 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"? :)
Większość przyjmuje to, że zrozumieniem.

--
Marek

do góry

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

>> 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"? :)
> Większość przyjmuje to, że zrozumieniem.
>

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

do góry

On Tue, 13 Feb 2018 09:29:56 +0100, Piotr
Gałka<p...@c...pl> wrote:
> Alarm. Żołnierze lecą do magazynu uzbrojenia a system kontroli
> dostępu:
> "Proszę czekać, trwa aktualizacja" :)

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

--
Marek

do góry

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

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.

do góry

W dniu 2018-02-13 o 14:43, Bool pisze:
> W dniu 2018-02-12 o 18:11, Piotr Gałka pisze:
>> 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ą.
>
> 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.
>

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.

do góry

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



--

www.flowservice.pl
www.flowsystem.pl

do góry

Marek wrote:

> On Mon, 12 Feb 2018 18:44:27 +0100, Bool <n...@n...com> wrote:
>> 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.
>
Ale rozumiem, że musisz mieć ponad 2x więcej flasha niż rozmiar wgrywanego
kodu?

jp

--


www.flowservice.pl
www.flowsystem.pl

do góry