19 e 20 de julho 2011 introduÇÃo ao desenvolvimento de software embarcado alexandra aguiar,...

19 e 20 de julho2011

INTRODUÇÃO AO DESENVOLVIMENTO DE

SOFTWARE EMBARCADO

Alexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel

Programação2

Sala Ponta Negra, Bloco C

19/07 – Terça-feira 17h as 19h

20/07 – Quarta-feira 11h as 13h 17h as 19h


Introdução ao desenvolvimento de software embarcado

Apresentação3



Faculdade de Informática (FACIN) – PUCRS CC (Ciência da Computação) – 498 alunos EC (Engenharia de Computação) – 328 alunos (compartilhada com FENG) SI (Sistemas de Informação) – 551 alunos PPGCC (Programa de Pós Graduação em Ciência da Computação) – 82 MSc; 44

PhD

Linha de pesquisaSESD – Sistemas Embarcados e Sistemas Digitais

GruposGSE – Grupo de Sistemas EmbarcadosGaph – Grupo de Apoio ao Projeto de Hardware

Equipe7 – professores24 – alunos mestrado 11 – alunos doutorado32 – alunos de graduação

Projetos industriais GSE / GAPH4

Telecom Parks Digistar Datacom Novus

Automação industrial Novus Innalogics INCT-Sec

RFID chip Innalogics Ceitec Hp Tsystems

Aplicações espaciais AEL INPE

• Apoio governamental• Capes• CNPq• Fapergs

Cooperação Acadêmica5

Cooperação Nacional UFRGS UNICAMP UFSM UFSC

Cooperação Internacional França

TIMA (Grenoble) CEA – LETI (Grenoble) LIRMM (Montpellier)

Holanda Philips Research Labs (EindHoven)

GSE – Equipe Hellfire6

Dr. Fabiano Hessel – (Supervisor) [email protected]

Alexandra Aguiar (Doutorado) [email protected]

Felipe Magalhães (Mestrado) [email protected]

Oliver Bellaver Longhi (Graduação) [email protected]

Sérgio Johann Filho (Doutorado) [email protected]



Sumário – Curso teórico-prático Teoria (aprox. 3 horas)

Sistemas Embarcados Sistemas de Tempo Real

Prática (aprox. 3 horas) Hellfire framework



7

Contextualização8



Introdução9

Sistemas Embarcados



Introdução10

Restrições Temporais De área De consumo de energia De custo ...

Time-to-market



Introdução11

Plataformas SoC MPSoC

Desafios de sistemas de propósito geral presentes em sistemas embarcados

Software em sistemas embarcados



Introdução12

Desenvolvimento de Firmware

Automação de processos

Área de Robótica

Aero-espacial

AutomobilísticaAlexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel


Conceitos básicos e de hardware

13



Sistemas embarcados14

Sistema dedicado a uma ou mais tarefa(s) específica(s)

Possui diversas restrições em relação ao seu desenvolvimento Não pode ser reprogramado em tempo de

execução Normalmente alimentados por baterias

Leva em consideração as características da aplicação em seu projeto Alta confiabilidade



Sistemas embarcados – Restrições

15

Energia ''Alimentado por baterias?'' ''Como reduzir consumo?''

Capacidade ''Que tipo de CPU será usada?'' ''Qual o tipo adequado?''

''Hardware, Software ou Hardware e Software?'' Memória

''Quanto de memória há disponível?'' Tempo de Desenvolvimento

''Quanto tempo para lançar o produto?'' Tempo Restrito de Resposta (Tempo Real)

''Qual a responsividade esperada?''




Integração de diversos componentes em uma única pastilha de silício

Uma unidade de processamento, uma unidade de memória e uma unidade de E/S

Primeiro produto em 1974Alexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel



Abstrações Aglomerações



Adapted from F. Schirrmeister (Cadence Design Systems Inc.)1970’s 1980’s 1990’s

abst

ract

abst

ract

cluster

abst

ract

cluster

RTL

Transistor model(=RC)

Gate level model1/0/X/U ( ns)

Register-transfer level modeldata[1011011] (critical path latency)

2000’s 2010+

ab

stra

ct

cluster

on-chipcommunication

Network

Com

m.interc.

SW

SW

HW

SW tasks

OS

MPU

Comm. int.

SW tasks

OS

MPU

Comm. int.

SW tasks

SW adaptation

MPU core

HW adaptation

HW adaptation

IPs

OS/drivers

SW Tasks

CPUcluster

IPs

HW adaptation

Platform Around CPU busSW call OS routines to send Framei

to DCT IP (bus priority)

ab

stra

ct

SW HW

Sistemas de tempo real19

Sistemas computacionais de tempo real: Submetidos a requisitos de natureza temporal Resultados devem estar corretos lógica e

temporalmente Requisitos definidos pelo ambiente físico

Aspectos temporais NÃO estão limitados a uma questão de maior ou

menor desempenho Estão diretamente associados com a funcionalidade

Sistemas em geral: “Fazer o trabalho usando o tempo necessário”

Sistemas de tempo real: “Fazer o trabalho usando o tempo disponível”




Conceitos EQUIVOCADOS Tempo real significa execução rápida Computadores mais rápidos vão resolver todos

os problemas Sistemas de tempo real são pequenos, escritos

em assembly Sistemas de tempo real são formados apenas

por Tratadores de interrupção, e; Drivers de dispositivos

Sistemas de tempo real operam em ambientes estáticos




Soft real-time systems Desempenho é degradado

Ex: sistemas multimídia Firm real-time systems

não cumprimento de restrições temporais pode ser tolerado. Ex: engarrafamento de refrigerantes.

Hard real-time systems Consequências para vidas humanas e/ou meio

ambiente Ex: sistemas de segurança crítica



Arquiteturas Embarcadas23

System-on-Chip – SoC




Multiprocessor System-on-Chip




Comunicação – Barramento Topologias

Simples, hierárquico...




Comunicação – Network-on-Chip – NoC

Tendência de comunicação Utiliza roteadores para gerenciar o tráfego Conexão ponto a ponto Comunicação paralela Maior área e complexidade para

implementação




Comunicação – Network-on-Chip – NoC Topologias

Mesh 2D, Anel, Direta




Virtualizadas



Hypervisor Tipo 1 Hypervisor Tipo 2


Ring de-privileging Paravirtualização



Software Embarcado30



Software embarcado31

Crescente utilização

Diversas camadas

Aplicação e Sistema Operacional



Software Embarcado32

Sistemas Operacionais Embarcados Lidam com restrições de memória e

armazenamento Geralmente não possuem interface para

usuário Estrutura simplificada em relação ao SO de

propósito geral Certos módulos podem não estar presentes Maior diversidade de processadores



RTOS Embarcados33

Real-time Operating System – Embarcados Atender requisitos dos Sistemas de Tempo

Real Conceitos básicos

Tarefa Periódicas x aperiódicas Esporádica Preemptiva x não preemptivas Estática x dinâmica



RTOS Embarcados34

Tempo de computação ou execução (computation time) é o tempo utilizado por uma tarefa para a execução

completa de suas atribuições. Casos especiais de tempo de execução incluem:

BCET (Best Case Execution Time) - melhor (menor) tempo de execução possível de uma determinada tarefa;

ACET (Average Case Execution Time) - tempo médio de execução de uma determinada tarefa, e;

WCET (Worst Case Execution Time) - pior (maior) tempo de execução possível de uma determinada tarefa.



RTOS Embarcados35

tempo limite de execução (deadline) é o tempo máximo permitido para que uma tarefa seja

executada; tempo de início (start time)

é o instante de início do processamento da tarefa em ativação;

tempo de término (completion time) é o instante de tempo em que se completa a execução

da tarefa; tempo de chegada (arrival time)

é o instante em que o escalonador toma conhecimento de uma ativação da tarefa, e;

tempo de liberação (release time) corresponde ao instante de inclusão da tarefa na fila de

tarefas prontas a ser executadas.Alexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel


RTOS Embarcados36

Controle de aplicações com restrições de tempo real

Sub-sistema semelhante a Sistemas Operacionais de Propósito Geral

Inclusão de uma unidade escalonadora de tempo real

Algoritmos de escalonamento de tempo real Earliest Deadline First - EDF Rate Monotonic – RM



RTOS Embarcados37

Estados de uma tarefa



RTOS Embarcados38

Estados de uma tarefa



RTOS Embarcados39

Modelo de tarefa Conjunto de

tarefas Fator de

utilização do processador

Fator de carga do processador

Idle timeAlexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel


RTOS Embarcados - Escalonamento

40

On-line versus off-line

Preemptivo versus não preemptivo

Melhor esforço (best effort) versus intolerâncias a falhas de tempo (timing fault intolerance)

Centralizado versus distribuído



RTOS Embarcado – Taxa Motônica (Rate Monotonic – RM)41

Desenvolvido por Liu & Layland. Produz escalas em tempo de execução

através de escalonadores preemptivos dirigidos a prioridades. Online: Escala é produzida em tempo de

execução É um esquema de prioridade fixa, ou

seja, tarefas sempre possuem a mesma prioridade. Estático: prioridades não variam em tempo

de execução


O algoritmo RM trabalha sobre um modelo de tarefas bastante simples, que obedece às seguintes premissas: As tarefas são periódicas e independentes. O “deadline” de cada tarefa coincide com o

seu período (Di = Pi) O tempo de computação (Ci) de cada tarefa

é conhecido e constante (Worst Case Computation Time)

O tempo de chaveamento entre tarefas é assumido nulo.


Idéia: Dar maior prioridade às tarefas de menor período.

Tarefas Periódica

s

Período Tempo de Computaçã

o

Prioridade RM

Utilização

Tarefa A

10 2 1 0,2

Tarefa B

15 4 2 0,267

Tarefa C

35 10 3 0,286


Tarefas Periódicas

Período Tempo de Computação

Prioridade RM Utilização

Task A 10 2 1 0,2

Task B 15 4 2 0,267

Task C 35 10 3 0,286

Até o tempo 40: 11 trocas de contexto3 preempções


A análise de escalonabilidade pode ser feita através de um teste que define uma condição suficiente.


Aplicando a fórmula no exemplo utilizado, temos:


Muito utilizado devido a sua simplicidade de implementação.

É um algoritmo ótimo para a classe de problemas que se propõe Tarefas periódicas. P = D. Prioridade Fixa.

RTOS Embarcado – Earliest Deadline First (EDF)

48

Desenvolvido por Liu & Leiland Produz escalas em tempo de execução

através de escalonadores preemptivos dirigidos a prioridades.

É um esquema de prioridade dinâmica. On-line e Dinâmico.


49

O algoritmo EDF trabalha sobre um modelo de tarefas bastante simples, que obedece as seguintes premissas:

As tarefas são periódicas e independentes. O “deadline” de cada tarefa coincide com o seu

período (Di = Pi) O tempo de computação (Ci) de cada tarefa é

conhecido e constante (Worst Case Computation Time)

O tempo de chaveamento entre tarefas é assumido nulo.


50

Idéia: Atribuição dinâmica de prioridades de acordo com os deadlines de cada tarefa.Tarefas

PeriódicasPeríodo / Deadline

Tempo de Computaçã

o

Utilização

Tarefa A 20 10 0,5

Tarefa B 50 25 0,5


51

A análise de escalonabilidade pode ser feita através do teste abaixo que define uma condição suficiente e necessária.


52

Embora consiga trabalhar com um conjunto maior de casos, EDF possui implementação complexa.

É um algoritmo ótimo para a classe de problemas que se propõe Tarefas periódicas. P = D. Prioridade Dinâmica.

Modelos e técnicas de programação

53



Propósito Geral x Propósito Específico

54

Alto nível Recursos virtualmente ilimitados Voltados ao usuário Estruturas pré prontas (suporte de

ferramentas) Exemplos de linguagens

Java C# C, C++ Visual Basic PHP ASP ...



Propósito Geral x Propósito Específico

55

Baixo nível Recursos Limitados Voltado a serviços Confibiabilidade mais importante que

desempenho Exemplos de linguagens

Assembly C, C++ ...



Virtualização de software56



Hellfire Framework57



Hellfire Framework58

Framework para criação, simulação e debug de MPSoCs

Integra em uma única ferramenta três módulos HellfireOS – Sistema Operacional de Tempo Real N-MIPS – Simulador de MPSoCs Ferramenta de Geração de Arquitetura

Geração de relatórios de funcionamento Geração de gráficos de funcionamento Ferramenta de inclusão de políticas de

escalonamento Interface WEB



Hellfire Framework – Design Flow

59



HellfireOS60

Características Sistema operacional de tempo real

preemptivo Parametrizável Gerenciamento dinâmico de tarefas Chamadas de sistema

perdas de deadline trocas de contexto parâmetros de tarefas uso de processador memória ...



HellfireOS61

Diferentes políticas de escalonamento (RM, PRR, EDF, DM)

Primitivas de exclusão mútua, semáforos Proteção contra inversão de prioridades (priority

inheritance) Alocação, liberação e gerenciamento dinâmico

de memória LibC customizada Emulação de ponto flutuante de precisão

simples Comunicação entre tarefas e migração de

tarefasAlexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel


HellfireOS62

Periféricos mapeados em memória

Camada de abstração de hardware Permite maior

portabilidade



HellfireOS63



HellfireOS64

Temporização (Tick) e trocas de contexto



HellfireOS65

Tarefas (TASKS) Possuem o comportamento definido em um

bloco de código São adicionadas ao sistema durante a

inicialização ou execução, com parâmetros que definem seus requisitos de tempo real, tamanho da pilha, consumo de energia ...

Estruturas de controle e pilha alocadas dinamicamente



HellfireOS66

Tarefas (TASKS)



HellifreOS67

Estados das tarefas



HellfireOS68

Particionamento e mapeamento inicial Definido manualmente por grupos de tarefas

(particionamento) e posição dos grupos (mapeamento)



HellfireOS69

Comunicação entre tarefas Localmente por memória compartilhada

Mutexes, semáforos, mailboxes Remotamente por trocas de mensagem

Modelo produtor / consumidor Filas individuais para cada tarefa Primitivas send() e receive()



HellfireOS70

Migração de tarefas Uso de primitiva do OS

OS_TaskMigrate (origem, destino); Migra apenas contexto Tarefa é “morta” na origem e inicializada

com o contexto no destino



HellfireOS71

API do HellfireOS Dividida em 5 grupos

Manipulação de Tarefas Exclusão Mútua Manipulação de Memória Comunicação entre Processadores LibC



HellfireOS72

API do HellfireOS - Manipulação de Tarefas Usadas para gerenciamento das tarefas

Inclusão de tarefas no sistema Manipulação de informações de funcionamento

do sistema e de tasks Uso de CPU, energia e memória CPU em que está rodando Informação/Mudança de prioridade, período,

deadline e WCET Frequência do processador

Mudança do estado de uma tarefa Inicializar o OS



HellfireOS73

API do HellfireOS



HellfireOS74



HellfireOS75



HellfireOS76



HellfireOS77

API do HellfireOS – LibC Função básicas da

linguagem C Reimplementadas

visando otimizar seu uso para sistemas embarcados



N-MIPS78

Ferramenta N-MIPS Escrita em linguagem C, simula, em nível de

abstração mais alto que HDL, entretanto mantém precisão de ciclo

Caracterização do HW (CPUs, comunicação, filas …)

Modelos de tempo e energia Atualmente utilizada para simular a arquitetura Simula até 128 processadores



Geração de Arquitetura79

Interface gráfica pra criação de MPSoC Estrutura do tipo drag-and-drop e push-

button Geração de makefiles automatizada Caracterização individual de cada

processador do sistema Tarefas do usuário Tamanho da pilha das tarefas Tamanho do heap Tamanho do tick Ativação/desativação de drivers Politica de escalonamento



Geração da Arquitetura80






Processadores Disponíveis




Meio deComunicação




ConfiguraçãoIndividual


Interface Gráfica – Configuração do Processador



HellfireFW

Exemplos de Uso88



Site e Acesso inicial89

http://hellfire.gse.inf.br/ WebFramework

Subscribe



Exemplos de Uso90



Novo Projeto

Exemplos de Uso91



Descrição doProjeto

Nome do Projeto

Exemplos de Uso92



Criar ArquivoFonte

Exemplos de Uso93



Nome doFonte

Exemplos de Uso94

Hello World – Template da aplicação criada



Exemplos de Uso95



Habilitar Edição

Exemplos de Uso96



Linha Adicionada

Exemplos de Uso97



Salvar Alterações

Exemplos de Uso98

Hello World – Aplicação Final



Exemplos de Uso99

Arquitetura



Exemplos de Uso100



Compilar

Exemplos de Uso101



3

Resultado daCompilação

Exemplos de Uso102



30

Passo daSimulação

Unidade deSimulação

IniciarSimulação

Exemplos de Uso103



Saida Padrão

Relatórios

Log ciclo a cicloGráficos de

Funcionamento

Resumo doSistema

Exemplos de Uso104

Novo projeto



Exemplos de Uso105



Carregar Exemplo

Exemplos de Uso106



Escolher Exemplo

Exemplos de Uso107



Exemplos de Uso108



Exemplos de Uso109



Exemplos de Uso110

Contador Distribuído



Exemplos de Uso111

Contador Distribuído



Exemplos de Uso112

Migração de Tarefas



Exemplos de Uso113

Migração de Tarefas



Desafios114



Desafios115

Algoritmo de ordenação de vetores Implementar um dos algoritmos clássicos

de ordenação de vetores (Bubble sort, quick sort, …) utilizando o ambiente de desenvolvimento HellfireFW.

Algoritmo de ordenação distribuído Re-escrever o algoritmo de ordenação

implementado de modo que o mesmo funcione de modo distribuído, utilizando as primitivas de comunicação do HellfireOS.



Desafios116

Filtro Sobel Embarcado Implementar o algoritmo de detecção de

bordas Sobel. Esse algoritmo aplica dois operadores sobre cada ponto g da imagem:



Desafios117

Filtro Sobel Embarcadogx = img[y-1][x-1] +2*img[y][x-1] +

img[y+1][x-1] - img[y-1][x+1] -2*img[y][x+1] - img[y+1][x+1]

gy = img[y-1][x-1] +2*img[y-1][x] + img[y-1][x+1] - img[y+1][x-1] -2*img[y+1][x] - img[y+1][x+1]

nova_imagem[y][x] = |gx| + |gy|;Alexandra Aguiar, Sérgio Johann, Felipe Magalhães, Fabiano Hessel


Desafios118

Filtro sobel embarcado



Desafios – Filtro Sobel119

buffer[128 x 128]

novo_buffer1[64x64]

novo_buffer2[64x64]

novo_buffer3[64x64]

novo_buffer4[64x64]

exemplo para buffer1:

y = 0

x = 0

for (v = 0; v < 64; v++)

for (u = 0; u < 64; u++)

novo_buffer1[v*64+u] = buffer[(y+v)*128+(x+u)];

Para os buffers seguintes apenas adotar esses valores de y e x:

y = 0 e x = 64

y = 64 e x = 64

y = 64 e x = 0



Avaliação120

Para que possamos melhorar nossa ferramenta, por gentileza, envie sugestões/críticas/dificuldades e comentários para [email protected]

Coloque no assunto [cursojai]

Sua participação é muito importante para nós!



Considerações Finais e Agradecimentos

121

Sistemas cada vez mais presentes Inúmeros desafios no desenvolvimento

embarcado Ferramentas de apoio ao projeto

(hardware + software) são mandatórias Apresentação do sistema Hellfire

Atividades práticas com a ferramenta Agradecimentos gerais



19 e 20 de julho2011

INTRODUÇÃO AO DESENVOLVIMENTO DE

SOFTWARE EMBARCADO


http://hellfire.gse.inf.br/

19 e 20 de julho 2011 introduÇÃo ao desenvolvimento de software embarcado alexandra aguiar,...

Documents