¿Cuáles son algunas situaciones en las que se prefiere un RTOS (SO en tiempo real) sobre un bucle while infinito simple en un sistema integrado?

Cuando tengas

1. múltiples trabajos que tienen restricciones de tiempo estrictas, debe usar RTOS.
2. Memoria compartida entre diferentes subrutinas / condiciones de carrera.

Tengamos ejemplo

Situación 1: tiene sensor de temperatura, acelerómetro, micrófono, timbre, pantalla y solo tiene 4 temporizadores. Ahora todos los sensores tienen un tiempo de respuesta diferente y usted necesita tomar / alimentar los datos de cada sensor a tiempo. Si tiene un bucle de espera ocupado para el sensor de temperatura y espera 1 para generar respuesta, pierde muestras de audio del micrófono y la calidad del audio se degrada. Ahora dirá que usará interrupciones pero tiene 5 sensores con diferentes requisitos de tiempo y solo 4 temporizadores. Entonces en ese momento se vuelve desordenado y complicado. Incluso si administra sin RTOS, no puede escalar su proyecto tarde. Si tenemos RTOS, el planificador se encargará de todos los requisitos de tiempo a través del temporizador común.

Situación 2: suponga que tiene un ciclo while en el que compara dos valores de sensor y si no se encuentran iguales, detiene el procesamiento. Ahora tiene interrupción para actualizar los valores del sensor.

mientras que (1) {
if (temp1! = temp2) {
stop_everything ();
}
}

__timer1 (nulo) {
temp1 = get_sensor1_data ();
temp2 = get_sensor2_data ();
}

Ahora en algún momento instantáneo t1: temp1 = 32, temp2 = 32

en el instante t2: temp1 = 34 temp2 = 34

Ahora, después de que t1 se está ejecutando la línea 2 y el valor de temp1 se recupera de la memoria y llega la interrupción. Entonces ambos valores de temperatura se actualizan. después de la interrupción cuando volvemos al programa while, el valor de temp2 se recupera de la memoria. Entonces, ahora en la memoria, ambos valores se actualizan, pero en la comparación de bucles while solo tenemos un valor actualizado. Entonces, cuando comparamos valores, detenemos todo el sistema, pero en el escenario real todo estaba en orden. Esto sucede porque habíamos compartido una variable y no podíamos proporcionar un exceso exclusivo a esas variables. Si tenemos RTOS, podemos usar el mecanismo de semáforos, etc. y detener el mal funcionamiento.

Además de esto, hay algunos otros escenarios complejos que conocemos a medida que comenzamos a trabajar con diferentes requisitos de tiempo complejos. Pero creo que esto es suficiente para demostrar el requisito de RTOS en lugar de superloop con interrupciones.

Un verdadero RTOS proporcionará un tiempo mínimo garantizado para manejar las interrupciones. Ese es prácticamente el objetivo de un RTOS, responder en tiempo real (o dentro de unos pocos milisegundos de tiempo real).

Un bucle while infinito no puede garantizar esto. Los comandos que se encuentran más arriba en el bucle pueden tardar más en ejecutarse de lo esperado, lo que hace que las cosas posteriores en el bucle no se procesen en el tiempo mínimo.

Por estas razones, la programación de tareas en RTOS se realiza por interrupción, no se realiza en bucles while gigantes (excepto posiblemente en el nivel más alto).

Cuando creas que usar un RTOS te facilitará el trabajo. Seriamente. Desarrollo un controlador de motor con una fecha límite de 10us y solo uso interrupciones y bucle infinito. Esto está perfectamente bien.

Cuando las cosas se vuelven más complejas, necesitamos RTOS para gestionarlo. Una característica excelente de RTOS es el planificador. El otro es la mensajería entre tareas / hilos. La programación asincrónica utilizando la máquina de estado y los bucles infinitos (a la prototreads) puede volverse desordenada rápidamente. Entonces, el subprocesamiento múltiple preventivo impulsado por interrupción es el caso más fuerte para usar RTOS. Protothreads es solo una buena manera de envolver el bucle infinito convencional

Cuando tenga que procesar algo mientras espera que llegue la entrada y no pueda permitirse perder la entrada mientras procesa otra cosa (en el caso de una CPU de un solo núcleo) !!!!.,

¿Por qué no girar una tarea separada que continúa procesando la entrada mientras que otros bloques para la entrada (a través de interrupción / sondeo, etc.)?

Cuando es difícil dividir los diversos componentes del ciclo do-while para que tomen menos tiempo que el tiempo de respuesta máximo para un estímulo externo.

Si tiene, sat, un tiempo de respuesta de 1 ms a un estímulo, y su ciclo while se ejecuta en 0,5 ms cada vez, no tiene ningún problema. Pero suponga que tiene un cálculo que toma 10 ms, pero que solo se ejecuta ocasionalmente. Para garantizar su tiempo de respuesta de 1 mseg, debe dividirlo en, por ejemplo, 20 partes para que pueda verificar su respuesta importante entre los cortes. Esto puede hacerse. Pero supongamos que tiene dos de esos cálculos … Puede descender rápidamente a una ciénaga de cálculos parciales, banderas y estado desordenado.

En un ciclo do-while, cada segmento del programa debe garantizar el tiempo que lleva. Con un RTOS, solo los de alta prioridad tienen que hacerlo.