RTOS para sistemas embebidos

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.

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.

¿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.

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!

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.

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.

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.

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.

Pregunta estrechamente relacionada: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

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.