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.
PRIORITA’ CRESCENTE
PROGRAMMA PRINCIPALE
SERVIZIO
SERVIZIO
RIPRESA SERVIZIO
RIPRESA PROGRAMMA
PRINCIPALE
t LIVELLO 0
LIVELLO 1 LIVELLO 2
INTERR.
INTERR.
FINE
FINE
IR0 IR2 IR1
SERVIZIO
FINE
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:
1. Ogni routine di servizio che prevede di essere interrotta (di priorità non max) debba rendere il processore nuovamente interrompibile (SETI).
2. 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.
3. 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.
4. 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à :
Sensore0Sensore1 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
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.
Esercizio tratto dall’appello 14/6/2000
I/O DB I/O CB
SELECT
Counter
I/O RD
CPU
Interfaccia del Sensore
I/O WR
RESET
I/O AB
sensore
inc
I/O DB I/O CB CPU
I/O WR
I/O AB
SELECT S Q
R Q STATUS
Interfaccia del Semaforo
SELECT
Q=0 => ROSSO
Q=1 => VERDE
Interfaccia del Timer
I/O AB I/O DB I/O CB
Decoder
SELECT
START
STARTD
O.C.
IRQ
SCO R Q
S Q STATUS
STARTDEV
COMPLETE CLEAR
IVN
CPU
IACKIN
IACKOUT
IRQ
