Clase 04: Arquitecturas de Software Embebido - Sistemas ...€¦ · Jos e H. Moyano (Departamento...

Clase 04: Arquitecturas de Software EmbebidoSistemas Embebidos

Prof: Lic. Jose H. Moyano

Departamento de Ciencias e Ingenierıa de la Computacion

2019

Prof: Lic. Jose H. Moyano (Departamento de Ciencias e Ingenierıa de la Computacion)Clase 04: Arquitecturas de Software Embebido 2019 1 / 54

Tareas e ISRs


Tareas

El software de un sistema embebido realiza diversas funciones tales como: atendery controlar dispositivos

I realizar computosI medir intervalos de tiempoI configurar e inicializar el hardwareI etc.

A cada una de dichas funciones podemos asociar una unidad de ejecucion que laimplementa (Tarea).


Tareas

En Sistemas Operativos de Tiempo Real se habla de tareas como unidades deprograma secuenciales y planificables.

Tarea (Sistemas Embebidos):I Es una unidad de ejecucion secuencialI Su ejecucion se planifica o coordina de alguna maneraI Posee cohesion funcional (se origina como resultado de descomponer

funcionalmente al sistema)I La nocion de tarea trasciende los constructores del lenguaje de programacion (una

tarea puede ser una funcion, modulo, metodo, objeto, etc. o simplemente unasecuencia de codigo en una unidad mayor)


Tareas

Planificacion y coordinacion de tareas:I En ausencia de un SO, las tareas son atendidas y coordinadas por un modulo

principal que se encarga de planificarlas de acuerdo a algun esquema.I En presencia de un SO, es el scheduler del sistema operativo quien abstrae al

implementador de estos detalles. El implementador simplemente especifica sustareas como unidades funcionales separadas, y la logica de coordinacion queda“oculta” por el sistema.

En ambos casos, si existe comunicacion entre tareas, hay que sincronizar suejecucion.


TareasTanto en presencia de Sistemas Operativos como sin ellos, podemos considerar que lastareas se encuentran en determinado estado:


Tareas

Las tareas suelen tener:I diversas prioridades.I deadlines (tiempos maximos en los cuales la tarea debe cumplirse – tiempo real).

La asignacion de prioridades determinara que tareas tienen privilegios para accederal CPU.

Los deadlines deben ser tenidos en cuenta para asegurar que ningun dispositivodeja de ser atendido en tiempo y forma.

En sistemas con restricciones de tiempo real: Correctitud funcional + correctitudtemporal.


ISR

En sistemas que realizan E/S usando interrupciones, la ejecucion de las tareaspuede ser interrumpida por la ocurrencia de eventos notificados por el hardware.

El control es transferido a rutinas que dan atencion a dichos eventos y que poseenmayor prioridad que las tareas: las Interrupt Service Routines (ISRs).

Las ISRs comparten con las tareas el hecho de:I Ser unidades de ejecucion secuencialI Poseer cohesion funcional (se originan como resultado de descomponer

funcionalmente al sistema)


ISR

Las ISRs se diferencian de las tareas en que:

Inician su ejecucion ante la ocurrencia de eventos asincronicos

No se rigen por los esquemas de planificacion y coordinacion habituales

Su implementacion se realiza mediante un constructor especıfico del lenguaje deprogramacion (normalmente una funcion con un calificador especial que denota sucondicion de ISR)

generalmente la implementacion funcional de un sistema esta compuesta por unconjunto de Tareas e ISRs.


Tareas e ISR

De la descomposicion funcional de un sistema:

Se identifican y especifican Tareas e ISRs

Se determinan dependencias entre las mismas (datos y recursos compartidos,sincronizacion y comunicacion, oportunidades de concurrencia, etc).

Se fijan las restricciones temporales (tiempo real)

Se aplican criterios de modularidad (optimizar tareas e ISRs)

Se analiza el esquema y la posibilidad de planificacion (por ej. Rate MonotonicAnalysis) ante restricciones de tiempo real (el analisis de planificabilidad lo veremosmas adelante).


Division tareas e ISRTelefono celular simple


Division tareas e ISROutside-in approach


Caso de Estudio: Impresora 3D



La impresora 3d derrite plastico, y lo deposita utilizando un estrusor en la cama,siguiendo el patron de una pieza de tres dimensiones, que es lo que se desea imprimir.

La maquina puede interpretar G code

En una memoria microSD, se almacenan archivos en un sistema fat32 o NTFS, conel codigo G de disenos que pueden imprimirse

Dos steppers controlan el movimiento del estrusor, en los ejes X y Z

Un tercer stepper controla el movimiento de la cama en el eje Y

Un cuarto stepper controla la entrada de filamento al estrusor



La impresora 3d derrite plastico, y lo deposita utilizando un estrusor en la cama,siguiendo el patron de una pieza de tres dimensiones, que es lo que se desea imprimir.

Una resistencia calienta el estrusor, y otra calienta la cama donde se deposita lafigura

Un display muestra informacion de estado

Una perilla permite al usuario controlar la maquina, a traves de un menu que semuestra en el display

Los steppers calibran su posicion en los tres ejes con tres sensores de fin de carrera

Sensores de temperatura miden la temperatura del estrusor y la cama. Latemperatura de ambos elementos dependen del diseno



Identificar las partes del sistemaI Diagrama de bloques: Permiten describir sw y hw

Identificar Tareas e ISRs (particion funcional)I Diagramas de Transicion de EstadosI Diagrama de Flujos

Identificar dependencias y oportunidades de comunicacion y sincronizacion

Definir temporizados, prioridades y deadlines

Modos de operacion del sistema (idle, working, calibration, error, etc.)I Diagramas de Transicion de Estados

Protocolo de comunicacionI Diagramas de secuencia


Arquitecturas de Software


Sobre las arquitecturas de software

El esquema de planificacion de tareas define la estructura del software embebido.

La eleccion de que arquitectura de software utilizar condiciona:I El tipo de respuesta del sistema ante eventosI La forma en que el sistema gestiona multiples eventos (ej. prioridades)I La complejidad del sistema (testeo, mantenimiento, interoperabilidad, etc)

A continuacion analizaremos diversas arquitecturas de software usuales en sistemasembebidos, en orden creciente de complejidad.


Problema de Sistemas Embebidos

Se desea desarrollar el software de un sistema embebido. Este sistema tiene unaconexion SPI con un dispositivo, cuyos datos deben procesarse, y enviar por UART a unsegundo dispositivo. A su vez, el sistema debe generar informacion propia, que debeenviar tambien por UART cada 20ms. Cada 1s, debe indicar que esta activo haciendoque parpadee un LED.


Se cuenta con una funcion system init() que inicializa todo el sistema

La funcion spi read(uint8 t *), verifica el flag del dispositivo para determinar sihay datos esperando, y en caso de haberlos, devuelve true, y guarda byte recibidoen la variable pasada como parametro.

La funcion uart send(uint8 t *) devuelve true si la UART esta disponible paraenviar un byte, y de ser ası, lo entrega al dispositivo para ser enviado.

La funcion led toggle() enciende el led si esta apagado, o lo apaga si estaencendido.

La funcion timer get ms() devuelve la cantidad de milisegundos transcurridosdesde que se inicio la ejecucion del sistema. Por simplicidad, se supone que estosvalores son infinitos y siempre validos.

La funcion own process(uint8 t *) realiza el procesamiento propio deldispositivo, y guarda los datos en el arreglo entregado como parametro.


La arquitectura desarrollada se llama Round-Robin.


Ejemplo de Arquitectura Round-RobinMultımetro digital


Propiedades de la Arquitectura Round-Robin

Util cuando:

Hay pocos dispositivos

No hay restricciones de tiempo importantes

No hay tiempos de procesamiento demasiado elevados en respuesta a eventos.

No es adecuada cuando:

El bucle se hace demasiado largo (o un dispositivo necesita ser atendidorapidamente)

Se pueden perder eventos o datos

Anadir un nuevo dispositivo puede comprometer los resultados alcanzados con esteesquema


Problema de sistemas embebidos 2

Cuando se puso en funcionamiento el sistema, el equipo detecto que si se recibe undato por SPI antes de ejecutar own process, puede suceder que el dispositivoenvıe otro dato antes de que own process termine.

Como resultado, se sobreescribe el dato anterior con el nuevo, y este primer dato sepierde.

El equipo de desarrollo ha decidido solucionarlo configurando tanto el SPI, como elUART, para que generen interrupciones al recibir y terminar de enviar.

Las dos ISR se declaran como ISR(UART tx) e ISR(SPI rx) respectivamente.


La arquitectura desarrollada se llama Round-Robin coninterrupciones.

Es la que propone Arduino.


Comparando prioridades RR y RR con int


Caracterısticas Round-Robin con interrupciones

El codigo de cada tarea corre a la misma prioridad (introduce latencias importantesen presencia de otras tareas demandantes en el tiempo).

I Opcion 1: Mover el codigo de la tarea a su ISR (complica los tiempos de atencionde los eventos de las demas tareas).

I Opcion 2: Incrementar la frecuencia de polling de las tareas demandantes (por ej.chequeando flags varias veces por ciclo). Es un esquema limitado: Mientras masveces se chequean los flags de una tarea, mas demora potencial introducimos en laatencion de las otras.

Tiempos largos de respuesta si justo ocurre el evento inmediatamente despues deque se paso el polling del flag.


Problema de Sistemas Embebidos 3Las funciones del sistema original se ampliaron.

I Debe recuperar de la EEPROM parametros de configuracion que deben reportarseal inicio, hacia el sistema 2 a traves de la UART.

I Un nuevo LED azul debe parpadear cada vez que se realice una transmision alsistema 2.

I Un nuevo LED verde debe parpadear cada vez que se realice una recepcion delsistema 1.

I Luego de 5 segundos sin recibir informacion del sistema 1, debe encenderse unnuevo LED rojo. Cuando regresa a la normalidad, debe apagarse.

I Cada 30 segundos, debe enviar al sistema 1 un mensaje solicitando informacion deestado. Esta informacion de estado deben remitirse al sistema 2.

Hay tambien rumores que se piensa reemplazar el microcontrolador con otro demenor costo, de otro fabricante. Las funciones spi read y uart send puede que noesten disponibles o tengan otros nombres. El timer tiene pocos bits y desbordararapidamente.


El equipo de desarrollo entiende que el diseno debe separar el software en modulos.I Un unico timer es insuficiente para todos los requisitos de temporizado, y se debe

prevenir el desbordamiento.I Debe poder reportarse a las capas superiores del sistema cuando un evento requiera

atencion.I El hardware debe abstraerse a traves de device drivers.

Se utilizara una nueva arquitectura, function-queue-scheduling que ofrece unafuncion function post(* void(fn)(void)) que permite encolar una funcion aejecutar luego, y otra funcion, function run() que ejecuta la proxima funcion encola.


Caracterısticas Function-Queue-Scheduling

Funciones largas de baja prioridad pueden comprometer los tiempos de respuestade las funciones de alta prioridad.

Si bien se puede reestructurar en bloques menores las rutinas largas (algo complejode hacer), en el fondo la planificacion de las rutinas no es apropiativa.

Para escenarios de mayor complejidad se utilizan sistemas operativos embebidos(RTOS).


Funciones de callback

Un callback es una funcion que se entrega como parametro, esperando que estafuncion sea llamada en algun momento, bajo alguna condicion.

Se las clasifica de sincronicas cuando se espera que la sea llamada antes del retornode la funcion; y asincronicas cuando pueden ocurrir mas adelante, luego de que lafuncion termino su ejecucion.

Tambien llamadas senales o eventos.

Se utilizan tambien en el desarrollo de aplicaciones en servidores y sistemas deescritorio.


Callbacks en function-queue-scheduling

Las funciones de callback permiten organizar el software en modulos independientesen sistemas embebidos con function-queue-scheduling.

Por ejemplo, se puede escribir un modulo que administre un dispositivo, e informeal programa principal o a otro modulo cliente cuando se presenta un evento quehay que atender.


Callbacks en function-queue-schedulingConvenciones

En general las rutinas de interrupcion agregan una funcion a la cola de funcionespara reportar el evento.

Se evita llamar a funciones de callback desde rutinas de interrupcion, porque sepierde el control de la duracion y las actividades que se estan realizando dentro deuna rutina de interrupcion.

Si es necesario llamar a funciones de callback desde una rutina de interrupcion, setoma una convencion para informar de esto al programador. Por ejemplo, enTinyOS se nombran esas funciones como async.

Las funciones de callback no llaman a otras funciones de callback. Si una funcionde callback necesita llamar a otra funcion de callback, pone otra funcion en la colaque hara la llamada.


Arquitectura RTOS

Para escenarios complejos: Real-Time Operating Systems.

La aplicacion se estructura en un conjunto de ISRs y tareas que se sincronizan.

Las ISRs senalizan a las tareas.

Las tareas son planificadas por el RTOS (prioridades, apropiacion, etc.).

Los mecanismos de sincronizacion (al igual que otros servicios) son provistos por elSistema Operativo.


Arquitectura RTOS

El bucle principal ahora forma parte del scheduler del sistema operativo.

La sincronizacion y planificacion son servicios provistos por el RTOS.


Comparacion de prioridades


Caracterısticas Arquitectura RTOS

El tiempo entre un evento y su atencion dependen del quantum asignado a cadatarea (ademas de la latencia de interrupcion, tiempo del cambio de contexto, etc.).

Si se cambia una tarea, el esquema de temporizado continua siendo estable(cambios en las tareas menos prioritarias no afectan a los tiempos de respuesta delas tareas mas prioritarias).

Los RTOS proveen muchos servicios adicionales.

Desventaja: El RTOS consume recursos (el scheduler insume tiempo), se requiereespacio en memoria para alojarlo, etc. Un sistema simple como el ATMega328Ptiene problemas para cumplir con todas sus funciones si ademas aloja un RTOS.


Seleccionando una arquitectura

Elegir la mas simple posible dentro delos requerimientos funcionales ytemporales de la aplicacion.

Ciertas soluciones utilizan arquitecturashıbridas.


Criterios de modularidad


Analizar dependenciasAnalizar las dependencias entre los dispositivos y el resto del sistema constituye unfactor clave al momento de descomponer el sistema en tareas e ISRs.


Dispositivos activos

Los dispositivos activos producen interrupciones

La atencion de este tipo de dispositivos tiene fuertes restricciones temporales(ISRs) y existe un mecanismo de comunicacion inter-tarea entre la ISR y la tarea.


Tareas activasEjemplos

Tareas asincronicas: reciben eventos aperiodicos.

Tareas sincronicas: reciben eventos periodicos o su operacion esta sincronizada conotras tareas del sistema.

Tareas que controlan el acceso a un dispositivo compartido.


Recomendaciones tareas activasAsignar tareas separadas para cada dispositivo de E/S que presente uncomportamiento asincronico (el dispositivo fija la tasa de transferencia).

Combinar tareas para dispositivos que interrumpen infrecuentemente o cuyosdeadlines (tiempo real) son largos.

Asignar diferentes tareas a dispositivos que presentan tasas de transferenciadispares.

Asignar prioridades mas altas a las tareas asociadas a dispositivos que generaninterrupciones (en general estos dispositivos requieren tiempos de respuesta masdemandantes).

Asignar una tarea que gestione el acceso a dispositivos compartidos (dispositivosque deben ser accedidos por multiples tareas).

Utilizar tareas de despacho de eventos para aquellos dispositivos que requieranproveer informacion a multiples tareas.


Dispositivos pasivos

Los dispositivos pasivos no producen interrupciones

El control en la comunicacion esta en manos de la tarea (normalmente polling orespuesta a eventos de otras tareas).


Tareas pasivasEjemplos

Tareas que operan sobre el dispositivo esporadicamente.Tareas que realizan polling a intervalos aperiodicos.Tareas de despacho de eventos (originados a partir del polling) hacia otras tareasdel sistema.


Recomendaciones tareas pasivas

Asignar una tarea para manejar dispositivos que se operan eventualmente o cuyosdeadlines no son urgentes.

Asignar tareas individuales para cada dispositivo que necesite sersondeado/escrutado a diferentes tasas (evitar under/oversampling).

Disparar el polling a dispositivos pasivos mediante timers (evitar delays en SW quepodrıan demorarse ante la ocurrencia de interrupciones).

Incrementar la prioridad de las tareas que realizan polling de mayor frecuencia (solohasta el nivel necesario, sino se corre el riesgo de sobre-ocupar el cpu).



Una vez identificadas las tareas e ISRs, y teniendo en cuenta sus prioridades relativas esnecesario:

Identificar las dependencias entre eventos (tareas que producen informacion queotras necesitan)

Identificar dependencias temporales:I Identificar actividades crıticas y urgentesI Identificar las tasas de ejecucion de tareas periodicasI Identificar cohesion temporal: aquellas porciones de codigo que se ejecutan en un

mismo momento (por ej. dependen de un mismo evento) pueden agruparse en unatarea para reducir la sobrecarga.

Identificar actividades limitadas por CPU (intensivas en procesamiento) y asignarlesprioridades bajas.



Una vez identificadas las tareas e ISRs, y teniendo en cuenta sus prioridades relativas esnecesario:

Identificar cohesion funcional: agrupar en tareas funciones relacionadas o tareas quecomunican grandes cantidades de datos.

Identificar tareas de propositos especıficos: agrupar tareas que se combinan paralograr un proposito particular y tratarlas como unidades funcionales separadas.

Identificar cohesion secuencial: agrupar tareas que revisten un ordenamientosecuencial en una unica tarea, reduce los recursos consumidos por las mismas ysimplifica el diseno.


Device drivers


Acerca de los device drivers

Son porciones de software destinadas a aislar al resto del sistema de los detallesespecıficos de un dispositivo particular de hardware.

El acceso al dispositivo se realiza exclusivamente vıa el driver (proteccion delrecurso) mediante una interfaz que abstrae de los detalles de implementacion(abstraccion de hardware).

Se dan tanto en presencia de sistemas operativos (seguiran el modelo de driverspara el sistema particular) como en su ausencia (presentaran la forma de una APIque el desarrollador podra integrar en su sistema).


Capas del software en un sistema embebido


Drivers como capas de abstraccion de hardware


Device driversCon excepcion de sistemas muy simples, la atencion de cada dispositivo (ISRs y tareas)se encapsula en device drivers (modulo/subsistema).


Referencias

Barr, M., Massa, A. Programming Embedded Systems: With C and GNUDevelopment Tools, 2nd Edition. O’Reilly Media. 2006. ISBN: 978–0596009830.Capıtulo 10.

Li, Q., Yao, C. Real-time concepts for Embedded Systems. CMP. 2003. ISBN:978–1578201242. Capıtulos 5, 14 y 15.

Simon, D. An Embedded Software Primer. Addison-Wesley Professional. 1999.ISBN: 978–0201615692. Capıtulo 5.


Clase 04: Arquitecturas de Software Embebido - Sistemas ...€¦ · Jos e H. Moyano (Departamento...

Documents

Transcript of Clase 04: Arquitecturas de Software Embebido - Sistemas ...€¦ · Jos e H. Moyano (Departamento...