Capítulo 1.
Una Primera Mirada a
los Sistemas Embebidos
A medida que los microprocesadores se han vuelto más pequeños y de menor precio, más y más productos tienen
microprocesadores “embebidos” en estos productos para hacerlos más “inteligentes”. Estos microprocesadores y su
software controlan productos como VCR, relojes digitales, ascensores, motores de automóviles, termostatos,
equipos de control industrial e instrumentos científicos y médicos. La gente usa el término sistema embebido para
referirse a cualquier sistema informático oculto en estos productos.
El software para sistemas embebidos debe manejar muchos tipos de problemas más allá de los que se
encuentran en el software de aplicación usados en computadoras de escritorio o mainframes. Los sistemas
embebidos a menudo tienen varias cosas que hacer a la vez. Deben responder a eventos externos (por ejemplo,
alguien que presiona el botón de un ascensor). Deben hacer frente a todas las condiciones inusuales sin intervención
humana. Su desarrollo está sujeto a tiempos de respuesta.
1.1 Ejemplos de Sistemas Embebidos
Para comprender los problemas del software de sistemas embebidos y concretar un poco más los problemas, se
comienza examinando algunos sistemas de ejemplo. Se revisarán estos ejemplos de vez en cuando mientras se
discutan algunos problemas y las propuestas de solución.
Caso de Estudio 1: Sistema Telegraph
El primer sistema que se estudiará recibió el nombre código de Telegraph durante su desarrollo. A pesar de que este
fue su nombre código no debería confundirse con un telégrafo tradicional para transmisión de código Morse. El
sistema Telegraph permite conectar una impresora con solo un puerto serial de alta velocidad a una red. La
apariencia del sistema Telegraph es la de una pequeña caja de plástico de 2 a 3 pulgadas de lado y aproximadamente
media pulgada de grosor. Un cable flexible en un lado de la caja se conecta al puerto serial de la impresora. Un
conector en el otro lado de la caja se conecta a la red. Un boceto del sistema Telegraph se muestra en la Figura 1.1.1
1
El sistema Telegraph se creó para funcionar con las impresoras de inyección de tinta de Apple, que normalmente tenían un
puerto serial que se podía conectar directamente a una computadora Macintosh. Su forma le permite encajar directamente en
la parte posterior de una de estas impresoras. Varias versiones funcionaron con diferentes redes.
Figura 1.1 Sistema Telegraph
El sistema Telegraph debe recibir datos de la red y copiarlos en el puerto serial. Sin embargo, el sistema Telegraph
es algo más complicado que eso. Aquí, hay algunas cosas que debe hacer el sistema:
•
•
•
•
•
•
En la red, los datos a veces llegan desordenados, a veces se pierden en el camino y algunos de los datos a
veces llegan repetidos. El sistema Telegraph debe solucionar el caos en la red y proporcionar un flujo de
datos limpio a una sola impresora.
Puede haber muchas computadoras en la red, todas ellas pueden querer imprimir a la vez. Se espera que la
impresora esté atendiendo a una sola computadora. El sistema Telegraph debe alimentar a la impresora con
un trabajo de impresión a la vez y de alguna manera mantener a raya a todas las demás computadoras.
Las impresoras de red deben proporcionar información de estado a cualquier computadora en la red que lo
solicite, incluso si están ocupadas imprimiendo un trabajo para otra computadora. La impresora de puerto
serial original no puede hacer eso, y el sistema tiene que hacerlo.
El sistema Telegraph tiene que trabajar con muchos tipos diferentes de impresoras sin configuración del
cliente, el sistema tiene que averiguar el tipo de impresora a la que está conectado.
El sistema Telegraph debe responder con bastante rapidez a eventos específicos. Hay, por ejemplo, varios
tipos de tramas de la red a las que el sistema debe enviar una respuesta en un plazo de 200 microsegundos.
El sistema Telegraph debe llevar la cuenta del tiempo. Por ejemplo, si una computadora que había envíado
datos a la impresora falla, y el sistema Telegraph finalmente debería abandonar ese trabajo de impresión,
probablemente después de 2 minutos, e imprimir desde otra computadora en la red. De lo contrario, una
falla en la computadora haría que la impresora no estuviera disponible para todos.
Desafíos en el Desarrollo del Sistema Telegraph
Para satisfacer la lista de requerimientos dados anteriormente, el sistema Telegraph tiene un microprocesador
incorporado. Su software es más extenso y sofisticado de lo que su apariencia externa podría hacerle creer. ¿Qué
problemas surgen al desarrollar dicho software? Antes de seguir leyendo, podría considerar escribir cuáles cree que
podrían ser estos problemas.
Para empezar, por supuesto, el software para el sistema Telegraph debe ser lógicamente correcto y no puede
perder el rastro de qué computadora está imprimiendo o dejando caer datos o reportando un estado incorrecto. Este
es el requisito exacto que se impone a cada pieza de software, tanto en el ámbito del software embebido como en el
de las aplicaciones.
Sin embargo, escribir el software para el sistema Telegraph, como escribir software para muchos otros
sistemas embebidos, ofrece algunos desafíos adicionales, que se discutirá ahora.
Rendimiento: throughput
La impresora puede imprimir tan rápido como el sistema Telegraph pueda proporcionarle datos, y el sistema no
debe convertirse en un cuello de botella entre las computadoras de la red y la impresora. En su mayor parte, el
problema de obtener más datos a través de un sistema embebido es bastante similar al de hacer que una aplicación
se ejecute más rápido. Lo resuelve mediante una programación inteligente: mejor búsqueda y clasificación, mejores
algoritmos numéricos, estructuras de datos que son más rápidas de analizar, etc. Aunque estas técnicas están más
allá del alcance de este libro, se discutirán los posibles errores con los sistemas operativos en tiempo real que
degradarán su rendimiento.
Tiempos de Respuesta
Cuando llega una trama crítica de datos de la red, el sistema Telegraph debe responder en 200 microsegundos,
incluso si está haciendo otra cosa cuando llega la trama. El software debe cumplir con este requerimiento. Se
discutirá los tiempos de respuesta extensamente porque es un problema común en los sistemas embebidos y porque
todas las soluciones representan compromisos en los requerimientos de varios tipos.
La gente a menudo usa la palabra, relativamente confusa: “velocidad”. Sin embargo, los diseñadores de
sistemas embebidos deben lidiar con dos problemas diferentes: rendimiento en términos de “throughput” y tiempos
de respuesta, y las técnicas para lidiar con los dos no son las mismas. Lidiar con uno de estos problemas a menudo
empeora el otro. Por lo tanto, este libro se ceñirá a los términos rendimiento en referencia al término en inglés
“throughput” y tiempos de respuesta, evitando la palabra “velocidad”.
Facilidad para Verificar el Funcionamiento: testability
No es nada fácil determinar si el sistema Telegraph realmente funciona. El problema es que gran parte del software
se ocupa de eventos poco comunes. El sistema Telegraph es típico de los sistemas embebidos en este sentido porque
estos sistemas deben poder manejar cualquier cosa sin intervención humana. Por ejemplo, gran parte del código del
sistema Telegraph está dedicado al problema de que los datos pueden perderse en la red. Sin embargo, los datos no
se pierden muy a menudo, especialmente en un laboratorio de pruebas, donde la red probablemente esté configurada
perfectamente, esté hecha completamente de piezas nuevas y mida 15 pies de largo. Esto hace que sea difícil probar
todas esas líneas de código.
De manera similar, el sistema Telegraph debe tratar con eventos casi simultáneos. Por ejemplo, si dos
computadoras solicitan iniciar sus trabajos de impresión al mismo tiempo, ¿el software se las arregla correctamente?
el sistema Telegraph contiene código para manejar esta situación, pero ¿cómo se hace para probar ese código?
Se discutirán los problemas de verificación.
Facilidad para Depuración de Errores: debugability
¿Qué cree que sucede normalmente cuando las pruebas descubren un error en el software del sistema Telegraph?
El sistema Telegraph no tiene pantalla, ni teclado, tampoco altavoz, ni siquiera lucecitas. Cuando surge un error,
no obtiene ningún ícono lindo o cuadro de mensaje en ninguna parte. En este caso, el sistema no funciona. ¿Un
error en el software de la red? ¿Un error en el software que realiza un seguimiento de qué computadora está
imprimiendo? ¿Un error en el software que informa sobre el estado de la impresora? El sistema Telegraph
simplemente deja de funcionar.
Desafortunadamente, el hecho de que el sistema Telegraph deje de funcionar no brinda mucha información
sobre la naturaleza del error. Además, sin teclado ni pantalla no se puede ejecutar una depuración en el sistema
Telegraph. Sería útil si se encontraran otras formas de averiguar qué ha sucedido. Se discutirán esta técnicas para
depurar el software de sistemas embebidos y en primer lugar se discutirán algunas técnicas para evitar que algunos
de los errores más complejos se introduzcan en su software.
Confiabilidad
Como la mayoría de los sistemas embebidos, el sistema Telegraph simplemente no puede bloquearse. Aunque los
clientes parecen tener cierta tolerancia con los sistemas de escritorio que deben reiniciarse de vez en cuando, nadie
tiene paciencia con las cajitas de plástico que fallan. En situaciones particularmente incómodas, el software de la
aplicación puede poner un mensaje en la pantalla y preguntarle al usuario qué hacer. Los sistemas embebidos no
tienen esa opción. Pase lo que pase, el software debe funcionar sin intervención humana.
Espacio de Memoria
El sistema Telegraph tiene solo una cantidad finita de memoria: precisamente, 32 KB de memoria para su programa
y 32 KB de memoria para sus datos. Esta era tanta memoria como podría tener el sistema Telegraph si su precio
fuera razonable. La memoria se vuelve más barata, pero aún así no es gratis. Hacer que el software encaje en el
espacio disponible es una habilidad necesaria para muchos ingenieros de software de sistemas embebidos, y lo
discutiremos.
Instalación del Programa
El software del sistema Telegraph no llegó allí porque alguien hizo click con el mouse en un ícono. Se discutirán
las herramientas especiales necesarias para instalar el software en sistemas embebidos.
Caso de Estudio 2: Escáner de Código de Barras Inalámbrico
Se pasará a otro ejemplo de sistema embebido, que consiste en un escáner de código de barras inalámbrico. Siempre
que el usuario aprieta el gatillo, el escáner de código de barras inalámbrico activa su láser para leer el código de
barras y luego envía el código de barras a través de un enlace de radio a la caja registradora. (Consulte la Figura
1.2.)
Figura 1.2 Escáner de código de barras inalámbrico
¿Cómo se comparan los problemas de desarrollar el software para el escáner de código de barras
inalámbrico con los problemas de desarrollar el software en el sistema Telegraph?
Bueno, en su mayoría son iguales. Un problema que el escáner de código de barras inalámbrico no tiene es
el problema de rendimiento. No hay muchos datos en un código de barras y el usuario no puede apretar el gatillo
tan rápido. En contraste, el escáner de código de barras inalámbrico tiene un problema que el sistema Telegraph no
tiene.
Consumo de Energía
Dado que el escáner es inalámbrico, su batería es su única fuente de energía y, dado que el escáner está diseñado
para ser portátil, el peso de la batería está limitado por lo que un usuario promedio debe poder sostenerlo
cómodamente. ¿Cuánto tiempo quiere el cliente que dure la batería? La respuesta obvia, para siempre; lo cual no es
factible. ¿Cuál es la siguiente mejor respuesta?
La siguiente mejor respuesta es que la batería debería durar un turno de 8 horas. Después de eso, el escáner
puede volver a colocarse en una funda al costado de la caja registradora para pasar la noche y recargar su batería.
Sin embargo, resulta que tampoco es factible hacer funcionar un láser, un microprocesador, una memoria y una
radio durante 8 horas con batería. Por lo tanto, uno de los principales dolores de cabeza de este software es averiguar
qué partes del hardware no se necesitan en un momento dado y apagarlas. Eso incluye el procesador. Esto también,
será objeto de discusión.
Caso de Estudio 3: Impresora Láser
Otro sistema embebido es una impresora láser. La mayoría de las impresoras láser tienen embebidos
microprocesadores bastante potentes para controlar todos los aspectos de la impresión. En particular, ese
microprocesador es responsable de obtener datos de los diversos puertos de comunicación de la impresora, de
detectar cuándo el usuario presiona un botón en el panel de control, de presentar mensajes al usuario en la pantalla
del panel de control, de detectar atascos de papel y recuperar adecuadamente, para darse cuenta cuando la impresora
se ha quedado sin papel, y así sucesivamente.
Sin embargo, la responsabilidad más importante del microprocesador es lidiar con el motor láser, que es la
parte de la impresora responsable de poner marcas negras en el papel. Lo único que sabe hacer un motor láser sin
la ayuda de un microprocesador es poner o no poner un punto negro en cada lugar de una hoja de papel. No sabe
nada acerca de las formas de las letras, fuentes, tamaños de fuente, cursiva, subrayado, negrita o cualquiera de esas
otras cosas que los usuarios de impresoras dan por hecho. El microprocesador debe leer los datos de entrada y
averiguar dónde debe ir cada punto negro. Esto conduce a otro problema que se encuentra en algunos sistemas
embebidos.
Acaparamiento del Procesador
Averiguar dónde van los puntos negros cuando se le pide a una impresora que imprima un texto en una línea
inclinada con una fuente inusual en un espacio del tamaño de un tornillo lleva mucho tiempo, incluso para
microprocesadores potentes. Los usuarios esperan una respuesta rápida cuando presionan los botones; sin embargo,
no debe ser una preocupación que el microprocesador esté ocupado determinando los valores de las funciones
trigonométricas para descubrir dónde deben ir las serifas de una letra girada en la página. El trabajo que inmoviliza
al procesador durante períodos prolongados hace que el problema de la respuesta sea mucho más difícil.
Caso de Estudio 4: Monitoreo de Nivel de Tanques Subterráneos
El sistema de monitoreo de tanques subterráneos vigila los niveles de gasolina en los tanques subterráneos de una
gasolinera. Su objetivo principal es detectar fugas antes de que la gasolinera se convierta por error en un vertedero
de desechos tóxicos y activar una fuerte alarma si descubre una. El sistema también tiene 16 botones, una pantalla
de cristal líquido de 20 caracteres y una impresora térmica. Con los botones, el usuario puede indicarle al sistema
que muestre o imprima información diversa, como los niveles de gasolina en los tanques, la hora del día o el estado
general del sistema.
Para saber cuánta gasolina hay en uno de los tanques, el sistema primero lee el nivel de dos flotadores en el
tanque. Uno de los cuales indica el nivel de la gasolina, y el otro indica el nivel del agua que siempre se acumula
en el fondo de dichos tanques. También lee la temperatura en varios niveles en el tanque; la gasolina se expande y
contrae considerablemente con los cambios de temperatura, lo cual debe tenerse en cuenta. El sistema no debe
disparar la alarma solo porque la gasolina se enfría y se contrae, bajando el flotador.
Nada de esto sería un desafío, excepto por el problema del costo que a menudo surge en el contexto de los
sistemas embebidos.
Costos
El propietario de una gasolinera solo compra uno de estos sistemas porque alguna agencia gubernamental le dice
que tiene que hacerlo. Por lo tanto, quiere que sea lo más económico posible. Por lo tanto, el sistema se construirá
con un microcontrolador muy económico, probablemente uno que apenas sepa sumar números de 8 bits, y mucho
menos cómo usar el coeficiente de expansión de la gasolina de manera eficiente. Por lo tanto, el microprocesador
de este sistema se encontrará extraordinariamente ocupado calculando cuánta gasolina hay ahí abajo; ese cálculo se
convertirá en un problema de acaparamiento del procesador.
En la Figura 8.7 se muestra un esquema del monitor del tanque subterráneo. La Figura 8.6 contiene una
descripción más detallada de lo que hace el monitor de tanque subterráneo.
Caso de Estudio 5: Monitoreo de un Reactor Nuclear
Por último, un ejemplo sencillo del que se puede aprender mucho es un sistema hipotético que controla un
reactor nuclear. Este hipotético sistema debe hacer muchas cosas, pero el único aspecto que interesará es la parte
del código que monitorea dos temperaturas, que se supone que siempre sean iguales. Si las temperaturas difieren,
indica que un mal funcionamiento del reactor lo está enviando hacia China. Este sistema se revisará varias veces a
lo largo del libro.
1.2 Hardware Típico
Puede omitir esta sección si conoce las generalidades de las partes de hardware que normalmente se encuentran en
los sistemas embebidos. De lo contrario, se recomienda seguir leyendo para encontrar un resumen de las partes que
componen estos sistemas.
Primero, todos los sistemas necesitan un microprocesador. Los tipos de microprocesadores utilizados en los
sistemas embebidos son bastante variados, como puede ver en la Tabla 1.1, una lista de algunas de las familias de
microprocesadores estándar y sus características.
(Tenga en cuenta que todas los fabricantes de semiconductores venden una variedad de modelos de cada
microprocesador. Los datos de la Tabla 1.1 son típicos de estas familias de microprocesadores. Algunos
microprocesadores individuales pueden diferir de manera considerable de lo que se muestra en la Tabla 1.1.)
Tabla 1.1 Microprocesadores usados en Sistemas Embebidos
Un sistema embebido necesita memoria para dos propósitos: almacenar el programa y almacenar los datos.
A diferencia de un sistema de escritorio, en el que los programas y los datos se almacenan en la misma memoria,
los sistemas embebidos utilizan diferentes memorias para cada uno de los dos propósitos diferentes. Debido a que
el sistema embebido típico no tiene una unidad de disco duro desde la cual cargar el programa, el programa debe
almacenarse en la memoria, incluso cuando se apaga la alimentación. Como sabrá, la memoria en un sistema de
escritorio borra la información cuando se apaga la alimentación. El sistema embebido necesita una memoria especial
que guardará el programa, incluso sin energía. Desafortunadamente, como se discutirá en el Capítulo 2, estas
memorias especiales no son muy adecuadas para los datos; por lo tanto, los sistemas embebidos necesitan una
memoria normal.
Después de un procesador y una memoria, los sistemas embebidos se destacan más por lo que no tienen que
por lo que tienen. La mayoría de los sistemas embebidos no tienen lo siguiente:
•
•
•
Un teclado. Algunos sistemas pueden tener algunos botones para la entrada del usuario; algunos otros, como
el sistema Telegraph por ejemplo, ni siquiera tienen eso.
Una pantalla. Muchos sistemas, especialmente los productos de consumo, tendrán una pantalla de cristal
líquido con dos o tres docenas de caracteres. Una impresora láser, por ejemplo, suele tener una pantalla de
estado de dos líneas con 10 o 12 caracteres en cada línea. Otros sistemas ni siquiera tienen tanta capacidad
de salida. Algunos pueden tener algunos diodos emisores de luz (esas pequeñas luces que a veces se ven en
los sistemas) para indicar ciertas funciones esenciales del sistema.
Una unidad de disco. El programa se almacena en la memoria y la mayoría de los sistemas embebidos no
necesitan almacenar muchos datos de forma permanente. Los que lo hacen suelen utilizar varios tipos de
dispositivos de memoria especializados en lugar de unidades de disco.
•
Discos compactos, altavoces, micrófonos, disquetes, módems. La mayoría de los sistemas embebidos no
necesitan ninguno de estos elementos.
Los sistemas embebidos suelen tener un puerto serial estándar, una interfaz de red y hardware para
interactuar con sensores y activadores en el equipo que controla el sistema.
Resumen del Capítulo
•
•
•
Un sistema embebido es cualquier computador oculto dentro de un producto que no sea un computador.
Cuando se escribe software para un sistema embebido, se encuentran muchas dificultades adicionales a las
que encontrará cuando se escribe software de aplicaciones:
o Rendimiento en términos del throughput: es posible que el sistema necesite manejar muchos datos
en un período breve.
o Tiempos de respuesta: es posible que el sistema deba reaccionar rápidamente a los eventos.
o Facilidad para comprobar el sistema: configurar equipos para comprobar y verificar el correcto
funcionamiento del software embebido, puede llegar a ser difícil.
o Facilidad para depurar el sistema: sin una pantalla o un teclado, descubrir qué está haciendo mal
el software (aparte de no funcionar) es problemático.
o Confiabilidad: los sistemas embebidos deben ser capaces de manejar cualquier situación sin
intervención humana.
o Espacio de memoria: la memoria está limitada en los sistemas embebidos y se debe hacer que el
software y los datos encajen en cualquier memoria existente.
o Instalación del programa: se necesitarán herramientas especiales para poder instalar el software en
los sistemas embebidos.
o Consumo de energía: los sistemas portátiles deben funcionar con batería y el software de estos
sistemas debe ahorrar energía.
o Acaparamiento de procesador: la computación que requiere grandes cantidades de tiempo de la
CPU puede complicar el problema de tiempos de respuesta.
o Costo: reducir el costo del hardware es una preocupación en muchos proyectos de sistemas
embebidos. El software a menudo opera en hardware que apenas es adecuado para el trabajo.
Los sistemas embebidos tienen un microprocesador y una memoria, y algunos tienen un puerto serial o una
conexión a red, y generalmente no tienen teclados, pantallas ni unidades de disco.