¿Por qué usar FREERTOS en lugar del mecanismo de interrupción en un microcontrolador? [duplicar]

Usted dijo: "el objetivo de la multitarea es dar la impresión de que se está realizando una paralelización en un solo núcleo". Eso está fuera de lugar. Diría que el objetivo de la multitarea es dividir un conjunto de requisitos complejos en partes más manejables al mismo tiempo que aumenta la capacidad de respuesta general del sistema.

Es posible que pueda lograr la primera parte de este objetivo utilizando solo las interrupciones. Pero si pone toda la funcionalidad de una tarea completa en un controlador de interrupciones, empeorará la capacidad de respuesta del sistema.

Imagina un dispositivo de monitoreo que:

• continuamente procesa muestras de un ADC conectado a un sensor y realiza algún procesamiento de señal en las muestras,
• tiene una interfaz de usuario simple con una pantalla y unos pocos botones,
• y tiene una interfaz Ethernet para comunicar datos en una red.

Hacer todo esto desde un super-loop principal haría un super-loop bastante complejo. Podría simplificar un poco el super-bucle moviendo la funcionalidad a los controladores de interrupción. Pero imagine que si la interrupción del ADC realiza todo el procesamiento de la señal, la interrupción del botón realiza todas las actualizaciones de la pantalla y la interrupción de Ethernet realiza todo el análisis de mensajes de la red. Este sistema no sería muy receptivo porque está pasando períodos de tiempo relativamente largos en los controladores de interrupción.

Con un RTOS, usted divide los requisitos en tareas que hacen que cada tarea sea relativamente sencilla de implementar. El procesamiento de interrupciones se mantiene al mínimo y el programador determina qué tarea ejecutar. Esto puede hacer para un sistema altamente sensible. Si ha diseñado las tareas de manera inteligente, también es más robusto y extensible que el complejo super-loop.

Tal vez esto se deba a una mala interpretación de lo que es un RTOS. No está ocurriendo magia que no puedas crear tú mismo.

Sin embargo, hace que muchas cosas sean mucho más fáciles. Hagamos un ejemplo de una máquina de estados simple que tiene que hacer diferentes cosas dependiendo de lo que haya sucedido en la máquina hasta ahora:

while(1) {
    switch( state ) {
        case 1:
            if( has_sample )
                fft_segment( sample_buffer, output );
            state++;
            break;
        case 2:
            if( has_packet )
                reply_to_packet( network_state );
            state++;
            break;
        case ...
    }
}

No desea que ninguno de estos se ejecute en un controlador de interrupciones. fft_segment y reply_to_packet pueden tomar algún tiempo.

Digamos que fft_segment tarda mucho tiempo en ejecutarse, y hay un paquete entrante para responder. Tiene que esperar hasta que se complete su FFT.

Con un RTOS en su lugar, los ejecutará en tareas con una prioridad diferente, y el sistema operativo puede prevalecer fft_segment si es necesario, para responder a la solicitud de red. Esto sin bloquear interrupciones de hardware más importantes.

Los beneficios adicionales son la separación de código, que por supuesto ayuda cuando tus proyectos crecen.

Nada te impide hackear esto "a mano", por ejemplo, dividiendo tu procesamiento pesado en partes más pequeñas que pueden correr una detrás de la otra, pero con un RTOS no tienes que hacerlo, te permite codificar una forma más natural.

  

Realmente no entiendo por qué se usaría FREERTOS en lugar del mecanismo de interrupción incorporado.

No lo usas en lugar de de las interrupciones, lo usas además de a las interrupciones. Un RTOS le brinda una forma más flexible de administrar prioridades y hardware diferente.

Esto es del propio sitio de FreeRTOS: enlace aunque un poco fuera de fecha.

Si puede beneficiarse de un RTOS o no, depende del tamaño de su aplicación y los requisitos de su aplicación, pero eso es obvio.

Aunque se ve más allá de "tratar de hacer que las cosas parezcan estar funcionando en paralelo", eso es importante para un sistema multiusuario (como Unix) pero casi irrelevante para un sistema dedicado pequeño. Lo que es más importante es cómo puedo hacer que mi diseño sea sencillo, cómo puedo realizar el diseño, cuál es la menor cantidad de código que tengo que escribir para implementar mis requisitos, cómo puedo obtener tanta funcionalidad en el más pequeño procesador posible (corrigiendo una idea errónea que aparece una y otra vez, haciendo que su sistema esté completamente controlado por eventos y nunca ejecutando código [verificar un estado, sondear una entrada, etc.] a menos que se necesite realizar algún procesamiento, significa que puede adaptarse a más funciones en un procesador cuando utilizo un RTOS que cuando no lo está), ¿cómo puedo tener la máxima capacidad de respuesta simultáneamente con el mínimo consumo de energía ... y así sucesivamente?

Sí, un RTOS lleva una gran cantidad de equipaje, es una gran cantidad de código que no es tuyo, pero te despedirá si falla y eres el propietario del proyecto. Cuando puede administrar las tareas sin él, genial, no hay problema. Si llega a donde su software está empezando a parecerse a un rtos con las funciones que necesita agregar, etc. Hay un punto de inflexión en el que debería considerar probar el rtos para ver lo que hace o no le da. Es probable que sea excesivo, pero puede tener muchas de las ruedas que estaba reinventando.

Obviamente, no hay nada allí que no puedas hacer por tu cuenta. Del mismo modo, todos los recursos y características del chip están igualmente disponibles para usted como lo están para el RTOS, interrupciones de prioridad si están presentes, etc.

Al final del día todo se reduce a las preferencias personales.