¿Cuándo usar un RTOS? [cerrado]

0

Digamos que tengo este programa

int main(void)
{
  #define STOP 0
  #define RUN  1
  flag = getEvent();
  while(flag != STOP)
  {
    func1(); // A function that takes 1 seconds to finish it's job
 => func2(); // A function that takes 60 seconds to finish it's job
    func3(); // A function that takes 1 seconds to finish it's job
    func4(); /// A function that takes 1 seconds to finish it's job
  }

func2 ()

int func2()
{
  int status = BUSY;
  while (status == BUSY)
    status = doSomeJob();
  if (status == SUCCESS)
     return FINISHED_WITH_SUCCESS
   else
     return FINISHED_WITH_FAILURE

getEvent() leerá permanentemente el estado de una señal de entrada: por ejemplo, si hago clic en un botón, el sistema se detendrá independientemente de la función en ejecución; de lo contrario, el indicador está en RUN y el sistema se ejecuta normalmente.

¿Es posible implementar un sistema de este tipo utilizando interrupciones y sin utilizar un RTOS?

¿Por qué RTOS?
Para mí, la idea es agregar dos tareas con diferentes prioridades. La primera tarea lee permanentemente la entrada y la segunda ejecuta el sistema. Si aparece un evento, la primera tarea toma el programador y bloquea el sistema.

    
pregunta Pryda

2 respuestas

3

Utilizaría un sistema operativo cuando quiera o necesite aislar las tareas realizadas por el sistema para que cada una pueda implementarse sin conocimiento de implementación sobre las otras tareas. Es una escala móvil la cantidad de un sistema operativo que tiene.

Entonces, si tiene una pieza de hardware que le permite definir un controlador de interrupciones que reacciona a un pin GPIO y poner otra función en el bucle principal, su sistema operativo es bastante mínimo: configure el controlador de interrupciones y luego comience la segunda tarea, no se necesita ningún otro arbitraje.

Si la reacción al pin GPIO hace que ocurra algo dentro del bucle principal, y por ejemplo, el bucle debería manejar ese evento inmediatamente, necesita cierta coordinación, que puede ser tan simple como configurar una bandera y verificarla en el bucle principal. En este punto, su código ha adquirido conocimiento de la implementación de otro código que se ejecuta en el mismo sistema: el manejador de interrupciones sabe que puede escribir en una variable que el bucle principal leerá periódicamente, y el bucle principal sabe que la variable puede cambiar Debido a la influencia externa.

Sin embargo, puede generalizar este código: el bucle principal, cuando está inactivo, llama a una función idle() , y la interrupción, cuando quiere señalar un cambio de estado, llama a una función action() . Ahora, ha abstraído los diferentes módulos entre sí, el comienzo de un sistema operativo.

Luego de varias mejoras en el sistema operativo, utiliza un bucle principal definido por el sistema que recorre una lista de tareas a realizar y realiza un seguimiento del tiempo asignado a cada una. Agregar otra tarea al sistema no requiere modificar ninguna de las tareas existentes.

Un RTOS es un tipo especial de sistema operativo que también garantiza una respuesta oportuna a eventos externos, al limitar aún más lo que pueden hacer las tareas individuales; por ejemplo, un requisito típico es que los controladores de interrupción de tareas se ejecuten mientras que las interrupciones están desbloqueadas, por lo que se puede anticipar un solo controlador que no se devuelva de manera oportuna.

Si se requiere un sistema operativo, con o sin soporte en tiempo real, depende de su aplicación y de las restricciones bajo las cuales está trabajando.

Por ejemplo, si el hardware admite la escritura directa de datos en la memoria y notifica a su aplicación una vez que algunos datos están listos, tendrá tiempo hasta que el búfer esté lleno para recuperar los datos.

Si no cumple con la fecha límite y los datos perdidos se pueden recuperar, o si la condición es poco probable y no es peligrosa, no necesita ninguna capacidad en tiempo real. Ejemplos de esto son Ethernet en computadoras de escritorio (los datos perdidos simplemente se retransmiten después de un tiempo de espera) o un teclado (la gente escribe lo suficientemente lento como para que tenga varios segundos para recopilar los datos).

Si los datos se pierden después de haber perdido la fecha límite, es una condición "en tiempo real suave": registrar un valor de sensor de un búfer cabría aquí. No puede corregir el error si le faltan valores, pero normalmente tiene mucho tiempo para recopilar los datos debido a los búferes.

"Tiempo real difícil" son restricciones en las que se deben tomar medidas dentro de un determinado período de tiempo, y el no hacerlo tendría consecuencias; el ejemplo más extremo sería el botón de parada de emergencia en una máquina, donde inmediatamente necesita invertir la potencia del motor para detener la máquina lo más rápido posible, y tan pronto como el motor se detenga, apague la alimentación.

Por lo general, tiene una combinación de estos en su sistema, y el problema más difícil define qué tipo de soporte en tiempo real necesita en su sistema operativo. Si puede descargar problemas "más difíciles", por ejemplo, manejando el botón de parada de emergencia en un controlador de interrupciones y todo lo demás en el programa principal, o construyendo un mecanismo de parada cableado que no está controlado por el microcontrolador, a menudo puede reducir la complejidad. De la programación significativamente.

Por ejemplo, tengo una fresadora CNC que tiene un grupo de contadores y puertas 74xx que inhibirán el movimiento más de 10 pasos (para frenar) en los topes, cuando se presiona el botón de parada de emergencia o si la máquina está abierta Sin importar lo que haga el microcontrolador, los errores de programación tienen menos impacto en la seguridad. El código de generación de pasos vive en un IRQ de alta frecuencia con temporizador con la prioridad más alta, por lo que la generación de pasos será exacta en el ciclo (requisito en tiempo real para mantener el movimiento suave), mientras que la interpretación de G-Code funciona en los datos que se reciben a través del UART (soft en tiempo real), USB (en masa, sin tiempo real) o Ethernet (TCP con retransmisiones, sin tiempo real).

    
respondido por el Simon Richter
2

Sí, es posible usar una interrupción para manejar un evento de botón pulsador. Un enfoque perfectamente bueno si solo tiene ese botón y una cantidad fija de tareas en ejecución.

En el contexto de su pregunta, un RTOS agrega valor al permitir que las tareas se establezcan como preventivas sin que tenga que realizar un seguimiento de cuántas interrupciones están pendientes, nivel de pila, etc., que se manejan por separado. También lo convierte en un sistema más escalable: agregue o elimine tareas sin un rediseño importante.

Hay muchas más ventajas que brindan las características de RTOS, pero fuera del alcance de su pregunta.

    
respondido por el AlmostDone

Lea otras preguntas en las etiquetas