RTOS para sistemas embebidos


57

He visto muchos artículos que me dicen que debería usar RTOS para la gestión del tiempo y la gestión de recursos. Mi tiempo no ha permitido mi propia investigación, por lo que acudo a Chiphacker en busca de asesoramiento.

Utilizo microcontroladores de bajos recursos (MSP430, PIC) y estaba buscando RTOS que pueda usar.

Al punto:

  1. Costo de recursos del sistema
  2. Ventajas del sistema
  3. Desventajas del sistema
  4. Trucos de implementación
  5. Situaciones en las que el RTOS debe / no debe usarse.

No uso sistemas como el arduino, los proyectos con los que trabajo no pueden soportar el costo de dicho sistema.


2
Estoy confundido sobre por qué recibió un voto negativo. Si el votante pudiera darme su opinión, intentaré evitar tal acción en el futuro.
Kortuk

1
ídem. Es una gran pregunta ...
Jason S

Acepté una pregunta porque, incluso si esto es abierto, tuve una gran cantidad de respuestas excelentes y quería recompensar al menos a un escritor por el esfuerzo.
Kortuk

Respuestas:


29

No he tenido mucha experiencia personal con RTOS que no sean QNX (lo cual es genial en general, pero no es barato y he tenido una experiencia realmente mala con un proveedor de placa en particular y la actitud de QNX de que no nos importa para otros sistemas que su más común), que es demasiado grande para PIC y MSP430.

Donde se beneficiará de un RTOS es en áreas como

  • gestión de hilos / programación
  • comunicaciones entre hilos + sincronización
  • E / S en sistemas con stdin / stdout / stderr o puertos serie o soporte de ethernet o un sistema de archivos (no es un MSP430 o PIC en su mayor parte, excepto los puertos serie)

Para periféricos de un PIC o MSP430: para puertos seriales usaría un buffer de anillo + interrupciones ... algo que escribo una vez por sistema y simplemente lo reutilizo; otros periféricos no creo que encuentre mucho soporte de un RTOS, ya que son tan específicos del proveedor.

Si necesita un tiempo que sea sólido como una roca al microsegundo, un RTOS probablemente no ayudará: los RTOS tienen un tiempo limitado, pero generalmente tienen una fluctuación de tiempo en su programación debido a retrasos en el cambio de contexto ... QNX ejecutándose en un PXA270 tenía fluctuación en las decenas de microsegundos típicos, 100-200us máximo, por lo que no lo usaría para cosas que tienen que correr más rápido que aproximadamente 100Hz o que necesitan una sincronización mucho más precisa que aproximadamente 500us. Para ese tipo de cosas, probablemente tendrá que implementar su propio manejo de interrupciones. Algunos RTOS jugarán muy bien con eso, y otros lo convertirán en un verdadero dolor: es posible que su sincronización y su sincronización no puedan coexistir bien.

Si el tiempo / programación no es demasiado complejo, es mejor que use una máquina de estado bien diseñada. Recomiendo encarecidamente leer Diagramas de estado prácticos en C / C ++ si aún no lo ha hecho. Hemos utilizado este enfoque en algunos de nuestros proyectos donde trabajo, y tiene algunas ventajas reales sobre las máquinas de estado tradicionales para gestionar la complejidad ... que es realmente la única razón por la que necesita un RTOS.


Trabajo en una empresa de nueva creación donde los tipos de sistemas embebidos más experimentados acaban de salir de la universidad (es decir, yo y el otro tipo que ha estado trabajando conmigo durante aproximadamente 2 años). Paso una gran parte del tiempo enseñándome sobre la práctica de la industria durante mi semana laboral. Como he estado leyendo, he sido informado de todos, excepto nuestro sistema de menor costo, un RTOS sería una gran mejora.
Kortuk

Parece que hay un sistema RTOS de muy bajos recursos para cosas como PIC y MSP430 que pueden ayudar a crear un sistema determinista a partir de uno muy complicado, que también limpia en gran medida nuestra gestión de mantener los módulos separados. He sido parte de un equipo de dos personas que construyó efectivamente un sistema de recolección y enrutamiento de datos en el campo. Ahora que miro a RTOS veo que es perfecto para lo que diseñamos.
Kortuk

Perdón por usar tres espacios de publicación, su respuesta es muy útil, estoy buscando una solución de recursos muy bajos, pero esta información es valiosa, gracias por la ayuda.
Kortuk

no se preocupe por el recuento de comentarios (en mi humilde opinión, una cosa de la que carece el marco StackExchange es el soporte para las discusiones ... el formato Q / A cubre la mayoría de las cosas, pero no algunas) ... parece que tiene un buen manejo de lo que estas buscando. No he visto el FreeRTOS que Steve ha mencionado, pero si se ha portado a microcontroladores de gama baja, tal vez haga la gestión de programación que necesita.
Jason S

Parece guardar el estado de cada subproceso a través de la pila (algo así como 50 declaraciones push / pull) y puede manejar interrupciones temporizadas. Mi sistema normalmente usaría una interrupción de puerto para el cambio de hilo, pero la tarea parece factible. Deseo que este tipo de sitio maneje la discusión en un mejor formato.
Kortuk

26

¿Has probado FreeRTOS ? Es gratis (sujeto a T&C) y ha sido portado tanto al MSP430 como a varios sabores de PIC.

Es pequeño en comparación con algunos otros, pero esto también facilita el aprendizaje, especialmente si no ha usado un RTOS antes.

Se encuentra disponible una licencia comercial (no gratuita), así como una versión IEC 61508 / SIL 3.


Muchas gracias, lo investigaré dentro de una semana, dejaré la pregunta abierta para otras respuestas, ¡pero son de gran ayuda!
Kortuk

12

Me acabo de enterar de NuttX RTOS, que incluso puede funcionar en un sistema 8052 (8 bits). No tiene muchos puertos, pero parece interesante. POSIX puede ser una ventaja, ya que puede hacer que parte de su código sea un poco más portátil si pasa a un procesador más robusto y desea ejecutar Linux en tiempo real o QNX.

No tengo ninguna experiencia con RTOS comerciales, ¡pero he usado los caseros durante años! Son excelentes para ayudarlo a dividir el desarrollo de su código entre muchos programadores, porque esencialmente cada uno puede obtener una "tarea" o "hilo" para trabajar de su parte. Todavía tiene que coordinar y alguien debe supervisar todo el proyecto para asegurarse de que cada tarea pueda cumplir su fecha límite.

También le recomiendo que investigue el Análisis de Frecuencia Monotónica o RMA cuando use un RTOS. Esto lo ayudará a garantizar que sus tareas críticas cumplan con sus plazos.

También buscaría en el marco de programación controlado por eventos QP-nano de Miro Samek que puede funcionar con o sin un RTOS y aún así brindarle capacidad en tiempo real. Con él, está dividiendo su diseño en máquinas de estado jerárquicas en lugar de tareas tradicionales. Jason S mencionó el libro de Miro en su publicación. Una excelente lectura!


9

Una cosa que he encontrado útil en varias máquinas es un simple conmutador de pila. Realmente no he escrito uno para el PIC, pero esperaría que el enfoque funcione bien en el PIC18 si ambos / todos los hilos usan un total de 31 o menos niveles de pila. En el 8051, la rutina principal es:

_tarea interruptor:
  xch a, SP
  xch a, _altSP
  xch a, SP
  jubilado

En el PIC, olvido el nombre del puntero de la pila, pero la rutina sería algo así como:

_tarea interruptor:
  movlb _altSP >> 8
  movf _altSP, w, b
  movff _STKPTR, altSP 
  movwf _STKPTR, c
  regreso

Al comienzo de su programa, llame a una rutina task2 () que carga altSP con la dirección de la pila alternativa (16 probablemente funcionaría bien para un PIC18Fxx) y ejecuta el bucle task2; esta rutina nunca debe volver o las cosas morirán de muerte dolorosa. En su lugar, debería llamar a _taskswitch cada vez que quiera ceder el control a la tarea principal; la tarea principal debería llamar a _taskswitch cuando quiera ceder el paso a la tarea secundaria. A menudo, uno tendrá pequeñas rutinas lindas como:

void delay_t1 (val corto sin signo)
{
  hacer
    taskwitch ();
  while ((unsigned short) (milisegundo_clock - val)> 0xFF00);  
}

Tenga en cuenta que el conmutador de tareas no tiene ningún medio para hacer ninguna 'espera de condición'; todo lo que soporta es un spinwait. Por otro lado, el cambio de tarea es tan rápido que intentar un cambio de tarea () mientras la otra tarea está esperando que expire un temporizador cambiará a la otra tarea, verificará el temporizador y volverá más rápido que un interruptor de tareas típico determinaría que no necesita cambiar de tarea.

Tenga en cuenta que la multitarea cooperativa tiene algunas limitaciones, pero evita la necesidad de muchos bloqueos y otros códigos relacionados con mutex en los casos en que los invariantes que se alteran temporalmente pueden restablecerse rápidamente.

(Editar): Un par de advertencias con respecto a las variables automáticas y tales:

  1. Si se llama a una rutina que utiliza el cambio de tareas desde ambos subprocesos, generalmente será necesario compilar dos copias de la rutina (posiblemente #incluyendo el mismo archivo fuente dos veces, con diferentes #definir declaraciones). Cualquier archivo de origen contendrá código para un solo subproceso o contendrá código que se compilará dos veces, una para cada subproceso, para que pueda usar macros como "#define delay (x) delay_t1 (x)" o #define delay (x) delay_tx (x) "dependiendo del hilo que esté usando.
  2. Creo que los compiladores PIC que no pueden "ver" una función que se llama asumirán que dicha función puede destruir todos y cada uno de los registros de la CPU, evitando así la necesidad de guardar cualquier registro en la rutina de cambio de tarea [un buen beneficio en comparación con Multi tareas preventivo]. Cualquiera que esté considerando un conmutador de tareas similar para cualquier otra CPU debe conocer las convenciones de registro en uso. Empujar registros antes de un cambio de tarea y abrirlos después es una manera fácil de ocuparse de las cosas, suponiendo que exista un espacio de pila adecuado.

La multitarea cooperativa no le permite a uno escapar completamente de los problemas de bloqueo y demás, pero realmente simplifica mucho las cosas. En un RTOS preventivo con un recolector de basura compactante, por ejemplo, es necesario permitir que se fijen los objetos. Cuando se usa un conmutador cooperativo, esto no es necesario siempre que el código asuma que los objetos GC se pueden mover cada vez que se llama a taskwitch (). Un colector de compactación que no tiene que preocuparse por los objetos anclados puede ser mucho más simple que uno que lo hace.


1
Impresionante respuesta. Creo que sería interesante obtener algunos enlaces sobre recursos para acercarme a mi propio RTOS. Mi enfoque aquí realmente fue obtener un RTOS de alta calidad de un proveedor que haya hecho el trabajo de garantizar un tiempo real difícil, pero este podría ser un proyecto de afición divertido para mí.
Kortuk

1
Genial, nunca pensé en las tareas como solo cambiar el SP ...
NickHalden

1
@JGord: He hecho pequeños conmutadores de tareas en el 8x51 y en un TI DSP. El 8051, que se muestra arriba, está diseñado para precisamente dos tareas. El DSP uno se usa con cuatro y es un poco más complicado. Sin embargo, tenía una idea loca: uno podía manejar cuatro tareas simplemente usando tres conmutadores de tareas. Cada vez que una de las dos primeras tareas quiera cambiar de tarea, debe llamar a TaskSwitch1 y TaskSwitch2. Cuando una de las segundas dos tareas quiere cambiar de tarea, debe llamar a Taskswitch1 y Taskswitch3. Suponga que el código comienza en stack0, y cada conmutador de tareas se establece con su número de pila correspondiente.
supercat

@JGord: Hmm ... eso no funciona del todo; parece producir un round-robin de 3 vías e ignora el tercer conmutador. Bueno, experimenta y creo que probablemente encontrarás una buena fórmula.
supercat

7

He usado Salvo en el MSP430. Esto fue muy ligero en los recursos del procesador y, siempre que obedezca las reglas de implementación, fue muy fácil de usar y confiable. Este es un sistema operativo cooperativo y requiere que los cambios de tareas se realicen en el nivel de llamada a la función externa de las funciones de la tarea. Esta restricción permite que el sistema operativo funcione en dispositivos de memoria muy pequeños sin utilizar grandes cantidades de espacio de pila manteniendo contextos de tareas.

En el AVR32 estoy usando FreeRTOS. De nuevo, muy confiable hasta ahora, pero he tenido algunas discrepancias de configuración / versión entre la versión que publica FreeRTOS y la versión suministrada con el marco Atmel. Sin embargo, esto tiene la ventaja de que es gratis.


5

La edición de diciembre de Everyday Practical Electronics tiene la parte 3 de una serie sobre sistemas operativos en tiempo real para PIC (en la columna PIC n 'Mix) y tiene detalles sobre la configuración de FreeRTOS con MPLAB y un PICKit 2. Los dos artículos anteriores (que I no he visto) parece haber discutido los méritos de varios RTOSes y se decidió por FreeRTOS. Una vez que el artículo actual ha configurado el entorno de desarrollo, comienzan a diseñar un reloj digital binario. Parece que hay al menos una parte más sobre este tema.

No estoy seguro de la disponibilidad de EPE en los EE. UU., Pero parece que hay una tienda de EE. UU. Vinculada desde su sitio y puede haber copias electrónicas disponibles.


4

El compilador CCS para el PIC viene con un RTOS simple. No lo he probado, pero si tienes este compilador, sería fácil experimentar con él.


1
De hecho, intenté esto como el primero. No es un RTOS en ningún significado real de la palabra. No es preventivo de ninguna manera. Requiere el uso regular de los comandos de rendimiento para que el RTOS pueda decidir quién ejecuta a continuación, debe ponerlos intencionalmente constantemente en caso de que otro programa necesite hacerse cargo.
Kortuk

2
Creo que todavía se llama RTOS. Parece que tiene un planificador cooperativo en lugar de un planificador totalmente preventivo.
Jay Atkinson

Sí, técnicamente sigue siendo un RTOS, pero tenía y sigo teniendo muy poco valor. Sé que es algo personal, pero para mí debe ser preventivo para ser valioso. Todavía hago +1 ya que fue una buena respuesta y valiosa.
Kortuk

3

¡Gracias! Parece que la mayoría de la gente no recibió la pregunta, pero sigue siendo interesante.
Kortuk

¡Publiqué sobre la pregunta en SO invitando al usuario a venir a E&R en busca de ayuda!
Kortuk

Creo que "obtuvimos" la pregunta sobre SO, era hacer algo diferente pero relacionado con esta pregunta. En cuanto a su comentario allí sobre la certificación; Eso depende de muchas cosas. Mirando las respuestas aquí, me gusta la respuesta de DoxaLogos que se refiere a QP-nano; mi experiencia me lleva a preferir el código controlado por eventos sobre los hilos y el cambio de contexto implícito de hilos.
enero

2

No ha dicho mucho sobre su solicitud. Si usa un RTOS depende mucho de lo que necesita hacer en el PIC. A menos que esté haciendo varias cosas asincrónicas diferentes, que requieren límites de tiempo estrictos o que tienen varios subprocesos en ejecución, entonces un RTOS podría ser excesivo.

Hay muchas formas de organizar el tiempo en un microcontrolador dependiendo de lo más importante:

  1. Velocidad de fotogramas constante: para un PIC que ejecuta un servocontrolador que debe funcionar a 1000Hz, por ejemplo. Si el algoritmo PID tarda menos de 1 ms en ejecutarse, puede usar el resto del milisegundo para realizar otras tareas, como verificar el bus CAN, leer sensores, etc.

  2. Todas las interrupciones: todo lo que sucede en el PIC se desencadena por una interrupción. Las interrupciones se pueden priorizar según la importancia del evento.

  3. Pegarlo en un bucle y hacer todo lo más rápido que pueda. Puede encontrar que esto proporciona límites de tiempo adecuados.


Entiendo otros métodos, pero quiero expandirme a un RTOS. Ejecutaré múltiples tareas y tendré un sistema de tiempo real difícil, pero estoy dispuesto a comenzar sin los requisitos de tiempo real difícil. Gracias por tomarse el tiempo para responder, pero quiero aprender un RTOS para poder usarlo en una situación de alta demanda.
Kortuk
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.