Sistemas Embebidos Avanzados DSI-EIE-FCEIA

Estructura del software en sistemas embebidos

Sistemas Embebidos AvanzadosDSI-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

Sistemas Embebidos Avanzados 4

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


Arquitectura

• La aplicación D gestiona recursos de hw directamente

• Las aplicaciones A y B deben hacerlo mediante el sistema operativo

• La ap. C interactúa con una máquina virtual

Hardware

Aplicación D

Sistema Operativo

Aplicación A

Máq Virtual

Aplicación C


Portabilidad y eficiencia

● Un programa es portable cuando puede ejecutarse sin grandes cambios en distintas plataformas de cómputo (generalmente recompilando)

● La eficiencia en el software tiene múltiples dimensiones: rapidez de ejecución, recursos de cómputo utilizados, energía consumida, esfuerzo requerido para construirlo, calidad del código, confiabilidad, mantenibilidad, etc.


1.2 Administración de recursos

● 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


Administración del procesador

● 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


Administración de dispositivos de entrada/salida

● Los dispositivos de E/S acoplados requieren

– Inicialización– Control– Interacción– Manejo de excepciones– Protocolos


Administración de la memoria

● Gestión de bloques asignados y libres● Protección ante violaciones de acceso● Relocalización● Interacción con DMA


Administración del almacenamiento persistente

● Filesystems● Variedad● Estándares

DSI-EIE-FCEIA Sistemas Embebidos Avanzados

Application Program Interfaces


Modelo de capas

● 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


Uso y desarrollo de interfaces de software

Software/hardware

API

Aplicación


API: Interacción

API

AplicaciónLlamada Respuesta

DSI-EIE-FCEIA Sistemas Embebidos Avanzados 16

APIs Síncronas / Asíncronas

● 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


APIs Síncronas

Aplicativo API

t0

t1

solicitud

respuesta


APIs Asíncronas

t t

Aplicativo API

Evento e

t0

t1

t3

t2

Registra interés en evento “e”

registrado

Suceso: evento “e”


API: Tipos

● 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


● POSIX: Interface a los servicios de los sistemas operativos UNIX/POSIX

● WIN32: Interface a los servicios de Windows● Nvidia CUDA: (Compute Unified Device

Architecture) compilador y conjunto de herramientas de desarrollo que permiten a los programadores usar una variación del lenguaje C para codificar algoritmos en GPUs de nVidia

● NMEA: interface a instrumentos de navegación

API: Ejemplos


● 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

Componentes de un API


Modelos

● 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


● Un API basada en funciones se presenta como una librería que se carga dinámica o estáticamente, y un conjunto de funciones o procedimientos que pueden invocarse desde un programa aplicativo

● Para utilizarla se debe compilar el aplicativo junto con los encabezados (*.h) y vincular con uno o mas archivos *.lib

● Si la librería es dinámica se carga sólo en el momento de ejecución, y toma la forma de DLLs (Windows) o SO (Unix/Linux)

API Basada en Funciones


API Basada en Funciones

● Es un modelo utilizado en lenguaje C● Ejemplos:

– Placas adquisidoras de datos y conversores A/D– Placas de comunicaciones– Placas de captura de video


APIs basadas en Eventos

● 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)


Desarrollo bare metal vs. S.O.

● 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


Desarrollo bare metal vs. SO (ii)

● 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

Parte II: Sistemas Operativos


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

Sistemas Operativos

● “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


Servicios del sistema operativo

● Gestión de los recursos de cómputo● Gestión de la memoria● Gestión de la E/S● Gestión de procesos● Control y arbitración de acceso a recursos● Gestión del almacenamiento masivo● Gestión de las comunicaciones● ...


Tipos de S.O.

● 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, ...

Multiprogramación

● 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

Si hay sólo una CPU

Si hay múltiples CPU

Multiprogramación

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


● 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)”

Niveles de Privilegio (i)


● La mayoría de las aplicaciones que usamos en un sistema operativo como por ejemplo Linux corre en un modo no privilegiado llamado “modo usuario (user mode)”

● En el “modo usuario” una aplicación no tiene acceso directo a la memoria física, por ejemplo

● Esta política permite arbitrar la concurrencia de aplicaciones

Fuentes: Intel® 64 and IA-32 Architectures Software Developer’s Manual The ARM Architecture With a focus on v7A and Cortex-A8

Niveles de Privilegio (ii)

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

http://www.arm.com/files/pdf/ARM_Arch_A8.pdf


● Los niveles de privilegio se representan como anillos concéntricos

● Hacia el centro Þ mayor privilegio

Niveles de Privilegio (iii)


● Un DD se ejecuta en el nivel de privilegio del kernel y una aplicación lo hace en el nivel de privilegio del usuario

● Esta separación es garantizada por el kernel, y permite proteger a cada aplicación de las demás ejecutándose concurrentemente, tanto el área de memoria asignada como el estado del procesador (contexto)

● Todas las operaciones críticas son ejecutadas en el nivel de privilegio del kernel del S.O.

Espacios del kernel y del usuario


Estructura de un Sistema Operativo

Fuente: https://www.cs.rutgers.edu/~pxk/416/notes/03-concepts.html


Caso de estudio: sistema operativo para dispositivos embebidos

● Operación en tiempo real● Operación reactiva● Configurabilidad● Flexibilidad con dispositivos de E/S● Mecanismos de protección estrictos● Uso directo de interrupciones por parte de las

aplicaciones


Enfoques para el diseño● Modificar un SO existente, por ejemplo, Linux, agregando:

– Capacidades de tiempo real

– Optimización de operaciones

– Otras funcionalidades requeridas● Ventajas:

– Interfaz conocida

– Herramientas y aplicaciones disponibles● Desventajas:

– No optimizado para operación en tiempo real, tampoco para plataformas embebidas


SO preexistentes, modificados

● OpenIL (https://www.openil.org/index.html)


Enfoques para el diseño (ii)

● 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


●SO construidos específicamente para SE (ii)

– Minimiza los intervalos con interrupciones inhabilitadas

– Provee flexibilidad en la administración de memoria*

– Proveee mecanismos de escritura de datos a alta velocidad**

*,**: según versiones


Gestión de recursos, planificación y tiempo

● Procesos, hilos, memoria● Prioridades, tipo de planificación● Restricciones en los sistemas de tiempo real


APIs del S.O.

● 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


APIs del S.O. (cont.)

● 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()


Device Drivers


● 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

¿Que es un DD?

DSI-EIE-FCEIA Sistemas Embebidos Avanzados 55 APIs y Device Drivers

Hardware

Capa de abstracción del hardware

Kernel

Device Driver

API del S.O.

Device Driver Device Driver

Aplicación Aplicación Aplicación Aplicación

EspacioDel

Kernel

EspacioDe

Usuario

open(), read(), write()

...

ioctrl()

Arquitectura


● 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

Clases de Device Drivers


Ejemplo: DD en Linux

● 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”

Política y Mecanismo


● Un DD, como toda pieza de software, tiene una fase de diseño, una de construcción y una de utilización

● Las dos primeras son similares a cualquier otra pieza de software

● La fase de utilización es específica:

– Integrado al núcleo del sistema operativo– Cargado y descargado a requerimiento del

usuario

Ciclo de Vida de un DD


● 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

Fase de Utilización

61 / 79

Modelos de desarrollo

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

Opcodes, hexCódigo de máquina

MnemónicosEnsamblador

Rutinas, módulosLenguaje procedural

Objetos, clases, mensajesLenguaje orientado a objetos

ComponentesFramework

DiagramasModelador UML

EntidadesHerramienta

Entidades

Niveles

● 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

Hardware

Sistema Operativo/Monitor

Máquina VirtualEntorno Runtime

Aplicación AAplicación

B AplicaciónC Aplicación

D

Capas de Abstracción


Herramientas de programación

● Entornos integrados de desarrollo (IDEs)● Herramientas de línea de comando● Depuración● Prueba● Perfilado● "Toolchains"


Desarrollo colaborativo

● El desarrollo de software en equipos dispersos● La experiencia Open Source● Problemas y soluciones


Herramientas de versionado

● Cuando se trabaja en proyectos no triviales es imprescindible el control de cambios

● Si es desarrollo colaborativo resulta inevitable● Múltiples soluciones:

– Git– SubVersion– Mercurial– ...


Repositorios

● Esquema de almacenamiento de los productos del desarrollo: fuentes, documentación, etc.

● Dos modelos:

– Centralizado– Distribuido


Repositorios: modelos

● Distribuido:Cada usuario tiene su propio repositorio. Los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. Es frecuente el uso de un repositorio, que está normalmente disponible, que sirve de punto de sincronización de los distintosrepositorios locales. Ejemplos: Git yMercurial.

● Centralizado:Existe un repositorio centralizado de todo el código, del cual es responsable un único usuario (o conjunto de ellos). Se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobación del responsable. Algunos ejemplos son CVS, Subversion o Team Foundation Server


Repositorio centralizado

Fuente: http://invernalia.homelinux.net/jstitch/content/versionadores


Repositorio distribuido

Fuente: http://invernalia.homelinux.net/jstitch/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

https://git-scm.com/

https://git-scm.com/docs/gittutorial

http://ndpsoftware.com/git-cheatsheet.html


Git: flujo e interacciones


Repositorios Git públicos

● GitHub: https://github.com/ repositorios públicos, privados con costo

● BitBucket: https://bitbucket.org/ gratis hasta 5 usuarios, repositorios privados ilimitados

● ...

https://github.com/

https://bitbucket.org/


Ejercitación propuesta● 1: Desarrolle un programa en C o C++ que permita conocer en Linux

los puertos y dispositivos conectados por USB (sugerencia: investigue la librería libusb)

● 2. Investigue el uso y mecanismo de la llamada al sistema select(). ¿Es un API síncrona o asíncrona?

● 3. Investigue el propósito y contenido del filesystem /proc en sistemas Linux. Desarrolle un programa simple que interprete y muestre información allí contenida (no toda, elija una clase)

● 4. Desarrolle un programa que permita conocer los threads de hardware soportados por una plataforma de SE (BB o Raspberry PI)

● 5. En Linux el comando ifconfig -a lista las interfaces de red conocidas por el sistema. Diseñe un programa capaz de entregar la misma información sin usar el comando ifconfig


Bibliografía● Sistemas Operativos Modernos, A. Tanenbaum ISBN 968-880-323-5

● Embedded Operating Systems, Eighth Edition. William Stallings

● OpenIL, Open Industrial Linux www.openil.org

● Linux device drivers third edition, Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman, O'reilly, 2005

● Sistemas Operativos, 7ª edición, Galvin, Silverschatz y Gagne

● Operating System Concepts, Paul Krzyzanowski https://www.cs.rutgers.edu/~pxk/416/notes/03-concepts.html

● Versionando con Git y Github, jsticht http://invernalia.homelinux.net/jstitch/content/versionadores

● Git: --local-branching-on-the-cheap https://git-scm.com/

http://www.openil.org/

https://www.cs.rutgers.edu/~pxk/416/notes/03-concepts.html

http://invernalia.homelinux.net/jstitch/content/versionadores

https://git-scm.com/

Sistemas Embebidos Avanzados DSI-EIE-FCEIA

Documents

Transcript of Sistemas Embebidos Avanzados DSI-EIE-FCEIA