Concordo con romoloman che non esiste un approccio valido per tutto, ogni applicazione è diversa e può anche richiedere hardware diverso.
Non è poi mia presunzione voler insegnare alcunchè, so di aver molto da imparare perchè la programmazione in se è cosa dinamica ed in continua evoluzione; nel mio campo di lavoro è un must avere temporizzazioni precise ed una latenza conosciuta e stabile, il sistema che uso normalmente (salvo varizioni sul tema è visibile nel seguente codice):
Codice:
while(1)
{
++Tic;
switch (Tic & 7)
{
case 0: SetMod();
break;
case 1: SendVar1();
break;
case 2: MisPTMet();
break;
case 3: CalH2O();
break;
case 4: CalAcc();
FrenMot();
break;
case 5: CalRpm();
CalPre();
AntiDet();
break;
case 6: DiaMat();
IntBid();
break;
case 7: CompGas();
CompOil();
CompAir();
CompEgr();
break;
}
TaskVel();
WaitMain();
}
void WaitMain()
{
while(!TMR2IF);
TMR2IF = 0; TMR2IE = 0;
WriteTimer2(0); // 512 us
} Con questa struttura è chiaro che tutte le funzioni dei task devono essere completate in meno di 512us come pure deve essere rispettato che TaskX + TaskVel < 512us.
Il Taskvel deve avere un tempo di esecuzione molto ridotto, tipo leggere solo un flag di OK, è altrettanto evidente che è molto importante la sequenza di assegnazione delle funzioni all' interno dei task.
In questa applicazione l'unico interrupt presente (e non mostrato) è la comunicazione seriale PC -> dispositivo; poichè tale evento avviene solo in caso diagnostico o di messa a punto, tutta la comunicazione avviene in 4,096ms e quindi i dati acquisiti od i comandi di output vengono 'congelati' per lo stesso tempo.
Del Timer2 leggo solo il flag di interrupt (overflow) e non genero e tratto realmente lo intterrupt.
