FreeRTOS - Problemas potenciales con tareas periódicas

0

Supongamos que la tarea 1 tiene la prioridad más alta de todas las tareas, y se ejecuta periódicamente usando vTaskDelayUntil ().

La tarea 2 tiene una prioridad más baja, pero también se requiere que se ejecute periódicamente en intervalos de tiempo estrictos.

¿Esto significa que puede haber casos en los que la Tarea 2 no siempre se pueda ejecutar en el momento correcto, mientras que la Tarea 1 siempre se ejecutará en los intervalos correctos?

¿Qué diferencia tendría la configuración de ambas tareas en la misma prioridad, si las hay?

Tengo entendido que se supone que un RTOS debe ejecutar tareas de manera predecible / determinista. ¿Cómo se puede evitar este problema?

    
pregunta M-R

2 respuestas

2

Si los intervalos son completamente asíncronos, entonces sí, a veces una tarea tendrá que esperar a la otra.

Si los intervalos se pueden sincronizar de alguna manera, entonces organice el tiempo de manera que la segunda tarea se ejecute en los espacios entre las ejecuciones de la primera tarea.

    
respondido por el Dave Tweed
0

Es posible que desee buscar Calificar la programación monótica en Wikipedia. Si tiene 2 tareas difíciles en tiempo real y quiere estar seguro de que pueden cumplir con sus fechas límite (la fecha límite será su próximo período programado), entonces el límite de Lui y Layland puede ser una estimación rápida si es posible programarlo. El límite de LL pone un límite a la cantidad de% de tiempo de CPU que puede usar todo su programa en tiempo real.

Tenga en cuenta que si se produce un error en el límite de LL, no refuta que el programa no sea programable. Hay más límites disponibles que se pueden usar para una mejor estimación, hasta la estimación del tiempo de respuesta, que es el enfoque más iterativo.

Tenga en cuenta que, sin embargo, la mayoría de los RTOS regulares utilizan programadores diferentes de los que dice la teoría. Entonces, en ese caso, realmente necesita asegurarse de que los períodos estén programados de forma monotónica, preferiblemente a través de un temporizador. Otros horarios tienen límites diferentes, como Programación EDF permite que el tiempo de CPU suba al 100%, al mismo tiempo que puede demostrar su El programa puede funcionar.

A partir de su publicación y otros comentarios, no parece que esté realmente creando un sistema en tiempo real, pero estos límites aún son agradables a tener en cuenta. Otro factor que puede ayudar en la robustez de los sistemas RTOS es asegurarse de que:

  • seguro para subprocesos; por ejemplo, su código puede ocuparse de las preferencias y es reentrante.
  • Hay suficiente espacio de búfer disponible para, por ejemplo, flujos entrantes o datos entre procesos.
  • Vigile el uso y la construcción de las interrupciones. Las interrupciones a menudo se ejecutan con un permiso del kernel y usan una pila diferente. Además, las interrupciones pueden ocurrir en cualquier momento y, por lo tanto, consumen tiempo de CPU para cualquier tarea de su programa.

Un patrón de diseño común es hacer lo mínimo en la interrupción para asegurarse de que el hardware esté disponible y luego señalar una tarea RTOS desde la interrupción para procesar los datos a un nivel superior.

    
respondido por el Hans

Lea otras preguntas en las etiquetas