Come testate il vostro modulo di gestione degli interrupt?

Question

Ho un modulo di gestione delle interruzioni che controlla l'hardware del controller di interruzione su un processore incorporato.Ora voglio aggiungere altri test.Attualmente, i test verificano solo se l'annidamento degli interrupt funziona creando due interrupt software dall'interno di un ISR, uno con priorità bassa e uno con priorità alta.Come posso testare ulteriormente questo modulo?

Answer 1

Ti suggerisco di provare a creare anche altri stimoli.

Spesso anche gli interrupt hardware possono essere attivati ​​dal software (test automatico) o dal debugger impostando un flag.Oppure come interruzione tramite I/O.O un'interruzione del timer.Oppure puoi semplicemente impostare il bit di interruzione in un controller di interruzione tramite il debugger mentre esegui il passaggio singolo.

Puoi aggiungere alcuni controlli di runtime su cose che non dovrebbero accadere.A volte scelgo di impostare i pin di uscita per il monitoraggio esterno (utile se hai un oscilloscopio o un analizzatore logico...)

low_prio_isr(void)
{
    LOW_PRIO_ISR=1;
    if (1 == HIGH_PRIO_ISR)
    { this may never happen. dummy statement to allow breakpoint in debugger }

}

high_prio_isr(void)
{
    HIGH_PRIO_ISR=1
} 

Lo svantaggio dell'interruzione del software è che il momento è fisso;sempre le stesse istruzioni.Credo che ti piacerebbe vedere la prova che funziona sempre;senza stallo.

Per le routine di servizio di interruzione trovo che le revisioni del codice siano molto preziose.Alla fine potrai testare solo le situazioni che hai immaginato e ad un certo punto la fatica del test sarà molto alta.Gli ISR ​​sono notoriamente difficili da eseguire il debug.

Penso che sia utile fornire test per quanto segue:- L'ISR non viene interrotto per un interrupt di priorità inferiore - L'ISR non viene interrotto per la stessa interruzione prioritaria - L'ISR viene interrotto per un interrupt prioritario più elevato - contazione massima di nidificazione entro le limitazioni dello stack.

Alcuni dei tuoi test potrebbero rimanere nel codice come strumentazione (in modo da poter monitorare, ad esempio, il livello massimo di nidificazione.

Oh, e un'altra cosa:In genere sono riuscito a mantenere gli ISR ​​così brevi da potermi astenere dal nidificare....se puoi, questo ti consentirà di ottenere ulteriore semplicità e maggiori prestazioni.

[MODIFICARE]Naturalmente, gli ISR ​​devono essere testati anche sull'hardware del sistema.A parte l'approccio passo dopo passo, potresti voler dimostrare:- stabilità del sistema al massimo carico di interruzione (preferibilmente diverse volte il carico massimo previsto;Se il driver seriale da 115 kbps può anche gestire 2 Mbps, starai bene!) - Momento corretto di abilitazione / disabilitazione ISR, soprattutto se il sistema entra anche in una modalità di sospensione - # di interruzioni.Può essere sorprendente se si aggiungono interruttori meccanici, rotanti meccanici (centinaia di momenti di interruzione/contatto prima di raggiungere una situazione stabile)

Answer 2

Vi consiglio di test real-hardware. gestione degli interrupt è intrinsecamente casuale e imprevedibile.

Utilizzare un generatore di segnale e mangimi un'onda quadra sul perno interrupt appropriato. Utilizzare più generatori (o uno con più uscite) per testare più linee IRQ e verificare gestione delle priorità.

Prova componendo la frequenza su e giù sui generatori di segnale (differenziare le aliquote tra loro), e vedere cosa succede. Hanno un sacco di codice diagnostico per verificare lo stato del controller di interrupt nei vari stati.

Alternativa:. Se la piattaforma è dotata di timer che possono scatenare gli interrupt, si possono usare al posto di hardware esterno

Answer 3

Io non sono uno sviluppatore incorporato, in modo da non so se questo è possibile, ma come circa disaccoppiamento il codice che gestisce gli interrupt dal meccanismo di callback-registrazione? Ciò consentirebbe di scrivere codice simulatore fireing interrupt-eventi come piace a te ...

Answer 4

Per cose come questa mi raccomando qualcosa come il SPIN model checker . Si finisce per testare l'algoritmo, non il codice, ma il test è esaustivo . Back in the day, Ho trovato un bug in gdb utilizzando questa tecnica.