Desenvolva Sistemas Embutidos com Software Livre - Carlos A. M. dos Santos e Thiago Rafael Becker

28 de março de 2009 1

TcheLinux 2009TcheLinux 2009

ULBRA/GravataíULBRA/Gravataí28 de março de 200928 de março de 2009

Desenvolva Sistemas Embutidos com Desenvolva Sistemas Embutidos com Software LivreSoftware Livre

Carlos A. M. dos Santos e Thiago Rafael BeckerCarlos A. M. dos Santos e Thiago Rafael Becker

unixmania (a) gmail.comunixmania (a) gmail.comthiago.becker (a) gmail.comthiago.becker (a) gmail.com

Arquitetos de SoftwareArquitetos de SoftwareHP P&D, Porto Alegre, BrasilHP P&D, Porto Alegre, Brasil

Esta apresentação é de responsabilidade única dos seus autores e seu teor é meramente informativo e

educacional. As informações e opiniões aqui contidas não representam políticas, processos ou produtos da Hewlett-Packard Corporation nem de

suas subsidiárias.

As imagens de produtos mostradas têm finalidade apenas ilustrativa e não implicam em

recomendação dos mesmos, favorável ou contrária.

As informações contidas aqui estão sujeitas a modificações sem aviso prévio.


Algumas Definições FundamentaisAlgumas Definições Fundamentais


1. Michael Barr. “Embedded Systems Glossary”. Netrino Technical Library.

Um sistema embutido (ou sistema embarcado) é um computador de propósito específico projetado para realizar uma ou poucas funções dedicadas,[1] às vezes com restrições de tempo real. Ele é comumente parte de um dispositivo completo, incluindo

hardware e partes mecânicas.

Sistema Embutido

http://www.netrino.com/Embedded-Systems/Glossary


Máquina Virtual

Uma máquina virtual é “uma duplicata isolada eficiente de uma máquina real”[1] . O uso atual inclui

máquinas virtuais que não têm correspondência direta com qualquer hardware real.

1. Gerald J. Popek and Robert P. Goldberg (1974). "Formal Requirements for Virtualizable Third Generation Architectures". Communications of the ACM 17 (7): 412 –421.


Simulador

Uma simulação ou modelo computacional é um programa, ou rede de computadores, que tenta

simular um modelo abstrato de um sistema particular. Simulações são úteis para compreender a

operação daqueles sistemas, ou observar seu comportamento.

Exemplo: simulação de uma plataforma de petróleo


Emulador

Um emulador duplica (emula) as funções de um sistema usando um sistema diferente, de

modo que o segundo sistema se comporta como o primeiro (ou parece fazê-lo). Este

foco em reprodução exata do comportamento externo contrasta com outras formas de

simulação computacional, que pode ser um modelo abstrato do sistema simulado.


Processador “lento” (ARM, ColdFire, SuperH, versões embedded de MIPS, x86, PowerPC ou SPARC)

Sistema Operacional específico (LynxOS, QNX, *Linux, *BSD, RTEMS, Windows CE, Android, nenhum)

Pouca memória: RAM, flash (sem disco)

Arquitetura simplificada: custo e manutenção baixos CPUs de 4, 8 e 16 bits ainda são usadas!

Desempenho cŕitico: roteador, controladora de disco

Interatividade limitada: sem teclado ou vídeo

Características Comuns


Custo baixo: destinam-se à produção em massa

Alta confiabilidade (exemplo: marcapasso cardíaco) Sair de fábrica “pronto”: atualização em campo é cara

Desempenho estável no tempo

Ficam ligados por longos períodos

Interrupções do serviço geram transtornos

Disponibilidade: usuários esperam reposta imediata

Subsistemas não devem atrapalhar uns aos outros

Requisitos comuns

8 de novembro de 2008 11

Alguns Exemplos


Estrutura Típica

Hardware

Sistema Operacional/Drivers

Aplicações

Periférico Periférico

O que pode ser simulado ou emulado

Periféricos: software + hardware com a mesma interface física

Hardware: equivalente instalado na estação de desenvolvimento ou emulação por software

SO/Drivers: equivalentes do SO da estação, substitutos ou stubs

Aplicação (parte dependente da arquitetura): substitutos ou stubs


Como Programar Sistemas Como Programar Sistemas EmbutidosEmbutidos


Vocês realmenteesperam desenvolver

qualquer coisa...

nisto aqui?


Compilação Cruzada

Compila-se em uma arquitetura; executa-se em outra GCC suporta 53 arquiteturas (na última contagem)

Vantagens Ambiente: a máquina destino nem suporta um

compilador

Rapidez: a máquina origem é muito mais rápida do que a destino (dez a mil vezes mais, tipicamente)

Desvantagens Teste e depuração podem ser trabalhosos

Cada compilação precisa ser instalada antes de testar


Instalação

Programação eCompilação

Execução

Compilação cruzada


Melhoria de Desempenho e EspaçoMelhoria de Desempenho e Espaço(para C e C++)(para C e C++)

28 de março de 2009TcheLinux 2009

Objetivos

Reduzir o tamanho

Pouca memória

Pouco espaço de armazenamento

Melhorar o desempenho

Processador “lerdo” Tempo de resposta

é fator crítico


Como Reduzir Espaço

Usar boas técnicas de programação

Algoritmos e estruturas de dados eficientes

Minimizar a repetição de código (com funções, não com macros)

Reduz a repetição de código objeto

Se impactar a performance, usar inline (descrito a seguir)

“Escreva seu programa da maneira mais direta possível, e só então preocupe-se com as otimizações.”


Como Melhorar o Desempenho

Reduzir o número de trocas de contexto

Reduzindo invocações de métodos/funções

Macros? Não! Declarar funções como static inline

Declarar num header, se for usada em mais de um módulo

Aumenta o tamanho do código, mas melhora a performance

Mantém as referências para debug (macros não aparecem no debugger)


Profiling de execução (gprof)

Ferramenta de profiling em tempo de execução

Para usá-la, o código deve ser compilado com

gcc -g -pg

O relatório gerado após a execução da ferramenta mostra

quais funções foram chamadas mais vezes

quais consumiram mais tempo

o call graph de cada caminho de execução


Como Usar a Otimização do GCC

-O3 ou -Os

Evitar -ansi (c89), que impede certas otimizações (inline)

-fomit-frame-pointer: omite ponteiros para stack-frame

Resulta em uma invocação de método “leve”

Pode impossiblitar a depuração do código (x86)

-finline-functions: executa o inlining de funções


Dicas para Código em C++

Evitar ao máximo o uso de C++

Se for inevitável...

Evitar passagem de argumentos grandes por valor A pilha é menor nos ambientes embedded

Evitar templates (são piores do que macros)

Evitar exceções (código maior e mais lento)

Compilar código C com gcc e código C++ com g++


libc para Mundos Pequenos

A libc provê funcionalidade básica para programas em C

stdio, stdlib, string, tz, unistd, zoneinfo, inet, crt

dl – carga dinamica de bibliotecas

m – funções matemáticas

thread

C++ (rtti, etc.)

Nem tudo isso é necessário num sistema embutido


Exemplos de libc Miniaturizadas

µControler libc – µClib (o nome já diz o propósito :)

Suporta 12 arquiteturas (inclui “MMU-less processors”)

http://www.uclibc.org

Bionic – “core system support” para o Android

Portada do NetBSD para operar adequadamente no Linux

Alteração nas chamadas de rotina (pilha->registrador)

Alguns IOCTLS com mnemônicos diferentes

Atualmente suportada em x86 e ARM(v5)

http://www.uclibc.org/


Dalvik VMDalvik VM

(Ou como o Google resolveu o problema das JVM para dispositivos embedded)


Problema

Virtual machines são desenhadas para emular processadores

Opcodes da VM imitam opcodes do processador Baixa densidade semântica dos opcodes Operações pouco otimizadas

Alto consumo de recursos (energia, memória e processador) = impacto na experiêcia de uso


Energia e Processamento

Fortemente ligados e proporcionais

A maior parte da execução de uma VM é dentro do laço do interpretador

Para entender o problema, devemos olhar para o modo como as intruções são despachadas

Máquina de pilhas

Cada operação encontra seus valores na pilha

Ciclos de carga e descarga de valores da pilha


Energia e Processamento (Dalvik)

Contração de operações comuns para um único opcode

Reduz os despachos dos opcodes

Por exemplo, prenchimento de arrays

Operações semanticamente densas

Mais de uma operação de processador por opcode

Além da reduzir processamento, reduz o tamanho do JAR

Máquina de registradores

Operandos estão em um offset a partir de um ponteiro base

Aumento de performance, redução de energia


Memória

Arquivos de classe são grandes e mal organizados

Constant pool mal organizado (tag de tipo + dado)

11 tipos distintos

Arquivos JAR são ainda piores!

Repetição de valores nos constant pools das classes contidas no JAR


Threads e Garbage Collection

Cada nova “aplicação” rodando na VM é na verdade uma thread nova executando na mesma VM

Memória é recuperada apenas nos ciclos de Garbage Collection, e não automaticamente com a finalização de uma aplicação

Requer a implementação de mecanismos de isolamento


Memória (Dalvik)

Separação das constantes em pools por tipo

Tipos implícitos, remove as tags de tipo do constant pool

Evita repetições de valores entre classes dentro de um mesmo dex (formato de arquivo adotado pela dalvik)

Aplicações rodam em processos separados

Ao término de uma aplicação, toda a sua memória é devolvida ao sistema

Aproveita os mecanismos de isolamento do sistema operacional


Resultados

As modificações da dalvik permitem a redução em até 65% do tamanho das aplicações em java, e ainda permitem uma melhoria significativa de performance

A dalvik foi feita usando o que já existe, adaptado a um novo cenário de uso


Como Testar Sistemas EmbutidosComo Testar Sistemas Embutidos


Compilação e Teste

Parte dependente do hardware Geralmente é código “nativo” (C, C++, Assembly)

Editado e compilado na estação de desenvolvimento

Testado no hardware de destino, simulador ou emulador

Parte independente do hardware Código nativo (C, C++)

Código interpretado (Java, PHP, TCL, Lua, C#)

Pode ser testado na estação de desenvolvimento, simulador, emulador ou hardware de destino


Problemas de Testar no Hardware

Protótipos são caros e difíceis de obter

Muito mais caros do que modelos de produção em massa

Outros custos: transporte, taxas, manutenção, suprimentos

Testes em hardware são difíceis de automatizar

Compilar e instalar uma nova versão pode demorar horas

O ambiente de execução é restritivo

Não há como rodar um depurador simbólico


Exemplo de EmuladorExemplo de Emulador


Emulador Baseado em Hardware

Sistema Operacional

Aplicações de Controle

Malta Development Platform (MIPS) Periféricos


Emulador Baseado em Hardware

Sistema Operacional


PB11MPCore (ARM) Periféricos


Depuração no Emulador

Sistema Operacional


Agente de Depuração Remota (gdbserver)

Console

Sistema Operacional

Depurador (gdb)

Código Fonte

CódigoObjeto


Vantagens do Emulador

Custo baixo (pouco mais do que um PC)

Custo operacional baixo (comparado a um protótipo)

Ocupa menos espaço e consome menos energia (às vezes)

Manutenção muito mais fácil

Facilita a execução de testes

Permite usar scripts para emular operações no equipamento

Emulador pode ser controlado remotamente

Equivale (assemelha-se muito) ao equipamento real

Está disponível antes do equipamento real


Desvantagens do Emulador

A emulação nem sempre é completa e correta

Desenvolvimento do emulador em si pode ser oneroso

Não há economia de escala

Há muitos detalhes a tratar, o que complica o software

O hardware está sujeito a defeitos físicos

Depuração é quase tão difícil quanto na máquina real


Exemplo de SimuladorExemplo de Simulador


Simulador Baseado em Software


DepuradorSimbólico

Código Fonte

CódigoObjeto Stubs do SO

destinoSimulação do

Hardware

Sistema Operacional


Vantagens do Simulador

Custo quase nulo: tudo é feito por software

Execução imediata, pois dispensa instalação

Disponibilidade imediata

Cada desenvolvedor tem sua própria estação de trabalho

Depuração é local, dispensando conexão via rede

Execução local é mais rápida (processador mais potente)

Quase não há limite para o que se possa simular

Sonho do desenvolvedor: emulação total por software em máquinas virtuais (estamos quase lá!)


Desvantagens do Simulador

É menos fidedigno que o emulador

O hardware não é emulado: forja-se resultados via “stubs”

O sistema operacional não é emulado: usa-se o sistema operacional local, com “stubs” de adaptação

Diferenças arquiteturais influenciam nos resultados

O código precisa de “bindings” para todas as variantes


Emulador em Máquina VirtualEmulador em Máquina Virtual


Em nível de processo

O hóspede é um único processo de usuário

A máquina virtual provê uma ABI* para o processo

Em nível de sistema

Muitos processos de usuário podem coexistir

A máquina virtual provê um ambiente completo

* Application Binary Interface

Tipos de Virtualização

8 de novembro de 2008TcheLinux 2008

Virtualização em Nível de Processo

Hardware

SistemaOperacional

Software deVirtualização

ProcessoAplicativoHóspede

Runtime

Hospedeiro

MáquinaVirtual

ProcessoAplicativo


Aplicação

Simulador em Nível de Processo

Código FonteCompilador

Java

IDE (Eclipse)Stubs

MáquinaVirtual Java

Sistema Operacional


Vantagens do Eclipse

Desenvolvimento muito rápido

Execução imediata

Depuração fácil (usando a interface do Eclipse)

Funciona em qualquer ambiente em que haja um JDK


Desvantagens do Eclipse

Serve apenas para código Java

Não usa a VM real (J2ME, SuperWaba, Dalvik, etc.)

Diferenças de API precisam ser observadas

Alguns comportamentos são muito diferentes

Gerência de memória no sistema destino e no PC

Acesso à rede no sistema destino e no PC

8 de novembro de 2008TcheLinux 2008

Virtualização em Nível de Sistema

Hardware

Software deVirtualização Máquina

Virtual

ProcessoAplicativo

Hóspede

VMM

Hospedeiro

SistemaOperacional

ProcessoAplicativo

SistemaOperacional


Máquina Virtual(QEMU/GXemul)

Depuração no Emulador

Sistema Operacional


Agente de Depuração Remota (gdbserver)

Sistema Operacional

Depurador (gdb)

Código Fonte

CódigoObjeto


Tendências Futuras

Limitar o uso de emuladores assistidos por hardware

Preferir emuladores por software e máquinas virtuais

Grande integração entre o ambiente de desenvolvimento e a simulação/emulação

Objetivos mestres

Ajudar o desenvolvedor a fazer seus testes unitários

Executar testes automáticos, continuamente

Desenvolvimento rápido, com menor número de defeitos

Produtos melhores, lançados mais depressa


Perguntas?Perguntas?


Muito Obrigado!Muito Obrigado!

unixmania (a) gmail.comunixmania (a) gmail.comthiago.becker (a) gmail.comthiago.becker (a) gmail.com

Technology

Desenvolva Sistemas Embutidos com Software Livre - Carlos A. M. dos Santos e Thiago Rafael Becker