next topic »

[Reply #240 on:]

Certo ancora manca da implementare semafori, code ed altre logiche... ecc ecc

Leo, correggimi se sbaglio ma penso che leOS difficilmente otterrà questo tipo di servizi, perché lo porterebbero alla fine ad essere molto simile ad un "vero" rtos, togliendogli la semplicità e la "snellezza" che lo contraddistinguono ora.

Per essere un po' più costruttivo, dico che la comunicazione inter-thread è facilmente ottenibile con l'uso di variabili globali e la keyword "volatile". Non che ciò sostituisca mutex, code e quant'altro, ma credo che sia sufficiente per l'ambito di utilizzo cui leOS si riferisce.

(disclaimer: finora ho fatto pochi test per confermare la mia precedente affermazione, anche se sono stati tutti positivi).

[Reply #241 on:]

i semafori non sarebbero molto complessi da fare: quando voglio testarlo o cambiare il valore,disabilito temporaneamente gli interrupt(ovviamente da ripristinare dopo)..al posto di usare il wait che blocca la funzione corrente,fare un wait a cui passare la funzione contenente la sezione critica..

[Reply #242 on:]

Certo ancora manca da implementare semafori, code ed altre logiche... ecc ecc

Leo, correggimi se sbaglio ma penso che leOS difficilmente otterrà questo tipo di servizi, perché lo porterebbero alla fine ad essere molto simile ad un "vero" rtos, togliendogli la semplicità e la "snellezza" che lo contraddistinguono ora.

E' esatto. Non è nei progetti del leOS portarlo ai livelli di un vero RTOS. Sia per mancanza di conoscenze da parte mia in materia sia anche perché di RTOS pronti e funzionanti ce ne sono diversi e sarebbe reinventare l'acqua calda. Il leOS è bello perché è semplice da usare e da implementare, supporta un sacco di microcontrollori e permette di sgravare tanti compiti noiosi la cui implementazione nel loop() principale crea non pochi grattacapi.

[Reply #243 on:]

Senza dimenticare il fatto che in caso di necessità il sorgente è del tutto affrontabile (rispetto ad un RTOS completo).

[Reply #244 on:]

Ciao Leo72,
Volevo chiederti una cosa il tuo leOS per funzionare si basa su, un timer interno ma se tu ti basassi su un timer hw esterno di precisione non risolveresti tutti i problemi di incompatibilita con altre liberie?

[Reply #245 on:]

come vorresti farlo(lo so di non essere leo  ) programmi un timer esterno per cambiarti lo stato di un pin dell'arduino ogni millisecondo(o ogni 10..),e intercetti l'interrupt del cambio stato del pin?

cmq,la comodità è che non richiede componenti esterne..

[Reply #246 on:]

Ciao Leo72,
Volevo chiederti una cosa il tuo leOS per funzionare si basa su, un timer interno ma se tu ti basassi su un timer hw esterno di precisione non risolveresti tutti i problemi di incompatibilita con altre liberie?

Sicuramente si può fare, e ci sono altri sistemi, uno è quello detto da m_ri. Però così fai tutto senza componenti esterni. Inoltre considera che il leOS gira anche sull'Attiny85: se su quel micro, che ha solo 5 pin utili, gliene levi 1, lo depauperi del 20% delle sue capacità di I/O 
Inoltre il leOS risulta incompatibile con alcune librerie per via dell'uso del timer 2, ma usando un timer esterno potrebbe risultare incompatibile con tanti shield, visto che dovresti togliere un pin a quelli usabili. Insomma, è un cane che si morde la coda 

[Reply #247 on:]

come vorresti farlo(lo so di non essere leo  ) programmi un timer esterno per cambiarti lo stato di un pin dell'arduino ogni millisecondo(o ogni 10..),e intercetti l'interrupt del cambio stato del pin?

cmq,la comodità è che non richiede componenti esterne..

ma per una componente esterna di 20 cent puoi tranquillamente usare i timer interni per le librerie più standard,si pensavo ad una cosa del genere ma non so se è realizzabile.

[Reply #248 on:]

Vi aggiorno sugli... aggiornamenti del leOS 

Con la versione 1.0.0 ho introdotto un nuovo metodo per sapere lo stato di un task.

Code:

myOS.taskIsRunning(nomeFunzione)

Esso restituisce PAUSED, SCHEDULED o ONETIME. La cosa è utile se ad esempio un task modifica lo stato di un altro task, indipendentemente dal codice dell'utente.

Con la versione 1.0.1 ho invece sistemato il problema dell'overflow del contatore a 32 bit. Ciò significa che dopo 49,7 giorni non si verificano situazioni strane. Si può così evitare di utilizzare i contatori a 64 bit, che comportano un aggravio di centinaia di byte di flash occupata in più, cosa utile soprattutto sui piccoli micro con poca memoria.

L'ultima versione della lib è scaricabile come sempre dal mio sito (link in calce alla mia firma).

[Reply #249 on:]

Ciao, se posso permettermi esprimo un dubbio sul nome della funzione.

Se tale funzione mi servisse per sapere se un task è "running" o no, la chiamaerei isTaskRunning(). Ma poiché non ritorna un booleano ma una tra diverse possibili costanti simboliche, secondo me è meglio chiamarla getTaskState() (o status).

my 2 cents

[Reply #250 on:]

Uhm... detta così ha una sua logica  

EDIT:
la versione 1.0.1a, da poco online, ha il metodo rinominato in getTaskStatus.

[Reply #251 on:]

per la serie,facciamo i rompic*****ni, una teorica funzione taskIsRunning dovrebbe (quasi) sempre restituire false,dato che non c'è esecuzione parallela..

(tanto leo non sai dove abito..)

[Reply #252 on:]

per la serie,facciamo i rompic*****ni, una teorica funzione taskIsRunning dovrebbe (quasi) sempre restituire false,dato che non c'è esecuzione parallela..

Bast.... 

(tanto leo non sai dove abito..)

Sei fortunato perché non me lo ricordo più 

[Reply #253 on:]

per la serie,facciamo i rompic*****ni, una teorica funzione taskIsRunning dovrebbe (quasi) sempre restituire false,dato che non c'è esecuzione parallela..

(tanto leo non sai dove abito..)

Ti prendo sul serio: un task è running quando il suo stato ha quel valore. Stai confondendo lo stato di un task con il fatto che in dato istante stia occupando la CPU.

[Reply #254 on:]

per la serie,facciamo i rompic*****ni, una teorica funzione taskIsRunning dovrebbe (quasi) sempre restituire false,dato che non c'è esecuzione parallela..

(tanto leo non sai dove abito..)

Ti prendo sul serio: un task è running quando il suo stato ha quel valore. Stai confondendo lo stato di un task con il fatto che in dato istante stia occupando la CPU.

ti contraddisco: quando si parla di stati di schedulatori,tra i tanti stati c'è ready(pronto per l'esecuzione,ma NON in esecuzione) e running(in esecuzione in quel preciso momento)..sono due stati diversi..i pcb(process control block,o i tcb) vengono poi spostati da uno all'altro a seconda delle politiche usate..

prima di contraddire leo,penso 2 volte a quello che scrivo.. 
altrimenti qualcuno mi sputt.....bbe per l'eternità,ti pare?