¿Tiene sentido mezclar un RTOS y un ejecutivo cíclico?

Question

En un pequeño proyecto de sistema integrado, tenemos un código que nos gustaría ejecutar en un hilo, por lo que elegimos compilarlo sobre un RTOS integrado (eCos).

Anteriormente, hemos utilizado un ejecutivo cíclico en main() que impulsaba tareas, cada una implementada como una máquina de estados.Para algunas tareas, encontramos problemas en los que la tarea debía dividirse en muchos estados detallados, lo que hacía que el código fuera más complejo.

Al cambiar a un RTOS, descubrimos que el uso de memoria para la pila de cada subproceso se acumula rápidamente si le asignamos a cada tarea por separado su propio subproceso.(sólo tenemos 64k y necesitamos la memoria para nuestros buffers de comunicaciones)

Estamos valorando utilizar una banda de rodadura para nuestra tarea de comunicación y otra hilo para un ejecutivo cíclico.El ejecutivo cíclico impulsará las otras tareas lógicas.

¿Tiene sentido mezclar un RTOS y un ejecutivo cíclico como este?

Answer 1

Este es un diseño perfectamente válido.
En uno de nuestros productos, utilizamos un diseño similar, donde los canales de E/S asíncronos (TCP/IP, 2 flujos en serie) tenían sus propias tareas y teníamos una tarea "principal" que sería responsable de múltiples áreas de funcionalidad. .

Piense en las tareas simplemente como un mecanismo de partición que le permite simplificar su diseño.

Answer 2

Sí, tener un ejecutivo cíclico en un subproceso del sistema operativo ejecutando múltiples "tareas" puede tener sentido.De hecho, a menos que dos tareas entren en conflicto con las necesidades de programación (una necesita bloquearse, una tiene mayor prioridad que la otra y la de baja prioridad tarda mucho en ejecutarse, etc.), recomendaría ponerlas en el mismo hilo.

Esto es especialmente cierto en el caso de que esté utilizando un RTOS liviano sin protección de memoria:Los subprocesos separados no son más seguros que un subproceso (sin protección MMU de los espacios de direcciones); de hecho, son potencialmente más peligrosos debido a la mayor necesidad de protección de concurrencia.Incluso si su esquema IPC es sólido y no susceptible de uso indebido por parte de los programadores, su sobrecarga generalmente es distinta de cero, por lo que evitar su necesidad puede generar ganancias de rendimiento.

Answer 3

Si usted mira FreeRTOS, en realidad ejecutan otro programador en una tarea, más o menos :)

Y para hacernos eco de otros, nada suena mal en el diseño.No hay razón para que (algunas de) sus tareas no puedan ser máquinas de estados si hay una manera clara de expresar algo de esa manera.

Answer 4

Es un diseño válido, pero creo que no entendí la razón para tener el sistema operativo.

¿Qué funciones del sistema operativo planeas utilizar?

Según la información disponible, parece que terminarás trasladando la complejidad de las tareas a tu nuevo bucle principal.