¿Beneficios de RTOS vs Bare Metal para la programación de MCU?

Tenga en cuenta: esta pregunta menciona específicamente dos RTOS, pero es más genérica y probablemente pueda ser respondida por cualquiera que haya escrito código C para RTOS integrados antes y que su software se ejecute directamente en MCU.

Estoy interesado en aprender más sobre RTOS integrados y escribir aplicaciones para ellos. Actualmente estoy viendo Embox y RIOT porque son de código abierto, modernos, activos y parecen tener una excelente documentación. Mi objetivo tiene dos fases: la Fase 1 es descubrir cómo compilar y actualizar estos SO a una MCU (probablemente AVR o ARM). La fase 2 consiste en escribir un programa C simple (básicamente un demonio sin cabeza), que evolucionará con el tiempo como una "aplicación de hobby". Luego destellaría / implementaría este programa en la misma MCU, implementando con éxito un conjunto de aplicaciones que consta de Embox / RIOT y mi aplicación que reside encima de él.

Antes de seguir cualquier camino que finalmente lleve a callejones sin salida, me topé con este artículo que hace un muy buen trabajo al explicar por qué las aplicaciones en tiempo real, escritas en C / ensamblador y flasheadas a MCU, realmente no necesitan RTOS debajo de ellas. .

Así que ahora estoy realmente confundido y estoy cuestionando algo de mi comprensión fundamental de la teoría de la computación. Supongo que estoy tratando de tomar la decisión de usar o no Embox / RIOT en primer lugar, ya sea:

• Mantén el rumbo y ve con una "pila de aplicaciones" en el MCU de ambas aplicaciones OS +; o
• Preste atención a la advertencia del artículo y simplemente vaya con un MCU que ejecuta mi aplicación "bare metal"

Obviamente, lo primero es más trabajo, por lo que es mejor que haya una buena razón / beneficio para seguir esa ruta. Entonces, pregunto: ¿cuáles son los beneficios reales que estos (y similares) RTOS integrados ofrecen a los desarrolladores de aplicaciones MCU / C? ¿De qué características específicas podría beneficiarse mi aplicación C (tal vez al no reinventar la rueda) usando un RTOS? ¿Qué se pierde al deshacerse del RTOS y volverse desnudo?

Estoy pidiendo ejemplos concretos aquí, no el bombo de medios que obtienes cuando vas a la entrada de wikipedia para RTOSes ;-)

Los programas de microcontroladores consisten en una serie de tareas . Supongamos que desea hacer un soporte para telescopio controlado por computadora. Las tareas serían:

• Recupere un nuevo byte de entrada del búfer en serie USB.
• Comprueba si hemos recibido un comando completo.
• Si es así, ejecute ese comando.
• Lea los sensores para la posición actual del telescopio.
• Establezca la salida adecuada para controlar el siguiente paso de los motores.

Este es un conjunto de tareas bastante típico para algo para lo que usaría un microcontrolador, y es bastante fácil de administrar con un bucle infinito, como:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

Si sigue agregando y agregando características, eventualmente comienza a encontrarse con problemas comunes para los que desea crear abstracciones, como:

• Su búfer se desborda, por lo que debe asegurarse de que esa tarea pueda interrumpir otras tareas antes de que se desborde.
• Desea ahorrar batería durmiendo cuando no se necesita nada.
• Desea asegurarse de que todas las tareas tengan una oportunidad justa. Si readSensorslleva demasiado tiempo, desea poder interrumpirlo y volver a él más tarde.
• Desea poder restablecer una tarea sin afectar a otras.
• Desea una pérdida de memoria u otro error en una tarea para no eliminar las otras tareas.
• Desea poder asignar diferentes tareas a diferentes prioridades.
• Desea poder poner en una zona de pruebas una tarea no confiable.
• Desea poder ejecutar tareas a diferentes velocidades. Quizás sus sensores solo se puedan leer 10 veces por segundo, pero desea ejecutar un paso de motor 100 veces por segundo.

Uno o dos de estos elementos se pueden manejar de forma manual con relativa facilidad. Si tiene suficientes problemas de este tipo con la frecuencia suficiente para comenzar a generalizarlos en bibliotecas, básicamente ha reinventado un RTOS. Si la gestión de tareas de su programa es lo suficientemente compleja, incluso si no utiliza un RTOS estándar, eventualmente terminará reinventando uno deficiente.

Sin embargo, en mi experiencia, la línea donde desea un RTOS está muy cerca de la línea donde desea un microprocesador en lugar de un microcontrolador. Si anticipa que su firmware se volverá tan complejo, generalmente es mejor seguir la ruta del microprocesador desde el principio.

Escribí mi propia biblioteca cooperativa de subprocesos múltiples para ARM Cortex-M0.

Era apenas un par de páginas de código, y la primera versión no tardó más de un día en escribir y depurar.

La gran ventaja de roll-your-own es que conoce el código y puede portarlo a chips que el RTOS podría no admitir. Además, pasa menos tiempo pensando en preguntas como "¿se bloqueará? Intento usar las funciones A y B simultáneamente". Desde que escribiste el código, sabes la respuesta.

El enhebrado es lo principal que obtienes de un RTOS, y resulta que no es un gran problema para implementarte. Es raro que necesite muchas de las características de un RTOS. Pero si no cumple con sus requisitos y resulta que sí, entonces use un RTOS.