Panoramica dei driver di dispositivo delle periferiche SPB
Un driver di dispositivo periferica SPB controlla un dispositivo periferico connesso a un bus di periferica semplice (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 offre il supporto dei driver per i dispositivi periferici su semplici bus periferici (SPB). Gli SPB, ad esempio I2C 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 di richiesta di I/O SPB.
Il diagramma seguente illustra una configurazione hardware di esempio in cui un SPB, in questo caso un bus I2C, 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 I2C e un controller di I/O (GPIO) per utilizzo generico. Il processore usa il controller I2C per trasmettere serialmente i dati da e verso i due dispositivi periferici. Le righe 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 il controller I2C 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 I2C.
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 bus e 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 interrupt di Windows a cui il driver può connettere la routine del 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 software e hardware
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 di dispositivo periferica 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 I2C e segnala le richieste di interrupt 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 l'estensione del framework GPIO (GpioClx) sono disponibili come estensioni per KMDF che eseguono funzioni specifiche dei controller SPB e dei controller GPIO, rispettivamente.
Nella parte superiore del diagramma precedente, l'applicazione chiama i metodi nell'API Sensor o nell'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 Introduzione alla piattaforma sensore e posizione 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, il driver passa immediatamente la richiesta all'estensione della classe del sensore, che accoda la richiesta fino a quando il driver non è pronto per gestirlo. 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 I2C. Tali richieste vengono gestite congiuntamente da SpbCx e dal driver controller I2C.
SpbCx è un componente fornito dal sistema che gestisce le code di richieste di I/O per un controller SPB, ad esempio il controller I2C in questo esempio. Il driver controller I2C, fornito dal fornitore hardware per il controller, gestisce tutte le operazioni specifiche dell'hardware nel controller I2C. Ad esempio, il driver del controller accede ai registri hardware mappati alla memoria del controller per avviare trasferimenti di dati da e verso il dispositivo periferico sul bus I2C.
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 dal dispositivo periferico è connessa a un pin GPIO configurato per ricevere le richieste di interrupt. Quando il dispositivo segnala un interrupt al pin GPIO, il controller GPIO segnala un interrupt al processore. 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 disattivato per impedire al processore di riprendere lo stesso interrupt quando il gestore trap restituisce. 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 venga restituito, pianifica l'ISR nel driver di dispositivo della periferica SPB per l'esecuzione in IRQL = PASSIVE_LEVEL. A partire da Windows 8, un driver UMDF può connettere il relativo 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 viene etichettato come interrupt secondario nel diagramma precedente. Al contrario, l'interrupt hardware dal controller GPIO viene 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, deve restituire il prima possibile e rinviare l'elaborazione in background per un interrupt a una routine di lavoro 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 all'applicazione in modalità utente dell'evento tramite l'API Sensor o l'API Location.