Sul fatto che ogni interrupt debba andare ad interrompere il flusso normale del programma vorrei ben sperarlo, visto che gli interrupt nascono proprio per quello.
Sul fatto che debbano salvare (push) e ripristinare (pop) i registri ed il program counter (che guarda caso è un registro) sono pure d'accordo, non mi spaventa il problema.
Sulla latenza, le macchine arm cortex ma anche quelle dei pic16 sono abbastanza deterministiche all'entrata ed all'uscita... Peraltro non credo che latenze di qualche microsecondo (esagerando) possano pesare così tanto su una applicazione a microcontrollori.
Se parliamo di jitter, ovvero di slittamento temporale dell'applicazione principale perché scattano gli interrupt allora significa che quest'ultima è stata fatta male, ma questo è colpa di chi scrive l'applicazione, non dell'architettura e neanche degli interrupt.
In uno dei miei orologi, pur andando piano (57,6 MHz) e con un'architettura non particolarmente aggiornata, ovvero un arm7 (LPC2368) con attivi interrupt di USB, 2 timer, 2 seriali, SD card, il jitter del sistema rimane quello del quarzo.
I DMA sono una comodità, ma non precludono gli interrupt. Anzi.
Poi ripeto. Tu parli di ciclo e di schedulazione. Ma lavorando così il tuo jitter rischia di essere superiore al mio
Hai ragione. Sono scelte. Ma vanno ponderate al fatto che i microcontrollori sono cambiati rispetto a qualche anno fa.
Nelle mie applicazioni i miei micro sono quantomeno in low power mode per il 70% - 80% del tempo perché esistono norme che implicano che uno debba risparmiare il più possibile energia, cosa che, tra l'altro i micro attuali fanno e piuttosto bene.
Me lo spieghi perché devo tenere un micro acceso in un while(1)?
Nei miei micro gira un kernel real time che si occupa di semplificarmi lo sviluppo senza impapocchiarlo in cicli senza fine, con maggiore leggibilità del codice, manutenibilità e portabilità.
Quanto al GOTO... non mi spaventa usarlo come nessun'altra istruzione del c. Anzi, ti dirò di più. Con alcune versioni di un compilatore c in cui avevo degli If con livelli molto annidati, per un errore di scrittura dello stesso mi sbagliava un long jump mi caricava solo l'LS Byte e non il MS Byte). Cosa che ho corretto indovina un po' con cosa?

Mi pare di capire che operiamo in campi applicativi dei micro molto diversi, nel mio caso lo sleep del micro non è proprio attuabile, così come gli annidamenti eccessivi.

Il jtter dell'oscillatore non mi preoccupa, uso solo TCXO esterni di ottima qualità.

:yeah:

Per me puoi anche usare dei BVA, non è che sono invidioso.
Mi rimane il dubbio del fatto che un ciclo while(1) con una serie di if annidate non abbia jitter maggiore di una gestione interrupt fatta "al minimo sindacale".
Mi spiego meglio.
Da quello che ho capito, i tuoi main dovrebbero assomigliare a qualcosa del genere
o, ancora peggio, il ciclo while è sostituito da un timer (in interrupt).
Supponiamo che debba essere servita Periferica4, e che la richiesta arrivi subito dopo l'if (RichiestaPeriiferica4)
Nella condizione migliore, ogni if può essere scritta con 4 istruzioni in assembler, la while (1) con un bel salto incondizionato all'indietro.
Nella migliore delle ipotesi hai che la latenza, a seconda del momento in cui ti arriva la richiesta, può variare di diversi cicli macchina, e che la latenza è pesantemente dipendente da come è fatto il ciclo.
Se ti arriva prima del ciclo, magari ti ci vuole un ciclo macchina, se ti arriva dopo, magari anche una ventina o una trentina...
Se poi mi aiuti a capire, posso anche correre il rischio di imparare qualcosa.

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).
Per altre cose un approccio a idle loop può invece essere ottimale quando ad esempio devo fare calcoli e gestire ingressi/uscite su loop dove la prevedibilità del tempo di esecuzione complessivo non sia rilevante.
Anche l'utilizzo di S.O. realtime a volte aiuta, a volte è ridondante a volte non praticabile.
Ritornando in topic: un approccio alla programmazione che usi pesantemente le risorse del processore diminuisce la portabilità ma di contro spesso aumenta le performance.

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

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.

:yeah:

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

Personalmente amo il C++ e la programmazione ad oggetti anche per i microprocessori. Sarà che in tal modo metto nelle classi la parte di basso livello a seconda del silicio uso quella che mi aggrada, ma i metodi pubblici sono sempre gli stessi e nascondo il basso livello dentro le classi.
Così come mi piacciono le struct per memorizzare i dati in modo da compattare al massimo l'uso della memoria... ma poter accedere alle variabili in modo leggibile da codice.
Ma qui si scende nella filosofia...

Romoloman... mi lasci basito!
Si che mi sembravi un tipo strano... ma il c++ anche nei microcontrollori...
Occhio che poi ti vengono delle strane deformazioni professionali.
Del tipo che quando ti dichiari ad una tipa ti dichiari come private object Romoloman...
Prometto di smetterla di dire ca....

Guardati il codice di open9x....
/ - open9x - Custom firmware for the Eurgle/FlySky/Imax/Turnigy 9x r/c Transmitter - Google Project Hosting

tre processori differenti... magari si può fare di meglio... ma sono contento di usare il c++