Suelen llamarse controladores de dispositivos de hardware. Proporcionan una interfaz abstracta entre los detalles particulares del hardware, y el software que quiere acceder al dispositivo, proporcionando una API (Interfaz de Programación de Aplicaciones) que se puede llamar y que es independiente del hardware.
Trabajo con el framework Harmony 3 que Microchip proporciona para facilitar a los programadores la escritura de aplicaciones para sus microcontroladores embebidos de 32 bits (tanto basados en MIPS como en ARM).
En Harmony 3, llamamos a los controladores de dispositivos de más bajo nivel «bibliotecas de periféricos» (PLIBs), para separarlos del siguiente nivel, que son controladores de software independientes del hardware.
Los PLIBs proporcionan llamadas para inicializar el hardware, escribir en (y quizás leer de) los registros de control, y escribir y leer datos en/desde el dispositivo.
El controlador de software tiene una interfaz más clásica, que implica la inicialización, la apertura y el cierre del controlador, la obtención del estado, y la adición a las colas para escribir o leer el dispositivo asociado, ya sea directamente o a través de DMA.
Esto se puede ilustrar utilizando una de mis aplicaciones, una app de streaming Bluetooth que es típica del código contenido en un par de auriculares Bluetooth.
Aquí hay un diagrama de bloques de la aplicación:
Los elementos en negro son los periféricos de hardware dentro del microcontrolador; cada uno de ellos tiene un controlador de dispositivo de hardware específico o PLIB. Los elementos en azul son los controladores de nivel superior, independientes del hardware.
El audio pasa del módulo Bluetooth BM64 al procesador a través de una interfaz I2S (Inter-IC Sound), y luego sale de nuevo a través de una segunda instancia del controlador I2S al códec AK4954 que controla los auriculares.
Aquí se ve la aplicación en el gráfico del proyecto Harmony 3, que el programador utiliza para especificar los componentes de su aplicación:
He resaltado en rojo cada uno de los PLIBs.
Aquí se ven claramente las dos instancias del I2S Driver, una para el módulo Bluetooth y otra para el códec, con cada instancia conectada a una librería periférica (I2S1 o I2S2 en este caso). Cuál se utiliza está determinado por el cableado de hardware de la placa – es decir, qué pines del procesador están conectados a qué pieza externa de hardware.
Puede haber varios PLIBs para el mismo tipo de periférico debido a las diferencias entre los chips. He escrito cuatro PLIBs diferentes para la interfaz I2S; este es el aspecto de la carpeta de la biblioteca de periféricos de audio en la versión actual de Harmony 3:
El número al final del nombre (por ejemplo, u2224) es el ID del periférico, que es específico de un procesador o familia de procesadores. Así, el i2s_u224 es para el SAME54 (ARM Cortex M4); el i2sc y ssc_6078 son para el SAME70 (ARM Cortex M7), y el spi_01329 es para la familia PIC32MX/MZ (la interfaz I2S para el PIC32 comparte el mismo hardware con la interfaz SPI).
El programador no tiene que ser consciente de estos ID’s; sólo el(los) PLIB’s apropiado(s) se presentan en el Configurador de Armonía MPLB X (MHC) cuando están seleccionando uno desde el menú de Componentes Disponibles:
Y si están utilizando una de las plantillas de audio o Bluetooth, en función de la placa de desarrollo concreta elegida se seleccionan automáticamente los PLIBs adecuados (junto con todos los controladores de software, además de las conexiones entre los componentes) para que el programador pueda crear un gráfico de proyecto como el anterior con sólo unos pocos clics de ratón.
Sin embargo, sólo hay un controlador de software I2S, ya que es independiente del hardware y funciona con cualquiera de los cuatro PLIBs I2S. El software de aplicación sólo hace llamadas a los controladores de software de nivel superior, y nunca accede directamente a los PLIBs. En este caso, la aplicación ni siquiera llama directamente a los controladores I2S o I2C – sólo son llamados indirectamente por los controladores BM64 y AK4954.
Aunque esta aplicación en particular se ejecuta sin un sistema operativo (conocido como ejecución en «bare-metal»), el gráfico (y el código de la aplicación) se vería esencialmente igual si estuviera utilizando un sistema operativo en tiempo real como FreeRTOS – la única diferencia sería un bloque adicional que muestra el componente FreeRTOS. Los controladores de software proporcionan semáforos del SO para evitar que dos tareas traten de acceder a secciones críticas del controlador al mismo tiempo, y colas para permitir que las llamadas de múltiples llamantes se manejen en serie a la misma interfaz de hardware (como múltiples piezas de hardware conectadas al mismo bus I2C).