Trabalhos Marta Becker Villamil [email protected] Trabalhos Marta Becker Villamil [email protected].
Desenvolva Sistemas Embutidos com Software Livre - Carlos A. M. dos Santos e Thiago Rafael Becker
-
Upload
tchelinux-slides -
Category
Technology
-
view
1.193 -
download
0
description
Transcript of 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.
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
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.
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
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.
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
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
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
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
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++)
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
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.”
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)
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
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
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++
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
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)
28 de março de 2009TcheLinux 2009
Dalvik VMDalvik VM
(Ou como o Google resolveu o problema das JVM para dispositivos embedded)
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 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
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
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
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
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
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
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
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
8 de novembro de 2008 38
Emulador Baseado em Hardware
Sistema Operacional
Aplicações de Controle
Malta Development Platform (MIPS) Periféricos
8 de novembro de 2008 39
Emulador Baseado em Hardware
Sistema Operacional
Aplicações de Controle
PB11MPCore (ARM) Periféricos
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ódigoObjeto
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
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
8 de novembro de 2008 44
Simulador Baseado em Software
Aplicações de Controle
DepuradorSimbólico
Código Fonte
CódigoObjeto Stubs do SO
destinoSimulação do
Hardware
Sistema Operacional
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á!)
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
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
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
8 de novembro de 2008 50
Aplicação
Simulador em Nível de Processo
Código FonteCompilador
Java
IDE (Eclipse)Stubs
MáquinaVirtual Java
Sistema Operacional
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
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
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
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ódigoObjeto
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