embedded - multiprogramacion - sistemas operativos en tiempo real pdf

¿Por qué consideraría usar un RTOS para mi proyecto incrustado? (5)

Primero los antecedentes, los detalles de mi pregunta seguirán:

En la empresa en la que trabajo, en la plataforma en la que trabajamos, actualmente se encuentra la familia Microchip PIC32 que utiliza el IDE de MPLAB como nuestro entorno de desarrollo. Anteriormente, también hemos escrito firmware para las familias Microchip dsPIC y TI MSP para esta misma aplicación. El firmware es bastante sencillo, ya que el código se divide en tres módulos principales: control del dispositivo, muestreo de datos y comunicación del usuario (generalmente una PC del usuario). El control del dispositivo se logra mediante una combinación de líneas de bus GPIO y al menos una parte que necesita control SPI o I2C. El muestreo de datos se controla mediante interrupciones utilizando un módulo de temporizador para mantener la frecuencia de muestreo y más líneas de bus SPI / I2C y GPIO para controlar el hardware de muestreo (es decir, ADC). La comunicación del usuario se implementa actualmente a través de USB utilizando el marco de aplicación de Microchip.

Entonces, ahora la pregunta: dado lo que he descrito anteriormente, ¿en qué punto consideraría emplear un RTOS para mi proyecto? Actualmente estoy pensando en estos posibles puntos de activación como razones para usar un RTOS:

Código de complejidad? La arquitectura / organización del código base es todavía lo suficientemente pequeña como para que pueda guardar todos los detalles en mi cabeza.
Multitarea / Threading? Cortar en el tiempo la ejecución del módulo a través de interrupciones es suficiente por ahora para realizar múltiples tareas.
¿Pruebas? Actualmente no realizamos muchas pruebas formales o verificaciones después de la prueba de humo HW (algo que espero corregir en un futuro cercano).
¿Comunicación? Actualmente utilizamos un formato de paquete personalizado y un protocolo que prácticamente solo ejecuta los comandos START, STOP, SEND DATA con datos que son un blob binario.
¿Alcance del proyecto? Existe la posibilidad de obtener un proyecto para integrar nuestro dispositivo en un sistema más grande con el objetivo de llevar ese sistema a la producción en masa. Actualmente, todos nuestros proyectos han sido prototipos experimentales con un rápido cambio de alrededor de un mes, produciendo una o dos unidades a la vez.

¿Qué otros puntos crees que debería considerar? Según su experiencia, ¿qué lo convenció (o lo obligó) a considerar el uso de un RTOS frente a la ejecución de su código en el tiempo de ejecución base? Los punteros a recursos adicionales sobre diseño / programación para un RTOS también son muy apreciados.

Además de los puntos mencionados anteriormente, usar un RTOS también puede ser útil si necesita soporte para

Dispositivos de almacenamiento estándar (SD, Compact Flash, unidades de disco ...)
hardware de comunicación estándar (Ethernet, USB, Firewire, RS232, I2C, SPI, ...)
Protocolos de comunicación estándar (TCP-IP, ...)

La mayoría de los RTOS proporcionan estas funciones o son ampliables para admitirlas

Hay muchas razones por las que puede querer usar un RTOS. Son variados y es difícil decir hasta qué punto se aplican a su situación. (Nota: tiendo a pensar de esta manera: RTOS implica un tiempo real difícil que implica un kernel preventivo ...)

Rate Monotonic Analysis (RMA) : si desea utilizar el Rate Monotonic Analysis para garantizar que se cumplan los plazos de entrega, debe utilizar un planificador preventivo
Cumpla con los plazos en tiempo real : incluso sin utilizar RMA, con un RTOS preventivo basado en la prioridad, su programador puede ayudar a garantizar que se cumplan los plazos. Paradójicamente, un RTOS generalmente aumentará la latencia de interrupción debido a las secciones críticas en el kernel donde las interrupciones generalmente están enmascaradas
Administre la complejidad : definitivamente, un RTOS (o la mayoría de los sabores de SO) puede ayudar con esto. Al permitir que el proyecto se descomponga en subprocesos o procesos independientes, y al utilizar servicios del sistema operativo como colas de mensajes, mutexes, semáforos, indicadores de eventos, etc. para comunicarse y sincronizar, su proyecto (en mi experiencia y opinión) se vuelve más manejable. Tiendo a trabajar en proyectos más grandes, donde la mayoría de la gente entiende el concepto de proteger los recursos compartidos, por lo que muchos de los errores de los novatos no ocurren. Pero tenga cuidado, una vez que vaya a un enfoque de múltiples hilos, las cosas pueden volverse más complejas hasta que encierre su cabeza en torno a los problemas.
Uso de paquetes de terceros : muchos RTOS ofrecen otros componentes de software, como pilas de protocolos, sistemas de archivos, controladores de dispositivos, paquetes GUI, cargadores de arranque y otro middleware que lo ayuda a crear una aplicación más rápido al convertirse en casi un "integrador" más que Una tienda de bricolaje.
Pruebas : sí, definitivamente, puede pensar en cada subproceso de control como un componente comprobable con una interfaz bien definida, especialmente si se utiliza un enfoque coherente (como bloquear siempre en un solo lugar en una cola de mensajes). Por supuesto, esto no es un sustituto para las pruebas de unidad, integración, sistema, etc.
Robustez / tolerancia a fallos : un RTOS también puede proporcionar soporte para la MMU del procesador (en su caso PIC, no creo que se aplique). Esto permite que cada hilo (o proceso) se ejecute en su propio espacio protegido; los hilos / procesos no pueden "sumergirse" en la memoria de los demás y pisotearlos. Incluso las regiones de dispositivo (MMIO) pueden estar fuera del límite de algunos (o todos) subprocesos. Estrictamente hablando, no necesita un RTOS para explotar una MMU (o MPU) de un procesador, pero las 2 funcionan muy bien de la mano.

Generalmente, cuando puedo desarrollar con un RTOS (o algún tipo de multitarea preventiva), el resultado tiende a ser más limpio, más modular, más educado y más fácil de mantener. Cuando tengo la opción, uso uno.

Tenga en cuenta que el desarrollo multihilo tiene una pequeña curva de aprendizaje. Si eres nuevo en RTOS / desarrollo multiproceso, es posible que te interesen algunos artículos sobre Cómo elegir un RTOS , Los peligros de la prevención y Una Introducción a la multitarea preferente .

Por último, aunque no pidió recomendaciones ... Además de los numerosos RTOS comerciales, hay ofertas gratuitas ( FreeRTOS es una de las más populares), y la Plataforma Quantum es un marco basado en eventos basado en el Concepto de objetos activos que incluye un kernel preventivo. Hay muchas opciones , pero he descubierto que tener el código fuente (incluso si el RTOS no es gratuito) es ventajoso, especialmente. cuando se depura.

Por lo general, desea utilizar un RTOS si tiene restricciones en tiempo real. Si no tiene restricciones en tiempo real, un sistema operativo normal puede ser suficiente. Los RTOS / OS proporcionan una infraestructura de tiempo de ejecución como colas de mensajes y tareas. Si solo está buscando un código que pueda reducir la complejidad, proporcione soporte de bajo nivel y ayuda con las pruebas, algunas de las siguientes bibliotecas podrían hacerlo:

Las bibliotecas estándar de C / C ++.
Boost bibliotecas
Bibliotecas disponibles a través del fabricante del chip que puede proporcionar soporte específico de hardware
Bibliotecas comerciales
Bibliotecas de código abierto

RTOS, ante todo, le permite organizar sus flujos paralelos en el conjunto de tareas con una sincronización bien definida entre ellos.

OMI, el diseño no RTOS es adecuado solo para la arquitectura de flujo único donde todo su programa es un gran bucle sin fin. Si necesita el flujo múltiple, una serie de tareas que se ejecutan en paralelo, es mejor con RTOS. Sin RTOS, se verá obligado a implementar esta funcionalidad de forma interna, reinventando la rueda.

Reutilización del código : si codifica controladores / controladores de protocolo utilizando una API RTOS, pueden conectarse a proyectos futuros más fácilmente

Depuración : algunos IDE (como IAR Embedded Workbench) tienen complementos que muestran buenos datos en vivo sobre su proceso en ejecución, como la utilización de la CPU de la tarea y la utilización de la pila