leOS - un semplice OS per schedulare piccoli task

[Bisbulle]

dunque, secondo te qualcuno sul Forum si era bevuta la storia del "little embedded Operating System" smiley-yell?
Il significato di leO era chiarissimo, i dubbi erano solo su cosa stesse a fare lì una S, sperando tutti che non fosse l'iniziale di un aggettivo/sostantivo arcinoto smiley-mr-green comunque io pensavo "Super", ormai è un titolo che ti spetta a pieno merito smiley-lol
Ottimo lavoro, non ti prometto test perché ormai respiro con la cannuccia fuori dal letame smiley-sad-blue

Concordo.

L'effetto sorpresa si è rivelato poco efficiente.

@Leo: ripeto bel lavoro (e grazie per la risposta!)

[leo72]

Nuova versione 0.0.3. Questa versione introduce la gestione dei task aggiunti allo scheduler. Nello specifico ho introdotto 3 nuovi metodi:

removeTask(nomeFunzione)
pauseTask(nomeFunzione)
restartTask(nomeFunzione)

I metodi hanno nomi autoesplicativi ma riassumo brevemente. removeTask serve a rimuovere permanentemente un task dallo scheduler. pauseTask serve a mettere in pausa un task, mentre restartTask serve a farlo ripartire.

L'utente è tenuto a scrivere il suo codice affinché lo stato del task al momento della messa in pausa, della ripartenza o della sua rimozione sia coerente e/o compatibile con il resto del codice e con il circuito collegato. Mi spiego: se al posto di un led, si pilota ad esempio un transistor che alimenta un altro dispositivo bisogna prevedere il fatto che se il pin resta alto ed il transistor in conduzione, che tale stato sia compatibile con il circuito ed il restante codice. Ma mi sembra logico.

Al momento non mi vengono in mente altre operazioni per questo semplice RTOS. Se avete idee o suggerimenti e se qualcuno riesce a provarlo anche sugli altri micro, ben vengano le sue segnalazioni 

[m_ri]

mhh,forse metti un tipo di ritorno alle tue funzioni,tipo char o bool..almeno sai se ha avuto successo

[leo72]

Sì, ci avevo già pensato, lo farò nella prox 0.0.4 

[m_ri]

inoltre vedo che tra le istruzioni atomiche di arduino c'è lo swap di nibble..quindi volendo potresti implementare un"semaforo non bloccante" o con un certo accrochio renderlo bloccante senza scrasare lo stack..
lo so che forse esagero,ma qlkn vuole passare da iOS a leOS,quindi..   

[leo72]

inoltre vedo che tra le istruzioni atomiche di arduino c'è lo swap di nibble..quindi volendo potresti implementare un"semaforo non bloccante" o con un certo accrochio renderlo bloccante senza scrasare lo stack..

Spiega spiega... perché non sono praticissimo di programmazione di SO quindi voglio capire per bene 

[m_ri]

neank'io sono programmatore di so(sono ancora al poli  )

spiegazione alla cavolo(e molto incompleta):
immagina che una risorsa possa servire solo una richiesta per volta..come fai a dire che solo una richiesta per volta possa accedere ?un modo potrebbe essere: in ogni pezzo di codice che sta per accedere alla risorsa,richiami una funzione test..se ti risponde true allora esegui il codice che usa la risorsa,altrimenti no..
come può essere fatta questa funzione test?
-primo approcio :ho una variabile booleana:se vale 1 è libero e posso entrare(mettendo a false la variabile) ,altrimenti esco o sospendo il processo(non fattibile direttamente con arduino anke x limiti di stack)
DIFETTO:se dopo aver fatto il test con var=true e PRIMA di aver messo var=false viene richiamata una funzione causa interrupt o altro,posso essere fregato..perciò dovrei testare e aggiornare nello stesso momento x essere tranquillo..viene detto Test-and-set..vabbò domani continuo..ora vado a dormire..

[Maurotec]

Penso di avere capito cosa vuole dire m_ri e sono in grado di spiegarlo un po meglio.

Un semaforo si usa nella programmazione concorrente ed è indispensabile per riservarsi una risorsa. Nella fattispecie posso fare un esepio con un pin del microcontroller:

T1 è il task 1 che usa il pin PD2, la funzione che fa è farlo accendere e spegnere tot volte a candenza prestabilita da task 1.
T2 il task 2 che vuole usare anchessa il pin PD2 e scopre che la risorsa (PD2) è locked, allora prende nota di ciò ed al prossimo turno prova nuovamente a vedere se la risorsa e libera.

Per complicarsi la vita i task con priorità 0 possono chiedere al gestore di risorse lo sblocco immediato della risorsa, ovviamente il gestore non sblocca nulla ma comunica al task che tiene locked la risorsa di liberarla subito, allora la risorsa provvederà a terminare l'uso in modo non dannoso (metti che sta scrivendo su un file) ed infine libera la risorsa.

Qui davvero c'è di sbizzarrirsi con la fantasia, pensa di prenotare una risorsa e quindi di tenere una lista di task che hanno prenotato la risorsa x.

Solitamente il semaforo in C++ è una classe che ogni task deve ereditare, sempre che questo task sia una istanza di classe task. Mentre se è un semplice puntatore a funzione si deve fare creare istanza di classe dentro la funzione/task.

Penso sia troppo, però se si trova il modo di bloccare l'uso della seriale già e tanto, così entrambe i task possono accedere alla seriale.

Occhio che non ho guardato il code, sto solo spiegando i semafori.

Ciao.

[leo72]

Uhm... ho capito.
In un microcontrollore il 90% delle cose viene fatto tramite pin, quindi si potrebbero prevedere 3 byte da usare come semafori per impostare lo stato di ognuno dei 20 pin di I/O gestibili sull'Arduino UNO (ce ne vogliono di più per la MEGA, ma per ora lasciamo stare).
Se io metto ad 1 il bit corrispondente ad uno specifico pin, un task sa che quel pin è impegnato da un altro task. Se un task che richiede l'accesso ad un pin lo trova occupato, restituisce il controllo allo scheduler. Però va implementato un meccanismo secondo il quale lo scheduler dovrebbe registrare il tentativo di accesso a quel pin in modo che, non appena trova il pin libero, lo prenoti per il task che in precedenza lo ha trovato occupato altrimenti si corre il rischio che quel task aspetti un sacco di tempo prima di poter accedere al pin. Non è impossibile... mumble mumble... resta da capire se il gioco vale la candela....

[dalubar]

Leo, se ti interessa approfondire questo aspetto dell'informatica non posso che consigliarti un libro davvero eccezionale, che spiega in modo chiaro, esaustivo e con centinaia di esempi pratici scritti in C, tutte le problematiche della progettazione "vera" e reale di un sistema operativo; inoltre spiega la maggior parte dei meccanismi adottati dai SO più comuni, quali Linux, Unix, Windows evidenziandone le differenze.

Il titolo è "I moderni Sistemi Operativi", l'autore è una garanzia assoluta: Andew S. Tanenbaum. Credo che tale capolavoro non dovrebbe mancare nella libreria di un professionista dell'informatica.
Un "malloppo" di quasi 1000 pagine che è una vera miniera di sapere (anche "pratico") che in maniera assolutamente non noiosa (all'autore piace fare anche battute per descrivere alcuni paradossi dell'informatica) ti svela dettagliatamente il funzionamento di Monitor, Semafori, Schedulazione dei processi e thread, senza parlare della gestione della memoria, file system...e tanto tanto altro.

Posso solo dirti che quando, anni fa, lessi per la prima volta la parte relativa alla schedulazione dei processi, tanto era scritta bene che mi venne la voglia di scrivere un SO nuovo di zecca (in realtà è proprio quello che ha fatto l'autore).
Anche se sono passati anni dalla sua scrittura, i concetti e soprattutto molti degli algoritmi alla base della gestione di un SO sono rimasti pressochè identici.

[leo72]

Ti è venuta voglia.... e sicuramente qualcosa avrai scritto 
Per che sistema era?

PS:
cerco il libro... 

[dalubar]

L'informatica (come la matematica, del resto) è un arcipelago fatto di tantissime isole, alcune anche molto distanti l'una dall'altra. Purtroppo per molti comuni mortali occorre fare delle scelte mirate e decidere, in qualche modo, su quale isola dedicare i propri sforzi e approfondire così la propria conoscenza.
A quei tempi avevo (e ho tutt'ora) una smodata passione verso le basi di dati e la loro progettazione, per cui "corteggiavo" tantissimo Oracle (molto meno DB2 e il suo linguaggio PL/SQL, cosa che mi ha permesso di scrivere, successivamente, diverse applicazioni dedicate.

I SO mi affascinano e, grazie a quel libro e altre pubblicazioni, conosco molti dei loro meccanismi di funzionamento (ad es. si fa presto a dire "gestisco la RAM"! Il famigerato Cap. 4 dedicato alla gestione della memoria è uno di quelli che ti fa capire quanta complessità ci possa essere dietro al semplice caricamento di un'applicazione) ma francamente non mi è mai passata per la testa l'idea "reale" di scrivere un SO (e con tutta probabilità credo che non ne sarei neppure capace).
Preferisco, invece, rimanere estasiato dalla fantasia e genialità con la quale i progettisti "pionieri" hanno risolto i tantissimi problemi di realizzazione che stanno alla base del funzionamento dei SO e che ora ci permettono di usare un PC come fosse poco più di un elettrodomestico. 

[leo72]

OK. Su BOL ho trovato il libro, terza edizione del 2009 scontato a 48€ ca.
Mi sa che lo compro 

Aggiornamento per leOS:
nuova versione 0.0.4.
Mi sono accorto di aver usato per sbaglio un tipo unsigned int per il conta ms interno. Al suo posto ho messo un bell'unsigned long lon così ora ho un contenitore a 64 bit che andrà in overflow fra 584.942.417 anni!!! Credo che bastino, no? 

[menniti]

Legacy, fammi capire (ma non ho letto con attenzione il tuo post), la frase

Una delle cose che mi ha fatto venir voglia di scrivere quel libro

significa che tu sei "Andrew S. Tanenbaum"? 

[leo72]

Sì, così è molto chiaro, grazie dell'esempio perché è chiarificatore.
Però credo che progetti complessi siano già in circolazione (FreeRTOS, FemtoOS, ChibiOS ecc...) ed arrivare a quel livello di complessità è completamente fuori dalle mie capacità. Né vorrei neanche reinventare la ruota, che se ne fa la gente di un simil-OS quando ci sono SO seri in circolazione? Inoltre le risorse di un microcontrollore sono limitate, bello tutto il discorso sui task che si contendono le risorse e sullo scheduler che sta lì a guardare quale di loro abbia la priorità... ma alla fine... "cui prodest"?

Io voglio solo fare un qualcosa che sia: facile da usare, utile, non abbia un impatto stratosferico sulle risorse.

Facile da usare: l'80% degli utenti di Arduino sono utenti che si avvicinano per la prima volta alla programmazione. Vogliono cose "semplici", non posso fornirgli un minestrone di C/C++ con schedulatori deadlockanti che girano per il loro codice con classi, metodi, mal di testa vari  

Utile: il 50% dei post che si vedono pubblicati sul forum sono inerenti a delay che bloccano il codice, a capire come eseguire 2 cose insieme con millis e simili. leOS è qui per loro: mette un paio di chiamate al metodo addTask per far lampeggiare il leddettino o fare la letturina sul pin digitale e l'utente è felice e contento. Senza stare a spiegare che un micro-pizzico rallenterà l'esecuzione del codice perché ogni task fermerà il loop principale. Non glielo diciamo, tanto lui vede che il loop (anche se rallentato dell'1%) va lo stesso ed è contento  

Non abbia un impatto sulle risorse: leOS così com'è non mi pare che consumi molte risorse.
Il BlinkWithoutDelay consuma 1078 byte, il flash di 1 led usando 1 task con leOS 2276 byte, 2 flash di 2 led con 2 task 2326 byte, 50 byte di più. Quindi il core di leOS sono circa 1kB in più. Se pensiamo che però così ho aiutato tutti gli utenti dei 2 precedenti punti, il leOS ha la sua ragione di essere.  XD

Ti ringrazio ancora comunque per tutte le info che mi stai dando, sono veramente utili. Mi fai capire che leOS è un poverello rispetto a veri SO e mi dai gli spunti per poterlo migliorare