leOS - un semplice OS per schedulare piccoli task

Ops... "Ready", come scordarsi di te ? :cold_sweat:

:wink:

Leo, hai visto questa discussione? --> http://arduino.cc/pipermail/developers_arduino.cc/2012-October/007211.html

No, non l'avevo vista. Non sono iscritto alle mailing-list.
Se hai modo di rispondere, fagli presente che esiste già uno schedulatore :wink: XD

Ne vogliono mettere uno nella futura release dell'IDE, modificando il delay e delaymicrosecond in modo che, mentre si aspetta gli altri task proseguano.

Esempio --> Added general yield()-hook for cooperative scheduling development · cmaglie/Arduino@107c192 · GitHub

Lo sai che in questi giorni stavo pensando proprio a modificare il timer che sugli Atmega ed Attiny gestisce millis per integrare il leOS lì, in modo da non consumare timer extra né interferire con altre librerie? :wink:

È una buona idea far fare tutto il lavoro a delle funzioni richiamate con leOS e lasciare il loop() vuoto se non serve eseguire in continuazione il codice o è meglio lasciare la parte principale in loop() e mettere un delay alla fine?

il famoso Delay2, di cui rivendico la paternita' dell'idea, sara' la funzione piu' importante di Arduino
cioe' se ti serve un delay bloccante userai delay() se ti serve uno non bloccante useray delay2()
senza dover mettere in campo millis ed i suoi giri contorti (per un non programmatore)

a proposito Leo, complimenti per il lavoro pubblicato sull'overflow di millis,
potresti chiedere di modificare il blinkwithoutdelay aggiungendo la tua idea per superare i famosi 50giorni
sarebbe comunque molto bello avere il tuo nome in uno sketch che viene inserito ufficialmente negli esempi dell'IDE

p.s. ma oltre all'articlo sul tuo blog c'e' hai aperto anche una discussione sul forum ?

d407336:
È una buona idea far fare tutto il lavoro a delle funzioni richiamate con leOS e lasciare il loop() vuoto se non serve eseguire in continuazione il codice o è meglio lasciare la parte principale in loop() e mettere un delay alla fine?

I task dovrebbero essere compiti semplici, che occupano poco tempo CPU, in modo da non rallentare l'esecuzione delle altre funzioni basate su interrupt. Se il tuo caso ricade in questo esempio, puoi anche inserire tutto in task e lasciare il loop vuoto. Se hai un compito che invece è molto gravoso, conviene inserirlo nel loop (e qui puoi rallentarne l'esecuzione con un delay).

Testato:
a proposito Leo, complimenti per il lavoro pubblicato sull'overflow di millis,

Grazie :wink:

potresti chiedere di modificare il blinkwithoutdelay aggiungendo la tua idea per superare i famosi 50giorni
sarebbe comunque molto bello avere il tuo nome in uno sketch che viene inserito ufficialmente negli esempi dell'IDE

Non credo che lo faranno mai :stuck_out_tongue_closed_eyes:

p.s. ma oltre all'articlo sul tuo blog c'e' hai aperto anche una discussione sul forum ?

No.

PaoloP:
Leo, hai visto questa discussione? --> http://arduino.cc/pipermail/developers_arduino.cc/2012-October/007211.html

Oggi ho studiato un po' la cosa, ed è una funzione molto più complessa della mia. Essa sfrutta un modulo presente nel SAM3X, il SysTick, un contatore indipendente dai timer del micro a cui hanno agganciato un gestore di task. Ogni task ha un suo tempo computazionale, ed il tutto è gestito dallo scheduler proprio tramite i tick, anche il delay segue lo stesso principio: usano un task che genera i millis, che poi leggono per i ritardi. Insomma, una cosina più raffinata che ovviamente non è replicabile sui Mega perché appunto utilizzano dell'HW dedicato.

PS:
in teoria si potrebbe agganciare il leOS ad un INT esterno o ad un PCINT, ma in questo modo si perderebbe un pin.

Mi sa che tra un po' per il DUE uscirà una sorta di ArduinOS ex-novo... :wink:

tuxduino:
Mi sa che tra un po' per il DUE uscirà una sorta di ArduinOS ex-novo... :wink:

Non credo, penso che non sia questo il desiderio del team di Arduino. Loro sono per le cose semplici, ed un RTOS nel vero senso della parola non è una cosa tanto facile da gestire per un utente di medio livello. E poi non penso che passerà molto tempo prima che progetti quali FreeRTOS o ChibiOS siano resi compatibili con il SAM3X della DUE.

In effetti la mia era più che altro una battuta. Penso che tu abbia ragione.

non penso che passerà molto tempo prima che progetti quali FreeRTOS o ChibiOS siano resi compatibili con il SAM3X della DUE[/quote

Il Chibi l'avevo provato sulla 2009, mi è sembrato interessante anche se non ho approfondito. Credo che la DUE diventerà una piattaforma molto interessante per lo studio dei sistemi operativi grazie alla maggiore potenza della cpu.

tuxduino:
Il Chibi l'avevo provato sulla 2009, mi è sembrato interessante anche se non ho approfondito. Credo che la DUE diventerà una piattaforma molto interessante per lo studio dei sistemi operativi grazie alla maggiore potenza della cpu.

Il problema della DUE è che non è abbastanza potente per poter farci girare un vero SO, e gli RTOS embedded girano tranquillamente anche su chippini insignificanti come i Tiny con 2 kB di Flash, vedi il FemtoOS. Insomma, nulla di nuovo.

Ah, ok. Pensavo che con un chip molto più potente si potesse fare chissà cosa nel campo rtos rispetto a UNO... :cold_sweat:

Diciamo che la gestione ne risulta avvantaggiata per diversi motivi: maggior clock, maggior memoria, 32 bit di potenza, sistema di tick gestito via HW, DMA per un accesso diretto e veloce alla memoria ecc...
Basta vedere appunto la libreria Scheduler creata ad oc per la DUE in men che non si dica

leo72:

d407336:
È una buona idea far fare tutto il lavoro a delle funzioni richiamate con leOS e lasciare il loop() vuoto se non serve eseguire in continuazione il codice o è meglio lasciare la parte principale in loop() e mettere un delay alla fine?

I task dovrebbero essere compiti semplici, che occupano poco tempo CPU, in modo da non rallentare l'esecuzione delle altre funzioni basate su interrupt. Se il tuo caso ricade in questo esempio, puoi anche inserire tutto in task e lasciare il loop vuoto. Se hai un compito che invece è molto gravoso, conviene inserirlo nel loop (e qui puoi rallentarne l'esecuzione con un delay).

Usare un analogRead() e poi stampare un valore su un display con LiquidCrystal non dovrebbe essere troppo gravoso?

e' gravoso :slight_smile:

l'analog read è gravosa (0.2millisecondi circa), stampare su LCD ancora di più.

0.2millisecondi vuol dire che dopo 5000 letture il tuo timer della millis() sballa di 1 secondo

Non tanto il fatto di stamparci sopra, se comunica in i2c sono 100Kbit/s, o 400Kbit/s se modifichi le libreria e il modulo supporta la fastI2c, però il vero problema è che l'esse umano non vede più velociemente di circa 20/50millisecondi, se poi parliamo di leggere arriviamo al secondo e rotto :slight_smile:

nel tuo caso sarebbe da attivare a livello di registri l'interrupt per il completamento della lettura analogica. All'interrupt del leos fai partire la lettura analogica (che lavora in parallelo, quindi non "spreca" cpu), al completamento viene lanciato un interrupt che mette il valore letto in una variaile volatile.

poi un altro task nel leos ogni secondo prende la variabile volatile e la stampa sull'LCD.

Il tempo impiegato dell'I2C, ma ancor meglio dalla SPI (fino a 5Mbit/s se ricordo bene, ma dipende dal modulo), è inifluente. Quello della seriale invece influisce, ma la Serial lavora per interrupt quindi in pratica lo sbattimento di cui sopra è già fatto, devi solo fare attenzione a non riempire il buffer seriale più in fretta di quanto esso non riesca a svuotasi