Driver di periferica per i dispositivi su porte seriali SerCx2-Managed

In genere, una porta seriale gestita da SerCx2 è connessa in modo permanente a un dispositivo periferico. Questo dispositivo è controllato da un driver periferico che invia richieste di I/O alla porta seriale. Queste richieste trasferiscono i dati da e verso il dispositivo e configurano lo stato della porta seriale. Le richieste di I/O inviate dal driver di periferica vengono gestite congiuntamente da SerCx2 e da un driver del controller seriale associato.

Spesso, i controller seriali sono contenuti in circuiti integrati System on a Chip (SoC). Esempi di dispositivi periferici che potrebbero essere connessi alla porta seriale di un controller seriale su un chip SoC includono GPS, LAN wireless, fotocamera e dispositivi Bluetooth.

Il driver periferico per il dispositivo periferico connesso in modo seriale è in genere un driver KmDF (Kernel-Mode Driver Framework ) o UMDF ( User-Mode Driver Framework ). Per comunicare con questo dispositivo, il driver periferico deve prima aprire una connessione logica al controller seriale e ricevere un handle di file a cui il driver può inviare richieste di I/O. Per altre informazioni, vedere Apertura di una porta seriale SerCx2-Managed.

In questa pagina

• Architettura del driver seriale
• Percorso della richiesta di I/O
• Percorso di interruzione

Architettura del driver seriale

Il diagramma a blocchi seguente mostra i livelli di software e hardware che formano i percorsi di comunicazione tra un dispositivo periferico (nella parte inferiore del diagramma) e il driver di periferica del dispositivo (nella parte superiore del diagramma). In questo esempio, il dispositivo periferico è connesso alla porta sul controller seriale e a un pin di interruzione nel controller GPIO.

Il driver periferico in questo esempio è un driver UMDF che invia richieste di I/O al dispositivo periferico. Queste richieste passano attraverso il percorso di comunicazione visualizzato sul lato sinistro del diagramma. Le richieste vengono gestite da SerCx2 e dal driver del controller seriale. Il driver periferico può richiedere operazioni di I/O che impostano la configurazione hardware della porta seriale (ad esempio, modificare la velocità di baud) e che trasferisce i dati da e verso il dispositivo periferico attraverso la porta seriale. Per altre informazioni, vedere Percorso della richiesta di I/O.

Gli interrupt dal dispositivo periferico passano verso l'alto attraverso il percorso di comunicazione sul lato destro del diagramma precedente. Come illustrato nell'angolo inferiore destro di questo diagramma, il pin di interruzione dal dispositivo periferico è connesso a un pin su un controller di I/O (GPIO) per utilizzo generico. Questo pin GPIO è configurato per ricevere segnali di interruzione dal dispositivo periferico. In una piattaforma hardware basata su SoC, un controller GPIO svolge spesso il ruolo del controller di interrupt programmabile. Per altre informazioni, vedere Percorso di interruzione.

I due blocchi visualizzati in grigio nel diagramma sono moduli forniti dal sistema. L'estensione del framework GPIO (GpioClx) è disponibile a partire da Windows 8. Come SerCx2, GpioClx è un'estensione di KMDF. GpioClx esegue funzioni comuni a un'ampia gamma di controller GPIO. GpioClx funziona con un driver del controller GPIO che gestisce tutte le operazioni specifiche dell'hardware nel controller GPIO. Per altre informazioni, vedere Panoramica del supporto dei driver GPIO.

Percorso della richiesta di I O

Per trasmettere i dati al dispositivo periferico, il driver periferico invia una richiesta di scrittura (IRP_MJ_WRITE) al controller seriale. Per ricevere dati dal dispositivo periferico, il driver periferica invia una richiesta di lettura (IRP_MJ_READ) al controller seriale.

Inoltre, Windows definisce un set di richieste di controllo I/O del dispositivo (IOCTL) che il driver periferico può usare per eseguire varie operazioni di controllo di I/O specifiche per i controller seriali. Di seguito sono riportati esempi di operazioni di controllo di I/O che il driver periferico può richiedere:

• Impostare la velocità baud in corrispondenza della quale la porta seriale trasmette e riceve i dati.
• Impostare gli intervalli di timeout per le richieste di lettura e scrittura.
• Specificare un set di eventi hardware nella porta seriale per cui il driver periferico riceve le notifiche.

SerCx2 supporta molti degli stessi IOCTL seriali del driver seriale in arrivo, Serial.sys e la versione 1 dell'estensione del framework seriale (SerCx). Per altre informazioni:

• Vedere la tabella in Interfaccia richiesta I/O seriale per determinare se SerCx2 supporta un IOCTL seriale specifico.
• Vedi Richieste di controllo dei dispositivi seriali per descrizioni dettagliate di tutti i IOCTL seriali definiti dall'interfaccia di richiesta di I/O seriale di Windows.
• Per una breve introduzione a Serial.sys, SerCx e SerCx2, vedere Serial Controller Drivers Overview (Panoramica dei driver del controller seriale ).

Percorso di interruzione

Come illustrato nel diagramma dell'architettura del driver seriale , il dispositivo periferico usa il pin GPIO per inviare gli interrupt del dispositivo al driver di periferica. In risposta a un segnale di interruzione dal dispositivo periferico, il controller GPIO segnala un interrupt hardware (denominato interrupt primario ) al processore. Il sistema operativo indirizza questo interrupt all'ISR di GpioClx. Successivamente, GpioClx identifica il pin GPIO che ha causato l'interrupt e cerca l'identificatore GSI (Global System Interrupt) per l'interrupt virtuale (denominato interrupt secondario ) dal dispositivo periferico. GpioClx fornisce il GSI a HAL e hal chiama l'ISR del driver periferico. Per gestire l'interrupt, il driver periferico invia in genere una o più richieste di I/O al dispositivo periferico tramite SerCx2 e il driver del controller seriale. Per altre informazioni sugli interrupt primari e secondari, vedere Interrupt GPIO.

Gli interrupt GPIO sono solo un modo per consentire al driver periferico di ricevere notifiche di eventi hardware nel dispositivo periferico. Un altro modo consiste nel richiedere notifiche da SerCx2 e dal driver del controller seriale quando si verificano determinati tipi di eventi hardware nella porta seriale. Ad esempio, il driver periferico può chiedere di ricevere una notifica quando il controller seriale riceve i dati seriali dal dispositivo periferico. Per richiedere queste notifiche, il driver periferico invia una richiesta di IOCTL_SERIAL_SET_WAIT_MASK al dispositivo periferico per specificare un set di eventi da monitorare e quindi invia una richiesta di IOCTL_SERIAL_WAIT_ON_MASK per avviare l'ascolto di questi eventi. Queste richieste vengono gestite da SerCx2, con l'aiuto del driver del controller seriale. Per altre informazioni sui tipi di eventi che il driver periferico può monitorare, vedere SERIAL_EV_XXX descritto in IOCTL_SERIAL_SET_WAIT_MASK.

Tuttavia, il controller seriale può rilevare gli eventi hardware solo quando si trova nello stato di alimentazione del dispositivo D0. Se il controller seriale si trova in uno stato a basso consumo, il driver periferico non può basarsi sulle notifiche del controller seriale per sapere quando, ad esempio, il dispositivo periferico dispone di nuovi dati per il driver da leggere. In questo caso, il dispositivo periferico deve inviare un segnale di interruzione (o, ad esempio, un segnale di riattivazione) tramite un pin GPIO. Un controller GPIO consuma pochissima potenza e in genere rimane attivo dopo che la maggior parte degli altri dispositivi ha immesso stati a basso consumo.