Interfaçage avec des capteurs modernes :pilotes ADC interrogés

Dans le dernier article, nous avons examiné comment, dans une application embarquée moderne, un développeur devrait créer une interface qui dissocie les détails d'implémentation du pilote de bas niveau du code de l'application. Cette interface fournit une abstraction architecturale qui augmente l'évolutivité et la portabilité du code de l'application en le rendant moins dépendant du matériel.

Nous allons maintenant commencer à examiner plusieurs manières différentes pour un développeur d'implémenter un pilote ADC sur la base des techniques que nous avons discutées dans 3 techniques de conception de pilotes pour microcontrôleurs. Dans cet article, nous examinerons plus en détail comment utiliser la technique d'interrogation et discuterons de la différence entre les pilotes bloquants et non bloquants.

Bloquer ou ne pas bloquer, telle est la question

Lors du développement d'un pilote pour un microcontrôleur, un développeur doit décider si son pilote sera bloquant ou non bloquant. Un pilote bloquant bloque essentiellement l'exécution du code jusqu'à ce que le pilote ait terminé sa tâche. Par exemple, l'implémentation typique de printf mappée à un UART est bloquante.

Lorsque vous passez un appel comme :

printf("Bonjour tout le monde!");

Un développeur sait que la ligne de code qui suit cette instruction ne s'exécutera pas avant l'intégralité du message "Hello World!" déclaration a été imprimée sur l'UART. "Bonjour le monde!" contient douze octets, 96 bits, mais la durée de blocage de l'instruction dépend du débit en bauds de l'UART. Pour un UART configuré à 1 Mbps, vous vous attendez à environ 96 microsecondes. Pour un UART configuré à 9600 bps, vous vous attendez à environ 10 000 microsecondes ! C'est une grande différence selon la façon dont le matériel est configuré et cela peut affecter considérablement l'exécution du programme avec le pilote UART configuré comme pilote bloquant.

Un pilote non bloquant est un pilote qui ne bloque pas l'exécution du programme pendant que le pilote termine sa tâche. Par exemple, printf et le pilote UART de l'exemple précédent pourraient être configurés de sorte qu'il ne se bloque pas et permette à la place à l'application de continuer à s'exécuter pendant que chaque octet est transmis à l'UART. Cela peut rendre l'application plus efficace dans les bonnes circonstances, mais nécessite une configuration supplémentaire telle que l'utilisation d'interruptions, de DMA ou au moins d'un tampon de transmission.

Le choix de la manière de concevoir votre pilote dépend de votre application et de votre matériel. Par exemple, si l'UART est configuré pour 1 Mbps, l'écriture d'un pilote non bloquant ne gagnera probablement pas grand-chose du point de vue de l'efficacité et pourrait en fait causer plus de problèmes qu'il n'en résout en raison de la complexité supplémentaire du programme. Cependant, si l'application demande 9 600 bits/s, lorsque le code de l'application est bloqué pendant 10 millisecondes, le fait d'avoir un pilote non bloquant peut considérablement améliorer l'efficacité du programme et le risque de problèmes de complexité de synchronisation supplémentaires est beaucoup moins et plus gérable.

Présentation du pilote ADC intégré

Il est important de noter que dans un seul blog, je ne peux pas parcourir toutes les étapes nécessaires pour écrire un pilote ADC complet. Je pourrais facilement écrire un article de vingt pages dessus ou donner un webinaire entier et il ne couvrirait probablement pas encore tous les détails, mais nous pouvons au moins examiner quelques-uns des éléments essentiels.

Il existe plusieurs façons d'organiser un pilote ADC, mais la façon dont j'aime les organiser nécessite trois composants :

• Le pilote de bas niveau
• Le code de candidature
• Un module de configuration

Le pilote de bas niveau prend le module de configuration lors de l'initialisation et configure le matériel en fonction de la configuration. Le pilote de bas niveau fournit une couche d'abstraction matérielle (HAL) commune que le code de l'application peut ensuite utiliser. Les appels ADC HAL doivent être génériques afin que l'application de haut niveau puisse configurer le matériel de toute manière nécessaire et afin qu'il puisse être réutilisable et évolutif. Par exemple, quelques appels ADC HAL que j'ai utilisés dans le passé 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 Adresse );
• void Adc_CallbackRegister(AdcCallback_t const Function, TYPE (*CallbackFunction)(type));

Les trois premières API offrent la possibilité d'initialiser le matériel ADC, de démarrer une conversion, puis de vérifier l'état de la conversion. Les trois dernières fonctions sont conçues pour permettre une évolutivité vers le matériel de bas niveau. Par exemple, si HAL ne fournit pas une option nécessaire à l'application, telle que la conversion d'un seul canal ADC, la HAL peut être étendue à l'aide des fonctions Adc_RegisterRead et Adc_RegisterWrite. Cela offre une flexibilité basée sur les besoins de l'application sans créer une API écrasante.

Écrire un pilote ADC bloquant simple

Nous pouvons écrire un pilote ADC très simple qui se trouve au-dessus de la couche matérielle. Par exemple, nous pouvons créer une fonction simple nommée Adc_Sample qui lance le matériel ADC, puis stocke tous les résultats dans un tampon auquel l'application peut ensuite accéder. Le tampon qui stocke les valeurs de comptage des valeurs analogiques n'a pas nécessairement besoin de stocker une seule valeur, mais peut stocker plusieurs valeurs qui pourraient ensuite être moyennées ou filtrées en fonction des besoins de l'application. La version bloquante de la fonction d'échantillonnage peut ressembler à ceci :

Comme vous pouvez le voir dans ce code, la boucle while bloque l'exécution jusqu'à ce que le matériel ADC ait terminé sa conversion, puis stocke les valeurs dans le tampon de l'application.

Écrire un pilote ADC non bloquant simple

La conversion du pilote bloquant en code non bloquant est assez simple, mais cela nécessiterait des modifications du code d'application de niveau supérieur. Par exemple, maintenant, si l'application souhaite échantillonner les capteurs, un développeur appelle :

Adc_Sample();

Dans la version non bloquante, un développeur doit vérifier la valeur de retour de Adc_Sample pour voir si les échantillons sont terminés et prêts à être utilisés. Cela permet aux exemples de s'exécuter en arrière-plan et au code d'application de continuer à s'exécuter avec les mises à jour suivantes de notre code de pilote :

Conclusion

Comme nous l'avons vu dans cet article, il existe plusieurs façons d'écrire un ADC et l'implémentation peut être bloquante ou non bloquante en fonction de nos besoins. Les pilotes bloquants ont tendance à être plus simples et moins complets que les pilotes non bloquants, mais ils peuvent être inefficaces. Les pilotes non bloquants permettent à d'autres codes de s'exécuter pendant que le pilote fonctionne, mais le code de l'application doit toujours vérifier l'état, ce qui en soi est inefficace dans une implémentation interrogée.

Dans le prochain article de cette série, nous examinerons comment nous pouvons écrire une application qui échantillonne un capteur via un périphérique ADC qui utilise des interruptions.