RTOS en uC - Cómo enfrentar la elección o no de un RTOS para tu uC y proyecto

[Geni Suarez]

Buenos días a todos,

Alguien por aquí que domine el uso de RTOS en uC para dar su opinión y hablar de su experiencia?

No llevo largos años dedicándome a esto así que no alcanzo a tener un criterio totalmente fiable para mí misma.
Hasta ahora he estado creando aplicaciones, sobretodo, para ARM y PIC; desde 0, empezando por los módulos de drivers hasta módulos de más alto nivel de abstracción como las tareas (código de aplicación), gestión de interrupciones y montando los schedulers más básicos con contadores de ticks (basándome en timer). Donde aquí la prioridad la marca el orden en que coloco las llamadas en este contador. Las tareas de periodicidad más corta irán en el contador de menor valor y las más tardías en el de mayores valores, etc.

Cuando ya quieres o necesitas algo más sofisticado, puedes recurrir a los RTOS disponibles en el mercado, algunos gratis otros de pago. Pero la gente que conozco me comenta que integrar RTOS en un uC y crear un proyecto basado en este, es parecido a andar por el infierno.

Desconozco dónde radica la dificultad o el motivo por el cual son tan temidos, puesto que no tengo ese background. Si vienen con sus APIs debería facilitar más las cosas. Sería como usar librerías de terceros. Es mi suposición. No sé si el infierno estaría más en la compilación o en la depuración, quizás en ambas!

Por eso si alguien tiene experiencia a ver si puede comentar algo aquí. Me gustaría conducir el hilo hacia el tema de: cómo elegir un RTOS para tu proyecto, saber cuándo realmente es más práctico usar un RTOS para gestionar tus tareas y comunicaciones o simplemente buscarte un stack que integre servicios que tu código pueda necesitar. Como puede ser el caso ejemplo de querer hacer hablar un uC con un chip de Ethernet para enviar datos a otro destinatario que le pasa el uC.

Que tengáis un lindo día. Saludos a todos.

[martin ribelotta]

Buenas... es una pregunta demasiado general, pero voy a tratar de escribir algo para ir encaminando la discusión.

El jue., 14 feb. 2019 a las 8:11, Geni Suarez (<geni...@gmail.com>) escribió:

Buenos días a todos,

Alguien por aquí que domine el uso de RTOS en uC para dar su opinión y hablar de su experiencia?

No llevo largos años dedicándome a esto así que no alcanzo a tener un criterio totalmente fiable para mí misma.
Hasta ahora he estado creando aplicaciones, sobretodo, para ARM y PIC; desde 0, empezando por los módulos de drivers hasta módulos de más alto nivel de abstracción como las tareas (código de aplicación), gestión de interrupciones y montando los schedulers más básicos con contadores de ticks (basándome en timer). Donde aquí la prioridad la marca el orden en que coloco las llamadas en este contador. Las tareas de periodicidad más corta irán en el contador de menor valor y las más tardías en el de mayores valores, etc.

Cuando ya quieres o necesitas algo más sofisticado, puedes recurrir a los RTOS disponibles en el mercado, algunos gratis otros de pago. Pero la gente que conozco me comenta que integrar RTOS en un uC y crear un proyecto basado en este, es parecido a andar por el infierno.

No se a que se refieren, pero como todo, tiene su area de aplicación y su area donde es overkill.

En general, lo que describes en el párrafo anterior es un SSOO simple colaborativo.

Los RTOS entran a tener su utilidad cuando la complejidad de las operaciones y temporizados nos obligan a recrear un pseudo SO por debajo de nuestra app.

Por supuesto, bien planteado un RTOS es tan innecesario como cualquier otra pieza de software, ocurre que, como soluciona problemas de una forma probada acelera mucho el tiempo de desarrollo tenerlo ya hecho.

Desconozco dónde radica la dificultad o el motivo por el cual son tan temidos, puesto que no tengo ese background. Si vienen con sus APIs debería facilitar más las cosas. Sería como usar librerías de terceros. Es mi suposición. No sé si el infierno estaría más en la compilación o en la depuración, quizás en ambas!

Los RTOS te dejan hacer cosas extraordinarias que sudarías para hacer con un scheduler normal. El hecho de freezar un contexto de ejecución y restaurarlo implica una multiplexación en el tiempo del procesador como si fuera otro recurso similar a la memoria (pero en términos de ocupación espacial en vez de espacial como la memoria)

Esto trae implícito que ahora ya el procesador no es "nuestro" y que hay que seguir determinadas reglas a la hora de programar (semáforos, concurrencia, colas de tarea, prioridades, etc)

Cuando empiezan a aparecer los conceptos anteriormente mencionados es que pueden aparecer problemas por no entender que estamos haciendo (los RTOS se saben usar para matar moscas cuando están para matar dragones)

No es que esos problemas sean exclusivos de los RTOS... podemos ahorcarnos nosotros mismos programando mal sin necesidad de un RTOS... de hecho, es mas probable que luego de un cierto grado de complejidad en la coordinación de las tareas nos matemos nosotros mismos por reinventar un pseudo RTOS nosotros sin tener los cuidados que hacen falta para fabricar uno...

En definitiva, un RTOS no es trivial, las implicaciones que tienen no son triviales y la coordinación entre tareas fuertemente acopladas puede ser muy dolorosa si no lo hacemos bien. Corolario: usar programación bare metal cuando no haga falta RTOS (coordinación entre tareas devilment acopladas, con consumidores-productores claros y sin inversion de roles -que no de prioridad-), usar RTOS *****PROBADOS***** cuando la complejidad suba lo suficiente para requerir un fuerte manejo delas tareas y JAMAS reinventar un RTOS salvo que estemos abocados a hacer RTOSs con todo lo que eso conlleva.

Por eso si alguien tiene experiencia a ver si puede comentar algo aquí. Me gustaría conducir el hilo hacia el tema de: cómo elegir un RTOS para tu proyecto, saber cuándo realmente es más práctico usar un RTOS para gestionar tus tareas y comunicaciones o simplemente buscarte un stack que integre servicios que tu código pueda necesitar. Como puede ser el caso ejemplo de querer hacer hablar un uC con un chip de Ethernet para enviar datos a otro destinatario que le pasa el uC.

Justamente Ethernet y todos los protocolos de red serios (1153, spacewire, etc) tienden a requerir dos cosas:

 * Manejo espacial de memoria

 * Manejo temporal del procesador

En ambos casos, un RTOS es IDEAL porque va a hacer el trabajo mejor de lo que podríamos escribir desde cero y vamos a tener muchos bugs resueltos por el simple hecho de haberse usado el software en situaciones similares.

En cuanto a "cual" elegir, bueno, realmente no depende tanto del problema a resolver ya que todos proveen al menos esas dos cosas que dije anteriormente, sino de consideraciones mas de borde:

 * Por ejemplo, FreeRTOS esta "speudo" certificado para muchas cosas (los mecanismos de FreeRTOS son testeados via SafeRTOS o OpenRTOS con normativas industriales y espaciales)

 * mbedOS tiene un ecosistema de soporte en ARM nada envidiable y una integración de librerías de tercero exquisita.

 * NuttX tiene una cantidad de herramientas y una dinamice enorme y es muy escalable, pero es un proyecto unipersonal...

 * ErikaOS es una implementasión de autosar con mucho peso en la industria, pero si el fabricante del chip no da soporte oficial, pueden surgir algunos escenarios muy bizarros con su funcionamiento.

 * Integriti si bien es de pago tiene un soporte fenomenal y ofrece prestaciones decentes a un buen costo. Si tienen plata y hay que gastarla en un RTOS esta es una alternativa

 * RTEMS tien años de prueba en plataformas aeroespaciales, pero yo no lo usaría fuera de SPARC/LEON porque su arquitectura de drivers es muy molesta para mantener sin el soporte de la comunidad o un grupo grande de desarrolladores

 * QNX es un señor RTOS con muchísimos años de testeo y un soporte increíble

 * Linux si bien no es un RTOS, puede arrimarse mucho a uno y posee una batería de stacks de comunicaciones de primer nivel, muy difícil de superar por cualquier herramienta comercial. Eso si, lo de real-time hay que tomarlo con pinzas y entender que esto no es hard-RT (y que posiblemente el 90% de los RTOS que mencione antes tengan problemas para adaptarse a esa definición)

Como corolario al corolario remarco: NO HAGAN RTOSs PARA UN TRABAJO DE VERDAD!!! Si quieren jugar haciendo uno todo bien... pero a la hora de los bollos dedíquense a usar soluciones que les han fallado a otros!

 

Que tengáis un lindo día. Saludos a todos.

Idem. Esperemos que mas personas se sumen 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Geni Suarez]

Qué gran explicación, creo que ya sé a qué se refieren. 

Aquí dónde estoy me he encontrado un proyecto ejecutado por un Coldfire II casi obsoleto al que le metieron uTasker 1.3. Hoy hablo con el chico que lo hizo, pero por lo que me cuentan no creo que tuvieran en cuenta las problemáticas que mencionaste. Más bien la idea que hay con respecto a meter RTOS en los uC de parte de su electrónica era y es disponer de un stack de Ethernet. Lo cual me genera gran incertidumbre cuando me piden que para un diseño nuevo que piense en un RTOS o que le metamos el uTasker más actual. Comunican electrónica con sw propio en PC. La cosa es que no sé si habrá sido suerte o estaba todo muy bien pensado, pero en 10 años no se les ha descalabrado nada y parece que estos conceptos problemáticos y poco triviales no están dando problemas.  

La verdad no me vería capaz de diseñar una aplicación usando un RTOS sin tener los problemas que mencionas porque no domino esos conceptos para saber lo que hago, sobretodo a la práctica. Después de lo que me dices de los requisitos de trabajar con Ethernet entiendo más la necesidad de un RTOS. 

• Y ya que mencionas el tema de la memoria, hay alguna forma de controlar la memoria que se consume y de monitorearla aunque sea en modo debug? 
  
• Luego tengo una pregunta respecto a algo que comentas. A qué te refieres con "reinventar un RTOS" y con "NO HAGAN RTOSs PARA UN TRABAJO DE VERDAD!!  dedíquense a usar soluciones que les han fallado a otros"? 
  

Muchas gracias por el tiempo que te has tomado en compartir tu experiencia y conocimiento. Ha sido muy útil.

[Lucas Alberto Escribano]

Excelente explicación, la verdad que a mí también me resolvió mis dudas al respecto.

Muchas gracias Martin!!!

---

De: embeb...@googlegroups.com <embeb...@googlegroups.com> en nombre de Geni Suarez <geni...@gmail.com>
Enviado: viernes, 15 de febrero de 2019 05:19
Para: Embebidos32
Asunto: Re: [embeb32] RTOS en uC - Cómo enfrentar la elección o no de un RTOS para tu uC y proyecto

 

[Mariano Volker]

Buenos días,

me sumo a ésta charla para realizar una pregunta acorde.

Estoy trabajando con un equipo de investigación para el departamento de ingeniería de la UNLAM (Universidad Nacional de La Matanza). Aclaro que somos de Sistemas y no de Electrónica.

Estamos trabajando en un dispositivo para asistir a personas con movilidad reducida y reportar sucesos que a éste le ocurra con su posterior notificación a familiares y/o personas interesadas.  

Estamos utilizando este procesador BluePill (STM32F103C8T6) con 72 MHZ, memoria de 128 KB y estuvimos implementando desde las herramientas STM32CUBE y Eclipse System Workbench.

Para realizar ésto utilizamos un acelerometro MPU6050 para implementar un algoritmo detector de caídas, un GPS C3-470 como sensor de geolocalización, un SIM800L como GSM/GPRS para el envío de las notificaciones, un Bluethoot HM-10 para supervisar otros sensores biométricos como por ejemplo un pulsometro.

Al día de hoy nos encontramos con una disyuntiva a resolver en los próximos meses que consta de lo siguiente:

Hemos desarrollado drivers para acceder a los distintos dispositivos conectados a éste y vemos que estamos haciendo "demasiadas cosas" en un único hilo de ejecución. Estamos evaluando la posibilidad de utilizar un FreeRTOS como SO para utilizar distintos hilos pero tenemos el temor de que no sea la mejor solución. El STM32CUBE nos permite agregar FreeRTOS.

Consulto con uds cual sería la solución más adecuada para realizar ésta implementación.

Muchas gracias.

Ing. Mariano Volker
15-5415-4702

[Mariano Volker]

Anexo un link en cual tenemos una descripción del proyecto de investigación.

http://sedici.unlp.edu.ar/handle/10915/68034

Muchas gracias.

[martin ribelotta]

El vie., 15 feb. 2019 a las 5:19, Geni Suarez (<geni...@gmail.com>) escribió:

Qué gran explicación, creo que ya sé a qué se refieren. 

Aquí dónde estoy me he encontrado un proyecto ejecutado por un Coldfire II casi obsoleto al que le metieron uTasker 1.3. Hoy hablo con el chico que lo hizo, pero por lo que me cuentan no creo que tuvieran en cuenta las problemáticas que mencionaste. Más bien la idea que hay con respecto a meter RTOS en los uC de parte de su electrónica era y es disponer de un stack de Ethernet. Lo cual me genera gran incertidumbre cuando me piden que para un diseño nuevo que piense en un RTOS o que le metamos el uTasker más actual. Comunican electrónica con sw propio en PC. La cosa es que no sé si habrá sido suerte o estaba todo muy bien pensado, pero en 10 años no se les ha descalabrado nada y parece que estos conceptos problemáticos y poco triviales no están dando problemas.  

uTasker es un buen sistema operativo. Tiene años de depuración y pruebas en varias plataformas, sumado a que tiene un stack de ethernet bastante probado (aunque con bugs serios y conocidos, pero en un embebido puede no haber suficiente superficie de ataque para que se muestren como un problema)

Tambien, los coldfire de motorola/freescale/nxp son una señora arquitectura (68k modificada) bastante consolidada.

El problema? Están en camino al museo de las cosas gloriosas de épocas pasadas... esto es, no va a haber desarrollo nuevo aquí... entonces las perspectivas de futuro para desarrollar con ellos se acotan totalmente al programa del fabricante para mantener la linea.

Sobre las problemáticas que te cuento, suelen surgir como resultado de interacciones complejas con el entorno (paquetes broadcast, ruido ARP en la red, paquetes multicast con MACs erróneas, todas cosas que existen en redes comunes y corrientes fuera del laboratorio)

Pueden no verlo debido a que se manejen en un ambiente restringido, a que el stack ethernet sea lo suficientemente limitado como para obviar esos problemas y a un sinfín de "side efects" que ocurren en cualquier proyecto. El problema es que cuando la complejidad crece, los problemas que no tuvimos en cuenta por no presentarse aparecen de improviso y generan problemas que no sabemos de donde vienen ni como los resolvemos.

 

La verdad no me vería capaz de diseñar una aplicación usando un RTOS sin tener los problemas que mencionas porque no domino esos conceptos para saber lo que hago, sobretodo a la práctica. Después de lo que me dices de los requisitos de trabajar con Ethernet entiendo más la necesidad de un RTOS. 

Si el sistema operativo esta bien diseñado (ejemplo Linux) ese tipo de problemas quedan bastante enterrados en los corner-case del uso de las API, debido a que, el caso de mayor uso, esta pulido al máximo.

Ahí es donde aparece la diferencia entre un buen RTOS y uno malo: Que tanto me obliga a conocer los entresijos del mismo y a depurar el trabajo de otro.

Para mi, buenos RTOS son: ChibiOS, FreeRTOS+FreeRTOS-TCP, NuttX y mbed (este ultimo todavía bastante inestable en muchas cosas, pero bueno... es el precio del desarrollo)

 

• Y ya que mencionas el tema de la memoria, hay alguna forma de controlar la memoria que se consume y de monitorearla aunque sea en modo debug? 
  

 La mayoria de los RTOS permiten obtener una traza de memoria dinamica. Sino, siempre se puede interceptar las llamadas a malloc/free para que logeen en alguna parte.

https://www.freertos.org/rtos-trace-macros.html

https://www.freertos.org/a00111.html

http://lwip.100.n7.nabble.com/lwIP-with-FreeRTOS-memory-problem-td27924.html

En mi opinion, LwIP tiene un buen mecanismo de heaps y pools, bastante flexible. Tambien bastante propenso a romperse si uno no sabe lo que hace.

• Luego tengo una pregunta respecto a algo que comentas. A qué te refieres con "reinventar un RTOS" y con "NO HAGAN RTOSs PARA UN TRABAJO DE VERDAD!!  dedíquense a usar soluciones que les han fallado a otros"? 

A que, cuando la complegidad del software aumenta tendemos a resolver los problemas que resuelve un SO (concurrencia, manejo de memoria, manejo del procesador, manejo de tiempos) con herramientas escritas por nosotros mismos que replican la funcionalidad de un RTOS. A eso me refieron con "hacer un rtos", y puntualizo que eso es la receta para el desastre debido a que, cuando la complegidad crece al punto de estar cambiando de areas, manejar memoria dinamica o coordinar muchas tareas de interacción compleja entre si, no estamos teniendo en cuenta toda la teoria fuerte de OOSS ni de realtime.

Puede que nuestro problema no fuese lo suficientemente complejo como para hacer que eso nos explote en la cara, pero... no escala... ni bien venga un nuevo requerimiento, una nueva funcionalidad, nos demos cuenta que hace falta una interaccion que no tuvimos en cuenta, o cualquier cisne negro del desarrollo, vamos a encontrarnos seriamente limitados, salvo que seamos expertos en escribir, depurar y testear sistemas operativos de tiempo real.

Conosco gente que puede hacer eso, en esta lista, me sobran los dedos de una mano para contar a las personas que puedo dar fe que pueden hacerlo :-( entre las que dificilmente pueda contarme realmente...

Muchas gracias por el tiempo que te has tomado en compartir tu experiencia y conocimiento. Ha sido muy útil.

Es la idea de la lista! Seria interesante que nos cuentes como va a terminar la historia de tu desarrollo :-D

[Eric Pernia]

Agrego que desde que freeRTOS fue adquirido por Amazon están agregándole muchísimas funcionalidades.

Además los libros pagos del autor original Richard Barry ahora pueden descargarse de forma gratuita:

https://www.freertos.org/Documentation/RTOS_book.html

Les recomiendo mucho su lectura, no solo para el caso de freeRTOS si no que sirve en general para introducirse al tema.

Además están disponibles los cursos de posgrado de la UBA, que desde el año pasado tienen alternativa on line:

http://laboratorios.fi.uba.ar/lse/cursos.html

Saludos.

Eric.

[martin ribelotta]

El vie., 15 feb. 2019 a las 10:40, Mariano Volker (<marian...@gmail.com>) escribió:

Buenos días,

me sumo a ésta charla para realizar una pregunta acorde.

Estoy trabajando con un equipo de investigación para el departamento de ingeniería de la UNLAM (Universidad Nacional de La Matanza). Aclaro que somos de Sistemas y no de Electrónica.

Estamos trabajando en un dispositivo para asistir a personas con movilidad reducida y reportar sucesos que a éste le ocurra con su posterior notificación a familiares y/o personas interesadas.  

Estamos utilizando este procesador BluePill (STM32F103C8T6) con 72 MHZ, memoria de 128 KB y estuvimos implementando desde las herramientas STM32CUBE y Eclipse System Workbench.

Para realizar ésto utilizamos un acelerometro MPU6050 para implementar un algoritmo detector de caídas, un GPS C3-470 como sensor de geolocalización, un SIM800L como GSM/GPRS para el envío de las notificaciones, un Bluethoot HM-10 para supervisar otros sensores biométricos como por ejemplo un pulsometro.

Al día de hoy nos encontramos con una disyuntiva a resolver en los próximos meses que consta de lo siguiente:

Hemos desarrollado drivers para acceder a los distintos dispositivos conectados a éste y vemos que estamos haciendo "demasiadas cosas" en un único hilo de ejecución. Estamos evaluando la posibilidad de utilizar un FreeRTOS como SO para utilizar distintos hilos pero tenemos el temor de que no sea la mejor solución. El STM32CUBE nos permite agregar FreeRTOS.

Las preguntas que se tienen que hacer para evaluar esto es:

• ¿Que estamos viendo para creer que tenemos muchas tareas en un mismo hilo?
• ¿Que clase de tareas tenemos? (clases: tareas de IO, tareas de procesamiento, tareas de monitoreo, tareas que se crean de forma dinamica, etc etc)
• ¿Que gano migrando a "hilos"? ¿Que problemas me genera eso? ¿Como los puedo resolver sin una reingenieria de todo el software?
• ¿Que codigo de terceros tengo disponible? ¿Que tan compatible es el codigo que no puedo tocar con lo que voy a hacer?

En definitiva, hay que estudiar caso por caso que es lo que hace falta y que se necesita.

A veces podemos obviar el uso de un RTOS escribiendo código no bloqueante en un loop de eventos bien hecho. Eso requiere que las librerías y el codigo de terceros este hecho de tal manera que permita eso (lwip tiene un API que permite manejo no bloqueante, bsd-sockets tambien puede manejarse de forma no bloqueante, uip es no bloqueante desde el vamos, y asi)

Ocurre que la resolución de problemas en nuestra cabeza, trabaja en forma bloqueante por defecto.

Yo cuando me levanto, me pego un baño, me visto, caliento la pava, hago el mate, me siento a desayunar y recien ahi salgo a la calle... si intento hacer el ultimo paso luego de bañarme y antes de vestirme, primero, en bariloche me muero de hipotermia y segundo en cualquier otro lado voy en cana por indecente jajajajaaj....

Lo que permite un RTOS, es describir nuestra solucion a los problemas en forma bloqueante y utilizar los distintos bloqueos como hilo conductor de las distintas tareas... por supuesto "adivinar" como hacer eso es un problema que no es algoritmicamente resoluble (tampoco por un humano) y que, para igual hacerlo, se usan heuristicas que "parecen" funcionar bien (round robin, FIFO, deadline, etc)

 

Consulto con uds cual sería la solución más adecuada para realizar ésta implementación.

Si podes escribir todo de forma no bloqueante, es un golazo porque te evita usar un RTOS. Si tu solucion es bloquenate por diseño, un RTOS y un buen estudio de la comunicacion entre procesos.

Segun veo, tu problema se reduce a sensor meshing y comunicaciones, asi que cualquiera de las dos soluciones es factible de implementar teniendo los recaudos necesarios en cada caso.

[Diego Turconi]

Hola Mariano ,

Yo estoy en la Unlam y estoy en Investigacion tambien pero somos de Electronica. Me podes encontrar los Martes que voy a la facultad y vemos tu problema con el STM32F103C8T6 si queres y como resolverlo y/ analizarlo. Yo manejo los micros de ST.

Saludos Diego

El vie., 15 feb. 2019 a las 10:40, Mariano Volker (<marian...@gmail.com>) escribió:

[Mariano Volker]

Muchas gracias Martin !!! 

Muy descriptiva tu respuesta !!!

Diego me voy ir para el laboratorio de electronica. 

Muchas gracias.

Saludos.

[Leandro Francucci]

A las consideraciones que bien detalló Martín agregaría:

• ¿El sistema debe cumplir con fuertes restricciones temporales?. ¿Es un sistema soft o hard real-time?. Si bien estas respuestas no implican estrictamente el uso de un RTOS, el hecho de usar uno ayudaría, en principio, a lograr una mejor uilización de la CPU y  cumplir con estas restricciones en un ambiente medianamente controlado.

Relacionado con el lazo de eventos en sistemas como el que mencionan, el concepto de objetos activos es realmente muy potente y puede utilizarse con y sin RTOS. Este concepto no sólo permite coordinar las tareas sino también lograr un acceso más seguro a los recursos compartidos que las maneras tradicionales.

Y lo mejor es que con un RTOS subyacente, los objetos activos pueden ser del tipo reactivo, continuo o periódico, y estos pueden coexistir en una misma aplicación, donde por ejemplo, los reactivos resuelven las cuestiones que están gobernadas por la ocurrencia de eventos y requieren mantener historia de lo sucedido, y el resto resuelve cuestiones como lazos de control, procesamiento de datos, comunicaciones, el manejo de algún dispositivo particular, entre otros.

Respecto a esto último paso algo de info.

Saludos!

Leandro

[Alejandro Celery]

Hola Geni!

Veo que disparaste una gran opinadera digna de polémica en el bar, la única diferencia es que acá los parroquianos saben un montón de lo que hablan.

En lo técnico no voy a agregar nada, pero creo que no le acertaron a tu pregunta original con las respuestas así que va mi intento de responder tu pregunta original:

El chiste de meter un RTOS no es el RTOS en sí ni su API ni nada, es saber manejar los conceptos de programación concurrente (o multitarea o multihilo o como le quieras llamar). Como todo, te da herramientas para que soluciones los mismos problemas de siempre pero de maneras más sencillas. El tema es que eso le abre la puerta a otro tipo de problemas más difíciles de solucionar que son las interacciones entre los distintos hilos de ejecución. Yo no conozco una manera práctica de testear un diseño así. Acá abro yo la puerta para que opinen los que saben.

En definitiva, si sabés programación concurrente (te recuerdo, son conceptos, no herramientas ni APIs) y diseñás tu aplicación criteriosamente no deberías tener grandes problemas al usar RTOS. "Andar por el infierno" me parece que les habrá pasado al tener un diseño no tan bueno, quién sabe. Mi mejor sugerencia sería que practiques un poco con cualquier RTOS como para sacar tus propias conclusiones (te recomiendo FreeRTOS, es muy fácil de empezar a usar, pero ese es solo mi parecer).

En el único caso que te podría traer problemas es si tu aplicación es en algún campo regulado (médico, aeroespacial, etc) donde vas a tener que usar componentes certificados para la aplicación en cuestión y eso te puede salir $$$. Es solo otra cosa a considerar.

Yo cuando daba clase de RTOS en UBA y UTN enseñaba primero a usar todasd las herramientas de los RTOS y luego a NO usarlas. Hay gente que jura y perjura que solo deberías tener un hilo por cada core que tengas, pero es materia opinable.

Para cerrar te dejo una frase de me tío Horacio "vos podés perfectamente tener un elefante en un bazar, solo lo tenés que manejar finito".

Ah, una más: te dejo una presentación que escribí yo hace varios años cuando era profe de estas cosas: http://www.sase.com.ar/2012/files/2012/09/Introduccion-a-los-RTOS.pdf

Está bastante desactualizada pero te puede servir para darte una mejor idea de todo este mundo.

Exitos!

Saludos,

Alejandro

[Mariano Volker]

Genial Leandro !. Gracias por la ayuda. 

Voy a considerar todas las respuestas y espero tomar la mejor decisión.

Saludos.