O documento discute o desenvolvimento de sistemas embutidos com software livre. Apresenta definições de sistemas embutidos, máquinas virtuais e emuladores. Também fornece dicas sobre como programar, compilar, otimizar desempenho, reduzir espaço e testar sistemas embutidos.
Desenvolva Sistemas Embutidos com Software Livre - Carlos A. M. dos Santos e Thiago Rafael Becker
1. 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
2. Desenvolva Sistemas Embutidos comDesenvolva 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.com
thiago.becker (a) gmail.comthiago.becker (a) gmail.com
Arquitetos de SoftwareArquitetos de Software
HP P&D, Porto Alegre, BrasilHP P&D, Porto Alegre, Brasil
3. 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.
4. 28 de março de 2009 4
Algumas Definições FundamentaisAlgumas Definições Fundamentais
5. 28 de março de 2009 5
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
6. 28 de março de 2009 6
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.
7. 28 de março de 2009 7
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
8. 28 de março de 2009 8
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.
9. 28 de março de 2009 9
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
10. 28 de março de 2009 10
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
12. 28 de março de 2009 12
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
13. 28 de março de 2009 13
Como Programar SistemasComo Programar Sistemas
EmbutidosEmbutidos
14. 8 de novembro de 2008 14
Vocês realmente
esperam desenvolver
qualquer coisa...
nisto aqui?
15. 28 de março de 2009 15
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
16. 8 de novembro de 2008 16
Instalação
Programação e
Compilação
Execução
Compilação cruzada
17. 28 de março de 2009 17
Melhoria de Desempenho e EspaçoMelhoria de Desempenho e Espaço
(para C e C++)(para C e C++)
18. 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
19. 28 de março de 2009TcheLinux 2009
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.”
20. 28 de março de 2009TcheLinux 2009
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)
21. 28 de março de 2009TcheLinux 2009
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
22. 28 de março de 2009TcheLinux 2009
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
23. 28 de março de 2009TcheLinux 2009
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++
24. 28 de março de 2009TcheLinux 2009
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
25. 28 de março de 2009TcheLinux 2009
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)
26. 28 de março de 2009TcheLinux 2009
Dalvik VMDalvik VM
(Ou como o Google resolveu o problema das
JVM para dispositivos embedded)
27. 28 de março de 2009TcheLinux 2009
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
28. 28 de março de 2009TcheLinux 2009
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
29. 28 de março de 2009TcheLinux 2009
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
30. 28 de março de 2009TcheLinux 2009
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
31. 28 de março de 2009TcheLinux 2009
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
32. 28 de março de 2009TcheLinux 2009
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
33. 28 de março de 2009TcheLinux 2009
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
34. 28 de março de 2009 34
Como Testar Sistemas EmbutidosComo Testar Sistemas Embutidos
35. 28 de março de 2009TcheLinux 2009
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
36. 28 de março de 2009 36
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
37. 28 de março de 2009 37
Exemplo de EmuladorExemplo de Emulador
38. 8 de novembro de 2008 38
Emulador Baseado em Hardware
Sistema Operacional
Aplicações de
Controle
Malta Development Platform (MIPS) Periféricos
39. 8 de novembro de 2008 39
Emulador Baseado em Hardware
Sistema Operacional
Aplicações de
Controle
PB11MPCore (ARM) Periféricos
40. 8 de novembro de 2008 40
Depuração no Emulador
Sistema Operacional
Aplicações de Controle
Agente de Depuração
Remota (gdbserver)
Console
Sistema Operacional
Depurador (gdb)
Código
Fonte
Código
Objeto
41. 28 de março de 2009 41
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
42. 28 de março de 2009 42
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
43. 28 de março de 2009 43
Exemplo de SimuladorExemplo de Simulador
44. 8 de novembro de 2008 44
Simulador Baseado em Software
Aplicações de Controle
Depurador
Simbólico
Código
Fonte
Código
Objeto Stubs do SO
destino
Simulação do
Hardware
Sistema Operacional
45. 28 de março de 2009 45
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á!)
46. 28 de março de 2009 46
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
47. 28 de março de 2009 47
Emulador em Máquina VirtualEmulador em Máquina Virtual
48. 28 de março de 2009TcheLinux 2009
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
49. 8 de novembro de 2008TcheLinux 2008
Virtualização em Nível de Processo
Hardware
Sistema
Operacional
Software de
Virtualização
Processo
AplicativoHóspede
Runtime
Hospedeiro
Máquina
Virtual
Processo
Aplicativo
50. 8 de novembro de 2008 50
Aplicação
Simulador em Nível de Processo
Código
FonteCompilador
Java
IDE (Eclipse)Stubs
Máquina
Virtual Java
Sistema Operacional
51. 28 de março de 2009 51
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
52. 28 de março de 2009 52
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
53. 8 de novembro de 2008TcheLinux 2008
Virtualização em Nível de Sistema
Hardware
Software de
Virtualização Máquina
Virtual
Processo
Aplicativo
Hóspede
VMM
Hospedeiro
Sistema
Operacional
Processo
Aplicativo
Sistema
Operacional
54. 8 de novembro de 2008 54
Máquina Virtual
(QEMU/GXemul)
Depuração no Emulador
Sistema Operacional
Aplicações de Controle
Agente de Depuração
Remota (gdbserver)
Sistema Operacional
Depurador (gdb)
Código
Fonte
Código
Objeto
55. 28 de março de 2009 55
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
57. 28 de março de 2009 57
Muito Obrigado!Muito Obrigado!
unixmania (a) gmail.comunixmania (a) gmail.com
thiago.becker (a) gmail.comthiago.becker (a) gmail.com