Gerarchie di priorit

1
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.

2
SERVIZIO
LIVELLO 2
FINE
INTERR.
SERVIZIO
LIVELLO 1
FINE
PRIORITA CRESCENTE
SERVIZIO
RIPRESA SERVIZIO
LIVELLO 0
FINE
INTERR.
PROGRAMMA PRINCIPALE
RIPRESA PROGRAMMA PRINCIPALE
t
IR0
IR2
IR1
3
Gestire la gerarchia di priorità delle
interruzioni via software
4
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 dellorigine dellinterruzione.
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 laltro le periferiche
(polling). Lordine di interrogazione definisce
la priorità nella gestione delle interruzioni.
5
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
  dellinterruzione, fa parte del contesto del
  programma e va ripristinato prima della RTI.
• Prima di rendere interrompibile il processore
  deve essere rimossa la causa dellinterruzione
  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
  dellinterruzione, 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!

6
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 uninterruzione da parte del device a
bassa priorità, questa viene subito servita ed è
violata la gerarchia di priorità!
7
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 1 SETIM Sensore2 CLRIM
Sensore1 CLRIM Sensore0 SETI . . CLRI SETI
M Sensore0 SETIM Sensore1 RTI
Driver sensore 2 . . RTI
Driver sensore 0 SETIM Sensore1 SETIM
Sensore2 CLRIM Sensore0 SETI . . CLRI SETI
M Sensore0 RTI
8
Esercizio tratto dallappello 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 labilitazione 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 dellaltra direzione (conteggiato
nellultimo 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 linterfaccia
del TIMER, una delle interfacce di input e
linterfaccia della periferica che gestisce il
semaforo. Inoltre progettare il software per la
gestione delle interruzioni provenienti dal
TIMER.
9
Interfaccia del Sensore
I/O AB
CPU
I/O DB
I/O CB
I/O RD
I/O WR
SELECT
inc
RESET
Counter
sensore
10
Interfaccia del Semaforo
I/O AB
CPU
I/O DB
I/O CB
I/O WR
Q0 gt ROSSO Q1 gt VERDE
SELECT
SELECT
11
Interfaccia del Timer
IRQ
CPU
I/O AB
I/O DB
I/O CB
START
CLEAR
IACKIN
IRQ
IVN
STARTD
Decoder
O.C.
SELECT
COMPLETE
SCO
STARTDEV
IACKOUT
12
Codice

• Vedi file semaforo.asm sul sito