Post by DarioG on Jan 6, 2020 22:39:25 GMT
Per il multitask diciamo che io vedo 3 possibilità - facciamo 4 se hai più di un core.
Ossia:
1) Il S.O. ha una lista di task (diciamo sempre creata con fork() che io in effetti non ho mai usato: in Windows hai CreateThread() ecc, e ogni OS ha il suo, direi) e assegna un po' di tempo ad ognuno: con le varie priorità, le necessità di start/stop/ecc. Servono ovviamente dei Semafori (Mutex ecc) e specialmente se si ha più di un core... la cosa va gestita "BENE".
2) La lista di task c'è ma non è il S.O. a gestire chi e come gira o si ferma: ogni task gira un po' e poi rilascia il controllo al "supertask" e quindi si passa al task dopo e così via. Se un task non rilascia mai il controllo, gli altri si attaccano...
3) C'è un solo task, che opera con una (o più) macchine a stati: una semplice variabile intera è incrementata da 0 a n, e a ogni stato viene eseguito un pezzetto di una serie di operazioni, passando allo stato dopo solo quando l'operazione è completa ed è sensato eseguire quella dopo. In questo modo, possono "girare" subroutine o altro, specialmente negli stati in cui la macchina a stati sta aspettando qualche evento prima di procedere.
A mio parere, il 90% dei software per MCU vanno benone con il caso 3, il che ti permette semplicità di implementazione e nessun bisogno di OS ossia di codice che non hai scritto tu
oltre a controllo TOTALE dell'HW che in un'applicazione embedded è fondamentale. Certo, devi smazzarti le macchine a stati ma di solito è piuttosto semplice (switch() ovvero SELECT CASE...)
Certo, se devi ricreare un Windows o un Android allora ti serve forse uno degli altri metodi. E, specialmente se hai più di un core, ti serviranno i semafori ecc.
Ossia:
1) Il S.O. ha una lista di task (diciamo sempre creata con fork() che io in effetti non ho mai usato: in Windows hai CreateThread() ecc, e ogni OS ha il suo, direi) e assegna un po' di tempo ad ognuno: con le varie priorità, le necessità di start/stop/ecc. Servono ovviamente dei Semafori (Mutex ecc) e specialmente se si ha più di un core... la cosa va gestita "BENE".
2) La lista di task c'è ma non è il S.O. a gestire chi e come gira o si ferma: ogni task gira un po' e poi rilascia il controllo al "supertask" e quindi si passa al task dopo e così via. Se un task non rilascia mai il controllo, gli altri si attaccano...
3) C'è un solo task, che opera con una (o più) macchine a stati: una semplice variabile intera è incrementata da 0 a n, e a ogni stato viene eseguito un pezzetto di una serie di operazioni, passando allo stato dopo solo quando l'operazione è completa ed è sensato eseguire quella dopo. In questo modo, possono "girare" subroutine o altro, specialmente negli stati in cui la macchina a stati sta aspettando qualche evento prima di procedere.
A mio parere, il 90% dei software per MCU vanno benone con il caso 3, il che ti permette semplicità di implementazione e nessun bisogno di OS ossia di codice che non hai scritto tu
oltre a controllo TOTALE dell'HW che in un'applicazione embedded è fondamentale. Certo, devi smazzarti le macchine a stati ma di solito è piuttosto semplice (switch() ovvero SELECT CASE...)Certo, se devi ricreare un Windows o un Android allora ti serve forse uno degli altri metodi. E, specialmente se hai più di un core, ti serviranno i semafori ecc.