|
 |
Procedure Seriali |
Struttura Driver Hardware
[190 di 403] |
- Gestione degli eventi seriali con la Tecnica dell'Interruzione |
|
5.1 Considerazioni
generali:
struttura
di un
Driver
Hardware |
 |
In generale
ogni
dispositivo periferico e potenzialmente in grado di richiedere
l'attenzione del processore generando una
richiesta d'interruzione hardware,
IRQ (Interrupt
ReQuest) governata da un
gestore specializzato (il PIC
8259, Programmable Interrupt
Controller) che affida a ciascuna di esse un diverso
livello di priorità, attivando poco
dopo la linea
INT del processore; se abilitato a
rispondere, esso interromperà la sua normale attività per eseguire una
particolare
procedura di
servizio. |
 |
Anche le
porte seriali (UART)
possono operare con questa tecnica; ad esse sono
assegnate rispettivamente le linee IRQ4
(COM1 o COM3)
e IRQ3
(COM2
o COM4); in risposta il processore
(istruito dal PIC) mette in esecuzione
rispettivamente le procedure puntate dai vettori (=indirizzi logici)
INT 0CH e INT
0BH. |
 |
La gestione degli
eventi seriali
con Tecnica di Interruzione è piuttosto
impegnativa:
certamente è la soluzione migliore possibile, ma
occupa risorse,
è difficile da progettare
e, se si desidera comprenderne il funzionamento,
comporta conoscenze teoriche
che vanno al di là del semplice funzionamento dell'UART. |
 | Nel progetto di un programma in grado di organizzare il
riconoscimento e il
servizio di una
IRQ non basta infatti
scrivere un codice in grado di soddisfare le esigenze della periferica; un buon driver Hardware
deve provvedere a tutti questi compiti:
 | garantire la
procedura di
servizio sulla base degli
eventi hardware
che possono richiedere l'attenzione del
processore |
 | rendere reperibile la
nuova procedura (rimappando il vettore
INT xxH chiamato a puntarla) e predisporre
il computer per accettare le
IRQ generate dal dispositivo |
 | salvare lo stato funzionale del computer prima di
sostituirlo, per poterlo ripristinare in uscita, lasciando il sistema nelle
stesse condizioni operative trovate in ingresso |
|
 | A ciascuna di queste fasi sarà dedicato un dettagliato
paragrafo, pensato per la gestione di una
porta seriale ma facilmente adattabile anche
ad altri dispositivi. |
 | In particolare gli
eventi seriali
che possono richiedere l'attenzione del
processore sono 4, ai quali l'UART stesso
ha affidato diversi livelli di priorità:
 | variazioni dello Stato
della Linea (Receiver Line Status):
durante la ricezione di dati è stata
rilevata la presenza di
errori (di
sovrapposizione, di parità o
di composizione) o la presenza di un
segnale
di break |
 | dato ricevuto pronto
(Received Data Available):
il numero di bytes ricevuti ha superato quello massimo (trigger
level) previsto per il buffer FIFO
in Ricezione oppure il
FIFO contiene bytes in misura inferiore al
massimo ma il tempo concesso a nuovi arrivi è terminato,
timeout) oppure nel
Registro di Ricezione è pronto
un singolo dato (con UART
8250/16450 o con UART
16550A, se il
FIFO è disabilitato) |
 | dato trasmesso
(Transmit Data Empty):
il Registro di trasmissione è
vuoto (con UART
8250/16450 o con UART
16550A, se il
FIFO in Trasmissione
è disabilitato) oppure il
FIFO ha posti liberi per uno o più bytes |
 | variazioni dello Stato
del Modem (Modem Status):
durante la comunicazione con il Modem,
è stata rilevata la variazione di segnali in arrivo, come Data Carrier Detect
(CD, rilevato modem
remoto/possibile comunicare),
Ring Indicator (RI, ricevuto segnale acustico
sul canale), Data Set Ready
(DSR, DCE connesso e pronto a
comunicare) e Clear To Send
(CTS, DCE
Pronto a ricevere) |
|
 | Nelle pagine seguenti dedicherò
particolare attenzione al servizio dei 2 eventi di
trasmissione e ricezione dati. |
©
2001-2010 - Studio Tecnico
ing. Giorgio OBER
Tutti i diritti sono riservati
|