leOS - un semplice OS per schedulare piccoli task

leo72:

pablos:
Lo sketch di esempio leOS2_use_of_reset.ino mi ha creato per 2 volte il blocco dell'AVR sul mio 2560, entrambe le volte ho dovuto applicare la manovra di emergenza.

ciao

Con che versione?
Preciso che la 2.0.90 aveva la gestione del reset buggata. La 2.1.0 ha rimediato a quei problemi.

Pablos, potresti confermarmi la versione che stai usando?
Non avendo una MEGA, non posso riprodurre l'eventuale bug :sweat_smile:

versione che ho provato 2.1.1, ho preso l'ultima qui
http://www.leonardomiliani.com/?p=516

ciao

pablos:
versione che ho provato 2.1.1, ho preso l'ultima qui
leOS, un semplice SO per Arduino – Leonardo Miliani

ciao

OK. Ti ringrazio. Investigherò il problema.

Se hai bisogno, mi mandi la lib modificata e te lo provo... ciao

pablos:
Se hai bisogno, mi mandi la lib modificata e te lo provo... ciao

OK, grazie dell'aiuto. Prima però mi studio il datasheet: devo capire cosa c'è di differente nella gestione del WD tra il 2560 ed il 328.

pablos:
Lo sketch di esempio leOS2_use_of_reset.ino mi ha creato per 2 volte il blocco dell'AVR sul mio 2560, entrambe le volte ho dovuto applicare la manovra di emergenza.

ciao

Ho studiato un po' la questione e sono giunto alla conclusione che il problema nasca dal bootloader della MEGA.
Per resettare il microcontrollore, la leOS2 utilizza lo stesso Watchdog: se si accorge che un task si blocca, aspetta il timeout e poi poi il Watchdog in modalità System Reset con un tempo di attesa di 30 ms, che genera appunto un reset del micro dopo tale periodo. Una volta riavviato lo sketch, la prima cosa che mi preoccupo di fare è il reset del circuito di Watchdog per evitare che resti acceso. Sull'Arduino UNO tale compito è facilitato dal fatto che il bootloader utilizza il Watchdog per impostare il tempo da attendere prima che qualcosa arrivi sulla seriale: se passa tale tempo senza arrivo di dati, resetta nuovamente il micro e fa partire subito lo sketch utente.
L'Arduino MEGA lavora invece in modo differente, e non inizializza il watchdog. Può essere che il circuito del watchdog resti attivo e continui quindi a resettare il microcontrollore. Prova aumentando il tempo di attesa prima del reset modificando la funzione reset() nel file leOS2.ccp (righe 229-234):

//reset the MCU
void leOS2::reset(void) {
    wdt_disable();
    wdt_enable(WDTO_30MS); //<--- MODIFICA QUESTO
    while(1){}; //wait for reset
}

Prova con
WDTO_4S
WDTO_2S
WDTO_1S
WDTO_500MS
WDTO_250MS
WDTO_120MS
WDTO_60MS

ecc...
Parti con un valore alto e guarda se riesci a superare il tempo che attende il bootloader. Ad occhio, ti serve un tempo pari o maggiore di 1 secondo, ma non ne sono certo: il codice del bootloader non è molto chiaro.
Se ce la fai, abbassa tale valore finché non ritorni ad avere il blocco della scheda.

Se non funziona neanche così, devo pensare ad un'altra soluzione.

Ok, ho in test uno sketch, appena termina carico il tuo.

Io lo avevo caricato per curiosità e ho notato il blocco, per la verità non so nemmeno a cosa serva XD XD
Un po' come con le cose nuove, si spacchettano, si attacca la spina, si premono un po' di bottoni e poi si leggono le istruzioni :wink:

ciao

pablos:
Ok, ho in test uno sketch, appena termina carico il tuo.

Io lo avevo caricato per curiosità e ho notato il blocco, per la verità non so nemmeno a cosa serva XD XD
Un po' come con le cose nuove, si spacchettano, si attacca la spina, si premono un po' di bottoni e poi si leggono le istruzioni :wink:

ciao

E' una caratteristica secondo me molto interessante, che si può anche utilizzare in altri ambiti, ossia anche come semplice funzione anti-freeze (se uno non ha nessun task da far eseguire in background).

Nella sua essenza originale tale funzione serve a controllare se un task si sia bloccato. Ogni volta che il watchdog va in overflow viene lanciato un segnale di reset. La ruotine che intercetta il reset controlla se c'è un task in esecuzione. Se c'è, decrementa un contatore che rappresenta il timeout passato dall'utente in fase di setup. Se tale timeout va a zero prima che il task termini la sua esecuzione, significa che si è bloccato ed ha conseguentemente bloccato tutto il micro. A questo punto, il watchdog lancia un reset e pone fine al problema :wink:

Però possiamo usarla anche come antiblocco del codice principale. Prendiamo ad esempio un task lanciato ogni secondo che controlla se una certa variabile di sistema è su un determinato valore. Se la trova ad esempio su false, la rimette a true ed esce mentre se la trova a true resetta il micro.
Nel loop principale l'utente la imposta a false ad ogni ciclo. Va da sé che se il loop si blocca, tale variabile non può essere impostata a false. Quindi il task di controllo, vedendola a true, resetta il micro.

Questa mi potrebbe interessare :wink:
Ho provato diversi esempi con reset via software, ma nemmeno uno funzionava.
Avevo pensato a un circuito esterno RC che controllasse l'attività di un pin, in caso la frequenza va a zero per n secondi fa il reset.
Se il tuo funziona, potrebbe essere molto utile su schedine dove scarseggia la presenza di un operatore.

ciao

Se il tuo funziona, potrebbe essere molto utile su schedine dove scarseggia la presenza di un operatore.

L'uso "standard" del watchdog, supponendo per un attimo che non ci siano bootloader tra i piedi :slight_smile: è proprio questo: il programma inizializza i registri opportuni e fa partire il WDT. Nel ciclo principale, che viene eseguito periodicamente, il WDT viene resettato, cioè riportato al valore iniziale. In questo modo gli si impedisce di arrivare zero e resettare il micro.

Se il programma principale si blocca, per qualsiasi motivo, allora il reset del WDT non viene più eseguito, il timer raggiunge lo zero e il micro viene resettato, come se si operasse sul pin di reset. In questo modo il programma riparte. Il tutto senza che un operatore debba fare alcunché.

A quanto detto da tuxduino, aggiungo che io uso una modalità differente.
Quella da lui descritta è la modalità "system reset", che resetta appunto il micro. Nella modalità "interrupt" invece viene semplicemente sollevato un interrupt intercettabile da una ISR.
La terza modalità è quella più figa. "Interrupt, then system reset".
Inizialmente viene sollevato un interrupt: soccessivamente viene resettato il microcontrollore se non viene reimpostato l'interrupt per il successivo overflow del contatore del watchdog.

Contando gli interrupt posso eseguire un conto alla rovescia: passato il timeout predefinito, non reimposto più il watchdog per risollevare l'interrupt ed attendo il successivo reset.

(un giorno o l'altro qualcuno dovrà pur distillare una piccola enciclopedia da questo megathread 8) )

tuxduino:
(un giorno o l'altro qualcuno dovrà pur distillare una piccola enciclopedia da questo megathread 8) )

Dì la verità, gli argomenti che tratto sono sempre interessanti :wink:

//reset the MCU
void leOS2::reset(void) {
wdt_disable();
//wdt_enable(WDTO_30MS); //riga originale blocco
//wdt_enable(WDTO_4S); //blocco 2560
//wdt_enable(WDTO_2S); //blocco 2560
//wdt_enable(WDTO_1S); //blocco 2560
//wdt_enable(WDTO_500MS); //blocco 2560
//wdt_enable(WDTO_250MS); //blocco 2560
while(1){}; //wait for reset

chiaramente chiudendo e riaprendo a ogni cambiamento l'IDE, la prima volta lo scrive, poi non riesco più a caricare nulla se non riaccendendo arduino tenendo premuto il reset ecc ecc

pablos:
//reset the MCU
void leOS2::reset(void) {
wdt_disable();
//wdt_enable(WDTO_30MS); //riga originale blocco
//wdt_enable(WDTO_4S); //blocco 2560
//wdt_enable(WDTO_2S); //blocco 2560
//wdt_enable(WDTO_1S); //blocco 2560
//wdt_enable(WDTO_500MS); //blocco 2560
//wdt_enable(WDTO_250MS); //blocco 2560
while(1){}; //wait for reset

chiaramente chiudendo e riaprendo a ogni cambiamento l'IDE, la prima volta lo scrive, poi non riesco più a caricare nulla se non riaccendendo arduino tenendo premuto il reset ecc ecc

Allora il problema è il bootloader, come temevo, che non usando il WDT, lo lascia attivo.
La cosa che mi fa pensare è qui:
http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
si legge:

Note that for newer devices (ATmega88 and newer, effectively any AVR that has the option to also generate interrupts), the watchdog timer remains active even after a system reset (except a power-on condition), using the fastest prescaler value (approximately 15 ms). It is therefore required to turn off the watchdog early during program startup

Quello che ti ho chiesto di fare è appunto di impostare un tempo superiore ai 15 ms, che doveva escludere il problema del watchdog che restava attivo. Ma così però non è.

Pablos, prova la versione allegata.
Ho riveduto la lib un po', aggiungendo maggiori setup per rendere l'operazione di disattivazione del WDT quanto più uguale a quanto scritto sul datasheet.

Se anche così non va, senza una MEGA in mano non so. L'unica alternativa che posso provare è la sostituzione della funzione di reset che ho scritto con il classico jump $0000 però preferivo il reset col WDT, perché è fatto a livello HW e quindi sicuramente più efficace di un semplice salto alla 1a istruzione del codice.

PS:
questa stessa versione funziona sulla Leonardo, che ha un bootloader che attende ben 8s prima di proseguire ma anche in questo caso viene resettato il watchdog subito.

leOS2.cpp (10.7 KB)

Questo non lo inchioda subito, il pin 13 lampeggia per un po' 5-6 secondi poi si ferma rimane fisso e da li in poi si blocca, entro quei secondi però riesco a riscrivere lo sketch, immagino che poi faccia il reset e non si rianima più :slight_smile:

Se non hai la scheda capisco che sia difficile ... bhe ci hai provato, grazie lo stesso

PS Ma per fare un reset ci vogliono tutte quelle istruzioni? .... :grin:

ciao

pablos:
Questo non lo inchioda subito, il pin 13 lampeggia per un po' 5-6 secondi poi si ferma rimane fisso e da li in poi si blocca, entro quei secondi però riesco a riscrivere lo sketch, immagino che poi faccia il reset e non si rianima più :slight_smile:

Non so le tempistiche del bootloader della MEGA. Comunque, se con questa versione la scheda non si inchioda subito allora prova ad aumentare nella ruotine reset() il tempo di attesa con wdt_enable(WDTO_4S) oppure WDTO_8S) per esempio.

PS Ma per fare un reset ci vogliono tutte quelle istruzioni? .... :grin:

Tutte quelle istruzioni ci vogliono per poter modificare i parametri del watchdog: 1) in maniera tale che le modifiche siano prese (per alterare il WDT, devi prima scrivere ad uno logico 2 particolari bit del suo registro, dopodiché entro 4 cicli di clock modificare i bit che vuoi alterare); 2)senza che questo venga alterato in un modo tale che poi si metta a resettare la scheda di continuo il micro.

Poi, ripeto. Si può anche mettere un jmp$0000 e via, ma così non si ha un vero reset HW.
Cmq se puoi fare la prova che ti ho suggerito, mi faresti un piacere.

No niente nemmeno con quei 2 valori wdt_enable(WDTO_4S) oppure WDTO_8S, si inchioda esattamente dopo 10 secondi penso a causa questa linea

myOS.addTask(reset, myOS.convertMs(10000)); //add a task to be executed after 10 seconds