Ha habido una discusión relacionada con esta pregunta aquí: link
Extractos:
El artículo de Linux Journal al que se hace referencia está aquí: link
Creo que los puertos 8052 y M68HC12 son especialmente malas elecciones para caracterizar a NuttX porque ambos tienen algunos problemas, y NuttX ahora está en la versión 5.16 con 63 versiones.
Sí completé la entrevista en la pestaña "Editor" aquí: link ; también hay una revisión: enlace .
La extensa documentación de NuttX está disponible aquí: enlace .
Los problemas con las partes hcs12 y 8051 son los siguientes:
8051 / 80c52: esta arquitectura es realmente hostil a RTOS. Tiene una pequeña pila de hardware (128 bytes en el 8051, 256 en el 80c52) en una ubicación de memoria dedicada (dirección 0). Para cambiar las tareas, debe copiar la pila completa de la tarea que se va a bloquear desde su dirección dedicada a alguna ubicación de guardado, y luego copiar la pila completa de la tarea que se iniciará desde su ubicación de guardado a la ubicación de la pila dedicada. YECH!
Y desde entonces, la pila es tan pequeña. Es muy, muy fácil sobrepasar la pila, especialmente durante el manejo de interrupciones.
El puerto NuttX 8051 es completo y funcional (al menos la última vez que lo usé). Pero para que sea útil, probablemente también tendría que copiar la pila completa en cada interrupción para evitar que se desborde. Básicamente, perdí el interés en ese momento, pero si alguien estaba realmente motivado para usar el 8051, es factible (aunque quizás no esté bien aconsejado).
Lo bueno del puerto 8051 es que fue un gran ejercicio para obtener NuttX en una ubicación de memoria muy pequeña. El puerto 8051 se ejecuta en 32Kb de RAM, que incluye RTOS, libc, bibliotecas de compilación, un programa de prueba sustancial, .data / .bss y heap. ¡Y con un poco de memoria de sobra!
hcs12: Este es un proyecto en el que trabajo en mi tiempo libre cuando no estoy haciendo nada más. Simplemente no está terminado y aún no está listo para el horario de máxima audiencia.
Con respecto a la comparación con otros RTOS, realmente no tengo ninguna respuesta buena y autorizada porque no uso otros RTOS. Pero aquí está mi ingenua comprensión:
FreeRTOS tiene toneladas de descargas y una huella realmente pequeña de aproximadamente 4Kb. Es el RTOS de elección para los MCU realmente pequeños. Un puerto de FreeRTOS está incluido en los proveedores de silicio con casi todas las MCU. Por lo tanto, es la opción predeterminada de RTOS.
Hay docenas de competidores con FreeRTOS por ahí. ChiBIOS viene a la mente inmediatamente. Todos estos son pequeños programadores de diferentes tipos.
Para hacer una comparación real, una cosa que debemos hacer primero es definir lo que queremos decir con un RTOS: ¿es solo un programador? O es un conjunto integrado de funciones estándar del sistema operativo, como programador, sistema de archivos, controladores de dispositivos, administración de memoria, redes, etc. La mayoría de los sistemas operativos, Linux, por ejemplo, son entornos de desarrollo completo, no solo programadores. NuttX es un sistema operativo completo que tiene el mismo sentido que Linux. Aquí hay un par de otros:
RTEMS : He trabajado con este. Ha existido desde siempre y debe ser muy estable. Es grande; pensar > 100kb. Creo que apunta un poco por encima del mercado de MCU.
uCOS : nunca lo usé, pero este es el RTOS bajo varios cargadores de arranque populares, ¿no es así? Mi impresión es que es similar a RTEMS, pero realmente no sé de qué estoy hablando.
¿Cómo compararía NuttX con esos? Bueno, es mucho más pequeño. La huella inicial es de alrededor de 20Kb. Una confirmación completa es de unos 10-20Kb más. Otra diferencia con estos RTOS es que NuttX está muy orientado a los estándares. Puedes pensar en NuttX como un pequeño Linux similar al trabajo. La mayoría del código que se compila y ejecuta en Linux también se ejecutará en NuttX (es posible que algunos códigos del sistema, como el código de red o los demonios, necesiten algunos ajustes).
Creo que RTEMS está más centrado en los microprocesadores; NuttX está más centrado en los microcontroladores.