2008-09-22 18 views
8

En un pequeño proyecto de sistema integrado, tenemos un código que nos gustaría ejecutar en un hilo, por lo que optamos por construir en la parte superior de un RTOS incrustado (eCos).¿Tiene sentido mezclar un RTOS y un ejecutivo cíclico?

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

Al cambiar a un RTOS encontramos que el uso de memoria para la pila de cada hilo se suma rápidamente si le damos a cada tarea por separado su propio hilo. (solo tenemos 64k y necesitamos la memoria para nuestros búferes de comunicaciones)

Estamos considerando usar una banda de rodadura para nuestra tarea de comunicaciones y otra para un ejecutivo cíclico. El ejecutivo cíclico dirigirá las otras tareas lógicas.

¿Tiene sentido combinar un RTOS y ejecutivo cíclico de esta manera?

Respuesta

6

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íncronas (TCP/IP, 2 transmisiones en serie) estaban en sus propias tareas y teníamos una tarea "principal" que sería responsable de múltiples áreas de funcionalidad.

Considere las tareas como simplemente un mecanismo de división que le permite simplificar su diseño.

0

Es un diseño válido, pero creo que olvidé la razón para tener el sistema operativo en absoluto.

¿Qué características del SO está planeando usar?

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

+0

La capacidad de subprocesamiento preventivo nos permite evitar la construcción de una máquina de estado demasiado compleja en la tarea de comunicaciones. Al tener un hilo para la parte de comunicaciones, el código es bastante directo. Si lo dividimos en un estado en cada punto que actualmente tiene un tipo de bloque de reposo (1000), el código sería básicamente un lío de código espagueti de estados muy pequeños. Se podría hacer, sin embargo, preferiríamos mantener el código limpio y mantenible. Las otras máquinas de estado varían de simples a algo complejas (una tiene ~ 15 estados).La máquina de estado de comunicaciones sería aún más co – JeffV

2

Sí, tener un ejecutivo cíclico en un subproceso del sistema operativo que ejecute múltiples 'tareas' puede tener sentido. De hecho, a menos que dos tareas entren en conflicto con las necesidades de programación (se necesita bloquear, una es de mayor prioridad que la otra y la de baja prioridad tarda mucho tiempo 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: hilos separados no son más seguros que un hilo (sin protección MMU de espacios de direcciones), de hecho son potencialmente más peligroso debido a la mayor necesidad de protección de concurrencia. Incluso si su esquema de IPC es robusto y no es susceptible de uso indebido por parte de los programadores, su sobrecarga generalmente no es cero, por lo que evitar la necesidad de hacerlo puede generar mejoras de rendimiento.

1

Si look at FreeRTOS, que en realidad ejecutar otro programador en una tarea, más o menos :)

Y a otros se hacen eco, nada suena mal en el diseño. No hay razón (algunas de) sus tareas no pueden ser máquinas de estado si hay una manera clara de expresar algo de esa manera.

Cuestiones relacionadas