Gerarchie di priorità per la gestione delle interruzioni Introdurre una gerarchia per la gestione delle interruzioni consiste essenzialmente nel definire dei meccanismi per: Stabilire quale dispositivo debba essere servito per primo nel caso di richieste contemporanee. Consentire che il servizio di una interruzione possa essere a sua volta interrotto da dispositivi più prioritari. Tali meccanismi possono essere implementati via hardware (vedi controllore interruzione a priorità) o, nel caso in cui non via un supporto hardware dedicato, via software.

IR0 IR2 IR1 LIVELLO 2 FINE INTERR. LIVELLO 1 PRIORITA’ CRESCENTE FINE SERVIZIO LIVELLO 2 FINE INTERR. SERVIZIO LIVELLO 1 FINE PRIORITA’ CRESCENTE SERVIZIO RIPRESA SERVIZIO LIVELLO 0 INTERR. FINE PROGRAMMA PRINCIPALE RIPRESA PROGRAMMA PRINCIPALE t IR0 IR2 IR1

Gestire la gerarchia di priorità delle interruzioni via software

1) Stabilire quale dispositivo debba essere servito per primo nel caso di richieste contemporanee. Soluzione Hardware: si utilizza il segnale di IACK propagato in daisy-chain per il riconoscimento dell’origine dell’interruzione. Così facendo si introduce una priorità che è funzione della “distanza” dal processore (la periferica più vicina ha priorità max). Una soluzione alternativa implementabile via software è di interrogare una dopo l’altro le periferiche (polling). L’ordine di interrogazione definisce la priorità nella gestione delle interruzioni.

2) Consentire che il servizio di una interruzione possa essere a sua volta interrotto da dispositivi più prioritari. Abbiamo già studiato una soluzione hw a tale scopo. Una possibile alternativa implementabile completamente tramite software prevede che: Ogni routine di servizio che prevede di essere interrotta (di priorità non max) debba rendere il processore nuovamente interrompibile (SETI). Per inibire i dispositivi a priorità minore, prima della SETI devono essere opportunamente mascherati i flip-flop IM dei devices presenti, cosi’ da stabilire da quali di questi, la routine di servizio possa essere interrotta. Lo stato di interrompibilità, definito dai valori dei registri IM dei dispositivi al momento dell’interruzione, fa parte del contesto del programma e va ripristinato prima della RTI. Prima di rendere interrompibile il processore deve essere rimossa la causa dell’interruzione stessa, per evitare lo stack overflow. Si può raggiungere questo scopo impedendo alla periferica di generare altre interruzioni con CLRIM. Anche resettando il flip-flop di status (START,CLEAR) , rimuoviamo la causa dell’interruzione, ma non inibiamo la periferica a generarne altri. Di conseguenza possono sorgere problemi nel caso in cui un driver sia interrotto da una nuova richiesta di interruzione a cui è associato lo stesso driver! Conflitti sui dati e sul codice!

2) Consentire che il servizio di una interruzione possa essere a sua volta interrotto da dispositivi più prioritari. 5) Il ripristino del contesto deve avvenire con il processore non interrompibile, per evitare le incongruenze che potrebbero sorgere a causa di una commutazione incompleta. Ad esempio, si consideri il driver periferica di priorità “media” (interrompibile solo da device con priorità “alta” e non da device con priorità “bassa”) …; codice del driver per device con priorità media SET I; il processore è interrompibile … ; fine codice, inizio ripristino contesto setim dev_low_priority; pop …; altre op. ripristino contesto pop …; rti Se arriva un’interruzione da parte del device a bassa priorità, questa viene subito servita ed è violata la gerarchia di priorità!

Un esempio + concreto 3 rilevatori di movimento sono connessi al PD32. Quando viene rilevato un movimento, i sensori generano una richiesta di interruzione. Si vuole servire le interruzioni provenienti dai sensori con la seguente priorità : Sensore0 Sensore1 Sensore2 Priorità crescente Driver sensore 0: SETIM Sensore1 SETIM Sensore2 CLRIM Sensore0 SETI …. CLRI SETIM Sensore0 RTI Driver sensore 1: SETIM Sensore2 CLRIM Sensore1 CLRIM Sensore0 SETI …. CLRI SETIM Sensore0 SETIM Sensore1 RTI Driver sensore 2: …. RTI

Esercizio tratto dall’appello 14/6/2000 Un processore è interfacciato a due periferiche di input che indicano il numero di autovetture passate nelle due direzioni di un incrocio a X, al relativo semaforo e ad un TIMER. Normalmente il processore ogni minuto comanda il semaforo ad invertire l’abilitazione ai passaggi (da rosso a verde e viceversa). Prima di abilitare la commutazione del semaforo, il processore legge il numero di autovetture passate nella direzione con il verde, se il numero di auto passate in questa direzione è maggiore di 32 unità rispetto a quello dell’altra direzione (conteggiato nell’ultimo periodo), allora il processore ritarda la commutazione del semaforo di un altro minuto. Ogni volta che il processore legge i valori del numero di autovetture passate avverte il SCO delle periferiche di input di riazzerare il relativo contatore. Progettare l’interfaccia del TIMER, una delle interfacce di input e l’interfaccia della periferica che gestisce il semaforo. Inoltre progettare il software per la gestione delle interruzioni provenienti dal TIMER.

Interfaccia del Sensore I/O AB CPU I/O DB I/O CB I/O RD I/O WR SELECT inc RESET Counter sensore

Interfaccia del Semaforo I/O AB CPU I/O DB I/O CB I/O WR Q=0 => ROSSO Q=1 => VERDE S Q R Q STATUS SELECT SELECT

Interfaccia del Timer CPU I/O AB I/O DB I/O CB IRQ CLEAR START IRQ IACKIN IRQ IVN Decoder STARTD O.C. R Q S Q STATUS SELECT COMPLETE SCO STARTDEV IACKOUT

Codice Vedi file semaforo.asm sul sito