Ils sont généralement appelés pilotes de périphériques matériels. Ils fournissent une interface abstraite entre les détails particuliers du matériel, et le logiciel qui veut accéder au périphérique, en fournissant une API (interface de programmation d'application) qui peut être appelée et qui est indépendante du matériel.
Je travaille avec le cadre Harmony 3 que Microchip fournit pour faciliter aux programmeurs l'écriture d'applications pour ses microcontrôleurs 32 bits embarqués (basés sur MIPS et ARM).
Dans Harmony 3, nous appelons les pilotes de périphériques de plus bas niveau "bibliothèques de périphériques" (PLIB), pour les séparer du niveau supérieur suivant qui sont des pilotes logiciels indépendants du matériel.
Les PLIB fournissent des appels pour initialiser le matériel, écrire dans (et peut-être lire à partir de) des registres de contrôle, et écrire et lire des données vers/depuis le périphérique.
Le pilote logiciel a une interface plus classique, qui implique l'initialisation, l'ouverture et la fermeture du pilote, l'obtention de l'état et l'ajout aux files d'attente pour l'écriture ou la lecture du périphérique associé, soit directement, soit via DMA.
Cela peut être illustré à l'aide d'une de mes applications, une application de streaming Bluetooth qui est typique du code contenu dans une paire d'écouteurs Bluetooth.
Voici un schéma fonctionnel de l'application :
Les éléments en noir sont les périphériques matériels à l'intérieur du microcontrôleur ; chacun d'entre eux possède un pilote de périphérique matériel ou PLIB spécifique. Les éléments en bleu sont les pilotes de plus haut niveau, indépendants du matériel.
L'audio passe du module Bluetooth BM64 au processeur via une interface I2S (Inter-IC Sound), puis ressort à nouveau via une deuxième instance du pilote I2S vers le codec AK4954 qui pilote les écouteurs.
Voici à quoi ressemble l'application dans le graphe du projet Harmony 3, que le programmeur utilise pour spécifier les composants de son application:
J'ai souligné chacune des PLIB en rouge.
Ici, vous pouvez clairement voir les deux instances le du pilote I2S, une pour le module Bluetooth et une pour le codec, avec chaque instance connectée à une bibliothèque périphérique (I2S1 ou I2S2 dans ce cas). Celle qui est utilisée est déterminée par le câblage matériel de la carte - c'est-à-dire quelles broches du processeur sont connectées à quel élément matériel externe.
Il peut y avoir plusieurs PLIB pour le même type de périphérique en raison des différences entre les puces. J'ai écrit quatre PLIB différents pour l'interface I2S ; voici à quoi ressemble le dossier de la bibliothèque de périphériques audio dans la version actuelle d'Harmony 3:
Le nombre à la fin du nom (par exemple u2224) est l'ID du périphérique, qui est spécifique à un processeur ou à une famille de processeurs. Ainsi, le i2s_u224 est pour le SAME54 (ARM Cortex M4) ; le i2sc et le ssc_6078 sont pour le SAME70 (ARM Cortex M7), et le spi_01329 est pour la famille PIC32MX/MZ (l'interface I2S pour le PIC32 partage le même matériel que l'interface SPI).
Le programmeur n'a pas besoin de connaître ces identifiants ; seuls les PLIB appropriés sont présentés dans le configurateur Harmony MPLB X (MHC) lorsqu'il en sélectionne un dans le menu des composants disponibles :
Et s'ils utilisent l'un des modèles audio ou Bluetooth, en fonction de la carte de développement particulière choisie, les PLIB appropriées sont automatiquement sélectionnées (ainsi que tous les pilotes logiciels, plus les connexions entre les composants) afin que le programmeur puisse créer un graphique de projet comme celui de tout à l'heure en quelques clics de souris.
Il n'y a cependant qu'un seul pilote logiciel I2S, car il est indépendant du matériel et fonctionne avec n'importe lequel des quatre PLIB I2S. Le logiciel d'application n'effectue que des appels aux pilotes logiciels de niveau supérieur, et n'accède jamais directement aux PLIB. Dans ce cas, l'application n'appelle même jamais directement les pilotes I2S ou I2C - ils ne sont qu'indirectement appelés par les pilotes BM64 et AK4954.
Bien que cette application particulière fonctionne sans système d'exploitation (connu comme fonctionnant sur "bare-metal"), le graphique (et le code de l'application) aurait essentiellement le même aspect si elle utilisait un OS en temps réel tel que FreeRTOS - la seule différence serait un bloc supplémentaire montrant le composant FreeRTOS. Les pilotes logiciels fournissent des sémaphores d'OS pour empêcher deux tâches d'essayer d'accéder aux sections critiques du pilote en même temps, et des files d'attente pour permettre aux appels de plusieurs appelants d'être traités en série à la même interface matérielle (comme plusieurs pièces de matériel connectées au même bus I2C).