Materia: Sistemas Electrónicos Embebidos

Profesor: Sangiovanni Dante

Ingeniería del Software

Embebido

2

¿Qué es un Sistema embebido?

Una definición de uso general de los sistemas

embebidos es que son dispositivos que se utilizan para

controlar, supervisar o ayudar en la operación de

equipos, maquinaria o planta. “Embebido” refleja el

hecho de que son una parte integral del Sistema. En

muchos casos, su “arraigo” puede ser tal que su

presencia está lejos de ser evidente para el observador

casual.

Instituto de Ingeniería Eléctrica (IEE)

3

Características de los sistemas embebidos (1)

Características básicas:

Número limitado de funciones predefinidas para ejecutar;

Fuente de alimentación limitada y la administración de energía

efectiva;

Disponibilidad de recursos de reserve para situaciones inesperadas.

Funcionamiento en tiempo real (con mayor frecuencia);

Periféricos anchos e interfaces

Interfaces:

Interfaces de operador (Interfaces Máquina-Hombre - HMI) –

teclados, monitores, interruptores, botones, indicadores emisores

individuales o grupales de los diferentes tipos de señales, motores

eléctricos, solenoides y otros.

Interfaces eléctricas (interfaces con otros components y dispositivos)

Interno - I2C, SPI, ISA y otros.

Externos - RS232, TTY, Ethernet, Centronics, FlexRay, CAN, LIN,

RF y otros

4

Características de los sistemas embebidos (2)

Plataforma de sistemas embebidos:

Microprocesador (MP o P) y los microcontroladores (MCU), que tienen

menos poder de cómputo, pero varios periféricos;

Arquitecturas - Von Neumann y Harvard;

Utilizan P y MCU - CISC (Complex Instruction Set Computer) y más a

menudo RISC (Reduced Instruction Set Computer);

Las populares familias de procesadores RISC: ARC (ARC International),

ARM (ARM Holdings), AVR (Atmel), PIC (Microchip), MSP430 (TI) y otros;

CISC CPUs: Intel y Motorola;

Por lo general en el interior hay una memoria cache y procesamiento de la

canalización de instrucciones;

Memoria para datos e instrucciones: RAM, PROM - OTP (Programable de

una sola vez), EEPROM o memoria Flash;

Periféricos: Propósito general Entrada /Salida - GPIO, temporizadores, ADC,

DAC y más.

5

Características de los sistemas embebidos (3)

Comunicación:

RS-232, RS-422, RS-485, UART / USART (Receptor / Transmisor universal

síncrono y asíncrono);

I2C (Inter-Integrated Circuit – Circuito integrado), SPI (Serial Peripheral Interface

Bus – Bus de la interfaz de periféricos serie), SSC and ESSI (Enhanced

Synchronous Serial Interface – Interfaz mejorada serie síncrona), USB (Bus

Universal en serie);

Protocolos de comunicación de red: Ethernet, CAN (Controller Area Network –

Controlador del área de red), LonWorks etc.

Software: Popular OS – QNX4 RIOS, Linux embebido y Linux-based (Android,

etc.), iOS, Windows CE, etc.

Herramientas para probar y corregir (depuración)

JTAG (Joint Test Action Group) – una interfaz especializada para la prueba

saturada PCB;

ISP (In-System Programming) – Programación de circuito;

ICSP (circuito de programación en serie) – un método para la programación

directa del microcontrolador, por ejemplo, de la serie PIC y AVR;

BDM (Modo de depuración de fondo) – utilizado principalmente en productos de

Freescale;

6

Sistemas embebidos: Ejemplos

Ingeniería del Software

Ingeniería del Software (SE): la aplicación de un enfoque disciplinado cuantificable sistemático, con el diseño, desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques;

Es decir, la aplicación de la ingeniería del software.

El plazo es de 45 años: conferencias de la OTAN– Garmisch, Alemania, 7-11 octubre, 1968

– Roma, Italia, 27-31 octubre, 1969

La realidad está finalmente empezando a llegar– La informática como base científica

• ¿Otras bases científicas?

– Muchos aspectos se han hecho sistemáticos: • Métodos / metodologías / técnicas

• Lenguajes

• Herramientas

• Procesos - Instrumentos7

¿Por qué estas dificultades?

SE es una marca única de la ingeniería

– El Software es maleable

– La construcción del Software es humano-intensivo

– El Software es intangible

– Problemas del Software son complejos sin precedentes

– El Software depende directamente del hardware.

• Está en la parte superior del Sistema de ingeniería “cadena

alimentaria”

Las soluciones del software requieren rigor inusual

– El software tiene carácter operativo discontinuo

8

Ingeniería del software ≠ Programación del Software

Programación del Software

– Desarrollador individual

– Aplicaciones de “juguete”

– Esperanza de vida corta

– Pocos actores o actores individuales

• Arquitecto = Desarrollador = Gerente = Tester = Cliente =

Usuario

– Uno de un Sistema tipo

– Construido desde cero

– Mantenimiento mínimo 9

Ingeniería del software ≠ Programación del Software

Ingeniería del software

– Equipos de desarrolladores con multiples funciones.

– Sistemas complejos

– Vida útil indefinida

– Numerosos grupos interesados

• Arquitecto ≠ Desarrollador ≠ Gerente ≠ Tester ≠ Cliente ≠ Usuario

– Las familias del sistema

– Reutilizar para amortizar costes

– Mantenimiento representa más del 60% de los costos generales de desarrollo

10

Ingeniería del software ≠ Programación del Software

Ingeniería de sistemas

– Campo interdisciplinario de la ingeniería que se centra en cómo los

proyectos complejos de ingeniería deben ser diseñados y gestionados;

– Se ocupa de todos los aspectos del desarrollo del Sistema

informático;

– Identifica las funciones de hardware, software, personas, bases de

datos y otros elementos del Sistema que participan en ese Sistema que

se va a desarrollar.

– Ingeniería del software

– Es una parte de la ingeniería de sistemas a nivel de usuario

– Decir los aspectos prácticos del desarrollo y distribución de software

útil.11

Aspectos de gestión económica y de SE

La produccion de software =mantenimiento + desarrollo (evolución)

Costes de mantenimiento > 60% de todos los costs de desarrollo

– 20% correctivo

– 30% adaptativo

– 50% perfectivo

Desarrollo más rápido no siempre es preferible

– Mayores costos por adelantado pueden sufragar los costos aguas abajo.

– Software mal diseñado / implementado es un factor de coste crítico.

12

Componentes típicos de software embebido

13 of 13

Casi idéntico a los sistemas generales informáticos

Software de aplicación

Controlador de dispositivo

Componentes típicos de software embebido (cont.)

14 of 14

Middleware – ¿Qué es? Middleware es un software que ha sido extraído de la capa de aplicación por una

variedad de razones. Una de las razones es que ya puede ser incluido como parte

del paquete del Sistema operativo fuera de la plataforma OS.

Otras razones para eliminarlo de la capa de aplicación son: permitir la

reutilización en otras aplicaciones, para reducir costes o el tiempo de desarrollo

mediante la compra off-the-shelf a través de un proveedor de terceros, o para

simplificar el código de la aplicación.

En los términos más generales, el software middleware es el software del

Sistema que no es el núcleo OS del Sistema operativo, controladores de

dispositivos, o software de aplicación.

A continuación se muestra el middleware en el Modelo de Sistemas Embebidos

(ver más en http://www.eetimes.com/document.asp?doc_id=1276764

Bus de datos

Memoria

De datos

Memoria

de programa

interrupciones

Digital o/p

Analog o/p

Digital i/p

Analog i/p

ENTRADAS SALIDAS

Links A otros sistemas

Interfaz de Usuario

Bus de direcciones

CPU

Analógico

Front End

Digital

i/p Ports

Módulos Interfaz Usuario

Digital

o/p Puertos

D/A,

Aislamiento

Comms:

ASC, SSC,

USB, IIC,

IrDA, etc.

Soporte:

Temporizad

or de

guarda

15 of 15

Desarrollo del ciclo de vida de software. Modelo Cascada

Requisitos

Diseño

Implementación

Integración

Validación

Despliegue

16

Evaluate alternatives,identify, resolve risks,develop prototypes

Develop, verifynext-level productPlan next phases

Desarrollo de ciclo de vida de software. Modelo espiral

17

Determinar objetivos, alternativas, limitaciones

Evaluar alternativas, identificar, solucionarriesgos, desarrollarprototipos

Planificar lassiguientes fases

Desarrollar, verificarlos productos del siguiente nivel

18

Hardware-Software Co-Diseño de Sistemas Embebidos

El Software que basa su

funcionalidad en los

productos embebidos de hoy

causan retrasos en la

completitud de los proyectos

si se tiene que esperar al

prototipo de hardware para

empezar el desarrollo de

software y su depuración.

Diseño concurrente y

verificación de hardware y

software es una tendencia que

reduce el tiempo de

lanzamiento al mercado.

(ver más en [4, 5] )

Requisitos

Problema de definición → Especificación de requisitos

– Determinar exactamente qué quiere el cliente y el usuario.

– Desarrollar un contrato con el cliente

– Especificar qué va a hacer el software de producto

Dificultades

– El cliente solicita el producto que no es adecuado

– El cliente no conoce el software

– Las especificaciones son ambiguas, inconsistentes e incompletas.

19

Arquitectura/Diseño

Especificación de requisitos→ Arquitectura/Diseño

– Arquitectura: descomponer el software en módulos con interfaces

– diseño: desarrollo de las especificaciones del módulo (algoritmos, tipos de datos)

– Mantener un registro de las decisiones de diseño y trazabilidad

– Especifica cómo el product de software hace sus tareas.

– Dificultades

– La falta de comunicación entre los diseñadores de módulos

– El diseño puede ser incoherente, incompleto y ambiguo.

20

Arquitectura vs. Diseño[Perry & Wolf 1992]

La Arquitectura tiene que ver con la selección de los

elementos arquitectónicos, sus interacciones y las

limitaciones de los elementos y sus interacciones necesarias

para proporcionar un marco en el que se cumplan los

requisites y que sirva como base para el diseño.

El diseño se ocupa de la modularización y las interfaces

detalladas de los elementos de diseño, sus algoritmos y

procedimientos, y los tipos de datos necesarios para apoyar

la arquitectura y para satisfacer los requisitos.

21

Implementación e Integración

Diseño → Implementación

– Implementar módulos; verificar que cumplen con sus especificaciones

– Combinar módulos de acuerdo con el diseño

– Especifica cómo el product de software realiza sus tareas

Dificultades

– Errores de interacción del módulo

– Orden de integración puede influir en la calidad y la productividad

22

Desarrollo basado en componentes

Desarrollar components generalmente aplicables de un

tamaño razonable y reutilizarlos a través de sistemas.

Asegurarse de que son adaptables a los diferentes contextos

Extender la idea más allá del código en el desarrollo de otros

artefactos

Pregunta: ¿Qué viene primero?

– Integración, a continuación despliegue

– Despliegue, a continuación integración

23

Diferentes componentes

Software de terceros “piezas”

Los Plug-ins de efectos/ complementos

Applets

Frameworks

Sistemas abiertos

Infraestructuras de objetos distribuidos.

Documentos compuestos

Los sistemas heredados

24

Verificación y validación

¿Qué es verificación y validación?

Verificación

La verificación confirma que el trabajo de los productos

reflejan adecuadamente los requisitos prescritos para los

mismos. En otras palabras, la verificación asegura que

“el product se ha construido correctamente”

Validación

La validación confirma que el product, según lo previsto,

cumplirá con su uso previsto. En otras palabras, la

validación asegura que “has construido lo correcto”.

25

Verificación y validación ¿Cómo actúa?

26

Modelo de desarrollo de sistema

Calidades de Software

Exactitud– Óptima calidad

– establecido w.r.t., la especificación de los requisitos

– absoluta

Confiabilidad– Propiedad estadística

– Probabilidad de que el software funcionará como se esperaba durante

un período de tiempo dado

– Relativo

Robustez– Comportamiento “razonable” en circunstancias imprevistas

– subjectiva

– Un requisito especificado es un problema de la corrección;

un requisito no especificado es un problema de robustez.

27

Usabilidad– Capacidad de que los usuarios finales puedan utilizer fácilmente el

software

– Extremadamente subjetivo.

Comprensibilidad– Capacidad de los desarrolladores a entender fácilmente los artefactos

producidos

– La calidad interna del producto

– subjetivo

Verificabilidad– La facilidad de establecer las propiedades deseadas

– Realizado por análisis formal o pruebas

– Calidad interna

Rendimiento – Equiparado con la eficiencia

– Evaluables mediante la medición, el análisis y simulación.

Calidades de software (cont.)

28

Desarrollo– Posibilidad de añadir o modificar la funcionalidad

– Aborda el mantenimiento adaptativo y perfectivo.

– problema: La evolución de la implementación es muy fácil

– La evolución debe comenzar en los requisitos o en el diseño

Reutilización– Capacidad de construir un Nuevo software a partir de piezas existentes

– Debe ser planificado

– Ocurre a todos los niveles: desde la gente a los procesos, desde los

requisitos hasta el código.

Interoperabilidad– Capacidad de los (sub)sistemas de software a cooperar con los demás

– Fácilmente integrable en sistemas más grandes.

– Técnicas communes que incluyen APIs, protocolos plug-in, etc.

Calidades de Software (cont.)

29

Calidad de software (cont.)

Escalabilidad– Capacidad de un Sistema de software para crecer en tamaño, mientras

que mantiene sus propiedades y cualidades.

– Asume el mantenimiento y la capacidad de evolucionar

– Objetivo de desarrollo basado en componentes

Heterogeneidad– Capacidad de componer un Sistema de piezas desarrolladas en varios

lenguajes de programación, en multiples plataformas, por multiples

desarrolladores, etc.

– Necesario para la reutilización.

– Objetivo de desarrollo basado en componentes

Portabilidad– Capacidad de ejecución en entornos nuevos con un mínimo esfuerzo.

– Puede ser planeado mediante el aislamiento de componentes

dependientes del entorno.

– Necesarios para la aparición de los sistemas altamente distribuidos

(por ejemplo, Internet) 30

Evaluar calidades del software

Las calidades deben ser medibles

La medición require que las calidades sean definidas de

forma precisa

La mejora requiere una medición precisa

Actualmente la mayoría de las calidades se definen de

manera informal y son difíciles de evaluar

Ingeniería del Software “Axiomas”

La adición de desarrolladores a un proyecto probablemente

resultará en más retrasos y acumulación de costes.

Tensión básica de la ingeniería de software

– Mejor, más barato, más rápido – elegir cualquiera de los dos¡

– Funcionalidad, escalabilidad, rendimiento – elegir cualquiera de los dos¡

Cuanto más dura un fallo en el software

– Mayores son los costes de la detección y corrección del fallo

– Menos probable es que sea debidamente corregido

Hasta el 70% de todos los fallos detectados en los proyectos

de software a gran escala se introducen en los requerimientos

y el diseño

– La detección temprana de las causas de los fallos puede reducir sus

costos resultantes por un factor de 100 o más.

Despliegue y evolución

Operación → Cambio

– Mantener el software durante / después de la operación del usuario

– Determinar si el product todavía funciona correctamente

Dificultades

– Diseño rígido

– Falta de documentación

– Rotación de personal

33

Principios de la Ingeniería del Software

Rigor y formalidad

La separación de los asuntos de interés

– Modularidad y descomposición

– Abstracción

Anticipación del cambio

Generalidad

Incrementalidad

Escalabilidad

Composicionalidad

Heterogeneidad

34

35

Arquitectura del Software

Arquitectura del Software es la organización fundamental de

un Sistema, dentro de sus componentes, las relaciones entre

sí y con el entorno, y los principios que rigen su diseño y

evolución.

La arquitectura del Software abarca el conjunto de decisionesimportantes sobre la organización de un Sistema de software

Selección de los elementos estructurales y sus interfaces por los que se compone un Sistema.

Comportamiento como se especifica en las colaboraciones entre esos elementos.

Composición de estos elementos estructurales y de comportamiento en subsistemas más grandes.

El estilo arquitectónico que guía esta organización

36

Arquitectura del software Embebido

Estructura de Software y la complejidad de un Sistema embebido

pueden variar significativamente según la aplicación

Las arquitecturas de software de uso general incluyen:

Lazos de control simples

Interrupción del Sistema controlado

Sistema multitarea no preferente

La multitarea preventive o multi-threading (incluye los sistemas

operativos en tiempo real – RTOS)

Microkernels - micronúcleos (un paso adelante respecto a un RTOS

para incluir la asignación de memoria, sistemas de archivos, etc)

Kernel Monolitico (un relativo gran kernel con capacidades

sofisticadas, se adaptan a un entorno embebido). Linux embebido y

Windows CE Móviles y embebidos son algunos ejemplos.

37

Sistemas operativos embebidos

Tradicional OS- Grandes requerimientos de memoria- Arquitectura multiamenazas- Modelo I/O (entrada/salida)- Núcleo y separación de usuario- No hay restricciones de energía- Amplios recursos disponibles

Características deseadas para EOS- Huella de memoria pequeña- Computo eficiente- Protocolos de comunicación- Interfaz fácil de exponer datos- Apoyar el diseño de aplicaciones

diversas- Forma fácil de programar, actualizar y

depurar aplicaciones de red.

38

Algunos sistemas operativos integrados

RTOSs

pSOS

VxWorks

VRTX (Versátil en tiempo real)

uC/OS-II

Java RTS etc.

Palm OS (fuente: Wikipedia)

Sistema operative embebido desarrollado inicialmente por U.S. Robotics-owned

Palm Computing, Inc. para asistentes digitales personales (PDAs) en 1996

SymbianOS (fuente: Wikipedia)

Sistema operativo diseñado para dispositivos móviles por SymbianLtd. (se

ejecuta generalmente en OMAP (Plataforma de aplicaciones multimedia abierta)

procesadores, los cuales generalmente incluyen un propósito general de

arquitectura en el núcleo del procesador ARM más uno o más coprocesadores

especializados.

Android

Projecto abierto Handset Alliance

Basado en núcleo Linux 2.6 (http://code.google.com/android/)

39

Algunos sistemas operativos embebidos (cont.)

Windows CE (WinCE) (fuente: Wikipedia)

Sistema operativo de Microsoft para ordenadores minimalistas y sistemas

embebidos

WinCE es un Sistema operative muy diferente, en lugar de una version

abreviada del escritorio de Windows

Linux embebido (uClinux, ELKS, ThinLinux) (fuente: Wikipedia)

El uso de un Sistema operativo Linux en sistemas informáticos integrados

Según la encuesta realizada por Venture Development Corporation, Linux

fue utilizada por el 18% de los ingenieros

Versiones embebidas de Linux están diseñados para dispositivos con

recursos relativamente limitados, tales como teléfonos móviles y

decodificadores

Dado que los dispositivos integrados se utilizan para fines específicos en

lugar de fines generales, los desarrolladores optimizan sus distribuciones de

Linux embebido para conseguir las configuraciones de hardware específicas

y las situaciones de uso.

40

Sistemas embebidos de tiempo Real

Los sucesos de procesos de sistemas de tiempo real.

Los eventos ocurridos en las entradas externas provocan

el que otros eventos tengan lugar como salidas (outputs)

Minimizar el tiempo de respuesta suele ser un objetivo

principal, o de lo contrario todo el Sistema puede dejar de

funcionar correctamente.

Los tipos de sistemas embebidos en tiempo real

Tiempo real Estricto (Hard) — por ejemplo, sistemas de control de

vuelos

Tiempo real Flexibles (Soft) — por ejemplo, Sistema de

adquisición de datos.

Tiempo real (Real) — por ejemplo Sistema de guía de misiles

Tiempo real firmes (Firm)

41

Tipos de sistemas en tiempo real

Tiempo Real Estricto (Hard) – sistemas en los que es

absolutamente imperativo que las respuestas ocurran dentro

del plazo requerido. Por ejemplo: Sistemas de control de vuelo.

Tiempo Real Flexible – sistemas en los que los plazos son

importantes pero que todavía funcionarán correctamente si se

determinan plazos que ocasionalmente no se cumplan. Por

ejemplo: El Sistema de adquisición de datos.

Tiempo real (Real) – sistemas que son estrictos en tiempo

real y su tiempo de respuesta es muy corto. Por ejemplo: Sistema

de guía de misiles

Tiempo real Firme (Firm)– sistemas que son en tiempo real

flexible pero en el que no haya beneficio de una entrega tardía

del servicio. Un solo Sistema puede tener todos los subsistemas de

tiempo real estricto, flexibles y reales. En realidad muchos sistemas

tendrán una función de coste asociada con el incumplimiento de los plazos.

Arquitectura Prism en sistemas embebidos

Durante las últimas décadas los investigadores de software

y profesionales han propuesto diversos enfoques, técnicas

y herramientas para el desarrollo de sistemas de software

a gran escala. Los resultados de estos esfuerzos han sido

caracterizados como de programación a gran escala

programming-in-the-large (PitL).

Un nuevo conjunto de desafíos que ha surgido con la

aparición del barato, pequeño y heterogéneo,

posiblemente integrado, altamente distribuido, así como las

plataformas de computación móviles. Nos referimos al

desarrollo del software en programación a pequeña escala

programming-in-the-small-and-many (Prism). 42

Arquitectura Prism en sistemas embebidos (cont.)

Propiedades de Prism: Recursos muy limitados

Potencia limitada

Ancho de banda bajo

Velocidad de la CPU lenta, memoria limitada

Tampaño pequeño del display

Middleware

– Desarrollado para apoyar la implementación de Arquitectura de Software en el entornog

– Proporciona conceptos de nivel de arquitectura

Componentes

Conector

Configuración

Eventos43

Arquitectura Prism en sistemas embebidos (cont.)

Proporciona:

– Flexibilidad

– Eficiencia (Tamaño, velocidad, sobrecarga)

– Escalabilidad (Número de componentes, conectores, eventos, hilos, dispositivos de hardware)

– Extensibilidad (Soporte relativo a los nuevos desarrollos)

Investigar los siguientes temas:

– Límites de dispositivos móviles (potencia, tamaño, memoria, ..)

– Modelado

– Análisis

– Simulación

Prism está caracterizado por la compañía OS’s (Palm, Symbian)

Prism está relacionado con la arquitectura del Software (arquitectura basada en el desarrollo) 44

Prism – ejemplo de aplicación

45

TDS (Despliegue de Tropas y simulación)

– Distribución del despliegue de personal

Cuartel general

– Recopila información de campo y muestra el estado actual de campo de batalla

– Red a través de enlaces seguros a PDA’s

Comandantes

– Conectado a soldados

– Dar órdenes a los soldados

Soldados

– Ver segmentos del campo de batalla y recibir órdenes

Más sobre las características PRISM, ver en:

http://sunset.usc.edu/~softarch/Prism/ y

Prism-MW – CS 795 / SWE 699, Sam Malek, Spring 2010

Programación de Sistemas embebidos

Normalmente se tiene que ser mucho más consciente de

los recursos que se consumen en la programación de

sistemas embebidos que los que son necesarios en los

programas ordinaries

Tiempo

Espacio

Canales de comunicación

Archivos

ROM (Read-Only Memory)

Memoria Flash

…

Se debe tomar el tiempo para aprender acerca de la forma

en que las características del lenguaje de programación se

implementan para una plataforma en particular.

• Hardware

Sistema operativo

Librería46

Programación de Sistemas embebidos

Una gran cantidad de éste tipo de programación es:

Mirar con atención las características especializadas de un RTOS

(Sistema Operativo en Tiempo Real)

El uso de un “entorno non-hosted” (que es una forma de decir “ un

lenguaje de programación justo en lo alto (right on top) del hardware

sin un Sistema operativo”)

Incluye (a veces complejas) arquitecturas de controladores de

dispositivos

El trato directo con interfaces de dispositivos hardware

…

No entraremos en detalles aquí

Para eso están los cursos y manuales específicos.

47

Lenguajes de programación de sistemas embebidos

Lenguajes Hardware

Verilog y VHDL son los lenguajes más populares para la

descripción del hardware y su modelización (ver las

características de abajo)

48

Lenguajes de programación de sistemas embebidos(cont.)

Lenguajes de Software

Lenguajes de Software describen secuencias de instruccionespara un proceso a ejecutar. Por lo tanto, la lista de la mayoríade las instrucciones imperativas se ejecutan para comunicar a través de la memoria: un array de almacenamiento de localizaciones que mantienen sus valores hasta que son modificados. Los lenguajes más populares son: Lenguajeensamblador, C, C++ y Java. Las características de estoslenguajes se muestran en la tabla de abajo.

49

Lenguajes de programación de sistemas embebidos(cont.)

C++ se extiende C con los mecanismos de estructuración para grandes

programas: los tipos de datos indefinidos, una manera de reutilizer código

con tipos diferentes, espacios de nombres a los grupos de objetos y evitar

conflictos de nombres accidentales cuando se ensamblan las piezas del

programa, y las excepciones para manejar errores. La librería standard C++

incluye una colección de datos polimórficos eficientes, tales como arrays

(matrices), árboles, cadenas para las que el compilador genera

implementaciones personalizadas.

Lenguaje Java Sun se asemeja al C++ pero es incompatible. Al igual que

C + +, Java está orientado a objetos, que proporciona clases y herencia. Es

un lenguaje de más alto nivel que C++, ya que utiliza las referencias a

objetos, matrices y cadenas en lugar de punteros. La recogida automática

de basura de Java libera al programador de la gestión de memoria. Java

proporciona subprocesos simultáneos.

50

Lenguajes de programación de sistemas embebidos(cont.)

Otro tipo de lenguaje de Sistemas Embebidos son languages de flujo de

datos y languajes Híbridos. Los lenguajes de flujo de datos son un

complemento perfecto para los algoritmos de procesamiento de señales,

que utilizan grandes cantidades de aritmética derivada de la teoría de

sistemas lineales de decodificación, comprimen o filtran corrientes de datos

que representan muestras periódicas de los valores continuamente

cambiantes, como el sonido o el video.

(Acerca de los lenguajes de sistemas embebidos, ver más en:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.4735&rep=rep

1&type=pdf )

51

52

Cuestiones de control

1. ¿Cuáles son los principales objetivos de la ingeniería del software?

2. Describir las principales etapas de desarrollo de software para

sistemas embebidos.

3. Comparar el Sistema operativo más popular para dispositivos

móviles (posiblemente en forma de tabla).

4. Comparar los lenguajes más populares utilizados en sistemas

embebidos.