5 formas en que una capa de abstracción de hardware puede transformar sus proyectos
Jacob de Benín | 05 de junio de 2023
Los desarrolladores de software integrado generalmente han evitado las capas de abstracción de hardware (HAL) al afirmar que reducen el rendimiento y aumentan la complejidad del código. Desafortunadamente, cuando los desarrolladores adoptan una HAL, una HAL proporcionada por el proveedor a menudo no abstrae el hardware y aun así garantiza un acoplamiento estrecho con el hardware. Después de todo, una HAL abstracta real permitiría a un desarrollador usar cualquier proveedor en un abrir y cerrar de ojos. Sin embargo, hay muchas maneras en que el uso o el desarrollo de su propia HAL puede afectar su software. En esta publicación, exploraremos cinco maneras sorprendentes en que una HAL puede transformar sus proyectos de software y liberar velocidad y valor que no sabía que era posible.
En general, descubrí que los desarrolladores suelen tener un proveedor de microcontroladores favorito. Por lo general, es el proveedor en el que primero escribió su software integrado o con el que está familiarizado. Tengo mis favoritos como cualquier otra persona, pero puede ser peligroso escribir su software dependiendo de su HAL o bibliotecas de software. Por ejemplo, ¿qué haces si de repente no puedes obtener sus microcontroladores? Tendría que seleccionar un nuevo proveedor y luego reescribir, probar y tal vez incluso certificar su producto. ¡Eso no es rápido ni barato! Si bien puede pensar que esto es poco probable, sucedió durante COVID y muchas veces antes.
El uso de una buena HAL le permitirá escribir un código de aplicación más portátil y reutilizable que sea independiente del hardware. Esa es una transformación masiva para muchos equipos integrados. Por ejemplo, podría ejecutar su código con el proveedor A y, al cambiar un indicador en su compilación, compilar para el proveedor B. La independencia del hardware le brinda la flexibilidad de usar cualquier hardware que desee y elimina la dependencia de su proveedor de microcontrolador.
Si le gusta la idea de usar la HAL proporcionada por el proveedor, está bien siempre y cuando revise varias características esenciales. Primero, el HAL debe ser un HAL real. Eso significa que debe tener una interfaz definida que rompa la dependencia del hardware. Discutimos esto en mi blog titulado "Escribir capas de abstracción de hardware (HAL) en C". A menudo veo "HAL" que no son más que funciones con la implementación. Eso no obedece al principio de inversión de dependencia y es igual de difícil de actualizar el código. A continuación, la HAL debe definirse por separado de la implementación. Finalmente, debería poder intercambiar rápidamente la función llamada por la interfaz. Si no tiene estas tres cosas, entonces no tiene independencia de hardware; usted tiene dependencia de hardware!
La clave para liberar valor y transformar su desarrollo de software comienza con el uso de una HAL. La HAL permite además transformaciones adicionales, como la habilitación de pruebas unitarias y de integración automatizadas. Los desarrolladores integrados a menudo luchan con las pruebas unitarias porque escriben código que toca el hardware. Eso significa que debe ejecutar sus pruebas en el microcontrolador. Cuando tiene un HAL adecuado, sí, aún necesita probar sus controladores en el objetivo, ¡pero todo el código de su aplicación se libera repentinamente! El código de su aplicación ahora se puede probar por unidad e integración en una máquina host independiente del hardware.
Eliminar el hardware de la ecuación y trasladar las pruebas al host beneficia a los desarrolladores. Primero, es más rápido. No tiene que preocuparse por todos esos ciclos lentos de borrado y escritura en la pieza. En segundo lugar, no necesita preocuparse por el tamaño de su arnés de prueba o cuántas pruebas tiene. En lugar de intentar adaptar su código y las pruebas en el microcontrolador, primero prueba todo el código de la aplicación en su host. A continuación, pasar a probar fuera del objetivo le permite utilizar la integración continua e incluso la implementación continua si lo desea. El resultado será detectar errores antes y más rápido, reducir los costos y mejorar la calidad.
Cuando saca el hardware de la ecuación usando un buen HAL, le permite poner cualquier implementación detrás de él. ¡Eso significa que puede tener una implementación para su objetivo, su arnés de prueba y un entorno de simulación! En muchos casos, los desarrolladores de software integrado deben comenzar a escribir software antes de que el hardware esté disponible. Entonces, si bien podemos usar placas de desarrollo para comenzar, con un buen HAL, ¡podemos ejecutar simulaciones en nuestro código de aplicación!
La simulación del código de la aplicación tiene muchas ventajas para los desarrolladores. En primer lugar, les permite obtener el código de la aplicación frente a sus clientes lo antes posible. Todos sabemos que a los clientes les encanta cambiar de opinión y tienen dificultades para visualizar cómo funcionará un producto hasta que puedan jugar con él. La simulación puede ayudar al cliente a comprender el producto y proporcionar comentarios productivos antes, lo que reduce los cambios costosos y que requieren mucho tiempo más adelante en el ciclo de desarrollo.
A continuación, la simulación permite realizar pruebas más sólidas al permitir que se prueben fallas y otros comportamientos aberrantes sin el hardware. Por ejemplo, hacer que un sensor se comporte mal o forzar una excepción de hardware en el procesador de destino a menudo puede ser un desafío. En un entorno de simulación, esto no es un problema. El resultado nuevamente es un software más robusto.
Cuando realiza la depuración en el destino, cada vez que se realiza un cambio, hay un ciclo de compilación cruzada, borrar flash, programar flash y ejecutar la aplicación. Todo el proceso puede llevar bastante tiempo, dependiendo de la aplicación, incluso con herramientas profesionales. ¡Usar un HAL para separar la aplicación permite que el código se depure más rápido! En un host, el ciclo de compilación y ejecución es mucho más corto. Eso significa que los desarrolladores pueden resolver los problemas más rápidamente y luego probar la versión final depurada en su hardware cuando sea necesario.
Si permite que las otras transformaciones que proporciona una HAL se realicen, utilizará las pruebas unitarias para impulsar el desarrollo, lo que significa que incluso dedicará menos tiempo a la depuración. Solo escribirá código para pasar la prueba. Su software se escribirá en pequeños incrementos, con pruebas validándolo todo el tiempo. Si rompe algo, las pruebas de regresión lo detectarán de inmediato. ¡El resultado será una depuración más rápida y eficiente y la eliminación casi completa de la depuración de su vida y proyecto! ¿No suena maravilloso?
La última transformación para usar una HAL para desarrollar software integrado es que reducirá los costos y el tiempo de comercialización. Una HAL crea una flexibilidad en el software integrado con la que la mayoría de los equipos nunca sueñan. Puede ver fácilmente que si puede obtener comentarios de los clientes rápidamente, tendrá menos reelaboración al final del ciclo de desarrollo. Además, si puede eliminar la depuración, ¡eso es enorme! ¡La mayoría de los equipos dedican, en promedio, del 20 al 40 % de su ciclo de desarrollo a la depuración! ¡Eso es de 2,4 a 4,5 meses al año por persona! Todo porque usó una HAL que permite probar el código de su aplicación y reducir el tiempo de depuración.
Con menores tiempos de comercialización, se hace evidente que el costo será menor. Ciertamente hay una inversión en el desarrollo de HAL, arneses de prueba y otras herramientas para garantizar que el ciclo de desarrollo transcurra sin problemas. Sin embargo, esos costos son a menudo un orden de magnitud menor de lo que se ahorrará. Ni siquiera he mencionado los gastos relacionados con el mantenimiento que pueden superar fácilmente los costos iniciales de desarrollo.
A menudo he tenido clientes y colegas que comentan cuánto puedo hacer. El secreto ha sido que he desbloqueado las transformaciones que una HAL puede proporcionar a los desarrolladores integrados. Como ha visto en esta publicación, el uso de un HAL "real" puede transformar drásticamente su proyecto y la forma en que desarrolla software integrado.
Algunas de las transformaciones que hemos discutido pueden parecer un poco extrañas porque los desarrolladores de software integrado tradicionalmente no han usado estas técnicas. Sin embargo, no lleva mucho tiempo ponerse al día con ellos y permitirles mejorar drásticamente la forma en que desarrolla el software integrado. Has visto los beneficios; la pregunta es si los aceptará y comenzará a construir un HAL independiente del microcontrolador en su software. Si lo hace, creo que revolucionará la forma en que desarrolla sus productos integrados.
Más información sobre formatos de texto