¿Por qué el nombre de rtBasics?

Estaba yo pensando, ¿por qué le he puesto este nombre? ¿Qué es eso de Back to Real Time Basics?

Bueno, quería reivindicar un poquito los tiempos en los que estas cosas del software embebido eran sencillas por necesidad.

Digo por necesidad porque la ROM era EPROM (con una E) y porque toda la RAM era estática. Claro, así contar con más 128KB de cada una era un lujo. Eso si tenías la suerte de que tu procesador pudiera direccionar más de 64KB. Yo tuve la suerte: Motorola 68008, que recuerdos!

Digo por necesidad porque programábamos en ensamblador y, claro, hacer un programa de más de 128KB de ROM que funcionara era un reto. Incluso siendo ensamblador del 68000.

Digo por necesidad porque depurábamos con un aparato que se llamaba MICE (Micro In Circuit Emulator) del tamaño de una caja grande de zapatos que sustituía al micro y que para que funcionara aquello tenían que estar todos los conectores de un montón de cables perfectamente puestos, conectados y colocados ortogonalmente respecto al borde de la mesa. Todavía me estoy preguntando por qué eso sería necesario.

Después de esto, los microprocesadores dejaron de ser procesadores y se convirtieron en microcontroladores. Lo que antes eran periféricos empezaron a estar dentro del micro. Cuando ya no cabían las patas, se inventaron las BGAs y los micros ya podían volver a tener más patas.

Ahora ya todo está dentro, controladores de NAND FLASH, de memorias dinámicas, de video, … sólo hace falte ponerle un reloj, unos cuantos GB de NAND, muchos cientos de MB de DDRX y ya está. Bueno, casi, ahora hay que tener cuidado con la alimentación. Con tantas cosas dentro suelen necesitar varias alimentaciones con una secuencia de arranque determinada.

No está mal. Mucho mejor. Y, además, en una gran variedad. Desde micros de cierta capacidad con todo integrado, incluso las memorias y el cristal, que funcionan sólo con la alimentación, hasta micros con varios núcleos homogéneos o incluso heterogéneos que pueden correr varios sistemas operativos simultáneamente. Hablaremos de esto algún día.

Vale, parece claro que el hardware ha mejorado y, desde el punto de vista del “usuario”, se ha simplificado, pero ¿qué ha pasado con el software?

El software… desde luego ha mejorado, pero no me atrevo a decir que se haya simplificado. Veamos…

En mi trayectoria, yo he sentido varios saltos cualitativos, que voy a tratar de describir aquí. Son subjetivos, así que otros lo habrán percibido de manera distinta.

Fue un salto cualitativo dejar el ensamblador y programar en C.

Fue un salto cualitativo empezar a usar un sistema operativo. En mi caso, VRTX sobre procesadores de Motorola 68020 y 68302. ¿Te acuerdas, David, de los convertidores de protocolo Profibus para Oresund?

Fue un salto cualitativo usar VxWorks sobre los PowerQUICC I de Freescale. Siempre funcionaba todo y, cuando no funcionaba, como todo estaba en su sitio, siempre sabía uno dónde ir a mirar. Descubrí muchas cosas con VxWorks. Un recuerdo desde aquí para Alberto Bonfiglio, que falleció a finales del año pasado.

Y, para mí, el último gran salto cualitativo fue la compra de WindRiver por Intel. ¿Y eso? ¿Tanto tiene esto que ver?

Yo diría que sí. Cuando Intel compró WindRiver la mayoría de los equipos industriales que usaban VxWorks tenían procesadores de Freescale. ¿Quería Intel cambiar esto y “fomentar” el uso de sus procesadores en los equipos industriales con VxWorks?

No lo sé, la verdad. Si yo hubiese sido el CEO de Freescale en aquel momento del año 2009 hubiese pensado que sí. Creo que él también lo pensó porque a partir de entonces Freescale se ha preocupado más de tener bajo control el software más íntimo, el que hace que sus procesadores sirvan para algo.

¿Y cómo lo ha hecho? Fundamentalmente, ofreciendo de manera gratuita, en código fuente, el sistema operativo MQX para la mayoría de sus procesadores y mejorando y poniendo un precio razonable a su IDE CodeWarrior. Otro día podemos dedicarle un monográfico a MQX. A mí me parece un regalo muy valioso. Está muy bien estructurado, incorpora drivers para prácticamente todos los dispositivos y proporciona a las aplicaciones los recursos habituales en este entorno como son stack TCP/IP, sistema de ficheros, stack USB, etc.

Acabo de decir que MQX es un regalo, pero no es así. Freescale sabe muy bien que un factor muy importante, quizás el más importante, en la selección de un procesador es su ecosistema software.

Bueeeno, voy a mencionar otro salto cualitativo: la incorporación de Linux al entorno de los sistemas embebidos. Es indudable que Linux ha ofrecido a los equipos industriales un crecimiento software muy importante, pero también es verdad que es un sistema complicado, con muchas posibilidades que hay que manejar con prudencia.

No voy a decir nada malo de Linux, Dios me libre, además, sería políticamente incorrecto, pero muchas veces se asume como la solución por defecto sin haber medido despacio sus ventajas y sus inconvenientes.

Quizás por esto último, y volviendo al título, reivindico que mantengamos el software sencillo, que la solución sea la solución más sencilla posible, que pensemos activamente cómo se puede simplificar la cosa porque aunque ya no es necesario que el software embebido sea sencillo, sigue siendo tremendamente recomendable.

Have fun!

About Juan Serrano

Juan Serrano es especialista en ingeniería eléctrica y en el diseño y desarrollo de equipos de telecontrol
This entry was posted in Broadcasting. Bookmark the permalink.

1 Response to ¿Por qué el nombre de rtBasics?

  1. Ronald says:

    Hola Juan,
    Estuve dando un vistazo a tu pagina y en especial a este Post, soy alumno del Master de renovables donde diste clases, me parece interesante lo que dices aquí, así que me anime a comentar unas cosas. Me parece interesante y cierto lo que dices acerca de como era la electrónica digital de hace unos años y lo que hay ahora. Cuando estuve en el grado ya me tope con los microcontroladores, pics, lenguajes en C sin embargo me intereso también investigar sobre sus antecesores y creo que saber apreciar y entender los inicios de las cosas es importante y te da criterios para entender las cosas como son mas adelante. Tal como mencionas también implemente programas en ensamblador, utilice las RAM, los microprocesadores, grabe EPROM, (buscando el dichoso borrador de luz ultravioleta que mi universidad no tenia), EEPROM conectandolos en protobards como muchos supongo y llevo gratos recuerdos de madrugadas buscando las mejores estrategias para conseguir un funcionamiento objetivo de los prototipos. Mencionas muchos sistemas que no eh llevado a ver aun, pero les daré un vistazo en cuanto el tiempo me sea propicio pues suenan interesantes. Respecto al software comparto que “la solución mas sencilla es siempre la mejor” pues trabajando en Sistemas de Automatización industrial me eh dado cuenta que los software ,en este campo por lo menos, vienen muy generales con infinidad de entradas por configurar y opciones que nunca llegan a usarse en toda la vida útil de la planta y que si preguntas nadie sabe para que sirve, finalmente nadie desea intervenir en su uso mas técnico pues se hace algo complejo para el que lo opera. Es interesante se proponga un software y hardware a medida de las necesidades así que bien por la iniciativa de la empresa.
    Saludos Cordiales

Leave a Reply

Your email address will not be published. Required fields are marked *