Cómo elegir entre FreeRTOS, RT-Thread y Zephyr: diferencias de arquitectura y casos de uso

Sun, 17 May 2026 12:32:06 +0800

FreeRTOS, RT-Thread y Zephyr suelen compararse como si fueran productos del mismo nivel. No lo son.

La pregunta correcta no es cuál es mejor, sino qué necesita tu proyecto: un kernel ligero de planificación, un RTOS con buen soporte para MCU chinos, o un sistema operativo embebido completo y multiplataforma.

En resumen:

FreeRTOS es un kernel RTOS muy extendido, con librerías IoT mantenidas por AWS.
RT-Thread añade un ecosistema de componentes más completo y buen soporte para MCU domésticos.
Zephyr, alojado en Linux Foundation, apuesta por subsistemas unificados, modelo de dispositivos, Devicetree y reutilización de aplicaciones entre fabricantes.

Conclusión rápida

Si solo necesitas tareas, colas, semáforos y temporizadores con poco consumo, FreeRTOS sigue siendo una opción segura.

Si usas muchos MCU chinos y valoras BSP listos, documentación en chino y más componentes, RT-Thread es práctico.

Si necesitas reutilizar código entre chips, placas y proveedores, y aceptas aprender Kconfig, Devicetree, west y el modelo de drivers, Zephyr es la ruta más orientada a ingeniería a largo plazo.

FreeRTOS: pequeño y conocido

FreeRTOS destaca por ser pequeño, familiar y muy usado.

FreeRTOS-Kernel se centra en kernel, ports y mecanismos básicos: scheduling, semáforos, colas, event groups, timers y memoria. En muchos proyectos, eso es exactamente lo que se necesita.

Tras la adquisición por AWS, también existen librerías como coreMQTT, coreHTTP, OTA y Device Shadow, además de versiones LTS.

Su límite es claro: no define un modelo de dispositivos común para GPIO, UART, I2C, pin control o HAL. Eso queda en manos del SDK del fabricante o de la arquitectura del equipo. Es flexible, pero cambiar de chip o placa puede arrastrar código de aplicación.

RT-Thread: componentes y soporte doméstico

RT-Thread está más cerca de un RTOS completo.

Incluye sistema de archivos, red, framework de dispositivos, USB, sensores, paquetes y herramientas. Para equipos chinos o proyectos con AT32, HC32, N32, APM32, HT32, Luat o HPMicro, puede acelerar mucho el arranque.

La limitación es que muchos BSP siguen siendo específicos de placa y dependientes de librerías del fabricante. No ofrece el mismo nivel sistemático de descripción de hardware y portabilidad de aplicación que Zephyr.

Zephyr: una plataforma de ingeniería embebida

Zephyr no es solo “otro RTOS más grande”.

Intenta unificar en un proyecto lo que normalmente queda disperso en SDKs, BSPs, HALs, drivers escritos a mano, scripts de configuración y código de aplicación.

Sus piezas clave son Kconfig, Devicetree, drivers unificados, subsys, west, CMake y abstracciones de Board / SoC / shield. Se parece a una versión MCU de algunas ideas de Linux embebido.

Por qué importa Devicetree

Zephyr procesa DTS y overlays durante la compilación, genera cabeceras como devicetree_generated.h y expone información con macros DT_. Así, gran parte de la selección de hardware queda resuelta en build time, no en runtime.

Esto separa hardware y aplicación, permite cambiar de placa tocando principalmente DTS / overlay, y reduce la necesidad de llenar main.c con detalles de registros, pines y HAL.

Código de aplicación más limpio

En proyectos MCU tradicionales, inicialización, pines, interrupciones, debounce, máquinas de estado y lógica de negocio se mezclan fácilmente.

Zephyr intenta separarlo:

Conexiones de hardware en DTS / overlay.
Opciones en Kconfig / prj.conf.
Drivers en mainline o módulos.
Aplicación centrada en eventos de negocio.

Esto es valioso cuando hay varias placas, varios chips y mantenimiento largo.

Coste de recursos

Zephyr puede usar más Flash que un FreeRTOS mínimo porque incorpora drivers, subsistemas y objetos de dispositivo. Pero esa infraestructura se reutiliza cuando crecen los periféricos y variantes.

Si el proyecto es fijo y pequeño, FreeRTOS puede ser más eficiente. Si el proyecto crece en placas y periféricos, Zephyr puede amortizar mejor esa base.

Cómo elegir

Elige FreeRTOS para hardware fijo, recursos ajustados y necesidades de scheduling simples.

Elige RT-Thread para muchos MCU domésticos, documentación china, BSP disponibles y componentes integrados.

Elige Zephyr para reutilización entre placas, drivers unificados, mantenimiento largo y una arquitectura más cercana al mundo Linux.

Cuándo no usar Zephyr

No conviene adoptar Zephyr si el proyecto es de una sola placa, el equipo no tiene tiempo de aprender Kconfig / Devicetree, el chip no está bien soportado upstream, o el producto ya está estable en producción.

Empieza con una placa bien soportada y prueba LED, UART, GPIO, input e I2C / SPI antes de migrar un producto real.

Resumen

FreeRTOS resuelve scheduling. RT-Thread añade componentes y soporte fuerte para MCU domésticos. Zephyr intenta reorganizar la ingeniería de software MCU alrededor de subsistemas unificados, Devicetree y portabilidad de aplicación.

Para dispositivos pequeños y fijos, FreeRTOS suele bastar. Para líneas de productos con MCU chinos, RT-Thread es práctico. Para productos multiplataforma y de larga vida, Zephyr merece inversión.

Referencias:

RT-Thread on KnightLi Blog