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.

PRIO

RIT

A’

CR

ESC

EN

TE

PROGRAMMAPRINCIPALE

SERVIZIO

SERVIZIO

RIPRESASERVIZIO

RIPRESA PROGRAMMAPRINCIPALE

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à mediaSET I; il processore è interrompibile… ; fine codice, inizio ripristino contestosetim dev_low_priority;pop …; altre op. ripristino contestopop …;rti

Se arriva un’interruzione da parte del device a bassa priorità, questa viene subito servita ed è violata la gerarchia di priorità!

Un esempio + concreto3 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

Sensore1Sensore2

Prioritàcrescente

Driver sensore 0:SETIM Sensore1SETIM Sensore2CLRIM Sensore0SETI….….CLRISETIM Sensore0RTI

Driver sensore 1:SETIM Sensore2CLRIM Sensore1CLRIM Sensore0SETI….….CLRISETIM Sensore0SETIM Sensore1RTI

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 DBI/O CB

SELECT

Counter

I/O RD

CPU

Interfaccia del Sensore

I/O WR

RESET

I/O AB

sensore

inc

I/O DBI/O CBCPU

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 ABI/O DBI/O CB

Decoder

SELECT

START

STARTD O.C.

IRQ

SCO

R Q

S Q

STATUS

STARTDEV

COMPLETE

CLEAR

IVN

CPU

IACKIN

IACKOUT

IRQ

Codice

Vedi file semaforo.asm sul sito