leOS - un semplice OS per schedulare piccoli task

Testato:
le librerie vengono importate direttamente dallo .zip ma non vanno in libraries dell'IDE ma in una cartella dentro alla cartella Sketch. E' una scelta intelligente perche' quando si cancella l'ide vecchio non si perde nulla, ne' gli sketch ne le librerie

Se ti ricordi io ho sempre suggerito di mettere le librerie di terzi proprio sotto /sketchbook/libraries per evitare i problemi che hai menzionato te :wink:

yes, quando lessi la caratteristica dissi, questo lo ha gia' inventato Leo XD

tu hai capito cosa intende Lesto ? mi sembra che dica che in alcune condizioni questa idea crea problemi ?

Testato:
tu hai capito cosa intende Lesto ? mi sembra che dica che in alcune condizioni questa idea crea problemi ?

So a cosa si riferisce, ed è in pratica una specie di sua personale "guerra santa" nata qualche mese fa :stuck_out_tongue_closed_eyes:
Se non ricordo male, propose anche un hack per sistemare quello che a lui pareva un bug dell'IDE, che cioè secondo i suoi test pareva ignorare le cartelle /utility contenute in una lib in fase di compilazione, quando l'IDE estraeva dalle cartelle i file .cpp ed .h
Ora di preciso non mi ricordo cos'è che a lui non tornava né in che condizioni si manifestava il problema, per cui sarebbe meglio aspettare un suo intervento :wink:

PS:
vedo con piacere che nessuno ha provato il leOS2 2.1... ottimo... :sweat_smile: :sweat_smile:

guarda, sinceramente alla luce dei nuovi ide devo capire anche io cosa succede, però prima era che la utility era l'unica cartella NON ignorata, e importata in modo non standard

Nuove versioni delle libreries (leOS 1.0.3 e leOS 2.1.1) che aggiungono la possibilità di far eseguire un task nel momento stesso in cui viene aggiunto allo scheduler. Per far ciò basta usare la parola chiave SCHEDULED_IMMEDIATESTART come stato del task al momento dell'aggiunta allo scheduler.

Ecco un esempio di utilizzo:

myOS.addTask(miaFunzione, intervallo, SCHEDULED_IMMEDIATESTART);

In questo modo il task miaFunzione sarà eseguito subito e poi dopo ogni intervallo.
Prima invece un task veniva eseguito la prima volta solo dopo il tempo stabilito per intervallo.

PS:
sul forum internazionale gli RTOS in queste ultime settimane sono spuntati come funghi :stuck_out_tongue_closed_eyes:

RTuinOS
Avr-OS
SCoop

Più i soliti port di FreeRTOS e ChibiOS/RT per Arduino fatti da fat16lib.

Letture per le feste :slight_smile:

tuxduino:
Letture per le feste :slight_smile:

L'ultimo arrivato RTuinOS, ha un PDF da 40 pagine :sweat_smile:
Lo sto leggendo la sera.

Cmq dico una cosa. Tutti gli RTOS che ho visto sono sicuramente belli, funzionanti, veramente RT, con prelazione, cooperativi ecc... ma facili come il leOS nessuno :wink:
Vabbè che non è un RTOS però sfido a trovare uno scheduler più facile da usare :stuck_out_tongue:

Ogni scarrafone... :smiley:

Non l'ho ancora usato in modo estensivo, ma ho un tarlo che mi rode le cervela... ed è il fatto che il codice utente di fatto è una ISR... Qualche problema lo dovrà pur dare, no ? (si scherza... :slight_smile: )

sì ma più o meno aggirabile, vedi discussione precedente

tuxduino:
Ogni scarrafone... :smiley:

Non l'ho ancora usato in modo estensivo, ma ho un tarlo che mi rode le cervela... ed è il fatto che il codice utente di fatto è una ISR... Qualche problema lo dovrà pur dare, no ? (si scherza... :slight_smile: )

Se dentro alla ISR ci infili di tutto, sostituendo in pratica il loop principale con un task, allora la risposta è sì. Se usi i task per piccoli compiti, di problemi non dovresti averne.

Considera che gli RTOS che ho citato (avr-os, RTuinOS, SCoop) consumano ben 256 byte di RAM per ogni task! Una cifra che li preclude all'utilizzo sui piccoli Tiny, dove alle volte la Ram è pari o inferiore a quest valore. Il leOS invece funziona egregiamente anche in queste condizioni

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

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.

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