Diseño de drivers ADC: Técnicas de sondeo bloqueante vs no bloqueante

En nuestro artículo anterior exploramos cómo una interfaz bien estructurada puede separar detalles de driver de bajo nivel de la lógica de aplicación, mejorando escalabilidad y portabilidad entre plataformas hardware.

En esta entrada profundizamos en implementaciones prácticas de driver ADC, enfocándonos en el enfoque de sondeo (polling). Contrastaremos diseños bloqueante y no bloqueante y mostraremos cómo cada uno impacta rendimiento del sistema.

Drivers Bloqueante vs No Bloqueante

Al crear un driver de microcontrolador, un desarrollador debe decidir si la API bloqueará ejecución hasta que la operación complete. Un driver bloqueante detiene el flujo del programa, asegurando que código subsiguiente solo corra tras finalizar la tarea. Un ejemplo clásico es un printf respaldado por UART:

printf("Hello World!"); 

Con un driver UART bloqueante, la línea siguiente a esta llamada no correrá hasta que la cadena de 12 bytes (96 bits) se haya transmitido completamente. El retraso real depende del baud rate: a 1 Mbps, el bloqueo dura ~96 µs; a 9.6 kbps, se estira a ~10 ms.

Por el contrario, un driver no bloqueante inicia la transferencia y retorna control a la aplicación inmediatamente. El UART puede entonces continuar procesando mientras los datos fluyen, típicamente vía interrupciones, DMA, o buffer de transmisión. Este enfoque mejora eficiencia en contextos sensibles a latencia pero añade complejidad al driver y aplicación.

Elegir el modelo correcto depende de las demandas de temporización de la aplicación y configuración hardware. Para UARTs de alta velocidad (ej. 1 Mbps), el overhead de diseño no bloqueante puede superar sus beneficios. Para enlaces más lentos (ej. 9.6 kbps), un driver no bloqueante puede desbloquear ganancias significativas de rendimiento con complejidad añadida manejable.

Arquitectura de un Driver ADC

Un driver ADC robusto típicamente comprende tres capas:

• El driver de bajo nivel, que acepta una estructura de configuración durante inicialización y configura registros hardware.
• El código de aplicación, que llama funciones HAL genéricas para iniciar conversiones y recuperar resultados.
• Un módulo de configuración que abstrae parámetros dispositivo-específicos.

El driver de bajo nivel provee una Capa de Abstracción Hardware (HAL) con API concisa y reutilizable. Ejemplos de proyectos reales 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(AdcCallback_t const Function, TYPE (*CallbackFunction)(type));

Estas APIs permiten inicialización directa, control de conversión y sondeo de estado. Los helpers de acceso a registro permiten a desarrolladores extender el HAL para características personalizadas, como conversiones single-channel, sin inflar la API pública.

Implementando un Driver ADC Bloqueante Simple

Un driver bloqueante mínimo podría exponer una sola rutina Adc_Sample que inicia el hardware, espera completación y copia el resultado a un buffer provisto por el llamador. El código abajo demuestra la idea central:

El bucle while bloquea hasta que Adc_ConversionComplete retorna true, tras lo cual el driver lee los registros de conversión y almacena las muestras.

Convirtiendo a un Driver ADC No Bloqueante

Cambiar a modelo no bloqueante requiere pequeño cambio en la API: el llamador ahora recibe una bandera de estado y debe sondear para completación. La función actualizada podría verse así:

En la aplicación, una secuencia típica se vuelve:

Adc_Sample(); while (!Adc_ConversionComplete()) { // Realizar otras tareas } // Leer resultados 

Este enfoque libera la CPU para ejecutar código no relacionado mientras el hardware ADC completa su conversión.

Conclusiones

Ambos drivers ADC, bloqueante y no bloqueante, tienen ventajas distintas:

• Drivers bloqueantes son simples y no requieren gestión de estado adicional pero pueden paralizar rutas críticas.
• Drivers no bloqueantes permiten ejecución concurrente, mejorando throughput general, pero demandan verificación cuidadosa de estado y lógica de driver potencialmente más compleja.

En el próximo post, extenderemos esta discusión demostrando un driver ADC basado en interrupciones que desacopla aún más la adquisición de sensores de la lógica de aplicación.