Questi sono solitamente chiamati driver di dispositivi hardware. Essi forniscono un'interfaccia astratta tra i particolari dettagli dell'hardware e il software che vuole accedere al dispositivo, fornendo un'API (Application Programming Interface) che può essere chiamata e che è indipendente dall'hardware.
Io lavoro con il framework Harmony 3 che Microchip fornisce per rendere più facile ai programmatori scrivere applicazioni per i suoi microcontrollori embedded a 32 bit (sia MIPS che ARM).
In Harmony 3, chiamiamo i driver di dispositivo di livello più basso "librerie di periferiche" (PLIBs), per separarli dal livello successivo che sono driver software indipendenti dall'hardware.
Le PLIBs forniscono chiamate per inizializzare l'hardware, scrivere su (e forse leggere da) registri di controllo, e scrivere e leggere dati da/per il dispositivo.
Il driver software ha un'interfaccia più classica, che comporta l'inizializzazione, l'apertura e la chiusura del driver, l'ottenimento dello stato e l'aggiunta alle code per scrivere o leggere il dispositivo associato, direttamente o tramite DMA.
Questo può essere illustrato utilizzando una delle mie applicazioni, un'applicazione di streaming Bluetooth che è tipica del codice contenuto in un paio di cuffie Bluetooth.
Ecco un diagramma a blocchi dell'applicazione:
Gli elementi in nero sono le periferiche hardware all'interno del microcontrollore; ognuna di esse ha uno specifico driver di dispositivo hardware o PLIB. Gli elementi in blu sono i driver di livello superiore, indipendenti dall'hardware.
L'audio viene passato dal modulo Bluetooth BM64 al processore tramite un'interfaccia I2S (Inter-IC Sound), e poi di nuovo fuori tramite una seconda istanza del driver I2S al codec AK4954 che pilota le cuffie.
Ecco come appare l'applicazione nel grafico del progetto Harmony 3, che il programmatore usa per specificare i componenti della sua applicazione:
Ho evidenziato ogni PLIB in rosso.
Qui si vedono chiaramente le due istanze del driver I2S, una per il modulo Bluetooth e una per il codec, con ogni istanza collegata a una libreria periferica (I2S1 o I2S2 in questo caso). Quale viene usato è determinato dal cablaggio hardware della scheda - cioè quali pin del processore sono collegati a quale pezzo di hardware esterno.
Ci possono essere diversi PLIB per lo stesso tipo di periferica a causa delle differenze tra i chip. Ho scritto quattro diversi PLIB per l'interfaccia I2S; questa è la cartella della libreria delle periferiche audio nell'attuale versione di Harmony 3:
Il numero alla fine del nome (per esempio u2224) è l'ID della periferica, che è specifico per un processore o una famiglia di processori. Così l'i2s_u224 è per il SAME54 (ARM Cortex M4); l'i2sc e ssc_6078 sono per il SAME70 (ARM Cortex M7), e lo spi_01329 è per la famiglia PIC32MX/MZ (l'interfaccia I2S per il PIC32 condivide lo stesso hardware dell'interfaccia SPI).
Il programmatore non deve essere a conoscenza di questi ID; solo i PLIB appropriati sono presentati nel configuratore MPLB X Harmony (MHC) quando ne seleziona uno dal menu Available Component:
E se stanno usando uno dei modelli audio o Bluetooth, in base alla particolare scheda di sviluppo scelta vengono automaticamente selezionati i PLIB appropriati (insieme a tutti i driver software, più le connessioni tra i componenti) così il programmatore può creare un grafico di progetto come quello precedente con pochi clic del mouse.
C'è solo un driver software I2S comunque, poiché è indipendente dall'hardware e funziona con uno qualsiasi dei quattro PLIB I2S. Il software applicativo fa solo chiamate ai driver software di livello superiore, e non accede mai direttamente ai PLIB. In questo caso, l'applicazione in realtà non chiama nemmeno direttamente i driver I2S o I2C - sono solo indirettamente chiamati dai driver BM64 e AK4954.
Anche se questa particolare applicazione funziona senza un sistema operativo (conosciuta come esecuzione su "bare-metal"), il grafico (e il codice dell'applicazione) sarebbe essenzialmente lo stesso se stesse usando un sistema operativo in tempo reale come FreeRTOS - l'unica differenza sarebbe un blocco aggiuntivo che mostra il componente FreeRTOS. I driver software forniscono semafori OS per evitare che due task cerchino di accedere a sezioni critiche del driver allo stesso tempo, e code per permettere alle chiamate da più chiamanti di essere gestite in serie alla stessa interfaccia hardware (come più pezzi di hardware collegati allo stesso bus I2C).