Citazione:
Io credo senza alcuna polemica che non esista un approccio corretto in assoluto. Molto spesso un mix di interrupt e idle loops è quantomeno inevitabile...
Se voglio che una routine non abbia jitter una delle poche speranze che ho è proprio quella di usare un interrupt legato ad un timer (esempio il settaggio del pwm hardware per la generazione di un treno di impulsi ppm.) così come se ad esempio se devo leggere la seriale velocemente su un AVR per garantire che il buffer di ricezione non si riempia mai (3 miseri byte).
|
Che le cose si possano fare in modo diverso è vero e sacrosanto.
Che ognuno possa usare l'approccio che più gli piace pure.
Per quanto riguarda gli Idle Loop, li uso, ma il meno possibile.
Citazione:
|
Anche l'utilizzo di S.O. realtime a volte aiuta, a volte è ridondante a volte non praticabile.
|
Per quello che ho visto aiuta nel 99% dei casi. Nel restante è indispensabile. Ma questo è perché sono abituato oramai a lavorare in un certo modo.
Citazione:
|
Ritornando in topic: un approccio alla programmazione che usi pesantemente le risorse del processore diminuisce la portabilità ma di contro spesso aumenta le performance.
|
Ritornando in topic sarebbe buona norma lavorare a due livelli, parte alta dove hai il 90% del codice, il flusso dei vari programmi o task, scritta in c rigorosamente standard (e lo standard è K&R, non ANSI o cazzabubole varie), ed una parte bassa che è l'unica che deve avere accesso al silicio, scritta in c ma fortemente dipendente non solo dalla famiglia di micro, ma addirittura dal singolo componente della famiglia stessa.
In quest'ultima ci mettiamo dentro interrupt e quant'altro.
La comunicazione tra le due parti avviene attraverso a delle funzioni standard (magari anche stub).
ElNonnino, stasera ti mando un MP.