FreeRTOS, RT-Thread y Zephyr a menudo se comparan juntos, pero estos tres proyectos en realidad no están al mismo nivel.
Si simplemente preguntas “¿Qué RTOS es mejor?” la respuesta puede extraviarse fácilmente. Una pregunta más precisa debería ser: ¿su proyecto requiere un núcleo de programación liviano, un RTOS con un ecosistema MCU doméstico o un sistema operativo integrado completo para ingeniería multiplataforma?
Desde esta perspectiva, el posicionamiento de los tres se puede dividir a grandes rasgos en lo siguiente:
- FreeRTOS: kernel de programación estándar de la industria, además de un conjunto de bibliotecas de IoT mantenidas por AWS.
- RT-Thread: el kernel más un ecosistema de componentes más completo es más amigable para las MCU nacionales de cola larga y la comunidad china.
- Zephyr: un RTOS completo alojado por la Fundación Linux, que enfatiza los subsistemas unificados, los modelos de dispositivos, el árbol de dispositivos y la reutilización de aplicaciones entre proveedores.
Hablemos primero de la conclusión.
Si el proyecto es solo una pequeña MCU, programación de tareas simple, semáforos, colas y temporizadores, FreeRTOS sigue siendo una de las opciones más estables.
Si el proyecto es principalmente para MCU nacionales, especialmente chips de cola larga como AT32, HC32, N32, APM32, HT32 y Hezhou, y el equipo espera que los materiales chinos, BSP y los comentarios de la comunidad sean más convenientes, RT-Thread tiene grandes ventajas.
Si el proyecto necesita reutilizar el código de la capa de aplicación en chips, placas y proveedores, y está dispuesto a aceptar los costos de aprendizaje que conllevan Kconfig, Devicetree, west y los modelos de controladores, Zephyr se parece más a una ruta de ingeniería orientada al futuro.
Así que no se trata de “quién elimina a quién”, sino de tres niveles diferentes de abstracción de la ingeniería.
FreeRTOS: lo más fuerte es liviano y determinista
La principal ventaja de FreeRTOS es que es lo suficientemente pequeño, familiar y popular.
Su repositorio principal FreeRTOS-Kernel se centra en el kernel, la capa de portabilidad y los mecanismos centrales de RTOS. Programación de tareas, semáforos, colas de mensajes, grupos de eventos, temporizadores de software, estrategias de asignación de memoria, estas son las partes que realmente utilizan la mayoría de los proyectos.
Los beneficios de FreeRTOS son sencillos:
- La cobertura de MCU es extremadamente amplia.
- La mayor cantidad de materiales de aprendizaje y casos de ingeniería.
- Se puede conectar fácilmente al SDK del fabricante del chip.
- Adecuado para sistemas pequeños con recursos ajustados y necesidades claras.
- Cuando ocurre un problema, el camino de localización es corto y muchos equipos han acumulado experiencia.
Después de que AWS adquirió FreeRTOS, mantuvo coreMQTT, coreHTTP, OTA, Device Shadow, Jobs, Defender y otras bibliotecas relacionadas con IoT. FreeRTOS 202406 LTS también incluye kernel, TCP, MQTT, HTTP, OTA y otros componentes en la ruta de soporte a largo plazo.
Pero los límites de FreeRTOS también son claros: no es esencialmente una “plataforma de sistema operativo completa”. FreeRTOS en sí no es responsable de cómo abstraer GPIO, cómo leer y escribir UART, cómo conectar dispositivos a I2C y cómo unificar HAL de diferentes fabricantes.
En otras palabras, lo que FreeRTOS te ofrece principalmente es el kernel. La capa de controlador, el modelo de dispositivo, la abstracción a nivel de placa y el marco de aplicación dependen del SDK del fabricante del chip o los construye el propio equipo.
Esto no es un defecto, sino una elección de diseño. Hace que FreeRTOS sea muy flexible y también facilita la combinación con SDK de fabricantes como ST, NXP, TI, Renesas y Espressif. Pero el precio es el siguiente: al cambiar chips, placas o HAL, la capa de aplicación suele verse implicada.
RT-Thread: Ventajas en MCU doméstico y ecología de componentes
RT-Thread está más cerca de un RTOS completo que FreeRTOS.
No es solo un programador, sino que también proporciona un sistema de archivos, una pila de protocolos de red, un marco de dispositivo, USB, un marco de sensores, un paquete de componentes y una cadena de herramientas. Para muchos equipos nacionales, la documentación china de RT-Thread, las herramientas ENV, el ambiente comunitario y el MCU BSP nacional son ventajas muy prácticas.
Especialmente en las MCU nacionales de cola larga, el soporte de RT-Thread es muy valioso. Muchos proyectos no utilizan chips de los principales fabricantes internacionales, sino que eligen MCU nacionales como AT32, HC32, N32, APM32, HT32, Hezhou y Xianji. Para este tipo de proyecto, RT-Thread a menudo puede obtener materiales BSP y chinos ejecutables más rápidamente.
RT-Thread es adecuado para estos escenarios:
- El equipo utiliza principalmente MCU nacionales.
- Requiere comunidad china e información local.
- Necesita un ecosistema de componentes más completo que FreeRTOS.
- El proyecto espera acceder rápidamente al sistema de archivos, la red, el shell, el marco del dispositivo y otras capacidades.
- El equipo no quiere construir un conjunto de abstracciones a nivel de tablero y de controladores desde cero.
Pero RT-Thread también tiene sus propias limitaciones.
En primer lugar, muchos de sus BSP todavía están organizados en torno a tableros y bibliotecas de proveedores específicos. Aunque existe un marco de dispositivo, desde la perspectiva de las descripciones de hardware unificadas entre proveedores y la migración sin sentido de la capa de aplicación, aún no ha alcanzado el nivel sistémico de Zephyr.
En segundo lugar, RT-Thread es muy compatible con las MCU nacionales de cola larga, pero en términos de algunos chips principales y el mantenimiento principal de los fabricantes internacionales, el impulso de Zephyr ya es fuerte. Por ejemplo, fabricantes como Espressif Systems, Nordic, NXP y Renesas han realizado cada vez más inversiones oficiales en el ecosistema Zephyr.
En tercer lugar, la ruta del árbol de dispositivos de RT-Thread realmente no se ha convertido en un método de trabajo convencional en el lado de la MCU. Tiene marcos relacionados, pero en proyectos de MCU como Cortex-M, aún no puede formar un mecanismo unificado que se ejecute a través del sistema de compilación, la coincidencia de controladores y la configuración de la capa de aplicación como Zephyr.
Por lo tanto, el posicionamiento de RT-Thread es más parecido: complementa muchos componentes comunes del sistema además de FreeRTOS y es muy práctico en el ecosistema MCU doméstico. Pero todavía no es una plataforma de ingeniería como Zephyr que ha unificado la planificación desde la construcción, la configuración, el controlador, el modelo de dispositivo hasta la capa de aplicación.
Zephyr: No “otro RTOS”, sino una ingeniería de sistemas
Zephyr se malinterpreta fácilmente como “un RTOS más complejo que FreeRTOS”. Esta afirmación es sólo una verdad a medias.
De hecho, es más complejo, pero la razón de la complejidad no es la simple función de montón, sino su intento de unificar los elementos dispersos a largo plazo del proyecto MCU en el SDK, BSP, HAL, el controlador escrito a mano y los scripts de configuración del fabricante en un solo proyecto de sistema operativo.
La clave de Zephyr no es sólo el programador, sino también estas cosas:
- Kconfig: Función de gestión de cambios y configuración de compilación.
- Devicetree: describe el hardware a nivel de placa y las conexiones de periféricos.
- controladores: unifique interfaces periféricas como GPIO, UART, SPI, I2C, ADC, DMA, reloj, reinicio y pinctrl.
- subsistema: proporciona red, Bluetooth, USB, sistema de archivos, entrada, administración de energía, registros, almacenamiento de configuraciones y otros subsistemas.
- oeste y CMake: gestiona proyectos, módulos, compilaciones, descargas y depuración.
- Abstracción de placa/SoC/escudo: convergencia de diferencias de hardware con la capa de configuración.
Esto hace que Zephyr se parezca más a una “versión minimizada de MCU para Linux integrado”: hereda muchas ideas de ingeniería del mundo Linux, pero transforma el mecanismo de sonda en tiempo de ejecución que no es adecuado para MCU pequeñas en una implementación en tiempo de compilación.
Por qué el árbol de dispositivos de Zephyr es fundamental
Devicetree es la clave para entender Zephyr.
En Linux, DTS generalmente se compila en DTB y el gestor de arranque lo pasa al kernel. Una vez que se inicia el kernel, analiza el árbol de dispositivos, busca el controlador y ejecuta la sonda. Este modelo de tiempo de ejecución es razonable para MPU y sistemas de gran memoria, pero es demasiado pesado para una MCU con decenas a cientos de KB de RAM.
Zephyr hace las cosas de manera diferente. Procesa DTS/superposición durante la fase de construcción, genera descripciones de hardware en archivos de encabezado como devicetree_generated.h y luego usa la macro DT_ para controladores y aplicaciones. En otras palabras, la descripción del hardware y la selección del controlador se determinan básicamente en el momento de la compilación y no es necesario realizar una gran cantidad de descubrimientos de dispositivos en el tiempo de ejecución.
Este diseño aporta varios beneficios:
- Separación de descripción de hardware y código de aplicación.
- Cambiar el tablero cambia principalmente DTS/overlay.
- Los controladores están expuestos a las aplicaciones a través de una API unificada.
- Se pueden eliminar los controladores y subsistemas no habilitados.
- La capa de aplicación no tiene que preocuparse directamente por registros, pines y HAL de proveedores específicos.
Por ejemplo, un LED o un botón generalmente están dispersos en la configuración de CubeMX, inicialización de GPIO, devoluciones de llamada, interrupciones, antirrebote, máquina de estado y código de aplicación en proyectos HAL tradicionales del fabricante FreeRTOS +. Con Zephyr, se puede colocar mucha información en DTS y la capa de aplicación solo maneja eventos a través de LED, GPIO o interfaces de subsistema de entrada.
Este es el valor de ingeniería de Zephyr: no hacer que las demostraciones simples parezcan más cortas, sino evitar que las diferencias de hardware de proyectos complejos contaminen el código comercial tanto como sea posible.
¿Por qué el código de la capa de aplicación se vuelve limpio?
En proyectos de MCU tradicionales, el código de la aplicación a menudo se mezcla con estos contenidos:
- Inicialización de hardware.
- Número de pin GPIO.
- Configuración de interrupción.
- Lógica antirrebote.
- Temporizadores y máquinas de estados.
- Redirección de puerto serie.
- Cola de eventos.
- Tramitación empresarial.
Cuando el proyecto es pequeño al principio, escribir de esta forma es muy rápido. Pero a medida que aumenta el número de periféricos, placas y líneas de productos, la capa de aplicación se parecerá cada vez más a una extensión del BSP.
El objetivo de Zephyr es descomprimir este contenido:
- Conexiones de hardware puestas en DTS/overlay.
- Los interruptores de función se colocan en Kconfig/prj.conf.
- Los controladores se colocan en la línea principal o módulo de Zephyr.
- La aplicación sólo maneja eventos empresariales.
Por lo tanto, las mismas funciones, como parpadeo del LED, pulsación corta, pulsación larga, doble clic y triple clic, se pueden convertir más fácilmente en “una pequeña cantidad de código comercial + archivo de configuración” en Zephyr. Al reemplazar la placa, el estado ideal es cambiar DTS pero no main.c.
Puede que esto no parezca rentable para demostraciones de una sola placa, pero para equipos con múltiples placas, múltiples chips y múltiples generaciones de productos, el valor será cada vez más obvio.
No se puede simplemente observar el uso de recursos a primera vista.
La primera reacción de mucha gente es: Zephyr es tan grande que debe consumir muchos recursos.
Este juicio debe ser desmantelado.
Flash de Zephyr generalmente tiene más proyectos que FreeRTOS simple debido al controlador, subsistema y modelo de dispositivo unificados. Esta parte no es pura “gastos generales del kernel”, sino que ha comprado una infraestructura reutilizable.
Por ejemplo, el subsistema de entrada, el controlador LED, el controlador GPIO, el temporizador, el registro, el objeto del dispositivo, etc. ocuparán espacio. Pero cuando más adelante se agregan perillas, codificadores, más botones y más dispositivos de entrada, gran parte de la infraestructura se puede reutilizar y no es necesario reescribir todas las funciones a mano.
La RAM es similar. Las reservas de montón, las reservas de pila de tareas y los buffers de cola comunes en proyectos FreeRTOS pueden hacer que el informe parezca más grande; Zephyr pone más énfasis en los objetos estáticos y en la poda del tiempo de enlace. Cuál es más económico depende de la configuración, funciones, opciones de compilación y escenarios reales. No se pueden simplemente comparar proyectos vacíos.
Una forma más práctica de juzgar es:
- Si hay pocas funciones, la placa es fija y los recursos son muy escasos, FreeRTOS puede resultar más económico.
- Si hay muchos periféricos, muchas placas y muchas reutilizaciones de controladores, el “coste de infraestructura” de Zephyr se diluirá.
- Si el equipo no tiene tiempo para aprender Zephyr, la complejidad en sí misma tiene un costo.
¿Cómo elegir entre los tres?
Puedes elegir según el formulario del proyecto.
Elija FreeRTOS
Adecuado:
- Los recursos del proyecto son escasos.
- Sólo se requieren programación, colas, semáforos y temporizadores.
- Plataforma de hardware arreglada.
- Ya existen SDK de fabricantes maduros.
- El equipo está familiarizado con FreeRTOS.
- No es necesario unificar los modelos de dispositivos entre proveedores.
Juicio típico: lo que necesita es un núcleo confiable, no un marco de ingeniería de sistema operativo completo.
Seleccionar hilo RT
Adecuado:
- Se utilizan más MCU nacionales.
- Requiere comunidad china y materiales chinos.
- Espero obtener rápidamente BSP, paquetes de componentes y capacidades comunes del sistema.
- El tamaño del proyecto es mayor que el de FreeRTOS puro, pero todavía no quiero entrar completamente en la curva de aprendizaje de Zephyr.
- El equipo espera resolver problemas en el ecosistema local.
Juicio típico: lo que necesita es “más componentes además de FreeRTOS + ecología amigable con MCU doméstica”.
Seleccione Céfiro
Adecuado:
- El proyecto debe abarcar varias placas, varios chips y varios fabricantes.
- Se espera que la capa de aplicación no esté tan ligada a un hardware específico en la medida de lo posible.
- Preste atención al mantenimiento a largo plazo y a las actualizaciones principales.
- Requiere subsistemas unificados como Bluetooth, red, USB, sistema de archivos, entrada y administración de energía.
- El equipo está dispuesto a aprender los modelos de controladores Kconfig, Devicetree, west y Zephyr.
- En el futuro, espero integrarme con las ideas de ingeniería de Linux.
Juicio típico: lo que necesita es una plataforma de ingeniería de sistemas integrados completa, no solo un kernel RTOS.
Cuándo no usar Zephyr
Zephyr no es una solución milagrosa.
En estos casos, no se recomienda elegir Zephyr:
- El proyecto tiene un solo tablero fijo y su función es muy sencilla.
- El equipo no tiene tiempo para aprender Kconfig y Devicetree.
- El soporte de chip o placa en la línea principal de Zephyr es débil.
- El proyecto depende en gran medida de las capacidades privadas de código cerrado del SDK de un determinado fabricante.
- El producto se ha producido en masa de manera estable y los beneficios de la migración no son obvios.
- Los entornos de creación y depuración del equipo aún no están listos.
La curva de aprendizaje de Zephyr es real. Sus mensajes de error, sistema de compilación, enlace de Devicetree, dependencias de Kconfig y administración de módulos requieren adaptación para los desarrolladores tradicionales bare metal/FreeRTOS.
Por lo tanto, una ruta más razonable es: primero elegir una placa de desarrollo con buen soporte de línea principal Zephyr, usar una pequeña función para ejecutar LED, UART, GPIO, entrada, I2C/SPI y luego decidir si migrar el proyecto real.
¿Por qué es aún más importante leer bien el código en la era de la IA?
Ahora mucha gente dirá: Con la IA, no es necesario aprender el marco subyacente tan profundamente, simplemente deje que el modelo escriba el código.
Esta idea es peligrosa.
La IA puede presentarle códigos candidatos, pero las personas que incorporan el código, lo graban en el firmware y lo entregan al dispositivo del cliente para que lo ejecute siguen siendo ingenieros. La IA no será responsable de la retirada de dispositivos, sino la gente.
En proyectos integrados, lo realmente escaso no es la capacidad de “escribir unos cientos de líneas de código más”, sino la capacidad de juzgar:
- ¿Por qué este código está escrito así?
- ¿Vale la pena este nivel de abstracción?
- ¿Se puede mantener esta interfaz de controlador durante mucho tiempo?
- ¿Este cambio de configuración afectará a otras placas?
- ¿Se puede incorporar este código generado por IA al firmware de producción en masa?
Uno de los valores de Zephyr es que proporciona un conjunto de muestras de arquitectura de sistemas integrados de nivel industrial. Incluso si Zephyr no es elegido para el proyecto final, comprender sus subsistemas, modelos de dispositivos, Devicetree, Kconfig y organización de controladores mejorará su capacidad para juzgar la calidad de la arquitectura integrada.
总结
FreeRTOS, RT-Thread y Zephyr no son una simple elección de tres productos similares.
FreeRTOS es un kernel RTOS ligero, maduro y popular, adecuado para hardware fijo y escenarios claros de programación de tareas. RT-Thread es un ecosistema RTOS más completo, especialmente adecuado para MCU nacionales, comunidades chinas y una rápida integración de componentes. Zephyr es un proyecto de sistema operativo integrado más sistemático, adecuado para el mantenimiento a largo plazo y la reutilización de la capa de aplicación entre proveedores y tableros.
Si sólo está construyendo un dispositivo pequeño, FreeRTOS puede ser la respuesta más sencilla. Si desarrollamos una línea de productos MCU nacional, el ecosistema RT-Thread será muy práctico. Si se enfrenta a múltiples plataformas, múltiples placas, múltiples periféricos y una evolución a largo plazo, vale la pena invertir seriamente en Zephyr.
La verdadera brecha no son más o menos API, sino el nivel de abstracción de ingeniería: FreeRTOS resuelve la programación, RT-Thread completa los componentes y Zephyr intenta reconstruir la organización de la ingeniería de software de MCU.
Enlaces de referencia: