Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SEA Unidad1
SEA Unidad1
SEA Unidad1
sistemas embebidos
Sistemas Embebidos Avanzados
DSI-EIE-FCEIA
Contenido temático
●
Parte I:
– 1.1. Introducción: El software en un SE. Arquitecturas. Portabilidad y eficiencia.
– 1.2. Administración y control de los recursos de hardware: Administración de dispositivos
de entrada/salida. Administración de la memoria. Niveles de abstracción. Uso y desarrollo
de Interfaces de software: Hardware Abstraction Layer, Librerías, Software development
Kits, Device Drivers, Application Program Interfaces.
●
Parte II:
– 1.3. Sistemas operativos: conceptos generales. Tipos de S.O. Estructura de un Sistema
Operativo. Elementos constituyentes. Gestión de recursos, planificación y tiempo. APIs del
S.O. Criterios de selección y utilización de SO para SE.
●
Parte III:
– 1.4. Diseño y construcción de software en SE: Modelos de desarrollo. Herramientas de
programación, entornos integrados de desarrollo y “toolchains”. Herramientas de
versionado. Desarrollo colaborativo. Repositorios.
Parte I: el software en un SE
Factores críticos
●
Limitado espacio de memoria
●
CPUs restringidas en clock y longitud de palabra
●
Fuertes restricciones al consumo de energía
●
Conectividad limitada/esporádica
●
Dimensiones físicas acotadas
●
Tiempo real
●
Aplicación crítica
• La aplicación D
gestiona recursos de
Aplicación C hw directamente
Aplicación A
Aplicación D • Las aplicaciones A y
B deben hacerlo
Máq Virtual mediante el sistema
operativo
• La ap. C interactúa
Sistema Operativo con una máquina
virtual
Hardware
●
Administración y control de los recursos de
hardware:
– Administración del procesador
– Administración de dispositivos de entrada/salida
– Administración de la memoria
– Administración del almacenamiento persistente
●
Gestión de la asignación de los recursos de CPU
(procesadores/núcleos/hilos) a las aplicaciones del
usuario, el procesamiento de interrupciones y las
tareas demandadadas por la plataforma
●
Simultaneidad implica planificación
●
Gestión de bloques asignados y libres
●
Protección ante violaciones de acceso
●
Relocalización
●
Interacción con DMA
●
Es una concepción arquitectural del desarrollo de
software donde la complejidad se subdivide en
conjuntos separados (capas)
●
En este modelo cada capa tiene una serie de
responsabilidades hacia la capa superior, y recibe
una serie de servicios de la capa inferior
●
Así, cada capa ofrece y utiliza servicios
completamente especificados
Aplicación
API
Software/hardware
Aplicación
Llamada Respuesta
API
●
En el primer caso, la respuesta se produce como
consecuencia de la llamada: existe una relación
causal entre ambas y un ordenamiento temporal
secuencial
●
En el caso asíncrono la respuesta se produce por la
ocurrencia de un evento externo, ante el cual la
aplicación es informada por el API
Aplicativo API
solicitud
t0
respuesta
t1
t2
Evento e
t3 Suceso: evento “e”
t t
●
Dependiente del lenguaje: disponible para ser
utilizada desde un lenguaje de programación
específico. Ejemplo: API de sockets de UNIX (C)
●
Independiente del lenguaje: diseñada de forma tal
que puede utilizarse por programas escritos en
distintos lenguajes de programación. Ejemplo: web
services, NMEA, ELCOM
●
Uno o mas archivos de encabezado (*.h)
●
Una o mas librerías (*.o, *.lib, *.dll, etc.)
●
Un paquete de clases (Java: *.jar)
●
Usualmente encapsuladas en un “SDK” (software
Development Kit)
●
Una especificación de protocolo y mensajes
●
Un API puede utilizar uno o mas mecanismos para
comunicarse con los programas aplicativos, por
ejemplo:
– Llamada a funciones
– Invocación de métodos
– Paso de mensajes
●
Es un modelo utilizado en lenguaje C
●
Ejemplos:
– Placas adquisidoras de datos y conversores A/D
– Placas de comunicaciones
– Placas de captura de video
●
Utilizadas para comunicaciones asíncronas con
dispositivos de interface que producen estímulos
desde el entorno, por ejemplo un sensor de nivel o
un pulsador
●
Frecuentemente la interacción se lleva a cabo
mediante “funciones de call-back”
●
Similar a las rutinas de atención de interrupción
(ISR)
●
Determinadas aplicaciones sencillas no justifican la
inclusión de un SO:
– Ejecución sincrónica, hilo único
– Requerimientos ajustados de tiempo
– RAM/ROM muy limitadas
– Baja complejidad
●
Hay condiciones que justifican la inclusión de un
SO:
– Concurrencia, ejecución asincrónica, hilos
múltiples
– Diversidad de E/S y dispositivos conectados
– Plataformas con múltiples CPUs
– Alta complejidad
28 / 79
Conceptos generales
●
La complejidad creciente de la plataformas de
hardware
●
Los nuevos requerimientos para las aplicaciones
●
La interoperabilidad
●
La portabilidad
●
El proceso de desarrollo de software
●
“Máquina ampliada”
●
El S.O. presenta una abstracción distinta al
hardware subyacente, proveyendo de interfaces de
programación de mayor nivel y, en algunos casos,
de portabilidad, por ejemplo, UNIX. Su tarea
principal es la administración de recursos
Propósito de un Sistema
Operativo
●
Un SO ofrece un entorno de ejecución para las
aplicaciones, en la forma de un conjunto de recursos y
servicios
●
Se interpone entre el hardware y las aplicaciones
mostrando un "máquina extendida"
●
Abstrae así la complejidad de la plataforma, y en algunos
casos, la existencia de varias aplicaciones corriendo en
paralelo
●
El SO debe arbitrar el acceso de las aplicaciones a los
recursos de hw
●
Múltiples tipos, definidos por el campo de
aplicación:
– Propósito general: Linux, Windows, Unix, ...
– Tiempo real: VxWorks, FreeRTOS, OSEK, …
– Aplicación específica: Android, iOS, ...
●
Un sistema operativo puede brindar distintas
abstracciones conceptuales:
– Monoprogramación: cada tarea se ejecuta
ininterrumpidamente hasta completarse
– Multiprogramación: pueden ejecutarse dos o
mas tareas “simultáneamente”
Multiprogramación
●
La capacidad de ejecución de tareas concurrentes
depende del diseño del S.O. y del hardware.
●
Los S.O. multiprogramables implementan técnicas
de 'timesharing', compartiendo la(s) cpu(s) entre
todas la tareas a ejecutar.
Multiprogramación
●
Todos los S.O. multiprogramables (multitasking)
incorporan un gestor de tareas llamado
"planificador“ (scheduler)
●
El scheduler es responsable de aplicar políticas de
planificación de procesos, prioridades de ejecución
y control de estado de los procesos
Multiprogramación
●
Dependiendo del hardware, la simultaneidad de
ejecución puede ser virtual o real
●
Si hay mas de un CPU, o si el CPU único tiene
capacidades de paralelismo, el S.O. puede
aprovechar estas capacidades planificando
distintos procesos por CPU o unidad de ejecución
Multiprogramación
Si hay
sólo una
CPU
Si hay
múltiples
CPU
Multiprogramación
●
Los microprocesadores superescalares son
capaces de ejecutar varias instrucciones
simultáneamente, brindando paralelismo a nivel
de un proceso.
●
Los procesadores paralelos soportan dos o mas
flujos de instrucciones, brindando paralelismo de
múltiples procesos
Niveles de Privilegio (i)
●
Todos los procesadores modernos permiten distintos “niveles de
privilegio” para la ejecución de software
●
Cada nivel permite ejecutar un subconjunto específico del set de
instrucciones del microprocesador
●
En procesadores Intel x86 el nivel 0 permite todas las
instrucciones del set, mientras que los siguientes (1, 2...)
restringen operaciones como out
●
El núcleo del sistema operativo (kernel) corre al nivel 0, es decir,
no tiene restricciones de ejecución. Se dice que corre en “modo
privilegiado (kernel)”
●
Los niveles de
privilegio se
representan como
anillos concéntricos
●
Hacia el centro Þ
mayor privilegio
Fuente: https://www.cs.rutgers.edu/~pxk/416/notes/03-concepts.html
●
OpenIL (https://www.openil.org/index.html)
●
SO construidos específicamente para SE:
– Conmutación rápida y eficiente entre procesos o
hilos
– El planificador es de tiempo real, y el despacho
es parte del planificador
– Tamaño minimizado
– Rápida respuesta a interrupciones externas
●
El S.O. expone sus servicios a los programas
mediante interfaces estándares documentadas
denominadas como APIs (Application Program
Interfaces)
●
Los programas acceden a la utilización de los
recursos administrados por el S.O. de forma
ordenada y controlada
●
Por ejemplo, solicitar un bloque de memoria, leer
un archivo o acceder al I/O físico
●
Ejemplo: API POSIX en Linux para acceder a
archivos o dispositivos:
– open(), close()
– read(), write()
– ioctrl()
●
Es una pieza de software que interactúa con (entre) el sistema
operativo y con uno o mas dispositivos físicos
●
Mientras que las aplicaciones tradicionales ejecutan una o varias
tareas desde su arranque hasta el fin de ejecución, un DD se
“inicializa” y queda en cargado en memoria a la espera de
“peticiones de servicio”
●
En algunos casos un DD puede ser “cargado” y “descargado” de
memoria dinámicamente, es decir, cuando se lo necesita. Ej.:
cuando conectamos una cámara de fotos a la PC
Kernel
Hardware
DSI-EIE-FCEIA Sistemas
APIsEmbebidos Avanzados
y Device Drivers 55
Clases de Device Drivers
●
Caracter: la transferencia de datos se lleva a cabo
byte a byte, como por ejemplo en una UART
●
Bloque: la transferencia de datos se lleva a cabo en
bloques de bytes de longitud fija, como por
ejemplo en un disco
●
Red: la transferencia tiene lugar en tramas o
paquetes de bytes. Ejemplo: un adaptador
Ethernet
●
El comando lsmod informa los DD cargados en
memoria
●
El comando modinfo informa las características
de un DD específico
●
insmod carga manualmente un DD en memoria
●
modprobe carga o descarga un DD
●
Un DD provee un conjunto de características que
las aplicaciones pueden usar, llamadas
“mecanismo”
●
La forma en la que cada aplicación decide usar
estas características es privativa de la aplicación y
se denomina “política”
●
El DD del disco rígido o el de la placa de red están
integrados al núcleo: son necesarios para el
arranque del S.O.
●
Los DD de dispositivos “plug-and-play” se cargan
cuando el dispositivo se conecta físicamente a la
computadora, por ejemplo, una cámara o un
celular
61 / 79
Herramientas: Evolución
●
La necesidad de desarrollar software
implicó la creación de múltiples
herramientas de diseño y construcción
de aplicaciones
●
En este terreno encontramos desde
simples ensambladores hasta
herramientas de modelado de sistema,
incluyendo lenguajes de alto nivel (C,
C++, Java, C#,...)
Lenguajes de Programación
●
Podemos ver al lenguaje como otra capa de
abstracción, que permite ver a las aplicaciones en
el contexto del programador, ‘traduciendo’ este
modelo al código ejecutable por la máquina
destino
●
De acuerdo al ‘nivel’ de esta abstracción, se califica
el lenguaje
Lenguajes de Programación
●
En orden decreciente de nivel de abstracción:
– Herramienta de modelado (UML, etc.)
– Framework (C++ STL, Boost, Java , .NET)
– Lenguaje orientado a objetos (C++, Java, C#, etc.)
– Lenguaje procedural (C, Pascal, FORTRAN)
– Ensamblador (assembler)
– Código de máquina
Entidades
Herramienta Entidades
Modelador UML Diagramas
Framework Componentes
Ensamblador Mnemónicos
●
Cuando usamos una herramienta de mayor nivel,
estamos interponiendo mas capas de abstracción
entre nuestra aplicación y el hardware
●
Generalmente (no siempre), mayor nivel implica
mas posibilidades de diseño y menor perfomance
Capas de Abstracción
Aplicación A
Aplicación
B Aplicación
C Aplicación
D
Entorno Runtime Máquina Virtual
Sistema Operativo/Monitor
Hardware
Herramientas de programación
●
Entornos integrados de desarrollo (IDEs)
●
Herramientas de línea de comando
●
Depuración
●
Prueba
●
Perfilado
●
"Toolchains"
●
El desarrollo de software en equipos dispersos
●
La experiencia Open Source
●
Problemas y soluciones
●
Esquema de almacenamiento de los productos del
desarrollo: fuentes, documentación, etc.
●
Dos modelos:
– Centralizado
– Distribuido
●
Distribuido: ●
Centralizado:
Cada usuario tiene su propio Existe un repositorio centralizado de
repositorio. Los distintos todo el código, del cual es
repositorios pueden intercambiar y responsable un único usuario (o
mezclar revisiones entre ellos. Es conjunto de ellos). Se facilitan las
frecuente el uso de un repositorio, tareas administrativas a cambio de
que está normalmente disponible, reducir flexibilidad, pues todas las
que sirve de punto de sincronización decisiones fuertes (como crear una
de los distintosrepositorios locales. nueva rama) necesitan la
Ejemplos: Git yMercurial. aprobación del responsable.
Algunos ejemplos son CVS,
Subversion o Team Foundation
Server
Fuente:
http://invernalia.homelinux.net/jstit Sistemas Embebidos Avanzados 73
ch/content/versionadores
Repositorio distribuido
Fuente:
http://invernalia.homelinux.net/jstit Sistemas Embebidos Avanzados 74
ch/content/versionadores
Git: control de versiones
distribuido
●
Creado en 2005 para controlar el desarrollo del kernel de
Linux
●
Libre, open source
●
No solo para software, documentos en general
●
Usado por las mayores compañías de software del mundo
(Google, Microsoft, Facebook, …)
●
Presentación y documentos en https://git-scm.com/
●
Tutorial: https://git-scm.com/docs/gittutorial
●
Referencia interactiva:
http://ndpsoftware.com/git-cheatsheet.html
●
GitHub: https://github.com/ repositorios públicos,
privados con costo
●
BitBucket: https://bitbucket.org/ gratis hasta 5
usuarios, repositorios privados ilimitados
●
...