Newsgroup: it.hobby.elettronica.digitale
Titolo: bootloader via radio

Ciao,
ho due schede basate su PIC (serie 16 o eventualmente 18) che comunicano 
tramite transceiver RF (PAN2350, le informazioni vengono scambiate con 
due linee: dati e clock). Una delle due schede è connessa al PC mediante 
USB.
Non sono praticissimo di bootloader pertanto vi domando quale possa 
essere la soluzione migliore per poter aggiornare il firmware dell'unità 
remota.
In pratica, da PC vorrei modificare il firmware di entrambe le schede. 
Per quella connessa al PC non ci sono grossi problemi credo in quanto la 
comunicazione avviene tramite UART (e CP2102). Quindi il BL andrà a 
leggere direttamente dai pin tx/rx. Ma per quella remota come si fa?
Marco / iw2nzm

 leggere direttamente dai pin tx/rx. Ma per quella remota come si fa?
Come avrai intuito modificare il codice via radio è pericoloso, corri il 
rischio di dover procedere manualmente nel caso la comunicazione dovesse 
interrompersi.
Non conosco il bootloader dei PIC, ma, in generale, la parte remota non 
differirà poi molto da quella locale: riceverai i dati via radio, li 
posizionerai in un buffer grande quanto una pagina di flash e una volta 
riempito provvederai a flashare la pagina, e così avanti fino alla fine 
delle pagine.
Come già detto, questo sistema è rischioso perchè se si interrompe la 
comunicazione devi riprogrammare il dispositivo manualmente.
Un soluzione a questo problema potrebbe essere quella di downloadare 
tutto il nuovo firmware in una memoria buffer locale e solo a download 
completo provvedere alla riprogrammazione.
Come memoria locale potresti usare un eeprom, che sono piccole, costano 
poco ed ultimamente sono anche abbastanza capienti.
A download completato, attivi il bootloader, che ha il solo compito di 
leggere i dati dalla eeprom e riprogramamre il dispositivo.
Spero di esserti stato di aiuto
ciao.

 completo provvedere alla riprogrammazione.
mmm... a questo avevo pensato ma non sapevo come si potesse gestire 
l'inizio dell'aggiornamento.
In pratica metto sulla scheda remota una classica eeprom i2c (anche una 
ram sarebbe sufficiente volendo, ma non so se si trovano di tipo 
seriale) sufficientemente grande. Poi:
+ alla ricezione del comando di update, comincio a riempire la eeprom 
con i dati ricevuti
+ al termine verifico la correttezza del download (es. parità, crc, ecc...)
+ dico al bootloader di prelevare i dati dalla eeprom i2c e di 
riprogrammare il PIC
E' sull'ultimo punto che ho dubbi!
Grazie!
Marco / iw2nzm

Per quanto concerne la corruzione dei dati in caso di mancato link non
è un problema di per se... come giustamente dici il bootloader non ne
viene minimamente intaccato in quanto risiede in una zona che lui
stesso per ovvi motivi non va sovrascrivere :) In un caso del genere
basta rimandare il sorgente.
La questione da risolvere è... come attivare il bootloader?
I normali bootloader con link fisico si attivano semplicemente
resettando il micro. Il sistema è molto semplice... da PC lanci il
software di interfaccia che si prepara a mandare il sorgente mettendosi
in ascolto sulla seriale (dove hai il PIC). A questo punto resetti il
micro... resettando il micro le prime istruzioni che paratono sono
quelle del bootloader il quale verifica (con timeout) se sulla seriale
c'è appunto qualcuno pronto a spedigli il sorgente, se è così entra
nella propria routine di caricamento richiedendo byte dopo byte il
sorgente al PC. Finito il caricamento questo fa un bel salto alla prima
locazione del programma vero e proprio ed è finita.
Il bootloader quindi entra sempre in funzione ad ogni reset del micro
ma se entro un timeout prestabilito (alcuni ms) non sente la presenza
del proprio programma lato PC salta direttamente al programma vero e
proprio.
Alex

Riflettendoci un attimo non è difficile caricare in condizioni normali
il programma perchè durante l'esecuzione di quello "vero" predisponi
una routine che ricevuto un comando causa il reset del micro (e subito
di poni in attesa sul PC per l'invio del sorgente)... con un Jump 0
oppure controlli la linea MCLR con un pin oppure sfrutti il WDT . Il
problema è.... la volta che il software si è caricato alla cavolo...
come fai la volta successiva a provocare il "reset"? :) Uno spunto su
cui riflettere...
Alex

 cui riflettere...
Beh, se il firmware contiene errori, non dovrebbe nemmeno funzionare. In 
quel caso il wdt (impostato con i fuse, quindi hardware) dovrebbe 
continuamente resettare il micro.
Se così non fosse, allora conviene usare un buffer e verificare la 
correttezza dei dati prima di procedere!
Marco / iw2nzm

 di un comando di update.
Come ti hanno già detto, il bootloader di solito si attiva da solo dopo 
ogni reset. In pratica, il tuo programma, invece di partire dal normale 
vettore di reset, parte da un'altra locazione di memoria in cui risiede 
il bootloader. Il boot farà i controlli del caso (presenza sulla seriale 
la di caratteri speciali; pressione di combinazioni di pulsanti, ecc...) 
e provvederà alla riprogrammazione del firmware.
Se, per esempio, scegli la strada di usare la memoria i2c buffer, 
potrebbe controllare se in una speciale locazione definita sia presente 
un "magic number", cioè un valore particolare, scritto dal software che 
ha riempito la memoria, in modo da segnalare al boot di iniziare un 
aggiornamento.
Purtroppo non posso esserti d'aiuto nel dettaglio perchè non conosco i 
PIC, devi consultare la documentazione del micro per conoscere come 
programmare i fuse e le isctruzioni da usare per scrivere in flash.
ciao

 continuamente resettare il micro.
Se il watchdog è programmato con i fuse, si attiverà di sicuro, ma tieni 
presente che il tuo firmware programmato alla cavolo potrebbe contentere 
loop che resettano il watchdog di continuo, vanificando la sua presenza.
Secondo la statistica questo è un evento molto improbabile, secondo la 
legge di Murphy ti succederà quando dimostrerai il funzionamento del tuo 
sistema al tuo capo/committente/cliente, con probabilità direttamente 
proporzionale ai danni che questo potrebbe causare (perdita di 
tempo/perdite di denaro/licenziamento) :)

 ha scritto nel messaggio
news:drffco$rpm$1...@nnrp.ngi.it...


 controllo del sw???...
Anzitutto grazie a tutti per gli interessanti interventi!
Il PIC montato sulla scheda in effetti ha già il suo del da fare per 
acquisire tutti i dati dei vari sensori. Potrebbe essere a questo punto 
l'ideale affiancargli un PICcino :) con il compito di 
memorizzare/verificare il codice scaricato via RF e di riprogrammare il 
fratellone.
Ultimo dubbio poi mi metto a raccogliere le varie idee emerse: in questo 
caso il PIC che deve essere aggiornato ha ancora bisogno del bootloader 
oppure il fratellino lo riprogramma come se fosse un ICSP? In ogni caso 
userei a questo punto la UART tra i due micro così da sfruttare i vari 
bootloader già collaudati presenti in giro e il reset può avvenire hardware.
Grazie ancora!
Marco / iw2nzm
ps. visto che è il prototipo ci sta anche di usare due PIC... poi una 
volta sistemato per benino tutto il firmware si vedrà se è necessario 
mantenere un aggiornamento flessibile del firmware oppure no.

 tempo/perdite di denaro/licenziamento) :)
Eh eh... vero! Mi stavo scordando di Murphy... :)
Marco / iw2nzm

 continuamente resettare il micro.
Come ti hanno detto, dovrebbe andare, ma c'è una remota possibilità che 
il programma faccia pasticci e inibisca il WDT.
Mia idea:
Il bootloader come prima cosa sostituisce il programma "vero" con uno 
composto da una singola istruzione, che resetta sistematicamente il 
micro. In questo modo se ci sono problemi il bootloader verrà sempre 
attivato in continuo.
Il bootloader prosegue scrivendo il programma DOPO questa istruzione, in 
pratica scrive tutti i byte meno il primo, sostituito appunto da un jump 
alla locazione zero, alla fine calcola la checksum (o CRC o quello che 
vuoi) del firmware ricevuto e SE corretto allora memorizza anche la 
prima istruzione del programma.
...:::Zmaster:::...

 
Questo non risolve il problema ma semplicemnte lo sposta da un'altra 
parte, aumentando i costi.
Se uso 2 PIC per risolvere il problema dello spazio limitato, significa 
che ho commesso un errore di progetto sovrastimando la dimensione del 
firmware, e allora userň un micro piů capiente.
ciao
P.S.
Di solito si risponde mettendo prima il testo quotato, tagliando le 
parti non pertinenti. in questo modo rendi piů comprensibile il tuo post 
e fai risparmiare banda a chi scarica le news offline.

> Mia idea:
Altra mia idea, ancora più semplice e pulita:
Il bootloader tiene su eeprom interna del micro o altra memoria non 
volatile un bit (byte) che chiamiamo "stato".
il bootloader al reset del micro controlla se si sta cercando di 
aggiornare il firmware e in tal caso azzera quella variabile e da inizio 
alla procedura di download. In caso di errore di timeout/wrong checksum 
si resetta, altrimenti setta "stato" a 1 e resetta.
Se non vi è richiesta di aggiornare il bootloader controlla "stato": se 
è a 0 vuol dire che per qualche motivo non è presente un firmware valido 
e quindi da inizio alla procedura di download, se è a 1 il firmware è 
valido e lo esegue.
...:::Zmaster:::...

 ha scritto nel messaggio
news:drfh0t$sf2$1...@nnrp.ngi.it...

...ok..!!mi ritiro...!!!
Steno