Newsgroup: it.hobby.elettronica.digitale
Titolo: avr, bootloader, controllo remoto...

Salve a tutti, non ho mai usato bootloaders nei miei (modesti)
progetti
e ora, improvvisamente, m'e' venuto lo sfizio.
Ho una scheda costruita attorno ad un atmega168, e sto monitorando da
remoto
il suo comportamento con un pc e delle sonde di temperatura.
Il pc e' connesso a internet e usa teamviewer per il controllo remoto,
ma anche pvserver
e dyndns per evitare di entrare sempre nel pc per controllare la
salute dell'aggeggio.
Ora ho scoperto un bug e necessito di riprogrammare il micro, e ho
fatto
un pensiero sporco: perche' non usare il pc per accedere ad un
bootloader da
remoto?
La seriale posso tirarla fuori dalla scheda e il pc ne ha una libera,
rimane da scegliere
il bootloader e il sistema di programmazione.
Consigli? Esperienze? Lascio perdere?
Tanto prima o poi la scheda la connettero' alla seriale del pc per
impostare
i parametri e leggere lo stato "interno" del firmware. Avevo pensato
ad un
bootloader tipo stkload
http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html
e magari inviare tramite pvbrowser i comandi a stk500.exe
che ne pensate?
Fabio.

 salute dell'aggeggio.
Scritto di fretta ed e' poco chiara la situazione attuale del sistema:
nella postazione remota c'e' la scheda con l'atmega168 che comanda
un impianto, a fianco della scheda vi e' un pc che monitora le
temperature
dell'impianto, le registra in un log ed ha un server pvserver
accessibile da
remoto con  pvbrowser tramite dyndns, oltre che un porgrammino per
accedere al pc da un computer remoto. Attualmente pc e scheda non
sono connessi ma dispongo di seriale su entrambi ed in futuro li
connettero' insieme.
Forse ora si capisce.
Ciao.

 ha
scritto:

La realizzazione di un bootloader non è cosa particolarmente difficile, ma
occorre innanzitutto capire la solfa del 'Read-While-Write Self-Programming',
che riassumendo molto significa che l'istruzione SPM la si può eseguire solo
nella sezione boot (scelta dai fuse).
Esistono esempi in rete sia in ASM che in C.
Per quanto riguarda il tuo caso, tieni presente che se aggiorni il sw da remoto,
sia da rete che con un modem esiste la possibilità che la linea cada e che
l'aggiornamento si interrompa, in questo caso la macchina deve poter essere in
grado di riprendere o ricominciare il boot o almeno di scrivere un messaggio per
l'utente e permettergli di ricominciare.
Io in un caso simile aggiorno da seriale+modem comunicando l'exe (un file
ASCII-INTEL) e andando a scrivere quando ho in ram 1K, in modo da aggiornare
quasi contemporaneamente 4 pagine da 256 e poter gestire l'eventuale caduta
delle linea.
Un' altra cosa da prevedere è la lettura e la verifica della Flash all'inizio o
dopo un reset per determinare se si è verificata una interruzione di un
aggiornamento, che ti potreb.
In realtà basta fare l'erase dell'ultima pagina prima di iniziare a scrivere le
prime della flash, in questo modo se non finisce avrai i dati sempre a 0FFH.
Per l'aggiornamento via web potresti usare qualcosa del genere:
http://www.pira.cz/eng/piracom.htm
 io non l'ho provato perchè uso un programma in VB6 con WebBrowser e MsComm, ma
mi dicono che vada.
--
ciao
  Stefano

 
http://www.pira.cz/eng/piracom.htm
Bello, puo' tornare utile...
Fabio.

Mmmmm, non l'ho capita...
In pratica si tratta di cancellare subito l'ultima pagina del programma, o
semplicemente quella prima del bootloader.
Dal momento che quella sarà l'ultima pagina ad aggiornarsi, se la ricezione
finisce sei sicuro che  il programma è arrivato tutto, altrimenti quella parte
conterrà dei bytes a 0FFH.
Quindi se il bootloader all'inizio (per partire da BootLoader bisogna settare un
fuse) va a leggere quel byte e ci trova 0FFH vuol dire che c'è qualcosa che non
va e comincia a scrivere un messaggio sul display e cerca di mandare al pc un
comando o al modem le stringhe AT...
Naturalmente le routines per scrivere su display o seriale debbono essere nel
bootloader o non puoi essere sicuro che quando il programma le chiamerà
succederà quello che hai previsto, anzi basta che siano shiftate di un byte
perchè succedano cose imprevedibili.
Ad esempio il programma potrebbe essere aggiornato fino a metà, ma la parte
vecchia avrà indirizzi fisici diversi da quella aggiornata.
Altrimenti bisogna fare un calcolo di CRC e poi confrontarlo con quello che fa
il pc, basta fare una somma dei bytes del programma e poi verificarli alla fine
prima di partire.
--
ciao
  Stefano

 male.
Certo, ma la normativa non prevede qualcosa a riguardo (60730 mi
pare)?
Magari se si dovra' certificare mi trovo il lavoro fatto.
Denghiu.
Fabio.

 prima di partire.
Grazie per la spiegazione.
Fabio.