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.

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

11. 8 de novembro de 2008 11
Alguns Exemplos

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

56. 28 de março de 2009 56
Perguntas?Perguntas?

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