RTOS

Tomado del libro "The Art of Designing Embedded Systems" 2ed de "Jack Ganssle"

Estos son mis reglas de oro para la decisión si obtener o no un RTOS

• Cualquier sistema grande, donde "grande" se define como la pornografía (es decir, "Sé esto cuando lo veo"), se pone bien un RTOS o, en su caso, un sistema operativo convencional como Linux. Grandes sistemas siempre se hacen más grandes, grandes sistemas son inherentemente complejos, y los grandes sistemas manejan muchas diferentes actividades, por lo que se benefician de tener un entorno multitarea.
• La mayoría de los sistemas pequeños, donde "pequeños" significa que estamos contando centavos, no le pongas un sistema operativo de ningún tipo.
• Cuando hay vidas en juego si el sistema no es cargado ligeramente hacemos un análisis muy cuidadoso para ver si el multitarea podría crear problemas en el determinismo (ver más abajo). Si el determinismo no se puede garantizar, y si no hay ningún mecanismo de seguridad redundante, evitar un RTOS. Tenga en cuenta, sin embargo, que el traslado de tareas a los llamados de interrupción no resuelve el problema de determinismo. Un mecanismo diferente, como secuencias de disparo por tiempo, es probablemente más adecuado.
• Si un organismo regulador debe certificar el producto, entonces, utilizar un RTOS sólo si una versión certificable está disponible. Por ejemplo, varios proveedores venden sistemas operativos comerciales certificable a DO-178B Nivel A, pero estos productos no están disponibles para todos los procesadores.
• Si hay múltiples actividades independientes en marcha, tales como la necesidad de actualizar la pantalla al mismo tiempo que la obtención de datos y escaneo de un teclado, prefiero usar un RTOS.
• Si un simple loop puede manejar todas las necesidades de la aplicación, y que se prevé la no necesidad futura de agregar mas funcionalidad más allá de lo que el bucle se puede manejar, no tome la RTOS