Panoramica dei driver delle periferiche SPB

Un driver di dispositivo periferica SPB controlla un dispositivo periferico connesso a un semplice bus periferico (SPB). I registri hardware di questo dispositivo sono disponibili solo tramite SPB. Per leggere o scrivere nel dispositivo, il driver deve inviare richieste di I/O al controller SPB. Solo questo controller può avviare trasferimenti di dati da e verso il dispositivo tramite SPB.

A partire da Windows 8, Windows fornisce il supporto driver per i dispositivi periferici su bus periferici semplici (SPB). Gli SPB, ad esempio I²C e SPI, sono ampiamente usati per connettersi a dispositivi sensore a bassa velocità, ad esempio accelerometri, dispositivi GPS e monitor a livello di batteria. Questa panoramica descrive in che modo un driver di dispositivo periferica SPB, in collaborazione con altri componenti di sistema, controlla un dispositivo periferico connesso a SPB.

È possibile creare un driver di dispositivo periferica SPB per usare User-Mode Driver Framework (UMDF) o Kernel-Mode Driver Framework (KMDF). Per altre informazioni sullo sviluppo di un driver UMDF, vedere Introduzione a UMDF. Per altre informazioni sullo sviluppo di un driver KMDF, vedere Introduzione a Kernel-Mode Driver Framework.

Informazioni sulla configurazione del dispositivo

I registri hardware di un dispositivo periferico connesso a SPB non sono mappati alla memoria. È possibile accedere al dispositivo solo tramite il controller SPB, che trasferisce in modo seriale i dati da e verso il dispositivo tramite SPB. Per eseguire operazioni di I/O, il driver di dispositivo periferica SPB invia richieste di I/O al dispositivo e il controller SPB esegue i trasferimenti di dati necessari per completare queste richieste. Per altre informazioni sulle richieste di I/O che possono essere inviate a dispositivi periferici in SPB, vedere Uso dell'interfaccia richiesta di I/O SPB.

Il diagramma seguente illustra una configurazione hardware di esempio in cui un SPB, in questo caso un bus I²C, connette due dispositivi periferici a un modulo System on a Chip (SoC). I dispositivi periferici sono esterni al modulo SoC e si connettono a quattro pin nel modulo. Il modulo SoC contiene il processore principale (non visualizzato), più un controller I²C e un controller di I/O per utilizzo generico (GPIO). Il processore usa il controller I²C per trasmettere in modo seriale i dati da e verso i due dispositivi periferici. Le linee di richiesta di interrupt da questi dispositivi sono connesse a due pin GPIO configurati come input di interrupt. Quando un dispositivo segnala una richiesta di interrupt, il controller GPIO inoltra l'interrupt al processore.

Poiché il controller GPIO e I²controller C in questo esempio sono integrati nel modulo SoC, i registri hardware sono mappati alla memoria e possono essere accessibili direttamente dal processore. Tuttavia, il processore può accedere ai registri hardware dei due dispositivi periferici solo indirettamente, tramite il controller I²C.

Un SPB non è un bus Plug and Play (PnP) e pertanto non può essere usato per rilevare e configurare automaticamente nuovi dispositivi collegati al bus. Le connessioni bus e interrupt di un dispositivo connesso a SPB sono spesso permanenti. Anche se il dispositivo può essere scollegato da uno slot, questo slot è in genere dedicato al dispositivo. Inoltre, un SPB non fornisce un percorso hardware in banda per l'inoltro delle richieste di interrupt da un dispositivo periferico sul bus al controller del bus. Il percorso hardware per gli interrupt è invece separato dal controller del bus.

Il fornitore della piattaforma hardware archivia le informazioni di configurazione per un dispositivo periferico connesso a SPB nel firmware ACPI della piattaforma. Durante l'avvio del sistema, il driver ACPI enumera i dispositivi sul bus per il gestore PnP. Per ogni dispositivo enumerato, ACPI fornisce informazioni sulle connessioni del bus e dell'interrupt del dispositivo. Il gestore PnP archivia queste informazioni in un archivio dati denominato hub risorse .

All'avvio del dispositivo, il gestore PnP fornisce al driver del dispositivo un set di risorse hardware che incapsulano le informazioni di configurazione archiviate dall'hub risorse per il dispositivo. Queste risorse includono un ID connessione e un numero di interrupt. L'ID di connessione incapsula le informazioni di connessione del bus, ad esempio il controller SPB, l'indirizzo del bus e la frequenza di clock del bus. Prima che le richieste di I/O possano essere inviate al dispositivo, il driver deve prima usare l'ID connessione per aprire una connessione logica al dispositivo. Il numero di interrupt è una risorsa per gli interrupt di Windows a cui il driver può collegare la sua routine di servizio di interrupt (ISR). Il driver può essere facilmente convertito da una piattaforma hardware a un'altra perché l'ID di connessione e il numero di interrupt sono astrazioni di alto livello che nascondono informazioni specifiche della piattaforma sul bus fisico e sulle connessioni di interrupt.

Livelli di hardware e software

Il diagramma a blocchi seguente mostra i livelli di software e hardware che connettono un dispositivo periferico in un SPB a un programma dell'applicazione che usa il dispositivo. Il driver del dispositivo periferico SPB in questo esempio è un driver UMDF. Il dispositivo periferico (nella parte inferiore del diagramma) è un dispositivo sensore (ad esempio, un accelerometro). Come illustrato nel diagramma precedente, il dispositivo periferico è connesso a un bus I²C e segnala le richieste di interruzione tramite un pin su un controller GPIO.

I tre blocchi visualizzati in grigio sono moduli forniti dal sistema. A partire da Windows 7, l'estensione della classe del sensore è disponibile come estensione specifica del sensore per UMDF. A partire da Windows 8, l'estensione del framework SPB (SpbCx) e estensione del framework GPIO (GpioClx) sono disponibili rispettivamente come estensioni a KMDF che eseguono funzioni specifiche dei controller SPB e dei controller GPIO.

Nella parte superiore del diagramma precedente, l'applicazione chiama i metodi nell'API sensore o API Location per comunicare con il dispositivo sensore. Tramite queste chiamate, l'applicazione può inviare richieste di I/O al dispositivo e ricevere notifiche degli eventi dal dispositivo. Per altre informazioni su queste API, vedere Introduction to the Sensor and Location Platform in Windows.

Quando l'applicazione chiama un metodo che richiede la comunicazione con il driver di dispositivo periferico SPB, l'API sensor o l'API Location crea una richiesta di I/O e la invia al driver di dispositivo periferica SPB. Il modulo di estensione della classe del sensore consente al driver di gestire queste richieste di I/O. Quando il driver riceve una nuova richiesta di I/O, passa immediatamente la richiesta all'estensione della classe del sensore, che la mette in coda fino a quando il driver non è pronto per gestirla. Se una richiesta di I/O dall'applicazione richiede il trasferimento di dati da o verso il dispositivo periferico, il driver di dispositivo periferica SPB crea una richiesta di I/O per questo trasferimento e invia la richiesta al controller I²C. Tali richieste vengono gestite congiuntamente da SpbCx e dal driver controller I²C.

SpbCx è un componente fornito dal sistema che gestisce le code di richieste di I/O per un controller SPB, ad esempio il controller I²C in questo esempio. Il driver controller I²C, fornito dal fornitore hardware per il controller, gestisce tutte le operazioni specifiche dell'hardware nel controller I²C controller. Ad esempio, il driver del controller accede ai registri hardware mappati alla memoria del controller per avviare i trasferimenti di dati da e verso il dispositivo periferico sul bus I²C.

Il dispositivo periferico segnala una richiesta di interruzione quando si verifica un evento hardware che richiede attenzione dal driver di dispositivo periferica SPB o dall'applicazione in modalità utente. La linea di interrupt del dispositivo periferico è collegata a un pin GPIO configurato per ricevere richieste di interrupt. Quando il dispositivo segnala un interrupt al pin GPIO, il controller GPIO segnala un interrupt al microprocessore. In risposta a questo interrupt, il gestore di trap interrupt del kernel chiama l'ISR di GpioClx. Questo ISR esegue una query sul driver del controller GPIO, che accede quindi ai registri hardware mappati alla memoria del controller GPIO per identificare il pin GPIO di interruzione. Per disattivare l'interrupt, il driver del controller GPIO cancella (se l'interrupt è attivato da edge) o maschera (se attivato dal livello) la richiesta di interrupt al pin GPIO. L'interrupt deve essere silenziato per impedire al processore di gestire nuovamente lo stesso interrupt quando il gestore della trap restituisce il controllo. Per un interrupt attivato a livello, l'ISR nel driver di dispositivo periferica SPB deve accedere ai registri hardware del dispositivo periferico per cancellare l'interrupt prima che il pin GPIO possa essere mascherato.

Prima che il gestore dell'interrupt del kernel ritorni, programma l'ISR nel driver del dispositivo periferico SPB in modo che venga eseguito a IRQL = PASSIVE_LEVEL. A partire da Windows 8, un driver UMDF può connettere il suo ISR a un interrupt ricevuto dal driver come risorsa di interruzione di Windows astratta; Per altre informazioni, vedere Gestione degli Interrupt. Per determinare quale ISR chiamare, il sistema operativo cerca l'interrupt virtuale assegnato al pin GPIO di interruzione e trova l'ISR connesso all'interrupt. Questo interrupt virtuale è etichettato come interrupt secondario nel diagramma precedente. Al contrario, l'interrupt di hardware del controller GPIO è etichettato come interrupt primario .

Poiché l'ISR nel driver di dispositivo periferico SPB viene eseguito a livello passivo, l'ISR può usare richieste di I/O sincrone per accedere ai registri hardware nel dispositivo periferico. L'ISR può bloccarsi fino al completamento di queste richieste. L'ISR, che viene eseguito con priorità relativamente alta, dovrebbe terminare il prima possibile e rinviare l'elaborazione specifica per un interrupt a una routine di lavoro che viene eseguita con priorità inferiore.

In risposta all'interrupt secondario, il driver del dispositivo periferico SPB invia un evento nell'estensione della classe del sensore, che notifica l'evento all'applicazione in modalità utente tramite l'API Sensor o l'API Location.