Ecosistemas de desarrollo en sistemas embebidos

Procesador de aplicaciones

El procesador de aplicaciones en esta demo es un MCU SAM E54 que ejecuta Zephyr RTOS (Sistema Operativo en Tiempo Real).

Una de las mayores ventajas de Zephyr frente a otros RTOS y cadenas de herramientas es la forma en que la API (Interfaz de Programación de Aplicaciones) se mantiene uniforme, con divisiones claras entre el código específico del proveedor y las APIs abstractas de nivel superior.

Esto permite a los desarrolladores escribir código que funciona en múltiples MCUs diferentes con mínimos dolores de cabeza.

Zephyr también cuenta con un excelente soporte de redes y una lista de capacidades cada vez mayor que lo convierten en imprescindible para aplicaciones complejas.

Zephyr es de código abierto (licencia Apache 2.0) con una base de usuarios muy activa y soporte para múltiples herramientas de programación diferentes como, pero no limitado a: OpenOCD, Segger J-Link y gdb.

Otros ecosistemas

Más allá de los ecosistemas usados directamente en la demostración del invernadero, hay varias otras opciones. Algunos de los ejemplos más populares incluyen IAR Embedded Workbench, Arm Keil, Necto Studio de MikroE y SEGGER Embedded Studio. Estas herramientas son ofertas premium con funciones avanzadas y soporte de alta calidad a la altura.

Por ejemplo, recientemente tuve un problema al arrancar Zephyr en un MCU donde no podía acceder a los depuradores habituales y printf no era una opción.

Usé SEGGER Ozone con un J-Link+ para solucionar este problema complejo. Ozone es un entorno especial de depuración que prescinde de las pestañas habituales del IDE para ofrecer al desarrollador ventanas y pantallas más especializadas.

En mi caso, el problema ocurrió porque el MCU arrancaba correctamente desde el depurador, pero no desde un arranque en frío.

Tras un tiempo de pruebas y diagnósticos, finalmente determiné que uno de los fallos era un error de inicialización de RAM en mi código.

Solucioné el problema con un pequeño fragmento de ensamblador de arranque que se ejecutaba antes de que el kernel principal arrancara.

El fragmento de ensamblaje que escribí está adjunto abajo para quien esté interesado.

#include

#include

#include

#define SRAM_NODE DT_CHOSEN(zephyr_sram)

_ASM_FILE_PROLOGUE

GTEXT(soc_reset_hook)

SECTION_FUNC(TEXT, soc_reset_hook)

/* Init the start and stop addresses

* R1 = Current Index

* R2 = Bytes to write (remaining)

* R3 = Zero

*/

ldr r1, = DT_REG_ADDR(SRAM_NODE)

ldr r2, = DT_REG_SIZE(SRAM_NODE)

eors r3, r3

b CLEAR_LOOP

CLEAR_LOOP:

str r3, [r1]

adds r1, #4

subs r2, r2, #4

cbz r2, INIT_DONE

b CLEAR_LOOP

INIT_DONE:

bx lr

La moraleja es que los otros entornos de desarrollo ofrecen ventajas únicas.

Otro ejemplo de esto es que IAR añadió soporte para Zephyr a su solución IDE.

En muchos sentidos, la elección de qué ecosistema desarrollar depende de la preferencia personal. No hay realmente una respuesta equivocada, si hace lo que necesitas para que tu diseño funcione.

La demostración del invernadero encarna esto mostrando múltiples ecosistemas y cadenas de herramientas trabajando juntos en un solo sistema.

Sobre el autor

Robert Perkel es ingeniero de aplicaciones en Microchip Technology. En este puesto desarrolla contenido técnico como notas de aplicaciones, artículos y vídeos contribuidos.

También es responsable de analizar casos de uso de periféricos y del desarrollo de ejemplos y demostraciones de código.

Perkel es graduado de Virginia Tech, donde obtuvo una licenciatura en Ingeniería Informática.