Citazione:
E' chiaro che ogni interrupt va ad interromper il normale flusso del programma, comporta il salvataggio di registri, della posizione dell'ultima istruzione e magari anche di qualche variabile nonchè il loro successivo ripristino.
Tutte queste operazioni quindi vanno ad alterare il tempo di ciclo dell'intera applicazione e quando si usano più interrupt, anche se con livelli di priorità ben congegnati, le possibiltà che qualcosa vada storto aumentano. Sicuramente si ha una latenza non predicibile del tempo di ciclo.
|
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.
Citazione:
|
Gli ARM ed anche i dsPIC e famiglie superiori hanno le funzioni DMA che consentono ad esempio di ricevere dati senza interrompere la normale schedulazione del programma, quindi basta all' interno del ciclo principale andarsi a leggere il flag del canale DMA e se settato operare di conseguenza a tempo opprtuno.
|
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
Citazione:
|
A me l'uso smodato degli interrupt in applicazioni semplici come quelle che mi trovo normalmente a realizzare non piace e mi ricorda un poco lo 'spaghetti code' irto di 'GOTO' di alcuni programmatori in BASIC; in genere preferisco anche usare più micro piccoli dedicati ad operazioni time-critical anzichè un megaprocessore che fa tutto lui, son scelte.
|
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?