Transición de desarrollador de LabVIEW a desarrollador de firmware

Cuando empecé en Erdos Miller, hacía desarrollo en LabVIEW para clientes. Un día, mi jefe me preguntó qué me parecería hacer un proyecto de firmware. Yo no tenía ninguna experiencia con el desarrollo de firmware, pero estaba listo para el reto. Esta transición no ha sido fácil, pero he aprendido mucho. Me gustaría compartir lo que suelo hacer y lo que he aprendido en mi camino para convertirme en desarrollador de firmware.

La mayoría de las aplicaciones que desarrollé como desarrollador de LabVIEW eran para sistemas de superficie, laboratorios y entornos de fabricación. Las aplicaciones se ejecutarían en una máquina Windows o National Instruments CompactRIO. En ambos escenarios, realmente no importaba en qué entorno se ejecutaba la aplicación, LabVIEW se encargaba de las interfaces de hardware de bajo nivel. El entorno de desarrollo era gráfico y requería conectar cables. Creé varias interfaces de usuario para mostrar datos en vivo y guardados con fines de verificación y análisis. Esto iba a ser muy diferente de lo que haría como desarrollador de firmware. Ahora programaría en C, no crearía interfaces de usuario y gestionaría todas las interacciones de hardware de bajo nivel.

Verificar la placa de pruebas contra el esquema

Una de las mejores maneras de ganar experiencia es trabajando en un proyecto real. Mi primera tarea fue configurar un sistema de archivos en una MCU de TI. Por suerte, tenía código de ejemplo de otro proyecto para revisar y bibliotecas de sistemas de archivos con las que trabajar. Como el sistema de archivos abarcaría varios chips flash, tuve que revisar el esquema de la placa para ver cómo se conectaban las cosas a la MCU y qué protocolo de comunicación se necesitaba para comunicarse con los chips flash. Cuando fui a probar el código, la Interrupción 19 se disparó. Pude usar puntos de interrupción mientras depuraba para descubrir que los chips flash no estaban instalados en mi placa de desarrollo. Lo que aprendí de esto es que siempre debo revisar la placa y el esquema para asegurarme de que todas las partes han sido instaladas.

Memoria limitada

Cuando se trabaja con MCUs, la memoria es muy importante y limitada. Esto no era una preocupación cuando se desarrolla en LabVIEW. Había un módulo que actualicé que requería asignar un array de caracteres muy grande. Resultó que no tenía suficiente memoria y no podía construir el código. La guía de referencia para el MCU ayudó con el aumento de la memoria RAM asignada. Aún así no fue suficiente y tuve que modificar el código para trabajar con trozos más pequeños de la matriz de caracteres.

Interrupciones de Hardware, Interrupciones de Software, Tareas y Prioridad

El control de las interrupciones por parte del usuario en LabVIEW es inexistente. El sistema operativo gestiona múltiples hilos e interrupciones de hardware. Como mucho, podemos crear bucles temporizados con una afinidad y prioridad de núcleo particular. Con MCUs, el programador es responsable de configurar las interrupciones de hardware, las interrupciones de software y las tareas. Las interrupciones de hardware suelen ser activadas por dispositivos externos o temporizadores de la CPU. Son tareas de tiempo crítico. Las interrupciones de software son solicitadas por el propio procesador y suelen procesar datos procedentes de una interrupción de hardware. Los hilos de tareas son menos prioritarios que una interrupción de software y pueden esperar hasta que los recursos estén disponibles para ejecutarse. Como ejemplo, se puede utilizar un semáforo para pausar una tarea hasta que los datos estén disponibles para ser procesados. Como parte del desarrollo de mi sistema de ficheros, también necesitaba registrar periódicamente los ficheros. Como el registro no era extremadamente crítico, lo configuré como una tarea. De lo que no me di cuenta es que le di una prioridad mayor que a una tarea más importante. Esto causó que otras funcionalidades se rompieran porque ahora esta tarea estaba bloqueando la ejecución de otras tareas.

Mi viaje como desarrollador de firmware continuará; tengo más que aprender. Con cualquier cambio de carrera, hay retos, pero con la actitud y la determinación adecuadas, se pueden superar.