RTOS para sistemas embebidos

55

He visto muchos artículos que me dicen que debería usar RTOS para la administración del tiempo y la administración de recursos. Mi tiempo no ha permitido mi propia investigación, así que acudo a Chiphacker para pedirle un consejo.

Uso microcontroladores de bajos recursos (MSP430, PIC) y buscaba 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 que el RTOS debería / debería no ser utilizado en.

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

    
pregunta Kortuk

9 respuestas

29

No he tenido mucha experiencia personal con los RTOS que no sean QNX (lo cual es genial en general, pero no es barato y he tenido una experiencia muy mala con un proveedor de tableros en particular y la actitud de no nos importa de QNX para sistemas distintos a los más comunes) que es demasiado grande para PIC y MSP430.

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

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

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

Si necesita una temporización que sea sólida como una roca en el microsegundo, un RTOS probablemente no ayude: los RTOS tienen una temporización limitada, pero generalmente tienen fluctuaciones en la programación debido a los retrasos en el cambio de contexto ... QNX se ejecuta un PXA270 tuvo fluctuaciones en las decenas de microsegundos típicas, 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 requieren 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 dolor real: es posible que su tiempo y su tiempo no puedan coexistir bien.

Si la sincronización / programación no es demasiado compleja, es posible que esté mejor utilizando una máquina de estado bien diseñada. Recomendaría encarecidamente leer Statecharts Prácticos en C / C ++ si aún no lo ha hecho. Hemos utilizado este enfoque en algunos de nuestros proyectos en los que trabajo, y tiene algunas ventajas reales sobre las máquinas estatales tradicionales para administrar la complejidad ... que es realmente la única razón por la que necesita un RTOS.

    
respondido por el Jason S
25

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

Es pequeño en comparación con otros, pero esto también hace que sea fácil de aprender, especialmente si no has usado un RTOS anteriormente.

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

    
respondido por el Steve Melnikoff
11

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

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, ya que esencialmente pueden obtener una "tarea" o "hilo" para trabajar de su parte. Aún tiene que coordinar y alguien debe supervisar todo el proyecto para asegurarse de que cada tarea pueda cumplir con el plazo.

También te recomiendo que investigues Rate Monotonic Analysis o RMA cuando utilizando un RTOS. Esto le ayudará a garantizar que sus tareas críticas cumplan con sus plazos.

También vería el QP-nano de Miro Samek que puede funcionar con o sin un RTOS y todavía le da capacidad en tiempo real. Con él, usted 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 post. Una excelente lectura!

    
respondido por el Jay Atkinson
9

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

_taskswitch:
  xch  a,SP
  xch  a,_altSP
  xch  a,SP
  ret

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

_taskswitch:
  movlb _altSP >> 8
  movf  _altSP ,w,b
  movff _STKPTR,altSP 
  movwf _STKPTR,c
  return

Al inicio 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 una muerte dolorosa. En su lugar, debe llamar a _taskswitch siempre que quiera ceder el control a la tarea principal; la tarea principal debe llamar a _taskswitch siempre que quiera ceder a la tarea secundaria. A menudo, uno tendrá pequeñas rutinas lindas como:

void delay_t1(unsigned short val)
{
  do
    taskswitch();
  while((unsigned short)(millisecond_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 interruptor de tareas es tan rápido que al intentar un interruptor de tareas () mientras que la otra tarea está esperando a que expire un temporizador, se cambiará a la otra tarea, verificará el temporizador y volverá más rápido que un conmutador de tareas típico determinaría que no es necesario cambiar las tareas.

Tenga en cuenta que la multitarea cooperativa tiene algunas limitaciones, pero evita la necesidad de un montón de bloqueo y otros códigos relacionados con la exclusión mutua en los casos en que las invariantes que están temporalmente alteradas pueden restablecerse rápidamente.

(Editar): Un par de advertencias sobre las variables automáticas y tales:

  1. si se llama a una rutina que usa el cambio de tareas desde ambos subprocesos, generalmente será necesario compilar dos copias de la rutina (posiblemente al #incluir el mismo archivo fuente dos veces, con diferentes #define sentencias). Cualquier archivo fuente dado contendrá código para un solo hilo, o bien contendrá código que se compilará dos veces, una vez para cada hilo, así que puedo usar macros como "#define delay (x) delay_t1 (x)" o #define delay (x) delay_tx (x) "dependiendo del hilo que estoy usando.
  2. Creo que los compiladores PIC que no pueden "ver" una función que se está llamando supondrá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 tareas beneficio en comparación con la multitarea preventiva]. Cualquier persona que esté considerando un conmutador de tareas similar para cualquier otra CPU debe conocer las convenciones de registro en uso. Presionar los registros antes de un cambio de tarea y abrirlos después es una forma fácil de cuidar las cosas, suponiendo que exista el espacio de pila adecuado.

La multitarea cooperativa no le permite a uno escapar por completo de los problemas del bloqueo, pero en realidad simplifica mucho las cosas. En un RTOS preventivo con un recolector de basura de compactación, por ejemplo, es necesario permitir que los objetos se fijen. Cuando se utiliza un conmutador cooperativo, esto no es necesario siempre que el código suponga que los objetos del GC pueden moverse en cualquier momento en que se llame a las funciones con el conmutador (). Un colector de compactación que no tiene que preocuparse por los objetos fijados puede ser mucho más simple que uno que sí.

    
respondido por el supercat
7

He usado Salvo en el MSP430. Esto fue muy ligero en cuanto a los recursos del procesador y, siempre que obedezca las reglas de implementación, es muy fácil de usar y confiable. Este es un sistema operativo cooperativo y requiere que los cambios de tarea se realicen en el nivel de llamada de función externa de las funciones de tarea. Esta restricción permite que el sistema operativo funcione en dispositivos de memoria muy pequeños sin usar vastas cantidades de espacio de pila que mantienen los 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 FreeRTOS publica y la versión suministrada con el marco Atmel. ¡Sin embargo, esto tiene la ventaja de que es gratis!

    
respondido por el uɐɪ
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 el PIC n 'Mix Column) y tiene detalles sobre la configuración de FreeRTOS con MPLAB y un PICKit 2. Los dos artículos anteriores (que no he visto) parecen haber discutido los méritos de varios RTOS y se han decidido 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 por venir 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 a su sitio y puede haber copias electrónicas disponibles.

    
respondido por el Amos
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.

    
respondido por el Jeanne Pindar
3

Pregunta estrechamente relacionada: enlace

    
respondido por el davidcary
2

No has dicho mucho sobre tu aplicación. Si utiliza un RTOS depende mucho de lo que necesita hacer en el PIC. A menos que esté haciendo varias cosas asíncronas diferentes, que requieren límites de tiempo estrictos, o que tenga varios subprocesos en ejecución, entonces un RTOS podría ser una exageración.

Hay muchas maneras de organizar la hora en un microcontrolador dependiendo de lo que es más importante:

  1. Velocidad de cuadros constante: para un PIC que ejecuta un servocontrol 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. Pégalo en un bucle y haz todo lo más rápido que puedas. Podría encontrar que esto proporciona límites de tiempo adecuados.

respondido por el Rocketmagnet

Lea otras preguntas en las etiquetas