Interruzione software vs funzione

Dopo circa 3 anni di lavoro con MCU non so ancora a che cosa servono gli interrupt di software? Ho fatto diversi lavori con STM32 e non ho mai usato gli interrupt software. In effetti questa è una grande domanda per me:

Perché quando possiamo usare una semplice funzione per svolgere un'attività, dovremmo usare un interrupt software? Quali sono le differenze tra un interrupt software e una funzione?

Ogni volta che vuoi, puoi chiamare una funzione (che hai scritto per il tuo lavoro). Dovrebbero esserci dei vantaggi nell'usare un interrupt software invece di una semplice funzione. Non sono sicuro, ma penso che ci sia un vantaggio per gli interrupt software: è possibile assegnare una priorità a un interrupt software, quindi è possibile assegnare una priorità più elevata all'interrupt software per evitare che l'interrupt hardware interrompa il compito.

arm stm32 interrupts

— Roh
fonte

Penso che lo scopo principale dell'uso degli interrupt sia che tu possa continuare a svolgere altri compiti importanti mentre è in attesa che succeda qualcos'altro e quando i tempi non saranno sempre costanti. Inoltre penso che sia un po 'più veloce del polling nella maggior parte dei casi.

— MrPhooky,

@MrPhooky È l'hardware che interrompe di cui stai parlando. L'OP sta parlando di interruzioni del software.

— brhans,

Risposte:

La principale differenza tra una funzione e un interrupt software è ciò che è noto come contesto .

Una funzione viene eseguita nel contesto del programma principale.
Un interrupt viene eseguito nel contesto del gestore di interrupt.

Su un sistema semplice ciò potrebbe non fare alcuna differenza, e gli interrupt software possono semplicemente essere usati come un modo conveniente per fornire routine di libreria hard coded nella ROM - non è necessario conoscere l'indirizzo di ogni routine, solo il codice ID e il punto di ingresso principale. Questo rende il tuo codice più portatile.

Tuttavia, su sistemi più complessi, l'interrupt software può essere eseguito in un ambiente completamente diverso, noto come contesto kernel . Normalmente l'applicazione verrà eseguita in un contesto utente protetto con accesso limitato alle risorse. Solo quando si esegue nel contesto del kernel è possibile eseguire le attività più complicate - in effetti alcuni sistemi addirittura limitano le istruzioni che possono essere eseguite, quindi è necessario un meccanismo per attivare il codice nel contesto del kernel - e per questo viene utilizzato un interrupt.

— Majenko
fonte

Inoltre, gli interrupt possono arrestare arbitrariamente l'avanzamento di un programma in modo che il sistema possa fare qualcos'altro (ad es. Interrupt di processo). I programmi non devono tenerne conto, poiché, dal punto di vista del programma, lo stato della funzione rimane invariato rispetto al momento in cui si è verificato l'interrupt. Sui sistemi più vecchi, questo è il modo in cui i programmi TSR (Terminate / Stay Resident) hanno simulato il multitasking, agganciando l'interruzione timer / orologio. Anche senza i livelli IOPL, c'è stato un vantaggio, ad esempio, per mantenere aggiornato il clock di sistema.

— phyrfox,

Forse si noti anche che quegli "interrupt software" sono anche chiamati "interrupt sincroni", perché il codice dell'applicazione sa esattamente quando e perché si verifica tale interruzione, al contrario di "interrupt asincroni" che possono, dal punto di vista del applicazione, fondamentalmente accade in qualsiasi momento in modo indesiderato.

— JimmyB,

@HannoBinder: Penso che l'OP stia parlando di inviare richieste di interruzione al controller di interruzione vettoriale Cortex-M3; se il codice per un interrupt ad alta priorità ne inserisce uno con priorità inferiore, la richiesta verrà rinviata fino a qualche momento successivo, quando tutti gli interrupt con priorità più alta sono terminati.

— supercat

Gli interrupt software possono essere utilizzati per completare un'attività di interruzione con una priorità inferiore. Al codice critico di temporizzazione viene spesso data un'alta priorità di interruzione per evitare troppa latenza. Una volta terminata la parte critica di temporizzazione, potrebbero essere presenti attività aggiuntive che potrebbero essere troppo critiche per il ciclo principale, ma non sono così critiche da trattenere altri interrupt ad alta priorità. L'attivazione di un interrupt software con priorità inferiore può ottenere questo risultato.

Ad esempio, supponiamo di avere più motori passo-passo ciascuno con il proprio timer. Alle interruzioni del timer viene assegnata un'alta priorità per ridurre al minimo il jitter dei passi. Il compito più critico in termini di temporizzazione può essere semplice come impostare o cancellare un impulso di passo o far avanzare le uscite di fase. Potrebbero essere necessarie funzionalità aggiuntive come il calcolo delle rampe di accelerazione, l'elaborazione del sensore, ecc. Poiché questo deve essere elaborato in ogni fase, potrebbe non essere appropriato elaborarlo da main () poiché la temporizzazione del loop principale potrebbe essere troppo lunga. Queste attività aggiuntive possono essere elaborate da un interrupt software di priorità inferiore in modo da non aumentare la latenza degli altri canali stepper ad alta priorità.

Qual è la differenza tra un interrupt software e una funzione?

Una funzione viene chiamata immediatamente da qualsiasi posizione e non cambia il livello di priorità di interrupt corrente se viene chiamata da un interrupt. Un interrupt software è un trigger di interruzione che causerà la chiamata di tale interrupt quando si presenta la priorità. Se una chiamata di funzione fosse inserita alla fine di un interrupt ad alta priorità, la funzione verrebbe contenuta in quell'alta priorità. Attivando l'interruzione del software con priorità inferiore e quindi ritornando dall'interruzione con priorità alta, la funzionalità viene chiamata alla nuova priorità (inferiore).

— Tut
fonte

Un altro schema comune potrebbe essere quello di avere un interrupt a 100 KHz per gestire elementi critici in termini di tempistica e anche un tick di timer a 1 kHz, ma non avere due timer separati disponibili. Non ci vuole un po 'di overhead per una routine di interrupt a 100 kHz per dire che if ((timer_count--) & 0x80000000) SET_TICK_INTERRUPT_FLAG(); else timer_count = temp-1; l'altro interrupt può fare la sua cosa e con gli interruzioni brevemente disabilitati aggiungere 100 a timer_count; anche se la routine da 1kHz impiega oltre 10us per l'esecuzione, non interferirà con quella da 100kHz.

— supercat

In modo simile, ho usato gli interrupt software in sistemi semplici (senza un RTOS completo) come pseudo-scheduler, in cui i requisiti hardware sono gestiti dagli ISR, ma le funzioni di callback e altre lunghe attività che vengono eseguite in risposta a cambiamenti in lo stato hardware è delegato all'interrupt software.

— Evil Dog Pie,

In pratica hai descritto una variante della "metà inferiore". Hai qualche riferimento per questo essere anche chiamato "interruzione software"? È un significato abbastanza diverso dalla risposta di Majenko e la domanda è contrassegnata come ARM - l'architettura ha in realtà l'istruzione SWI (interruzione software).

— domen,

@domen Non sono sicuro di quale tipo di riferimento hai bisogno. Si chiama "interruzione software" perché è quello che viene utilizzato per raggiungerlo. Nel contesto di ARM, l'OP ha fatto specifico riferimento a STM32 e ha fornito un collegamento al manuale di riferimento di RM0008. Questo non è un manuale di riferimento del core ARM. L'unico "interrupt software" coperto in RM0008 è EXTI_SWIER (registro eventi di interrupt software) che può essere utilizzato per generare interrupt software indipendentemente dal fatto che i pin hardware effettivi vengano utilizzati o meno per gli interrupt. Non ho usato personalmente l'istruzione SWI (SWC).

— Tut

Grazie! Potrebbe essere utile includere alcune di queste informazioni nella risposta, per chiarire quale "interruzione del software" è.

— domen

Per espandere un po 'la risposta di Majenko, gli interrupt software vengono utilizzati per implementare i sistemi operativi, in particolare l'interfaccia di chiamata del sistema. Ciò significa che non è necessario che le applicazioni siano collegate al sistema operativo per effettuare chiamate di funzione e il cambio di contesto consente al sistema operativo di limitare l'accesso all'hardware e sfruttare elementi come la memoria protetta.

Se non si utilizza un sistema operativo e si controlla tutto il codice sull'MCU, probabilmente non è necessario utilizzare gli interrupt di software. (Anche se come ha detto Tut, possono avere altri usi.)

Le interfacce di chiamata di sistema Linux e MS-DOS su x86 utilizzano gli interrupt di software, quindi mi collegherò a quelli come esempio.

— Adam Haun
fonte

E in molti casi in cui il sistema operativo utilizza interrupt soft, sono avvolti in funzioni per semplificare la vita.

— Hildred

Continuo a programmare cose (anche nuove di zecca) per DOS, e ho molta familiarità con i gestori di int 21. Quasi tutto ciò di cui ho bisogno I / O saggio viene gestito con l'ISR DOS.

— R Drast,

Si noti che la pagina citata per Linux è del 1993-1996.

— un CVn

Ho sostituito il link con uno più aggiornato.

— Adam Haun,