1
¿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)
2
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
3
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.
4
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;
IDE (Integrated Development Environment- Entorno de desarrollo integrado) – para el desarrollo de programas.
5
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 – Instrumentos
6
¿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
7
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
8
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
9
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.
10
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.
11
Componentes típicos de software embebido
12 of
12
Casi idéntico a los sistemas generales informáticos
Software de aplicación
Controlador de dispositivo
Componentes típicos de software embebido (cont.)
13 of
13
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
(Gp:) Bus de datos
(Gp:) Memoria
De datos
(Gp:) Memoriade programa
(Gp:) interrupciones
(Gp:) Digital o/p
(Gp:) Analog o/p
(Gp:) Digital i/p
(Gp:) Analog i/p
(Gp:) ENTRADAS
(Gp:) SALIDAS
(Gp:) Links A otros sistemas
(Gp:) Interfaz de Usuario
(Gp:) Bus de direcciones
(Gp:) CPU
(Gp:) AnalógicoFront End
(Gp:) Digitali/p Ports
(Gp:) Módulos Interfaz Usuario
(Gp:) Digitalo/p Puertos
(Gp:) D/A,
Aislamiento
(Gp:) Comms:
ASC, SSC,USB, IIC,
IrDA, etc.
(Gp:) Soporte:
Temporizador de guarda
14 of
14
Desarrollo del ciclo de vida de software. Modelo Cascada
Requisitos
Diseño
Implementación
Integración
Validación
Despliegue
15
Desarrollo de ciclo de vida de software. Modelo espiral
16
Determinar objetivos, alternativas, limitaciones
Evaluar alternativas, identificar, solucionar riesgos, desarrollar prototipos
Planificar las siguientes fases
Desarrollar, verificar los productos del siguiente nivel
17
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.
18
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.
19
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.
20
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
21
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
22
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
23
Verificación y validación
¿Qué es verificación y validación?
VerificaciónLa 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ónLa 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”.
24
Verificación y validación ¿Cómo actúa?
25
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.
26
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.)
27
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.)
28
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)
29
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
32
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
33
34
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 decisiones importantes 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
35
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.
36
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.
37
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/)
38
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.
39
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)
40
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).
41
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
Eventos
42
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)
43
Prism – ejemplo de aplicación
44
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ía
45
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.
46
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)
47
Lenguajes de programación de sistemas embebidos (cont.)
Lenguajes de Software
Lenguajes de Software describen secuencias de instrucciones para un proceso a ejecutar. Por lo tanto, la lista de la mayoría de 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: Lenguaje ensamblador, C, C++ y Java. Las características de estos lenguajes se muestran en la tabla de abajo.
48
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.
49
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=rep1&type=pdf )
50
51
Cuestiones de control
¿Cuáles son los principales objetivos de la ingeniería del software?
Describir las principales etapas de desarrollo de software para sistemas embebidos.
Comparar el Sistema operativo más popular para dispositivos móviles (posiblemente en forma de tabla).
Comparar los lenguajes más populares utilizados en sistemas embebidos.