Volviendo sobre nuestros pasosHasta el momento hemos visto que los RTOS pueden ser muy útiles al enfrentar la implementación de aplicaciones complejas, ellos nos ofrecen herramientas poderosas y simples que facilitan el desarrollo rápido de aplicaciones, las desventajas fundamentales que hemos estado viendo son aceptables cuando las comparamos con los beneficios que obtenemos por utilizar un RTOS.
Hasta hace algún tiempo, el diseño de sistemas con microcontroladores se enfrentaba con horas y horas delante de una PC o con una hoja de papel, escribiendo código en ensamblador y pasando mucho trabajo para que cualquier cosa que diseñásemos funcionara, eso solamente en teoría, ni que decir de llevar esos diseños a la práctica, y tener que lidiar entonces con las PCB, circuitos haciendo cosas “extrañas” y demás.
Con la llegada de los compiladores para lenguajes como C, PASCAL, BASIC y simuladores avanzados como el PROTEUS, los desarrolladores de aplicaciones han tenido un importante respiro para llevar adelante sus diseños. Pero el mercado, y los consumidores se han vuelto más exigentes y la parada ha tenido que subir un poco, la solución: utilizar sistemas operativos en los dispositivos embebidos.
Como toda maravilla tecnológica, el uso de un SO requiere muchas veces perder ciertas ventajas respecto a los métodos anteriores. Cuando programábamos en ensamblador obteníamos el máximo en desempeño y aprovechamiento del microcontrolador pero el desarrollo y puesta a punto era muy lento y las aplicaciones podían tener errores muy difíciles de detectar.
Los compiladores mejoraron el problema de los errores y redujeron considerablemente el tiempo de desarrollo, pero los programas gastan más memoria de programa, memoria de datos y son más lentos en ejecución.
Los SO aumentan las desventajas de los compiladores pero mejoran el desarrollo de aplicaciones en muchos otros aspectos.
La solución al dilema de eficiencia vs eficacia nos la ofrecen los mismos fabricantes de microcontroladores, al diseñar dispositivos cada vez más rápidos y con más memoria. Ahora podemos simplemente movernos entre las diferentes gamas y familias de dispositivos buscando el que se adapta mejor a nuestras necesidades y utilizar métodos de diseño tan avanzados como los RTOS. Los precios no son el mayor problema como antaño, incluso algunos uC ya obsoletos salen más caros que sus sustitutos.
Toda la explicación anterior está destinada a refrescar el por qué utilizar un RTOS respecto de utilizar los medios que hemos venido utilizando hasta el momento y porque a partir de ahora comenzaremos a ver los peligros de implementar aplicaciones con el uso de este tipo de herramientas.
La mayor pesadilla para cualquier programador es que su aplicación se bloquee o “cuelgue” y el sistema deje de trabajar como debe, este tipo de problemas es muy frecuente en sistemas operativos orientados a usuarios como Windows y en menor medida GNU/LINUX, la razón para ello está en la diversidad de aplicaciones que puede utilizar un usuario, los errores de estos programas, los propios del SO, la capacidad del usuario para hacer que el SO colapse (conozco varios usuarios expertos en esta materia), etc.
Al utilizar un RTOS para programar aplicaciones nos estamos enfrentando al problema de crear aplicaciones que tienen alta probabilidad de bloquear al sistema, ello está dado porque las cosas que debe hacer el sistema están divididas en procesos o tareas que se ejecutan de forma más o menos independiente del resto, compartiendo recursos del sistema y compitiendo por ellos. A todo lo anterior hay que sumarle que en el momento de la ejecución, el SO no tiene idea de que orden lleva la ejecución de los procesos o cuanto tiempo le tomará a un proceso terminar su ejecución, es por eso que no se pueden programar aplicaciones para SO en base a suposiciones en el orden de ejecución de las tareas o los tiempos requeridos para su completamiento.
Todo lo anterior puede asustarnos mucho porque implica que programar utilizando RTOS es potencialmente peligroso, y sí, ¡ES PELIGROSO! Pero más que peligroso es complicado y puede ser muy tedioso, ya que se complica la semántica y la depuración de las aplicaciones, pero eso no debe ser motivo de desaliento, ya que existen técnicas para reducir esas complicaciones y los problemas están debidamente identificados. Y eso es lo que vamos a comenzar a tratar en las próximas entregas.
Existen muchos problemas con los que los diseñadores deben lidiar al programar utilizando un SO, pero en nuestro caso, por las características de nuestros dispositivos, estamos salvados de un buen número de ellas. Sin embargo Némesis ha querido de todas formas poner un límite a nuestra dicha, y nos ha obsequiado dos clases de problemas que pueden hacernos perder la razón si decidimos utilizar un RTOS:
- Condiciones de competencia
- Bloqueo mutuo
En las próximas entregas iremos viendo poco a poco cada una de estas clases de problemas, como detectar los problemas, ejemplos tipos de aplicaciones en que se presentan y como enfrentar estas dificultades.
El arma fundamental con que contamos está en utilizar correctamente los mecanismos de coordinación y sincronización, ya que el mal uso de ellos es una da las causas que pueden provocar una condición de competencia o un bloque mutuo, otras veces el hecho está en un diseño chapucero, mal pensado, errores semánticos en el código o simplemente que no haya solución al problema (aunque esto último es muy poco frecuente o muy difícil de detectar).
Ahora, como veremos próximamente, aprender a programar con un RTOS es mucho más complicado de lo que hemos visto hasta el momento, pero yo no quise meterles miedo y poner los problemas por delante de las ventajas de los RTOS, sino mostrarles un poco de lo mucho que se puede hacer para luego meternos con los problemas a los que debemos enfrentarnos.
Como han podido apreciar, hoy no tengo ninguna aplicación que mostrarles, pero no se desalienten porque próximamente vamos a toparnos con cada programita que ya ustedes tendrán de sobra para dolores de cabeza, pero al final cada uno de ustedes estará en condiciones de enfrentarse a la solución de aplicaciones difíciles de implementar en muy poco tiempo, podrán también estudiar y profundizar en la teoría de los Sistemas Operativos sin muchas dificultades y si explotan bien lo aprendido podrán llegar a ser profesionales muy competitivos y capaces.
Un saludo Reinier
