leOS - un semplice OS per schedulare piccoli task

astrobeed:

leo72:
Modesto, vero? :stuck_out_tongue:

Guarda che l'avevamo capito tutti il chiaro riferimento al tuo nome e lo sforzo incredibile per trovare un acronimo compatibile :grin:

+1 :smiley:

comunque bravo! bel lavoro:)

Spero di non andare OT ma volevo sapere solo una cosa, nell esempio di test Dell leOS il
Blink dei led è gestito tramite un istruzione del genere:
Led1status = ^1;
Ma come funziona? Non ho trovato nessuna documentazione riguardo il ^ qualcuno potrebbe linkarmi o spiegarmi qualcosa?

Grazie!

Nik_90:
Spero di non andare OT ma volevo sapere solo una cosa, nell esempio di test Dell leOS il
Blink dei led è gestito tramite un istruzione del genere:
Led1status = ^1;
Ma come funziona? Non ho trovato nessuna documentazione riguardo il ^ qualcuno potrebbe linkarmi o spiegarmi qualcosa?

Grazie!

L'operatore ^ corrisponde ad effettuare l'operazione XOR tra i bit, quindi quando la variabile Led1status vale 0 applicando XOR con 1 il valore diventa 1, viceversa XOR di 1 con 1 da come risultato 0

Ciao

--> http://www.cplusplus.com/doc/tutorial/operators/

Ah ecco cos'era.. Ho capito perfetto grazie mille!

MauroTec:
Sei proprio un hacker, e lo si vede anche da questo nome originale e ti consiglio di lavoraci ancora un poco.

Tempo fa hai scritto che un hacker non si definisce tale per cui se se tu che mi chiami hacker allora son convinto di esserlo :wink:

Dai anche una occhiata a come spostare il puntatore PC, come salvare la situazione nello stack e come fare la cosa
contraria e allora sei ad un passo dal kernel premptive.

Arriverei però a tentare di ricreare ciò che già esiste (es.: FemtoOS). Non è nei miei intenti, soprattutto di quelli attuali perché le mie conoscenze non mi permettono di arrivare così in profondità lato programmazione :sweat_smile:

Io però non saprei dove mettere le mani, se studi e vuoi condividere può essere che impariamo qualcosa tutti quanti sugli RTOS.

Ciao.

Ce ne vuole ancora un bel po', ad iniziare da un bel libro :wink:

Nik_90:
Appena provata con il tuo esempio! E' fantastica complimenti!! :slight_smile:

Grazie, molto gentile :wink:

astrobeed:

leo72:
Modesto, vero? :stuck_out_tongue:

Guarda che l'avevamo capito tutti il chiaro riferimento al tuo nome e lo sforzo incredibile per trovare un acronimo compatibile :grin:

:sweat_smile: :sweat_smile:

p.s.
Bel lavoro, complimenti.

Ti ringrazio, i tuoi complimenti sono moooolto ben accetti :wink:
Ho provato a tenere il tutto molto semplice, se noti l'aumento del consumo delle risorse è contenuto.

@legacy:
hai perfettamente ragione, e l'ho anche esplicitamente ammesso:

leo72:
Il mio più che un RTOS è uno schedulatore, se vogliamo proprio dirla tutta perché non ha nessuno strumento degli RTOS per la gestione dei task. A cominciare dal fatto che non è un SO di tipo preemptive per cui se un task si blocca, si blocca tutta la baracca XD

Quindi posso solo dirti grazie per le critiche ma sapevo già che me le sarei attirate addosso perché scrivere RTOS avrebbe fatto venire il mal di pancia a qualcuno. Però ero anche certo che questo titolo avrebbe fatto capire immediatamente di cosa si stava parlando, più di un "un semplice schedulatore": la gente sa cos'è un RTOS meno cos'è uno schedulatore. :wink:

leo72:
PS:
vi svelo una cosa.... leOS non sta solo per "little embedded Operating System". Siccome sono molto egocentrico, è anche un gioco di parole sul mio nome "leo" :sweat_smile: :sweat_smile: leoS però si capiva troppo, quindi ho scelto leOS.
Modesto, vero? :stuck_out_tongue:

dunque, secondo te qualcuno sul Forum si era bevuta la storia del "little embedded Operating System" :stuck_out_tongue_closed_eyes:?
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 :grin: comunque io pensavo "Super", ormai è un titolo che ti spetta a pieno merito XD
Ottimo lavoro, non ti prometto test perché ormai respiro con la cannuccia fuori dal letame :disappointed_relieved:

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

:smiley: Concordo.

L'effetto sorpresa si è rivelato poco efficiente.

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

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 :wink:

leOS-0.0.3.zip (18.2 KB)

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

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

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.. :stuck_out_tongue:

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..

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

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

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..

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.

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....

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.