Interfaz con sensores modernos:controladores ADC encuestados

En la última publicación, examinamos cómo en una aplicación incrustada moderna un desarrollador debe crear una interfaz que desacople los detalles de implementación del controlador de bajo nivel del código de la aplicación. Esta interfaz proporciona una abstracción arquitectónica que aumenta la escalabilidad y portabilidad del código de la aplicación haciéndolo menos dependiente del hardware.

Ahora vamos a empezar a ver varias formas diferentes en las que un desarrollador puede implementar un controlador ADC basado en las técnicas que discutimos en 3 técnicas de diseño de controladores para microcontroladores. En este artículo, examinaremos con más detalle cómo podemos usar la técnica de sondeo y discutiremos la diferencia entre controladores bloqueantes y no bloqueantes.

Bloquear o no bloquear, esa es la cuestión

Al desarrollar cualquier controlador para un microcontrolador, un desarrollador debe decidir si su controlador será bloqueante o no bloqueante. Un controlador de bloqueo esencialmente detiene la ejecución del código hasta que el controlador haya completado su tarea. Por ejemplo, la implementación típica de printf que se asigna a un UART es el bloqueo.

Cuando haces una llamada como:

printf ("¡Hola mundo!");

Un desarrollador sabe que cualquier línea de código que siga a esa declaración no se ejecutará hasta que el mensaje "¡Hola mundo!" La declaración se ha impreso en la UART. "¡Hola Mundo!" contiene doce bytes, 96 bits, pero la cantidad de tiempo que bloqueará la instrucción depende de la velocidad en baudios de UART. Para un UART configurado a 1 Mbps, esperaría unos 96 microsegundos. Para un UART configurado a 9600 bps, ¡esperaría alrededor de 10,000 microsegundos! Esa es una gran diferencia dependiendo de cómo esté configurado el hardware y puede afectar la ejecución del programa drásticamente con el controlador UART configurado como controlador de bloqueo.

Un controlador sin bloqueo es aquel que no detiene la ejecución del programa mientras el controlador está completando su tarea. Por ejemplo, printf y el controlador UART del ejemplo anterior podrían configurarse para que no se bloquee y, en cambio, permita que la aplicación continúe ejecutándose mientras cada byte se transmite fuera del UART. Esto puede hacer que la aplicación sea más eficiente en las circunstancias adecuadas, pero requiere una configuración adicional, como el uso de interrupciones, DMA o al menos un búfer de transmisión.

Decidir de qué manera diseñar su controlador depende de su aplicación y hardware. Por ejemplo, si la UART está configurada para 1 Mbps, escribir un controlador sin bloqueo probablemente no obtendrá mucho desde el punto de vista de la eficiencia y, de hecho, podría causar más problemas de los que soluciona a través de la complejidad adicional del programa. Sin embargo, si la aplicación requiere 9600 bps, donde el código de la aplicación se bloquea durante 10 milisegundos, tener un controlador sin bloqueo puede mejorar drásticamente la eficiencia del programa y el riesgo de problemas de complejidad de tiempo adicionales es mucho menor y más manejable.

Descripción general del controlador ADC integrado

Es importante tener en cuenta que en un solo blog no puedo seguir todos los pasos necesarios para escribir un controlador ADC completo. Podría escribir fácilmente un artículo de veinte páginas en él o dar un seminario web completo y probablemente no cubriría todos los detalles, pero al menos podemos ver algunas de las piezas centrales.

Hay varias formas en que podríamos organizar un controlador ADC, pero la forma en que me gusta organizarlos requiere tres componentes:

• El controlador de bajo nivel
• El código de la aplicación
• Un módulo de configuración

El controlador de bajo nivel toma el módulo de configuración durante la inicialización y configura el hardware según la configuración. El controlador de bajo nivel proporciona una capa de abstracción de hardware común (HAL) que luego puede usar el código de la aplicación. Las llamadas ADC HAL deben ser genéricas para que la aplicación de alto nivel pueda configurar el hardware de la forma que sea necesaria y para que pueda ser reutilizable y escalable. Por ejemplo, algunas llamadas ADC HAL que he usado en el pasado incluyen:

• 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 (Función const AdcCallback_t, TYPE (* CallbackFunction) (tipo));

Las primeras tres API brindan la capacidad de inicializar el hardware ADC, iniciar una conversión y luego verificar el estado de la conversión. Las últimas tres funciones están diseñadas para permitir la escalabilidad al hardware de bajo nivel. Por ejemplo, si la HAL no proporciona una opción necesaria para la aplicación, como convertir un solo canal ADC, la HAL se puede extender usando las funciones Adc_RegisterRead y Adc_RegisterWrite. Esto proporciona flexibilidad en función de las necesidades de la aplicación sin crear una API abrumadora.

Escritura de un controlador ADC de bloqueo simple

Podemos escribir un controlador ADC realmente simple que esté por encima de la capa de hardware. Por ejemplo, podemos crear una función simple llamada Adc_Sample que inicia el hardware ADC y luego almacena todos los resultados en un búfer al que la aplicación puede acceder. El búfer que almacena los valores de recuento de valores analógicos no necesariamente necesita almacenar un solo valor, sino que puede almacenar varios valores que luego se podrían promediar o filtrar según las necesidades de la aplicación. La versión de bloqueo de la función de muestreo podría tener un aspecto similar al siguiente:

Como puede ver en este código, el ciclo while bloquea la ejecución hasta que el hardware ADC ha completado su conversión y luego almacena los valores en el búfer de la aplicación.

Escritura de un controlador ADC simple sin bloqueo

Convertir el controlador de bloqueo en código sin bloqueo es bastante simple, pero requeriría cambios en el código de la aplicación de nivel superior. Por ejemplo, ahora mismo, si la aplicación quiere muestrear los sensores, un desarrollador llama:

Adc_Sample ();

En la versión sin bloqueo, un desarrollador debe verificar el valor de retorno de Adc_Sample para ver si las muestras están completas y listas para usarse. Esto permite que las muestras se ejecuten en segundo plano y que el código de la aplicación continúe ejecutándose con las siguientes actualizaciones de nuestro código de controlador:

Conclusiones

Como hemos visto en esta publicación, hay varias formas de escribir un ADC y la implementación puede ser bloqueante o no bloqueante según nuestras necesidades. Los controladores de bloqueo tienden a ser más simples y menos completos que los controladores sin bloqueo, pero pueden ser ineficaces. Los controladores sin bloqueo permiten que se ejecute otro código mientras el controlador funciona, pero el código de la aplicación aún necesita verificar el estado, lo que en sí mismo es ineficiente en una implementación encuestada.

En el próximo artículo de esta serie, examinaremos cómo podemos escribir una aplicación que muestrea un sensor a través de un periférico ADC que usa interrupciones.