Non solo non c'è motivo per cui non puoi farlo. Un sistema guidato dagli eventi non è raro. MA. Su molte architetture se ci si trova in un interrupt non è possibile averne un altro, quindi anche un interrupt a bassa priorità può in alcuni sistemi impedire che si verifichi un interrupt a priorità più alta, quindi la regola generale è di entrare e uscire velocemente. Spesso un approccio progettuale è l'interrupt che arriva e fa un po 'di gestione, ma lascia un compito per il kernel o l'attività in primo piano da completare, più visibile con i sistemi operativi.

Credo che il Cortex-M possa annidare le interruzioni, quindi se una si sovrappone a un'altra viene gestita. La maggior parte del chip non è correlata a ARM, quindi non c'è alcun motivo per cui il fornitore del chip non possa mettere un gestore di interrupt davanti al Cortex-M e / o un gestore di priorità, oltre a tutto ciò che è nel braccio fine delle cose.

Tuttavia, è necessario progettare un design basato sulle interruzioni. Come con qualsiasi altro progetto, è necessario eseguire l'ingegneria del sistema. È necessario conoscere ogni possibile interruzione (in situazioni normali, istruzioni indefinite, ecc. Sono fatali) e quanto spesso si verificano. Molti saranno periodi regolari.

Devi anche sapere quanto tempo impiega ogni interruzione e programmarlo in modo tale da assicurarti che tutte le interruzioni vengano gestite in una quantità di tempo che soddisfa le tue specifiche. Ad esempio, un evento di interrupt basato su timer per qualcosa richiede 50 ms per essere gestito normalmente, ma c'è un interrupt casuale non periodico che richiede 20 ms. Sono tollerabili 70 ms per uno di questi? Il chip / core ha una soluzione prioritaria? In caso contrario, hai definito le tue priorità di interruzione in modo tale da poter rispettare i tempi su tutto?

Alla fine della giornata, c'è poca differenza tra tutte le interruzioni e alcune interruzioni e alcune in primo piano rispetto al design e alla tempistica delle interruzioni; hai lo stesso problema.

Quindi la regola generale è rendere gli interrupt snelli, meschini e veloci, ma la realtà è fare l'ingegneria del sistema e sapere quanto tempo hai per ciascuno o gruppi di essi messi insieme.Deve richiedere meno di x quantità di tempo.

Re-entrancy è / diventa un grosso problema quanto più i tuoi ISR ​​sono complessi. La voce di wikipedia ha una descrizione piuttosto succinta di un ISR rientrante:

Un gestore di interrupt rientrante è un gestore di interrupt che riattiva gli interrupt all'inizio del gestore di interrupt. Ciò potrebbe ridurre la latenza degli interrupt. [6] In generale, durante la programmazione delle routine del servizio di interrupt, si consiglia di riattivare gli interrupt il prima possibile nel gestore degli interrupt. Questa pratica aiuta a evitare di perdere interruzioni. [7]

Supponendo che tu non stia scrivendo un sistema operativo generico in cui il rientro potrebbe essere inevitabile, devi tenere presente che l'ulteriore complessità di rientrare nel codice del controller personalizzato potrebbe non valere la pena percepita facilità di scrittura di ISR ​​pigri e di lunga durata.

Ecco un esempio:

• ISR di lunga durata e priorità bassa inizia a fare qualcosa, chiama una versione di malloc che hai implementato.
• Chiamata malloc media, vieni interrotto da un thread con priorità più alta: chiama anche malloc
• scenario a: l'ISR ad alta priorità esce da malloc prima della priorità bassa
• scenario b: l'ISR ad alta priorità esce da malloc dopo una priorità bassa *

Ok, dirai, metterò un blocco di rotazione su malloc, quindi tutto ciò che devi fare è ripetere la condizione precedente alla primitiva spinlock_aquire che hai creato: è it rientrante?

Dovrei sottolineare qui che semplicemente schiaffeggiare le cose e chiamarlo un giorno è una ricetta per i deadlock basati sull'inversione di priorità. Non è così semplice.

La soluzione del povero uomo a tutti questi problemi è mantenere brevi i tuoi ISR. Ad esempio, nel kernel NT, molto tempo fa (non si è tenuto aggiornato), a qualsiasi IRQL sopra gli ultimi due non era nemmeno permesso guardare la memoria di paging. Questo perché il paging era gestito da un interrupt ...

Quindi la scelta diventa: implementare un meccanismo di accodamento di base e fare in modo che i propri ISR ​​ inviano unità di lavoro, oppure fare in modo che i propri ISR ​​si comportino liberamente ma assicurarsi di avere un ambiente estremamente robusto che non soffocerà su questioni strane (ad es. inversione di priorità).

Se il tuo compito è semplicissimo, come accendere una luce nel tuo drone controllato da arduino, allora vai avanti con tutti i mezzi. Ma se vuoi evitare grattacapi ingegneristici in seguito man mano che il tuo codice diventa più complesso, dovresti davvero evitare il beneficio percepito di non darti alcun vincolo con un ISR.

* chiarimento: lo scenario b non può verificarsi al valore nominale poiché l'ISR con priorità più alta verrà sempre eseguito e completato prima di quello con priorità più bassa. Tuttavia, il percorso del codice preso da uno dei due può essere scambiato. Quindi nella stessa routine malloc , se c'è un accesso a una struttura dati globale, quel codice può essere interrotto in ogni possibile combinazione di modi.

Oltre a questo punto, si dovrebbe affermare che il requisito di rientranza per qualsiasi funzione riguarda l'intero albero delle chiamate. Questo diventa molto difficile da garantire se si finisce per utilizzare librerie di terze parti.

Nota anche: per indirizzare un commento da @ user253751, il re-entrancy non viene risolto semplicemente avvolgendo le cose in un lucchetto. Piuttosto, re-entrancy ha una serie di requisiti che sono ben compresi. Ecco alcuni esempi di codice banali che illustrano la questione.

Si può vedere, osservando questo aspetto, che la scrittura di una funzione di acquisizione di risorse o malloc rientranti diventa molto difficile.

Per un computer generico, mantenere breve il gestore degli interrupt consente all'elaborazione normale di essere ragionevolmente deterministica, il che può o meno essere un problema a seconda dell'applicazione.

In un difficile processo integrato in tempo reale (in cui il determinismo è di fondamentale importanza) questo ha molto senso.

Ho implementato un sensore di inclinazione molto preciso (2 assi) in cui l'azionamento del sensore era controllato da timer e il loop principale era in modalità sleep fino a quando il contatore non ha attivato l'interruzione per aggiornare quale asse era guidato; anche l ' ADC esterno che stavo utilizzando era controllato da un timer (diverso) per ridurre al minimo il jitter di acquisizione per i campioni medi (che può causare il caos in un sistema di dati campionati).

Per mantenere la capacità di eseguire alcuni calcoli in una finestra di tempo molto ristretta, i gestori di interrupt dovevano essere veloci (prendi l'interrupt, fai il minimo richiesto ed esci).

In altre applicazioni, tutte le cose interessanti possono accadere nei gestori di interrupt (come nel caso in cui ero coinvolto in un sistema di video on demand con fino a 2000 stream simultanei disponibili).

Non esiste una risposta "taglia unica" per i gestori di interrupt e dipende dall'applicazione, anche se, come notato, gli interrupt annidati possono diventare disordinati soprattutto se due gestori devono condividere una singola risorsa (il che può portare alla corruzione dei dati se non viene affrontato correttamente e in un sistema multitasking può anche portare all ' inversione di priorità).

L'approccio da adottare per interrompere i gestori dipende dall'applicazione, ma un primo approccio di "mantenerli semplici e veloci" è sempre un buon punto di partenza.

Mi sono occupato spesso di questo genere di cose in un progetto precedente, e qui ci sono alcune cose che ho affrontato (spesso imparate nel modo più duro). Alcuni dettagli possono variare in base all'architettura del tuo chip e a quanto sei vicino al bare metal, ma le idee generali sono comunque valide.

• Nel periodo di tempo prima di cancellare / riattivare l'interruzione, potrebbe attivarsi un'altra interruzione non correlata. Potresti fare la cosa sbagliata servendo un interrupt a bassa priorità quando è in sospeso un interrupt a priorità critica. Alcuni gestori di interrupt possono effettivamente avere una priorità inferiore rispetto ai thread non interrotti, che è una relazione che non puoi implementare se fai tutto il tuo lavoro all'interno del gestore.
  • Questo diventa ancora più un problema se condividi un'interruzione tra più fonti. Un secondo interrupt potrebbe essere completamente mascherato se non hai ancora terminato l'elaborazione del primo. Alcune architetture hardware sono peggiori rispetto ad altre.
• Quando le interruzioni provengono da dispositivi esterni, tali dispositivi potrebbero avere aspettative su quanto tempo impieghi a rispondere alle loro interruzioni. Ho avuto ISR complessi che impiegavano troppo tempo per essere eseguiti e il dispositivo esterno ha pensato che fossi morto e ha smesso di parlarmi.
• Su alcune architetture, gli ISR ​​vengono eseguiti sopra lo stack utilizzato dal programma attualmente in esecuzione (per evitare di allocare memoria per uno stack separato, che potrebbe bloccare, fallire o attivare interruzioni). Non sai quanto spazio di stack avrai a disposizione, quindi non puoi davvero permetterti di fare nient'altro che cancellare lo stato di interruzione e segnalare qualcos'altro per fare il lavoro.
• Alcune architetture eseguono ISR a un livello di privilegio più elevato rispetto ai thread normali. Potrebbero avere accesso a risorse hardware di basso livello normalmente protette. Ciò implica che ci possono essere implicazioni per la sicurezza nel fare molto lavoro in un ISR.
• Gli ISR ​​hanno la massima priorità nel tuo sistema. Chiamare una funzione che blocca o si basa internamente sugli interrupt può portare a deadlock.
• Alcune architetture utilizzano gli interrupt internamente, per cose come l'attivazione dello svuotamento della cache tra i core o la notifica all'ALU che un coprocessore matematico ha terminato di elaborare qualcosa. La manutenzione di queste interruzioni può essere bloccata mentre sei ancora all'interno del tuo ISR, quindi trascorrere troppo tempo qui può avere impatti non evidenti sulle prestazioni.
  • Un altro uso interno degli interrupt potrebbe essere la comunicazione con i motori di debug (JTAG, ecc.). Ho lavorato con chip in cui le sonde di debug non erano molto efficaci mentre si trovavano in un ISR, ma altrimenti funzionavano alla grande. Il debug del codice ISR era un ordine di grandezza più difficile del debug del codice normale.
• Alcune CPU multi-core serviranno sempre gli interrupt su un core specifico. Fare tutto il tuo lavoro all'interno dell'ISR può forzare l'esecuzione del codice in modo efficace a thread singolo.

Per fortuna, tutti questi problemi hanno la stessa semplice soluzione. Il gestore degli interrupt dovrebbe memorizzare le informazioni necessarie sull'interruzione, cancellare e riattivare l'interruzione, quindi segnalare a qualche altra parte di codice di eseguire il lavoro effettivo. È abbastanza facile da fare sulla maggior parte delle piattaforme che non c'è davvero molto vantaggio nel cercare di stipare tutto il tuo lavoro nello stesso ISR.

Perché gli interrupt impediscono l'esecuzione di altri interrupt.Tenerli brevi fondamentalmente significa solo non fare più del necessario nell'interrupt.

un grande interrupt con priorità molto bassa e l'altro interrupt

Ciò richiede interrupt annidati (per consentire agli interrupt di interrompersi a vicenda) che possono creare confusione.Non tutti i processi possono essere interrotti in modo sicuro.

Posso essere una decisione progettuale consapevole per spostare il tuo carico di lavoro solo nelle interruzioni.
Ma è necessario prestare molta attenzione e precauzioni per garantire che le scadenze e lo stack non vengano superati.

Un NVIC è fondamentalmente uno scheduler molto grezzo. Le attività verranno eseguite come priorità impostata, se attivate da un timer, software o altra fonte.
In un ARM Cortex M3 hai un controllo preciso sulle priorità e sull'annidamento. In un ATMega o 8051 no.

Se guardi cosa stai facendo in base ai thread con questo modello, avrai:

• Thread principale tramite il gestore di ripristino. (inattivo)
  • Interrompi TIMER_ISR_A con un thread normale.
    • Interrompi TIMER_ISR_B con un thread irregolare.
      • Interrompi UART_ISR con un thread di buffer in tempo reale.

Sei già a 3 livelli di profondità, questo significa almeno 3 stackframe!
Con il raggruppamento prioritario puoi limitare l'annidamento a pochi livelli. Ma questo potrebbe costarti delle scadenze.

Con un RTOS preventivo avrai un controllo più preciso, meno interruzioni annidate e meno rischi di far saltare lo stack. E spesso includeva metriche sul rendimento.

E ovviamente tutti gli effetti collaterali dei dati condivisi asincroni e del rientro. Poiché in un ISR non puoi aspettare che qualche risorsa diventi disponibile. Bloccherai tutti i thread con priorità uguale e inferiore dall'esecuzione. A meno che non venga utilizzato solo da thread con priorità più alta.
Molti vincoli impliciti!

Se riesci ad adattare il tuo progetto software per operare entro i vincoli di questo modello, spesso combinato con il modello superloop per attività che non prevedono una scadenza rigida, allora sì, è un progetto valido .
Se adeguatamente documentato per essere compreso anche dal tuo team.

Per le applicazioni in tempo reale, la tempistica prevedibile è spesso più importante delle prestazioni.Le interruzioni esterne avranno un tempismo imprevedibile, quindi più a lungo dureranno e maggiore sarà l'impatto che avranno sulla tempistica complessiva del sistema.Nota che sto parlando di interrupt ad alta priorità qui: avere un lungo interrupt a bassa priorità non è un problema, fintanto che non influisce sulle cose critiche in termini di tempo (ma attenzione al problema di rientranza menzionato in un'altra risposta).

Ho visto diversi progetti che facevano fatica a ottenere un tempo di I / O coerente nonostante il carico della CPU fosse ragionevolmente basso.Sostituire gli ISR più lunghi eseguendo il polling o riducendoli a semplici gestori di "copia byte / set flag" e facendo il resto in attività periodiche era l'unico modo per tenere sotto controllo quel tempo, a scapito di un po 'di carico aggiuntivo sulla CPU.

Il concetto di interrupt essenzialmente ti consente di fare due cose: le cose normali che faresti normalmente e le cose immediate che devono essere gestite quando si verifica un evento.

Non hai bisogno di fare le cose in questo modo, ma se non lo fai, non stai sfruttando realmente la struttura degli interrupt.Il tuo codice sarà probabilmente più difficile da capire, mantenere ed eseguire il debug.

Qualcosa nelle tue architetture suggerite, però, mi ricorda gli RTOS.

Non posso ancora commentare, quindi lo posterò qui:

È stato detto da alcuni che si potrebbe progettare con cura un sistema di pianificazione basato sugli interrupt su un hardware che supporti gli interrupt.

Vorrei aggiungere: Sul Cortex-M, ciò sembrerebbe sciocco, tuttavia, poiché ha strutture dedicate per supportare il cambio di contesto per "thread" non basati su interruzioni, in altre parole, invece di dare fastidio alla testa per progettare un sistema di interruzione tutto funzionante, potresti anche usare qualcosa come FreeRTOS?

Cambio di contesto su ARM Cortex-M

La grande differenza tra un ciclo principale e gli interrupt è la pianificazione.

Un ciclo principale funziona come un sistema fifo. Passo dopo passo elabora ciò che gli viene richiesto. È lineare, quindi il consumo di memoria è piuttosto deterministico e se chiedi al ciclo principale di fare più di quanto possa gestire, ogni attività verrà comunque eseguita, ma solo più lentamente. È anche piuttosto facile eseguire il debug.

Gli interrupt, quando emessi, interrompono il ciclo principale. Pertanto il ciclo principale viene messo in pausa, il che può causare problemi di temporizzazione se il ciclo principale viene messo in pausa troppo a lungo.

Se viene emesso un secondo interrupt mentre il primo è ancora in esecuzione, ci sono due modi in cui un processore può gestirlo. Il modo in cui è determinato dal processore, ma alcuni processori lasciano scegliere al programmatore. O il processore può rifiutare altri interrupt mentre uno viene gestito, oppure può interrompere l'ultimo interrupt, metterlo nello stack, eseguire il nuovo interrupt e quindi tornare all'ultimo interrupt.

La prima opzione è piuttosto semplice, ma potrebbe far perdere gli interrupt, perché la condizione di interrupt non è più valida quando il primo interrupt termina la sua esecuzione. Inoltre, in questo modo gli interrupt con priorità più bassa possono ostacolare l'esecuzione di interrupt con priorità più alta.

L'altra opzione consente agli interrupt di priorità più alta di interrompere gli interrupt di priorità più bassa e inoltre gli interrupt non possono andare persi. Ma questo è a costo di introdurre problemi relativi alla concorrenza anche su un sistema a thread singolo. Inoltre questo rende il consumo di memoria non deterministico, dal momento che molte esecuzioni di interrupt inserite nello stack aumentano il consumo di memoria di parecchio.

Ho avuto questo problema una volta durante la programmazione di un'applicazione che gestisce i segnali IR su un ATMega328p.La mia routine di interrupt era troppo lunga e lenta e se due mittenti IR avessero inviato un segnale allo stesso tempo all'ATMega (che dovrebbe risultare solo un segnale irriconoscibile) l'esecuzione dell'interruzione del primo fianco del segnale non era terminata prima che arrivasse il segnale successivoin, che ha fatto sì che l'esecuzione dell'interruzione venisse inserita nello stack.Ciò è stato ripetuto fino a quando entrambi i mittenti IR hanno interrotto l'invio.Fino ad allora lo stack aveva centinaia di esecuzioni di interrupt impilate su di esso, il che ha causato un overflow dello stack.Ora, l'ATMega328p non ha la prevenzione dell'overflow dello stack, quindi ha continuato a riversarsi nell'area dell'heap e ha completamente danneggiato l'intera memoria.

Idealmente, vuoi fare il meno possibile tramite gli interrupt.È molto più facile eseguire il debug di un ciclo che avere interruzioni che saltano apparentemente in modo casuale.Meno sono e meglio è.