Conception drivers ADC : techniques polling bloquant vs non-bloquant

Dans notre article précédent, nous avons exploré comment une interface bien structurée peut séparer détails driver bas niveau de la logique applicative, boostant scalabilité et portabilité across plateformes hardware.

Dans cette entrée, nous plongeons dans les implémentations pratiques de driver ADC, focalisant sur l'approche polling. Nous contrasterons designs bloquant et non-bloquant et montrerons comment chacun impacte la performance système.

Drivers bloquant vs non-bloquant

En créant un driver microcontrôleur, un développeur doit décider si l'API bloquera l'exécution jusqu'à completion de l'opération. Un driver bloquant halt le flux programme, assurant que le code subséquent s'exécute seulement après fin de tâche. Un exemple classique est un printf backed par UART :

printf("Hello World!"); 

Avec un driver UART bloquant, la ligne suivant cet appel ne s'exécutera pas tant que la chaîne 12-octets (96 bits) n'a pas été fully transmise. Le délai réel dépend du baud rate : à 1 Mbps, le bloc dure ~96 µs ; à 9,6 kbps, il s'étire à ~10 ms.

Inversement, un driver non-bloquant initie le transfert et retourne immédiatement le contrôle à l'application. L'UART peut alors continuer traitement pendant que les données sortent, typiquement via interruptions, DMA, ou buffer de transmission. Cette approche améliore l'efficacité en contextes latency-sensitive mais ajoute complexité au driver et application.

Choisir le bon modèle dépend des exigences timing de l'application et configuration hardware. Pour UARTs haute vitesse (ex. 1 Mbps), l'overhead d'un design non-bloquant peut outweigh ses bénéfices. Pour liens plus lents (ex. 9,6 kbps), un driver non-bloquant peut débloquer gains de performance significatifs avec complexité ajoutée gérable.

Architecturer un driver ADC

Un driver ADC robuste comprend typiquement trois couches :

• Le driver bas niveau, qui accepte une structure de configuration pendant l'initialisation et configure les registres hardware.
• Le code applicatif, qui appelle fonctions HAL génériques pour démarrer conversions et récupérer résultats.
• Un module de configuration abstraisant paramètres device-spécifiques.

Le driver bas niveau fournit une Hardware Abstraction Layer (HAL) avec API concise, réutilisable. Exemples de projets réels incluent :

• AdcError_t Adc_Init(const AdcConfig_t * Config);
• AdcError_t Adc_StartConversion(void);
• bool Adc_ConversionComplete(void);
• void Adc_RegisterWrite(uint32_t const Address, uint32_t const Value);
• uint32_t Adc_RegisterRead(uint32_t Address);
• void Adc_CallbackRegister(AdcCallback_t const Function, TYPE (*CallbackFunction)(type));

Ces APIs permettent initialisation straightforward, contrôle conversion, et polling statut. Les helpers d'accès registres permettent aux développeurs d'étendre le HAL pour fonctionnalités custom, comme conversions single-channel, sans gonfler l'API publique.

Implémenter un driver ADC bloquant simple

Un driver bloquant minimal pourrait exposer une unique routine Adc_Sample qui démarre le hardware, attend completion, et copie le résultat dans un buffer fourni par l'appelant. Le code ci-dessous démontre l'idée core :

La boucle while bloque jusqu'à ce que Adc_ConversionComplete retourne true, après quoi le driver lit les registres de conversion et stocke les échantillons.

Conversion vers driver ADC non-bloquant

Passer à un modèle non-bloquant requiert un petit changement dans l'API : l'appelant reçoit maintenant un flag de statut et doit poller pour completion. La fonction mise à jour pourrait ressembler à ceci :

Dans l'application, une séquence typique devient :

Adc_Sample(); while (!Adc_ConversionComplete()) { // Perform other tasks } // Read results 

Cette approche libère le CPU pour exécuter du code non lié pendant que le hardware ADC complete sa conversion.

Points clés

Les drivers ADC bloquant et non-bloquant ont des avantages distincts :

• Drivers bloquants sont simples et ne requièrent pas gestion d'état additionnelle mais peuvent staller paths critiques.
• Drivers non-bloquants permettent exécution concurrente, améliorant throughput global, mais demandent vérification de statut soigneuse et logique driver potentiellement plus complexe.

Dans le prochain post, nous étendrons cette discussion en démontrant un driver ADC basé interruptions qui découple encore plus l'acquisition capteur de la logique applicative.