Embed Size (px)
Citation preview
UNIOESTE – Universidade Estadual do Oeste do Paraná
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
Colegiado de Ciência da Computação
Curso de Bacharelado em Ciência da Computação
Avaliação de Desempenho e Potência de Aplicações Embarcadas em Plataformas Heterogêneas
Alexandre Augusto Giron
CASCAVEL
2012
ALEXANDRE AUGUSTO GIRON
AVALIAÇÃO DE DESEMPENHO E POTÊNCIA DE APLICAÇÕES EMBARCADAS EM PLATAFORMAS HETEROGÊNEAS
Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação, do Centro de Ciências Exatas e Tecnológicas da Universidade Estadual do Oeste do Paraná - Campus de Cascavel
Orientador: Marcio Seiji Oyamada
CASCAVEL
2012
ALEXANDRE AUGUSTO GIRON
AVALIAÇÃO DE DESEMPENHO E POTÊNCIA DE APLICAÇÕES EMBARCADAS EM PLATAFORMAS HETEROGÊNEAS
Monografia apresentada como requisito parcial para obtenção do Título de Bacharel em Ciência da
Computação, pela Universidade Estadual do Oeste do Paraná, Campus de Cascavel, aprovada pela Comissão
formada pelos professores:
Prof. Marcio Seiji Oyamada (Orientador)
Colegiado de Ciência da Computação,
UNIOESTE
Prof. Adair Santa Catarina
Colegiado de Ciência da Computação,
UNIOESTE
Prof. Edmar Bellorini
Colegiado de Ciência da Computação,
UNIOESTE
Cascavel, 17 de Outubro de 2012.
DEDICATÓRIA
Dedico este trabalho à minha família, que
sempre se fez presente e nunca mediu esforços
em me ajudar. Dedico também à minha querida
namorada Francielle Soder, sempre muito
amável e companheira, e a todos os meus
parentes e amigos que contribuiram nesta
jornada.
“Você não é amado porque você é bom, você é
bom porque é amado”
______________________________________
Nelson Mandela
“Não é preciso que a bondade se mostre; mas
sim é preciso que se deixe ver”
______________________________________
Platão
AGRADECIMENTOS
Agradeço aos meus pais, Maria Cristina Nedel Giron e Paulo Gilberto Giron, por fornecerem
excelentes condições para que eu pudesse realizar este curso. Graças a eles, tive (e ainda tenho!) uma
vida ótima, e agradeço ao meu irmão Guilherme Eduardo Giron, pela sua alegria espontânea e pelos
bons momentos compartilhados.
Agradeço também à minha namorada Francielle Cristina Soder, por todo o amor e carinho que
me deu, ajudando-me em vários momentos que precisei. Seu apoio incondicional e principalmente os
maravilhosos momentos vividos jamais serão esquecidos.
Agradeço aos meus parentes, que sempre acreditaram em mim e também me forneceram
auxílio em diversos momentos. Agradeço a todos os meus primos e primas, em especial ao Lucas
Henrique Giacomini, por estar sempre por perto, e ao João Carlos Pagnoncelli, pelos bons momentos e
festas em que estivemos. Agradeço ao meu amigo Julian Weber, pelas diversas “caronas” fornecidas
em muitas das incontáveis vezes que percorri o trajeto Marechal Cândido Rondon – Cascavel.
Agradeço de forma especial ao meu orientador, Marcio Seiji Oyamada, por me orientar três
anos nos trabalhos de Iniciação Científica, no estágio supervisionado e neste trabalho de conclusão de
curso, proporcionando um vasto aprendizado que vou carregar para minha vida profissional.
Agradeço a todos os meus amigos e companheiros de curso, em especial aos colegas Cauê
Schuch Lopes e Diego Robles Viera Ribeiro por contribuir e ajudar nos trabalhos e por participar dos
bons e maus momentos do curso. Além disso, agradeço a todos os demais colegas de turma, amigos e
companheiros de curso pelo apoio e pelo companheirismo.
Também agradeço à UNIOESTE, com todo o seu corpo docente e técnico-administrativo, pela
oportunidade de um curso desta magnitude.
Enfim, agradeço a todos os que me auxiliaram a vencer esta longa jornada. Muito obrigado.
Lista de Figuras2.1: Funcionalidades Samsung SmartTV ES8000. Extraído de [17]........................................................................7
3.1: Diagrama de blocos funcionais do OMAP 3530 [27]......................................................................................12
3.2: Foto da Placa BeagleBoard-xM, Revisão C. Extraído de [15]........................................................................16
3.3: Exemplo do problema de alinhamento de bytes..............................................................................................23
3.4: Etapas do processo da decodificação de vídeos H.264 [43]...........................................................................26
3.5: Gráfico da utilização do processador ARM, na decodificação H.264 efetuada pelo DSP..............................29
3.6: Esquemático do circuito de medição de consumo de potência da BeagleBoard-xM [48]...............................30
4.1: Foto da decolagem do Tiriba [51]....................................................................................................................33
4.2: Diagrama de blocos do Tiriba [51]..................................................................................................................33
4.3: Foto da placa controladora ATMega2560 [52]................................................................................................35
4.4: Foto da placa IMU Shield [52].........................................................................................................................35
4.5: Esquemático da Arquitetura do ArduPlane-SITL [12]....................................................................................37
4.6: Screenshot da simulação de um voo através do APM Planner para visualização do voo...............................38
4.7: APM Planner utilizado para criação de uma rota para um voo simulado........................................................39
4.8: Esquemático da organização do ambiente de simulação.................................................................................40
4.9: Esquemático do fluxo de execução de uma simulação completa....................................................................41
4.10: Planos de voo das missões 2 e 3, utilizadas na análise do funcionamento do ArduPlane.............................42
4.11: Plano de voo utilizado para as avaliações de desempenho e potência do ArduPlane....................................43
4.12: Visualização da rota percorrida pelo VANT na simulação da missão 1........................................................44
4.13: Trecho do código-fonte do ArduPlane...........................................................................................................45
4.14: Gráfico da utilização do processador ARM, na execução do ArduPlane na BeagleBoard-xM.....................46
vi
Lista de Tabelas
2.1 Áreas chave e exemplos de sistemas embarcados.........................................................................................8
3.1 Exemplos de Plataformas e suas características .........................................................................................11
3.2 Resumo dos componentes da placa de desenvolvimento BeagleBoard-xM [15]........................................15
3.3 Dispositivos que utilizam processador ARM..............................................................................................17
3.4 Funcionalidades do processador DSP TMS320C64x+ e descrição.............................................................20
4.1 Informações sobre o comportamento dos voos simulados das missões de teste.........................................45
vii
Lista de Abreviaturas e Siglas
MPSoC Multiprocessor System-on-Chip
VANT Veículo Aéreo Não Tripulado
AGC Apollo Guidance Computer
MIT Massachusetts Institute of Tecnology
IDC International Data Corporation
GPS Global Positioning System
USB Universal Serial Bus
ARM Advanced Risc Machine
DSP Digital Signal Processor
VGA Video Graphics Array
RISC Reduced Instruction Set Computing
DSL Digital Subscriber Loop
MIPS Million Instructions Per Second
VLIW Very Long Instruction Word
MPEG Moving Picture Experts Group
QCIF Quarter Commom Intermediate Format
HD High Definition
CPU Central Processing Unit
INCT-SEC Instituto Nacional de Ciência e Tecnologia em Sistemas Embarcados Críticos
UDP User Datagram Protocol
TCP Transmission Control Protocol
viii
Sumário
Lista de Figuras vi
Lista de Tabelas vii
Lista de Abreviaturas e Siglas viii
Sumário ix
Resumo xi
1 Introdução 1
1.1Sistemas Embarcados ....................................................................................................................................1
1.2 Histórico........................................................................................................................................................2
1.3 Justificativa, Objetivos e Organização do Texto...........................................................................................3
2 Características dos Sistemas Embarcados 5
2.1 Características comuns aos Sistemas Embarcados........................................................................................5
2.2 Áreas chave de utilização de sistemas embarcados.......................................................................................7
2.3 Características de Projeto de sistemas embarcados.......................................................................................8
3 Desenvolvimento em Plataformas Heterogêneas 10
3.1 Características e Vantagens da utilização de MPSoC.................................................................................10
3.1.1 Ferramentas........................................................................................................................................12
3.2 Plataforma utilizada: BeagleBoard-xM.......................................................................................................14
3.2.1 Processador ARM Cortex-A8.............................................................................................................17
3.2.2 Processador DSP ...............................................................................................................................18
3.3 Portabilidade de aplicações.........................................................................................................................21
3.3.1 Problemas de alinhamento de bytes em processadores ARM............................................................22
3.4 Análise do desempenho do H.264 na BeagleBoard-xM..............................................................................25
3.4.1 O padrão de vídeos H.264..................................................................................................................25
3.4.2 Resultados Obtidos na análise............................................................................................................28
4 Estudo de Caso 32
4.1 Contextualização: VANTs ..........................................................................................................................32
4.2 ArdupilotMega: Plataforma Arduino para VANTs.....................................................................................34
4.3 ArduPlane Software In The Loop (SITL)....................................................................................................36
4.4 Avaliação do SITL-Arduplane na BeagleBoard-xM).................................................................................39
4.4.1 Avaliação do Funcionamento.............................................................................................................42
ix
4.4.2 Avaliação do Desempenho.................................................................................................................46
4.4.3 Avaliação do consumo de Potência....................................................................................................48
5 Conclusões e Trabalhos Futuros 50
5.1 Conclusões...................................................................................................................................................50
5.2 Trabalhos Futuros........................................................................................................................................52
A Arquivos do Planejamento do Voo Simulado 53
B Arquivo resultado GPROF 54
Glossário 71
Referências Bibliográficas 72
x
Resumo
No desenvolvimento de sistemas embarcados, os requisitos que determinam o seu sucesso no mercado
devem ser considerados, tais como desempenho, consumo de potência, custo, design. De modo geral,
as arquiteturas MPSoC (Multiprocessor System-on-Chip) heterogêneas, que integram um ou mais
processadores de diferentes propósitos, respondem bem aos requisitos desses sistemas, com eficiência
no processamento de diversas tarefas, como a decodificação de áudio e vídeo. No entanto, nos
sistemas embarcados críticos, outro requisito de fundamental importância é o de tolerância a falhas.
Um exemplo de um sistema desse tipo é o VANT (Veículo Aéreo Não Tripulado), onde falhas podem
acarretar consequências trágicas. Assim, é importante que sejam feitos processos para validar esses
sistemas, como, por exemplo, a avaliação de desempenho. O objetivo desse trabalho foi realizar
análises de desempenho e consumo de potência, bem como o funcionamento na simulação de um
VANT em operação, através do software ArduPlane. A arquitetura utilizada como base nessa
simulação foi a placa de desenvolvimento BeagleBoard-xM, que contém a plataforma MPSoC DM
3730. A execução do ArduPlane na simulação de um VANT em missões distintas nesta arquitetura
obteve um desempenho satisfatório, em termos de utilização de processador, e o consumo de potência
pelo DM3730 da placa, foi estimado em 2,38 W, em média. O comportamento do voo simulado do
VANT também foi verificado, com a utilização do software APM Planner.
Palavras-chave: Sistemas Embarcados Críticos, Desempenho, Consumo de potência, BeagleBoard-
xM, MPSoC heterogêneo, simulação, VANT.
xi
Capítulo 1
Introdução
1.1 Sistemas Embarcados
Do inglês “Embedded Systems”, os sistemas embarcados são sistemas computacionais que
processam informação e são incorporados em um produto maior [1]. Uma segunda definição
para o termo, mais informal, é a definição de Jakob Engblom, “Um computador que não
parece ser um computador” [2].
Além disso, no passado, tinha-se o conceito de que os sistemas embarcados são utilizados
para finalidades específicas. Por exemplo, antigamente os aparelhos celulares eram utilizados
apenas para realizar ligações. Com o surgimento dos smartphones, esse conceito se revela
obsoleto. Alguns sistemas embarcados atualmente são capazes de realizar diversas tarefas que
torna a definição de Engblom, embora confusa, coerente.
Vários são os exemplos desses sistemas que estão cada vez mais presentes no cotidiano das
pessoas. Os mais comuns são telefones celulares, DVD players, eletrodomésticos como
aparelhos micro-ondas, sistemas de controle automotivos (como injeção eletrônica, freios
ABS) e sistemas em aviônicos (como sistemas de navegação e comunicação, sistemas de
controle de voo).
Entretanto, a crescente necessidade de desempenho aliada à limitação no consumo de
potência impacta no esforço de desenvolvimento dos sistemas embarcados. Ao contrário dos
sistemas para desktop, esses sistemas são construídos pela integração otimizada de hardware e
software, fazendo-se necessário considerar os requisitos de consumo de potência bem como o
de desempenho da aplicação.
Atualmente, encontram-se várias soluções contendo vários processadores em um único
chip, denominadas MPSoC (Multiprocessor System-on-Chip) [3]. Muitas aplicações já
utilizam estes processadores, principalmente aplicações multimídia, destacando-se a
1
decodificação de vídeos [4]. Como exemplos de arquiteturas de MPSoCs temos: TI OMAP
[5], Philips Nexperia [6], Intel IXP2850 Network Processor [7], ST Nova A9500 [8], entre
outros.
1.2 Histórico
De acordo com [9] podemos resumir o histórico dos sistemas embarcados. Com relação ao
surgimento desses sistemas, o dispositivo considerado como o primeiro sistema embarcado
foi o Apollo Guidance Computer (AGC), desenvolvido pelo Massachusetts Institute of
Tecnology (MIT), no início da década de 1960.
O AGC foi considerado como primeiro sistema embarcado por ser o primeiro a se utilizar
de circuitos integrados, cuja CPU trabalhava a velocidade de 1,024 MHz (aproximadamente
1000 vez mais lento que um computador comum hoje). Esta velocidade era dividida por dois
para fazer a comunicação com os outros sistemas da nave Apollo que trabalhavam a 512 KHz.
A partir de 1960, houve um salto na utilização dos sistemas embarcados, devido
principalmente ao barateamento da produção dos circuitos integrados. Entretanto, ainda na
década de 1980, estes microprocessadores/microcontroladores necessitavam de vários de
componentes externos para funcionar.
Terminando a década de 1980, quando o custo de um microcontrolador caiu abaixo de um
dólar americano, os sistemas embarcados começaram a substituir componentes físicos como
potenciômetros e capacitores variáveis.
Juntamente com a popularização dos telefones celulares, em meados de 1990, os sistemas
embarcados começaram a fazer parte da vida das pessoas. Em 1996 foi estimado que, em
média, um cidadão americano entrava em contato com 60 microprocessadores por dia [10].
Um fato que contribuiu significativamente na popularização dos sistemas embarcados foi a
cultura da Eletrônica de Consumo1. Nos Estados Unidos, de acordo com uma pesquisa
realizada pela CEA (Consumer Eletronics Association), as vendas de produtos eletrônicos
alcançaram aproximadamente 181 bilhões de dólares, no ano de 2008. Além disso, à medida
que novos sistemas embarcados eram produzidos, agregando novas e diferentes finalidades,
seus lançamentos eram acompanhados de sucessos de venda.
1Eletrônica de Consumo: é um termo designado a qualquer equipamento eletrônico de uso pessoal, geralmente com intuito de prover entretenimento, comunicações e produtividade de trabalho. Alguns exemplos desses equipamentos são os computadores pessoais, tocadores MP3, calculadoras, GPS, entre outros..
2
Um exemplo disso pode ser visualizado em um estudo do International Data Corporation
(IDC), estudo no qual é destacado que as vendas de smartfones no Brasil aumentaram no ano
de 2011 em torno de 84%, comparado ao ano de 2010 [11].
Nos dias atuais pode-se entrar em contato com diversos sistemas embarcados, como ao
realizar uma ligação através de um aparelho celular, ouvir música em um player mp3,
cozinhar um alimento em um aparelho micro-ondas, conduzir um carro moderno, viajar de
avião, entre outras.
1.3 Justificativa, Objetivos e Organização do Texto
Como descrito anteriormente, a importância dos sistemas embarcados aumentou
significativamente, tendo em vista sua popularização causada por vários fatores, entre eles a
redução de custos de produção e a grande quantidade de áreas chave nas quais podem atuar.
Essas áreas são detalhadas na seção 2.3.
Com relação ao desenvolvimento desses sistemas, devem ser consideradas as dificuldades
no processo de construção de um sistema desse tipo, pois vários são os requisitos a serem
atendidos, necessitando integrar de forma otimizada hardware e software.
Assim, os objetivos gerais desse trabalho são destinados a mostrar as características dos
sistemas embarcados, apresentar os requisitos do desenvolvimento desses sistemas e compará-
los com o desenvolvimento para sistemas desktop. Além disso será apresentada uma placa de
desenvolvimento para sistemas embarcados, a placa BeagleBoard-xM[15]. Serão apresentadas
as formas de desenvolvimento e as ferramentas existentes.
Dois estudos de caso distintos foram abordados neste trabalho. A decodificação de vídeos
do padrão H.264 [18] foi avaliada na placa de desenvolvimento BeagleBoard-xM, na forma
de um estudo de caso inicial deste trabalho, abordando métricas para a avaliação dos
requisitos de desempenho e consumo de potência.
A avaliação de um VANT (Veículo Aéreo Não Tripulado) [16] em um ambiente de
simulação foi desenvolvida neste trabalho, como sendo o principal estudo de caso, porém
reutilizando as mesmas métricas usadas no primeiro estudo deste trabalho. O software
ArduPlane [12], que permite a criação de rotas e o voo autônomo de aeromodelos, foi
utilizado como base desse estudo de caso. O ArduPlane executa originalmente em uma
plataforma de hardware Arduino [13] com alguns periféricos como acelerômetros, barômetro
e GPS. O ArduPlane foi utilizado neste trabalho com o objetivo específico de simular um voo
3
autônomo, através da execução desse software na plataforma BeagleBoard, avaliando o
desempenho bem como o comportamento da simulação. Para isso, a compilação Software In
The Loop (SITL) do código do ArduPlane foi usada, já que ela simula os periféricos (sensores
e atuadores) que seriam utilizados em um VANT real, no nível de registradores. Isso significa
que os drivers dos componentes usados em um voo real (como acelerômetros e GPS)
funcionam da mesma forma no simulador.
A estrutura de capítulos compõem o texto da seguinte forma: o Capítulo 2 apresenta a
classificação e as características comuns desses sistemas; já o Capítulo 3 descreve os
requisitos e as diferenças sobre o desenvolvimento de sistemas embarcados com relação ao
desenvolvimento desktop; o estudo de caso deste trabalho, com a intenção de avaliar a
utilização do ArduPlane [12] na plataforma Beagleboard-xM [15], simulando um VANT em
operação, está detalhado no quarto capítulo; por fim, os resultados obtidos, conclusões e
trabalhos futuros são apresentados no quinto capítulo.
4
Capítulo 2
Características dos Sistemas Embarcados
2.1 Características comuns aos Sistemas Embarcados
A vasta gama de aplicações dos sistemas embarcados causa uma série de diferenças entre
eles, tanto quanto à finalidade, design, tamanho, entre outros. Entretanto, segundo [1], os
sistemas embarcados possuem características comuns, as quais são listadas a seguir:
1. Interação com o meio externo: normalmente os sistemas embarcados interagem
com o ambiente físico através de sensores, para coletar informações sobre esse
ambiente. Além disso, a maioria desses sistemas se utilizam de uma interface com
o usuário diferente das utilizadas em um computador de propósito geral,
considerada como interface dedicada. Assim, é incomum um sistema embarcado
possuir teclado e uma tela de alta resolução, por exemplo.
2. Segurança/Confiabilidade: é uma característica crucial nos sistemas embarcados
críticos, principalmente pelo fato de que esses sistemas possuem um impacto
imediato sobre o ambiente externo. Um exemplo clássico são os sistemas que
controlam o funcionamento (total ou parcial) das usinas nucleares, na qual uma
falha de segurança ou na confiabilidade pode causar uma catástrofe. Inclui-se nesse
quesito a tolerância a falhas, na qual um sistema deve continuar funcionando caso
algum componente apresente falhas.
3. Eficiência dos sistemas embarcados: geralmente o hardware dos sistemas
embarcados é limitado; então seus recursos devem ser usados de maneira eficiente.
As métricas para avaliar a eficiência são várias, entre elas:
• Consumo de Potência: sabe-se da dependência de muitos dispositivos sobre
as baterias que os alimentam, mostrando que a energia deve ser usada da
melhor forma possível;
5
• Tamanho de código embarcado: o código a executar em um sistema
embarcado deve ser o menor possível, por limitações de memória, visto que
esse código deve ser armazenado no dispositivo.
• Custo: principalmente no ramo de eletrônica de consumo, o custo de
produção de um sistema embarcado deve ser reduzido ao máximo, para que
este seja competitivo e possa ter sucesso de aceitação pelos utilizadores.
• Tempo de Execução: deve ser otimizado ao máximo, através da utilização
mínima dos recursos de software e hardware, necessários para a
implementação de uma determinada funcionalidade. Consequentemente, o
consumo de energia é reduzido.
4. Restrições de Tempo Real: um sistema embarcado de tempo real significa que ele
deve realizar uma certa tarefa dentro de um limite de tempo. As restrições são de
dois tipos:
• Hard real-time: a perda do intervalo limite de tempo da execução de uma
certa tarefa poderá causar uma catástrofe. Exemplos são: sistema de
controle de operação de usinas nucleares, software de controle de freios
ABS;
• Soft real-time: são os intervalos de tempo que, caso perdidos, não resultarão
em danos sérios ao ambiente externo. Exemplo: software de codificação de
vídeo.
Obviamente nem todos os sistemas atendem todas as características acima. Alguns
sistemas que possuem uma vasta gama de finalidades, como o SmartTV da Samsung [17],
perdem o conceito de interface dedicada. Apesar de possuir um controle remoto comum, esse
aparelho permite a utilização de uma câmera embutida como sensor de movimento, controle
por reconhecimento de faces e voz, ou ainda um smartfone compatível para controlar o seu
funcionamento. Na Figura 2.1, as características do SmartTV podem ser visualizadas:
Além disso, de acordo com [9], existem outras características que podem ser levadas em
consideração, como o tamanho variado (pequenos aparelhos celulares até grandes
equipamentos como aviões e estações espaciais) e conectabilidade (o grau de interação de um
dispositivo com uma rede).
6
Figura 2.1: Funcionalidades Samsung SmartTV ES8000. Extraído de [17].
2.2 Áreas chave de utilização de sistemas embarcados
As áreas chave nas quais os sistemas embarcados são utilizados podem ser visualizadas na
Tabela 2.1 [1], na qual pode-se perceber que as aplicações dos sistemas embarcados são
várias e em diferentes áreas de atuação.
Além disso, vale ressaltar que as características fundamentais para esses sistemas
significam que elas são mais importantes, comparadas com quaisquer outras características
que possam ter. Exemplificando, um sistema de automação industrial que falhar na
confiabilidade pode acarretar prejuízos sérios à indústria, em termos de lucro, principalmente.
Por outro lado, se esse sistema deixar a desejar na eficiência, no quesito de custo do
sistema, por exemplo, os prejuízos serão menores ou podem ser sobrepostos ao longo do
tempo e até por medidas de redução de outros custos da indústria. Por isso, esse quesito é de
menor relevância comparado à confiabilidade.
7
Tabela 2.1: Áreas chave e exemplos de sistemas embarcados
Áreas chave Alguns Exemplos Característica fundamental
Eletrônica automotiva: Sistemas de freios ABS, Sistemas
GPS
Segurança/Confiabilidade,
Restrições de tempo real
Aviônicos Sistemas anticolisão, de controle de
voo, de navegação.
Segurança/Confiabilidade,
Restrições de tempo real
Telecomunicações Telefones celulares, TV Digital [18] Eficiência: baixo consumo de
potência, tempo de execução, custo
Sistemas Médicos Membros artificiais, Ouvido
artificial
Eficiência,
Segurança/Confiabilidade,
Restrições de tempo real
Aplicações Militares Sistemas de defesa aérea, de
monitoramento [19]
Eficiência,
Segurança/Confiabilidade
Sistemas de Autenticação Sistemas biométricos [20] Segurança/Confiabilidade
Eletrônica de Consumo Tablets, Smartfones, players mp3 Eficiência: tempo de execução,
custo, baixo consumo de potência
Automação Industrial Controladores de braços mecânicos,
atuadores
Segurança/Confiabilidade,
Restrições de tempo real
Ambientes inteligentes Casa Inteligente [21], sistemas de
reconhecimento de voz para
automação residencial
Eficiência,
Segurança/Confiabilidade
Robótica Robôs móveis autônomos Eficiência,
Segurança/Confiabilidade
2.3 Características de Projeto de sistemas embarcados
Quando se trata do desenvolvimento de sistemas embarcados é necessário levar em conta
um conjunto de requisitos que difere em algumas características ao compará-lo com o
desenvolvimento de sistemas de propósito geral.
Primeiramente deve-se pensar na arquitetura que será utilizada, pois a mesma apresenta
requisitos em termos de desempenho e consumo de potência. Além disso faz-se necessário
levar em conta a tolerância a falhas (sistemas embarcados críticos), custo de produção, design
e tempo de projeto [22].
Um dos principais fatores que tornam mais complexo o processo de desenvolvimento
desses sistemas é a relação direta entre o desempenho da aplicação e o consumo de potência,
8
o que significa que processadores com maior desempenho tendem a consumir mais energia.
Isso prejudica o funcionamento de sistemas que dependem de bateria como fonte de energia.
Além disso o desempenho e o consumo de potência, bem como os componentes de
hardware utilizados, impactam no custo de produção. Com um custo alto, o preço do sistema
embarcado no mercado aumenta, podendo comprometer a aceitação do consumidor.
Aceitação esta que também é influenciada pelo design do produto desenvolvido e pelo tempo
de projeto, que deve ser o menor possível para ganhar a aceitação do mercado mais
rapidamente.
Em determinadas áreas, o requisito de tolerância a falhas é de extrema importância no
desenvolvimento desses sistemas, principalmente os sistemas embarcados críticos, como
sistemas aviônicos e de controle de usinas nucleares.
9
Capítulo 3
Desenvolvimento em Plataformas Heterogê-neas
3.1 Características e Vantagens da utilização de MPSoC
Em um ambiente heterogêneo o processo de desenvolvimento difere, em muitos aspectos,
do processo em um ambiente homogêneo. Nas arquiteturas multiprocessadas heterogêneas é
necessário utilizar um compilador específico para cada tipo de processador utilizado, o que
quer dizer que o código que será compilado para um processador DSP (Digital Signal
Processor) será diferente do código a ser compilado para um processador de arquitetura RISC
(Reduced Instruction Set Computing). Assim, o processo de desenvolvimento se torna mais
complexo, necessitando tratamentos diferenciados nas etapas de desenvolvimento.
Algumas vantagens para utilização de MPSoC são apontadas por [23]. MPSoCs
heterogêneos são mais eficientes no requisito de consumo de potência, principalmente por se
utilizarem de diferentes conjuntos de instruções para diferentes processadores, tornando a
execução de determinadas tarefas mais eficiente. Um exemplo típico é a utilização de
processadores de sinais digitais DSP para aplicações multimídia, os quais tendem a consumir
menos energia do que processadores de propósito geral neste tipo de tarefa [24].
Outra vantagem desse tipo de arquitetura está sobre o requisito de desempenho em tempo
real. A utilização de arquiteturas multiprocessadas heterogêneas permitem reduzir conflitos de
acesso e escrita em memória no processamento de informações, melhorando o desempenho
quando comparado com as arquiteturas multiprocessadas homogêneas, que precisam resolver
esses conflitos via software.
Com relação ao desenvolvimento e prototipação de novas aplicações, plataformas para
sistemas embarcados podem ser utilizadas com um custo relativamente baixo. A Tabela 3.1
mostra algumas plataformas de desenvolvimento e suas características:
10
Tabela 3.1 Exemplos de Plataformas e suas características
Plataforma Processador(es) Desempenho Custo*
BeagleBoard C4 MPSoC OMAP3530 Até 720 MHz $125
BeagleBoard-xM MPSoC DM3730 Até 1 GHz $149
PandaBoard ES OMAP4430 1.2 GHz $182
Snowball ARM Dual Cortex-A9, ARM
Mali 400-1
1 GHz $265
DevKit 8000 OMAP3530 600 MHz $169**
* Custo, em dólares, baseado no site da empresa Digi-Key Corporation [25].
** Custo, em dólares, baseado no site da empresa Embest Technology Co. [26].
Segundo [23], as situações onde é recomendado o uso de plataformas SoC (System-on-
Chip) são aquelas que apresentam requisitos como consumo de energia reduzido, melhoria de
desempenho e também no requisito de área ocupada, pois integram vários componentes
(como processadores, memórias, interfaces de teste e de periféricos) dentro de um único chip,
reduzindo o espaço ocupado. Na Figura 3.1 encontra-se o diagrama de blocos da plataforma
MPSoC OMAP 3530 [27], que ilustra a série de componentes integrados.
Pode-se visualizar na Figura 3.1 que o OMAP 3530 integra, no seu chip, uma série de
componentes além do processador ARM Cortex-A8 (bloco azul, na figura), como o
subsistema IVA 2.2, que contém o processador DSP (bloco amarelo, na figura). O OMAP
também dispõe do acelerador gráfico POWERVR SGXTM (bloco verde) memórias internas
On-chip 112 KB ROM e 64KB RAM (blocos vermelhos), controladores de memória,
interfaces de periféricos (blocos marrons), entre outros componentes. Isso mostra a
quantidade de componentes de diferentes propósitos integrados dentro de um único chip.
11
Figura 3.1 Diagrama de blocos funcionais do OMAP 3530 [27]
3.1.1 Ferramentas
No desenvolvimento de sistemas embarcados podem ser utilizadas algumas ferramentas
que auxiliam o processo, provendo mais recursos ao programador. Como citado
anteriormente, podem ser utilizados kits de desenvolvimento contendo processadores
embarcados facilitando a validação do software.
Em termos de hardware, os kits de desenvolvimento auxiliam no desenvolvimento de
protótipos, permitindo a escolha de componentes a serem adicionados (de acordo com o
suporte a interfaces e portas USB pelo kit), bem como auxiliando na avaliação de um sistema
ou aplicação, com estatísticas do comportamento da execução.
O uso de ambientes de desenvolvimento de software em desktop é mais adequado, quando
comparado com o desenvolvimento de programas diretamente na placa. Por meio da
utilização de cross-compilers, os ambientes de desenvolvimento em desktop aumenta a
agilidade desse processo, pelo fato do maior desempenho das arquiteturas desktop. Além
disso, esses ambientes de programação podem ser usados em conjunto com a placa de
12
desenvolvimento, permitindo maiores capacidades de depuração e solução de problemas de
integração.
Um exemplo de ferramenta desse tipo é o Code Composer Studio (CCS) [28],
disponibilizado pela Texas Instruments Inc [29]. Esse ambiente de programação possui
diversas funcionalidades que auxiliam o programador no desenvolvimento de sistemas
embarcados:
• Explorador de Recursos: auxilia na criação de novos projetos e no gerenciamento
destes, além de prover rápido acesso às tarefas comuns, como compilação e
depuração, bem como utilização de exemplos de código.
• Integração com o sistema operacional de tempo real SYS/BIOS [30]. Esse sistema
pode ser utilizado em uma ampla gama dos processadores DSP da Texas Instruments,
microcontroladores e também processadores ARM.
• Disponibilidade de compiladores C/C++ para várias arquiteturas. É possível construir
código para microcontroladores MSP430, para processadores ARM e para
processadores DSP da família C5000 e C6000.
• Depuração de um ou mais processos na arquitetura alvo. Conectando a máquina host
(PC) com a placa de desenvolvimento através de um cabo serial ou de rede TCP/IP, é
possível realizar uma depuração de código na própria placa. Para terminar uma sessão
de depuração, o CCS utiliza um emulador JTAG, permitindo a avaliação do estado do
kernel e do processo.
• Análise de Sistema: provê ao programador estatísticas do desempenho e do
comportamento da aplicação em execução. De modo geral, o CCS permite ao
programador o monitoramento da utilização de CPU, visualizar carga de rede, grafo de
execução, e outras funcionalidades de benchmarking.
• Depuração via Hardware: para processadores da Texas Instruments, cujas capacidades
variam de acordo com o processador, por exemplo acesso não intrusivo a registradores
e memória, execução síncrona com processadores Multicore, modo tempo real
(permite suspender a execução de códigos sem interromper a execução de tarefas
críticas).
• Analisador de Imagens: permite visualizar graficamente dados e variáveis e fornece a
capacidade de analisar frames de vídeo e imagens no seu formato nativo.
13
• Geração de código para periféricos: no caso dos microcontroladores MSP430, o CCS
permite a geração de código C para gerenciar o uso de periféricos.
• C6EZFlo: essa ferramenta gráfica de desenvolvimento serve para a geração de código
para uma ampla gama de processadores DSP a partir de um diagrama de blocos,
provendo algoritmos de processamento otimizados e de E/S de periféricos.
Esses tipos de ferramentas auxiliam ao programador no desenvolvimento de sistemas
embarcados, à medida que há a possibilidade de maior auxílio nas etapas de construção e
compilação de código, havendo o suporte da ferramenta com compiladores para diferentes
modelos de processadores, além de exemplos (templates). Além disso, auxilia nas etapas de
execução e depuração, provendo análises dos recursos por meio de simulação e agilizando na
resolução de possíveis erros, através de depuração via hardware da arquitetura alvo. Porém,
em alguns casos deve-se considerar o custo de aquisição de uma licença de um ambiente
desse tipo. O CCS dispõe de uma licença gratuita para fins acadêmicos, mas uma versão mais
completa pode chegar a custar $19,994.95 [28].
Somando-se a isso, a utilização dos kits de desenvolvimento auxiliam na prototipação de
novos sistemas, permitindo analisar e testar o comportamento da execução da aplicação
desenvolvida, aproximando-se da ideia do produto final. Assim, pode-se verificar de maneira
mais realista a utilização dos recursos desejados, desde componentes USB, áudio, vídeo, telas
sensíveis ao toque, captação de vídeo por câmera, entre outros.
3.2 Plataforma utilizada: BeagleBoard-xM
Neste trabalho a placa de desenvolvimento utilizada é a BeagleBoard-xM [15], que utiliza
uma arquitetura MPSoC DM3730, composta por dois processadores em um mesmo chip.
Algumas características fazem a BeagleBoard-xM torna-se uma boa escolha como plataforma
de desenvolvimento.
Primeiramente, essa plataforma dispõe de uma arquitetura multiprocessada heterogênea,
cujo processador de propósito geral (ARM Cortex-a8) é amplamente utilizado no mercado de
embarcados [31]. O segundo processador é um DSP, que permite a execução otimizada de
algoritmos de processamento de sinais digitais.
Além disso essa plataforma possui interfaces e drivers de vídeo, USB e som, além das
dimensões reduzidas (8.5x8.7 cm) e baixo consumo de potência. A BeagleBoard-xM possui
14
também uma interface nativa com suporte a câmeras de resolução VGA até 5 MP (Mega
Pixel).
Outro fator importante é o fato de que a BeagleBoard-xM pode ser adquirida com um
custo relativamente baixo, a partir de US$ 149 em lojas dos Estados Unidos [32]. O resumo
dos componentes dessa placa de desenvolvimento pode ser visualizado na Tabela 3.2.
Tabela 3.2: Resumo dos componentes da placa de desenvolvimento BeagleBoard-xM [15]
Plataforma de Desenvolvimento BeagleBoard-xM
Processadores - 1 GHz ARM Cortex-A8 (Arquitetura RISC)
- TMS320C64x (800 MHz) (Arquitetura DSP)
Memória - 512 MB DDR RAM
Periféricos e conexões - HDMI/DVI
- Porta de interface nativa para Câmera
- S-video
- HUB USB (4 portas)
- Entrada e saída Stereo
- Porta RS232 (serial)
- Conector JTAG
Armazenamento - Slot Cartão SD
Na Figura 3.2 encontra-se uma foto da placa, na qual os componentes podem ser
visualizados. Como citado anteriormente, a BeagleBoard-xM agrega dois processadores com
propósito diferente na plataforma DM3730 [40]. Então, o conjunto de instruções entre eles é
diferenciado, pois enquanto o ARM é voltado para propósito geral, possuindo uma arquitetura
RISC de 40 registradores (33 de propósito geral e 7 de estado) [31], o DSP possui instruções
otimizadas para processamento de imagens e vídeo, com a execução de até 8 instruções por
ciclo de processamento e 64 registradores no total [27] [33].
15
Figura 3.2: Foto da Placa BeagleBoard-xM, Revisão C. Extraído de [15].
Esta plataforma suporta diversas distribuições do sistema operacional Linux, como
Ubuntu, Android, Debian e Angstrom. Isso torna o desenvolvimento mais flexível, pois várias
aplicações e projetos em código aberto, ou livre para uso, estão disponíveis e são compatíveis
com essas distribuições. Nesta plataforma, o sistema operacional pode residir em um cartão
SD (Secure Digital) ou em um MMC (MultiMedia Card).
Para o desenvolvimento de aplicações para a Beagleboard pode-se optar pela codificação,
compilação e testes de aplicações diretamente na placa. No entanto, devido aos recursos
escassos, uma solução mais adequada é a utilização de um ambiente de desenvolvimento
desktop, através de uma IDE (Integrated Development Environment) de programação, com
suporte aos cross-compilers para a arquitetura alvo em uso.
No desenvolvimento dos módulos DSP é necessário utilizar um compilador específico,
disponibilizado pela Texas Instruments, para gerar código compatível com o processador
DSP. Esse compilador é gratuito e está disponível para os sistemas operacionais Linux e
Windows. Após a compilação do código o mesmo deve ser copiado para o cartão SD.
Em termos de desempenho, nessa plataforma há a possibilidade de se utilizar instruções
especializadas para determinadas tarefas, tanto no processador ARM quanto no processador
DSP, melhorando o desempenho. Para melhorar o desempenho de uma aplicação, pode-se
utilizar o paralelismo no nível de threads, onde as tarefas são divididas entre os
processadores, ou o paralelismo no nível de instruções, que provê a capacidade para um
determinado processador executar várias instruções por ciclo. [36]. Entretanto, cabe ao
programador conhecer detalhadamente o conjunto de instruções da arquitetura utilizada, bem
16
como arranjar o código de forma que seja possível aproveitar esse paralelismo, aumentando a
complexidade do código.
3.2.1 Processador ARM Cortex-A8
A empresa britânica ARM Holdings [34] é a empresa responsável pelo desenvolvimento da
arquitetura ARM (Advanced RISC Machine) e possui os direitos autorais sobre a mesma.
Entretanto, ela não produz os processadores; apenas licencia os direitos (de implementação
ou de uso da arquitetura compatível com o conjunto de instruções ARM) sobre a arquitetura
para outras empresas que desejam produzi-los.
De modo geral, os processadores ARM são destinados a dispositivos embarcados, e nos
últimos anos são os líderes de venda no mercado. De acordo com um relatório da ARM
Holdings, estima-se que mais de 25 bilhões de processadores ARM já foram criados e que,
além disso, são despachados cerca de 16 milhões por dia [34].
O MPSoC DM3730 incorpora como processador de propósito geral (GPP – General
Purpose Processor) o ARM Cortex-A8. Esse processador é muito utilizado no mercado de
sistemas embarcados, principalmente pelo fato de aliar bom desempenho a um relativo baixo
consumo de potência. Na Tabela 3.3, encontram-se alguns dispositivos que utilizam esse tipo
de processador [34]:
Tabela 3.3: Dispositivos que utilizam processador ARM
Nome do Dispositivo Família da Arquitetura
Acer n300 ARM9
Amazon Kindle Wi-Fi ARM11
Air Hogs Hawk Eye ARM Cortex-A
Comfile Technology Cuwin3200 ARM9
Dell Latitude e4200 Laptop ARM Cortex-M
Dash Express Navigation ARM9
Baseado na arquitetura ARMv7 de 32 bits, o ARM Cortex-A8 consegue operar em uma
frequência de relógio que varia entre 300MHz até 1 GHz. Normalmente, os sistemas
operacionais compatíveis com esse processador o mantém trabalhando a 300 MHz, mas
podem aumentar a frequência de trabalho do mesmo “sob demanda”, caso uma aplicação
necessitar maior poder de processamento. Dessa forma é possível diminuir o consumo de
potência.
17
Um fato que contribui para a utilização deste processador nos sistemas embarcados é a
possibilidade de se estender o conjunto de instruções da arquitetura ARMv7, utilizando-se de
um coprocessador, no caso o NEONTM [35]. Os coprocessadores são processadores de
propósito específico, com o objetivo de melhorar o desempenho para determinados grupos de
instruções. Essa possibilidade de extensão do conjunto de instruções aumenta a flexibilidade
da arquitetura para utilização em grande parte dos sistemas embarcados.
Disponível para a série de processadores ARM Cortex-A, o coprocessador NEONTM é
composto de uma extensão do conjunto de instruções SIMD (Single Instruction Multiple
Data) de 128 bits, chamado de Advanced SIMD, e de uma extensão de suporte à operações em
ponto flutuante de precisão simples.
Dentre as funcionalidades do coprocessador NEONTM, temos:
• Instruções de processamento de valores em ponto flutuante de precisão simples;
• Estrutura SIMD de instruções Load/Store;
• Transferências entre o processador ARM e os registradores NEON da ordem de 8,
16, 32 e 64-bit.
Dessa forma, apesar de ser tratado como um processador de propósito geral por ser o mais
atuante em termos de desempenho, na plataforma DM 3730, bem como na OMAP 3530, esse
processador acelera processamento de tarefas mais específicas, como o processamento de
mídia [22].
3.2.2 Processador DSP TMS320C64x+
Em muitos casos, a maioria das informações costuma ser representada por sinais,
variações físicas que podem ser mensuradas, como luz e temperatura. Esses sinais são
analógicos por natureza e possuem características de serem contínuos ao longo do tempo [36].
A partir do momento que passa a ser necessário ou conveniente tratar esses sinais
analógicos computacionalmente, é necessário representá-los em um formato digital. Um sinal
digital, nesse caso, nada mais é do que uma sequência discreta de estados que codifica uma
mensagem. Um vídeo do padrão H.264, um arquivo de áudio mp3 e um pacote TCP/IP são
alguns exemplos de sinais digitais. Assim, para tratar essa classe de processamento, surgiram
os processadores de sinais digitais.
Projetados para executar com eficiência algoritmos de processamento de sinais digitais,
possuem uma arquitetura diferenciada, mas em geral esses processadores possuem vantagens
18
sobre os processadores de propósito geral [37,38]. Mesmo com recursos limitados, são
capazes de realizar processamento de algoritmos com vantagens em relação ao consumo de
energia, desempenho e também com relação ao custo da arquitetura.
Na plataforma DM 3730, bem como na plataforma OMAP 3530 [27], o processador DSP é
o TMS320C64x+ [39], fabricado pela Texas Instruments. Ele faz parte da família de
processadores c64x que possuem um conjunto de instrução (ISA) compatível entre os
processadores [41] .
A família de processadores TMS320TM consiste em processadores DSP de ponto fixo,
ponto flutuante e também de multiprocessadores DSP. A arquitetura desses processadores é
designada para tarefas específicas de tempo real, e as áreas de aplicação dos processadores
TMS320C6000 incluem [39]:
1. Redes:
• Estações base Wireless;
• Modems cabeados e sistemas DSL (Digital Subscriber Loop);
• Sistemas de telefonia multicanal;
2. Segurança personalizada:
• Reconhecimento de face, mão e impressão digital;
3. Áudio
• Reconhecimento de voz;
4. Processamento de Imagens
• Ultrassom, gráficos de realidade virtual 3-D
5. Outras:
• Navegação GPS (Global Positioning Systems) com prevenção de acidentes;
• Diagnósticos médicos remotos;
• Radares e modelagens atmosféricas;
• Indústria automotiva;
19
O desempenho desses processadores chega até 8000 MIPS (Million Instructions Per
Second) [39], oferecendo diferentes abordagens para tratar problemas de processamento de
sinais digitais, incluindo aplicações complexas que possam requerer dos benefícios de
desempenho do paralelismo de instruções por ciclo de frequência.
O processador TMS320C64x+ pode chegar a trabalhar a uma frequência de relógio de 800
MHz, com a capacidade de executar até oito instruções por ciclo. Sua CPU possui 64
registradores de propósito geral de 32 bits, com seis ULAs (Unidade Lógica e Aritmética) e
duas unidades multiplicadoras, totalizando 8 unidades funcionais. As funcionalidades desse
processador podem ser vistas na Tabela 3.4.
Vale ressaltar que a utilização de paralelismo de instruções que o processador c64x+
proporciona aumenta a complexidade do código. Além disso é muito difícil conseguir
paralelizar de maneira total um determinado código, utilizando-se de todas as unidades
funcionais, pois isso dependerá do nível de dependência de dados que a aplicação exige.
Tabela 3.4: Funcionalidades do processador DSP TMS320C64x+ e descrição
Funcionalidade Descrição
Empacotamento de Instrução Provê tamanho de código equivalente a 8 instruções,
executadas em paralelo ou serial. Reduz o tamanho de
código e também consumo de potência.
Very Long Instruction Word VLIW CPU Executa até 8 instruções por ciclo.
Execução condicional da maioria das instruções Aumenta o nível de paralelismo para manter maior
performance.
Modo de operação protegido Um sistema de dois níveis que provê execução de
programas privilegiados, proteção de partes da
memória.
Suporte a exceções Para facilitar na detecção de erros e redirecionamento
de execução.
Operações 16 bit otimizadas Instruções adicionais para suporte a 8 adições/
multiplicações/subtrações de 16 bit por ciclo no
máximo.
20
3.3 Portabilidade de aplicações
Muitas aplicações embarcadas são desenvolvidas com base em aplicações desktop já
existentes no mercado, ou seus projetos surgem adaptações para os SEs, com o intuito de se
obter as vantagens da utilização dos SEs.
Através do código-fonte da aplicação é possível portá-la para outras arquiteturas. Uma
forma é se utilizar de um compilador compatível com a arquitetura de destino da aplicação, ou
seja, a arquitetura sobre a qual a aplicação vai executar. É necessário que a linguagem possua
um compilador para a arquitetura de destino, mas a vantagem está na possibilidade de reuso
parcial ou total do código-fonte da aplicação.
Além disso, é possível realizar otimizações no código portado, de acordo com a
necessidade. Uma das formas de se fazer isso é utilizando otimizações realizadas pelo
compilador, de acordo com o objetivo a ser alcançado. Com a utilização do GCC é possível
realizar otimizações de desempenho e de tamanho de código gerado, que podem ser úteis
tanto para sistemas desktop, quanto para SEs. Em [59], algumas opções e níveis de otimização
para a versão 3.2.2 do compilador GCC (Gnu Compiler Collection)[58]:
• Nível 1: especificando a flag “-O1” na compilação, o código executável será
construído tendo como objetivo redução de tamanho de código e aumento de
desempenho.
• Nível 2: neste nível, com a flag “-O2” o compilador realiza as mesmas otimizações do
nível anterior, além de outras otimizações cujos objetivos não envolvem redução de
tamanho de código e desempenho.
• Nível 3: Nível máximo de otimização, acrescenta otimizações ao Nível 2, colocando
ênfase ao desempenho. Normalmente produz código com melhor desempenho, mas
com impacto no tamanho do código. Para utilizar este nível, deve-se acrescentar a flag
“-O3” na compilação.
De modo geral é mais viável portar uma aplicação existente e adaptá-la de acordo com os
requisitos e necessidades do SE, do que recomeçar o desenvolvimento da mesma. Porém, este
processo não é trivial, visto que os requisitos dos SEs a serem atendidos podem impactar no
funcionamento normal da aplicação. Um exemplo disso é o padrão de vídeos H.264, que
21
possui perfis para melhor atender aos requisitos da arquitetura de destino. Assim, o perfil mais
simplificado, destinado a sistemas com recursos computacionais limitados, economiza mais
energia, mas possui um desempenho inferior, em termos de resolução e qualidade de imagem,
comparado ao perfil mais robusto, destinado a decodificadores de alta definição de imagem.
3.3.1 Problemas de alinhamento de bytes em processadores ARM
Apesar das vantagens que a portabilidade de aplicações podem proporcionar ao
desenvolvimento de SEs, um problema de alinhamento de dados na memória pode ocorrer ao
se portar uma aplicação para outras arquiteturas.
Com base em [57], acessos à memória de forma não alinhada podem ser um problema,
visto que processadores ARM mais antigos são mais limitados no acesso a dados, caso estes
não estejam alinhados em limites de 4 bytes.
Esses acessos não alinhados a memória podem gerar problemas em arquiteturas que são
mais restritas no acesso aos dados, como as já mencionadas. Considerando a Figura 3.3, onde
é mostrada uma estrutura contendo valores arbitrários, o dado pode ser lido de maneira
diferente de acordo com a arquitetura utilizada, caso ela tenha restrições aos acessos
desalinhados na memória.
Na Figura 3.3, dentro de cada retângulo estão contidos valores numéricos em base
hexadecimal. Estes valores são “endereçados” pelos seus índices, números decimais sobre os
retângulos. Considerando que seja feita uma leitura de 32 bits (4 bytes) por um processador
little endian, começando pelo índice 1 e de forma contígua, o valor esperado seria o valor
0x0E0D0C0B (235 736 075 em decimal). É desta forma pois o suposto processador realiza a
leitura da direita para a esquerda, na Figura 3.3. Assim, o byte menos significativo é o do
índice 1.
Porém o dado efetivamente lido é o valor 0x0D0C0B0A (218 893 066 em decimal), que é
o valor que se encontra dentro dos limites de 32 bits. Isso porque a leitura foi alinhada a partir
do índice 0, pois o suposto processador não suporta leituras desalinhadas, e assim o valor lido
não será o valor que realmente se encontra a partir do índice 1 especificado.
De modo geral, as soluções para este problema se encontram ou na compilação ou em
ações do próprio sistema operacional que executa a aplicação. O GCC, por exemplo, realiza
adaptações no código de forma a evitar esses problemas.
22
Figura 3.3: Exemplo do problema de alinhamento de bytes.
No momento em que o compilador identifica problemas de alinhamento, principalmente
em estruturas de dados do tipo struct, ele insere “padding bytes” nas estruturas para que estas
residam e estejam alinhadas dentro dos limites que a arquitetura requer. É possível visualizar
este comportamento do compilador, no caso do GCC, através de algumas flags de
compilação:
• -Wpadded: notifica quando bytes forem inseridos em uma estrutura, incluídos para
alinhar elementos da estrutura ou mesmo para alinhar a estrutura como um todo.
23
• -Wpacked: Quando a instrução __attribute__((packed)) for utilizada para tentar
reduzir o espaço em bytes ocupado por uma estrutura na memória, mas a instrução não
conseguir o efeito desejado, essa notificação é mostrada.
• -Wcast-align: notifica quando um ponteiro para um tipo de dado (com um tamanho
determinado em bytes), sofre uma conversão de tipo (type casting) para outro de
tamanho superior ao primeiro. Por exemplo, considerando um ponteiro para o tipo
char, que foi convertido para o tipo int, em uma determinada arquitetura. Se o acesso
aos valores deste tipo nesta arquitetura for restrito ao alinhamento em limites de 2 ou 4
bytes, o GCC irá lançar essa notificação ao usuário.
O sistema operacional também pode identificar e corrigir estes problemas. No caso do
linux, as informações de quantos acessos não alinhados efetuados e a política de resposta a
esses acessos podem ser visualizados e configurados no arquivo /proc/cpu/aligment.
Neste arquivo, a primeira linha corresponde à quantidade de acessos não alinhados por um
processo do usuário que foram detectados pelo sistema operacional. As linhas que se seguem
dão informações sobre esses acessos e a última linha mostra a política de resposta do sistema
operacional, quando este detectar um problema de alinhamento. Os tipos de resposta são :
• Ignorar o acesso não alinhado: quando o parâmetro da última linha do arquivo for “0”
(zero), o acesso será ignorado, e a única forma de saber se houve um acesso desse tipo
é monitorando a quantidade de acessos não alinhados.
• Notificar: quando o valor do parâmetro for “1”, o sistema operacional irá notificar o
usuário a cada acesso não alinhado, com informações referentes ao acesso, permitindo
ao programador identificar os problemas de acessos não alinhados realizados pela
aplicação, se for o caso.
• Corrigir: quando o valor do parâmetro for “2”, o acesso será corrigido introduzindo
bytes de alinhamento, da mesma forma que é realizada pelo compilador, reduzindo o
desempenho da aplicação.
• Corrigir e Notificar: quando o valor do parâmetro for “3”, o sistema operacional irá
corrigir o acesso não alinhado (equivalente à opção “2”) e notificará o usuário
(equivalente à opção “1”).
24
• Enviar Sinal: com valor do parâmetro igual a “4”, o sistema irá enviar um sinal ao(s)
processo(s), terminando-o(s).
• Enviar Sinal com Notificação: com valor do parâmetro igual a “5”, o sistema irá
enviar um sinal ao(s) processo(s), terminando-o(s) (equivalente ao tipo “4”),
mostrando informações relativas ao acesso não alinhado (equivalente ao tipo “1”).
As consequências dos acessos desse tipo podem ser: dados corrompidos, falhas de
segmentação, ou redução de desempenho. Normalmente, o que ocorre é apenas uma redução
de desempenho da aplicação, por consequência da necessidade de uma maior quantidade de
acessos para obter o dado correto. Entretanto, nos casos em que o comportamento da
aplicação portada for diferente do esperado, será necessário a reescrita de partes código,
focando nos tamanhos das estruturas utilizadas (struct e estruturas derivadas).
3.4 Análise do desempenho do H.264 na BeagleBoard-xM
Uma análise de desempenho e consumo de potência na BeagleBoard-xM, com a execução
do decodificador H.264 foi realizada, avaliando as particularidades desse processo com a
utilização do processador ARM e do DSP.
A motivação para se avaliar o processo da decodificação de vídeos H.264 se dá pela
popularidade desse padrão. O fato de que esse padrão tem a capacidade de obter a mesma
qualidade de imagem com aproximadamente a metade da taxa de bits utilizada pelo seu
antecessor (padrão MPEG-2) [42], e sua gama de aplicações que varia desde dispositivos
portáteis até decodificadores de alta definição, justificam a popularidade do H.264.
3.4.1 O padrão de vídeos H.264
Desenvolvido a partir dos padrões MPEG-2 e MPEG-4, o padrão H.264 teve seu
surgimento em 2003 e é composto de um codificador e de um decodificador. O codificador
tem a função de compactar o vídeo digital, economizando espaço de armazenamento e
exigindo assim uma menor largura de banda para transmissão. Já o decodificador realiza o
processo inverso, ele extrai as informações de um vídeo comprimido, recriando a sequência
de imagens para serem exibidas na tela de um computador, por exemplo.
25
Pelo fato do H.264 ser dividido em perfis de aplicação, ele tem maior flexibilidade para
execução em diversos dispositivos, de acordo com os requisitos destes. Esses perfis são
descritos a seguir [42] :
• Perfil Baseline: criado com o foco em dispositivos com recursos limitados. Não
suporta a codificação CABAC (Context-Adaptive Binary Arithmetic Coding) nem
partições de quadro do tipo B.
• Perfil Main: destinado a consumidores finais de eletrônicos, servidores de vídeo e
broadcast. Suporta vídeos da resolução QCIF (176x144) até Full HD (1920x1080).
• Perfil Extended: criado para aplicações de streaming de vídeo, ele possui
ferramentas para facilitar a troca entre diferentes bit streams.
• Perfil High: Incluído posteriormente aos perfis anteriores, possui codificação com
mais eficiência e praticamente substituiu o perfil Main. O Sistema Brasileiro de
Televisão Digital – SBTVD [18] utiliza este perfil nas suas especificações de
compressão de vídeo digital.
No H.264 a decodificação é composta de etapas, cada qual com uma função específica
sobre a stream de entrada, ou seja, o vídeo compactado. São elas: descompressão (entropy
decoder), reordenação, quantização inversa (Q-1), transformada inversa (T-1), compensação
de movimentos (MC), predição Intra e Filtragem [43]. O diagrama das etapas do
decodificador H.264 e suas etapas podem ser vistas na Figura 3.4.
Figura 3.4: Etapas do processo da decodificação de vídeos H.264 [43]
26
Na primeira etapa os bits comprimidos são obtidos da stream de entrada, oriundos de
meios como cabo, ar ou internet e encapsulados em “pacotes” de dados via NAL (Network
Abstraction Layer).
A segunda etapa produz os elementos de sintaxe através desses bits, cuja codificação pode
ser do tipo CAVLC (Context-Adaptive Variable-Length Coding) ou CABAC (Context-
Adaptive Binary Aritmetic Coding). Essa etapa é denominada por Decodificação de Entropia,
ou Entropy Decoding.
Após esta etapa, vem a etapa da reordenação, que se faz necessária pois o H.264 permite o
envio dos dados do vídeo desordenados. Então, as etapas denominadas Quantização Inversa
(Q-1) e Transformada Inversa (T-1) são realizadas com o intuito de recuperar os coeficientes
truncados durante a codificação e passá-los para o domínio espacial, respectivamente.
O H.264 possui dois tipos de predição, a predição Intra e Inter. Na predição Intra, que é um
processo de predição espacial, significa que atua apenas em um mesmo quadro. Essa etapa
tem a função de reduzir as redundâncias de dados em um bloco, a partir de informações de
blocos vizinhos a ele.
O outro tipo de predição é denominado Compensação de Movimentos (CM). Com o intuito
de detectar semelhanças entre quadros próximos e reduzir essas redundâncias entre os
mesmos, a CM torna a decodificação de cenas com características semelhantes (como o fundo
da imagem) mais eficiente, utilizando para isso quadros de referência.
Os principais tipos de quadros são: I, P, e B. O tipo do quadro define a predição utilizada,
sendo que o tipo I é um frame que usa predição Intra, e a sua decodificação é independente
dos demais. O tipo P usa predição Intra e Inter, sendo que sua decodificação depende de um
ou mais frames anteriores, e o tipo B utiliza predição Intra e a sua predição Inter depende de
frames anteriores a ele ou posteriores a ele [44].
A última etapa é denominada Filtragem, com a função de suavizar as bordas entre os
blocos vizinhos de um quadro. Essa filtragem é executada de maneira “In-loop”, e tende a
melhorar a qualidade da imagem. Além disso, podem ser utilizados filtros de pós-
processamento, que são opcionais [45].
Os processos da codificação e posterior decodificação, para que o vídeo seja visualizado,
possuem custo computacional considerável, principalmente se tratando de vídeos de alta
27
definição. Além disso, para dispositivos dependentes de bateria, é necessário realizar um
balanço entre os requisitos de desempenho e de gasto de potência.
3.4.2 Resultados Obtidos na análise
Como citado anteriormente, os MPSoCs heterogêneos tem se apresentado como uma boa
solução para melhoria de desempenho, considerando requisitos relevantes dos sistemas
embarcados, em aplicações desse tipo.
Utilizando-se da placa BeagleBoard-xM, foi analisada a decodificação de um vídeo no
padrão H.264 perfil Baseline, perfil compatível com os recursos de processamento limitados
da placa. O vídeo possui resolução de 854x480 pixels contendo 2000 quadros.
Para os experimentos realizados nesse trabalho foi utilizado o Gstreamer [46], na
decodificação de vídeo para arquitetura ARM. Para a arquitetura DSP, da mesma forma, mas
com a utilização do gst-dsp [47], que utiliza do codec disponibilizado pela Texas Instruments.
A análise da utilização de CPU foi realizada para avaliar o desempenho da aplicação nesta
arquitetura. Em um primeiro momento foi feita a avaliação da decodificação utilizando apenas
o processador ARM e, em um segundo momento, avaliou-se com a utilização em conjunto
com o processador DSP.
A partir de dados do percentual de utilização da CPU, coletados com o auxílio do
aplicativo Vmstat, foi feita a análise em termos de desempenho. Esses dados coletados são
compostos por:
• Percentual de tempo gasto na execução de códigos que não fazem parte do kernel,
chamado de user time, ou apenas us;
• Percentual de tempo gasto na execução de componentes do kernel, chamado de
system time, ou sy;
• Percentual de tempo de ociosidade da CPU. Pode incluir tempo de espera em
operações de E/S, se houver, chamado de idle time, ou apenas id.
Na decodificação do vídeo H.264 no processador ARM, constatou-se que a utilização da
CPU foi total nesse processo, ou seja, 100%. Apesar de estar operando em 800MHz, houve
perdas de frames na decodificação do vídeo, fato que pode ser explicado pelo atraso na
28
renderização dos quadros na tela, e também pela disputa de outros processos pela CPU, como
o servidor gráfico X do Linux.
Com relação à decodificação com o uso do DSP, a carga de processamento no ARM
diminuiu, com percentual de utilização neste último de 83%, em média (%us + %sy). Não
foram constatadas perdas de frames durante a decodificação, e vale ressaltar que a utilização
do processador se manteve alta devido a execução de outros componentes relacionados à
decodificação, como a leitura de dados e a demultiplexação do arquivo de entrada, conversão
do espaço de cores para a apresentação da imagem e também renderização desta, efetuada
pelo ARM. Os percentuais de utilização do processador ARM podem ser visualizados na
Figura 3.5:
Figura 3.5: Gráfico da utilização do processador ARM, na decodificação H.264 efetuada pelo DSP.
Estes dados revelam uma vantagem de se utilizar o processador DSP, neste caso
diminuindo a carga no processador ARM, deixando-o com um percentual de tempo ocioso e
também pela melhoria no desempenho. Em média, a carga no processador DSP foi de
77,15%, durante a decodificação do vídeo.
Para a avaliação do consumo de potência, durante a decodificação, foi utilizada a
ferramenta I2c-tools para fazer a leitura de dados, via software, da tensão em um subsistema
de Monitoramento ADC (Analog-to-Digital Converter) da plataforma. Este subsistema faz
29
parte do dispositivo TPS65950 OMAP [48], que permite o controle e gerenciamento de
energia da plataforma.
Primeiramente, com a a utilização da ferramenta I2c, foi necessário iniciar e configurar o
subsistema MADC [48]. Foi especificado a partir de quais componentes ADC seriam feitas as
leituras, que correspondem ao ADCIN3 e ADCIN5, de acordo com o esquemático do circuito
da plataforma, na Figura 3.6.
Figura 3.6: Esquemático do circuito de medição de consumo de potência da BeagleBoard-xM [48].
O ADCIN5 corresponde à tensão de entrada no DM3730 e o ADCIN3 a tensão de saída.
Os valores dos ADCs lidos em conjunto com o resistor R13 (ver Figura 3.6), de 0,1 ohms, são
usados para calcular a perda de tensão sobre R13.
Como a resistência R13 é de 0.1 ohms, para cada 100 mA consumido, uma redução de 0,01
V entre o ADCIN3 e ADCIN5 é detectada. A alimentação do circuito é de 4.2V dado pelo
pino 4 do CI TL1963A, mas com o uso dos resistores R48 e R52 de 12K e 10K Ohms
respectivamente, a tensão efetiva da alimentação é de 46% do valor de entrada. Isso equivale
a uma tensão de aproximadamente 2V que é efetivamente a tensão utilizada pelo DM3730.
Desconsiderando recursos integrados na placa, como HUB USB com teclado e mouse
conectados, foi possível realizar uma estimativa do consumo de potência durante a
30
decodificação do vídeo, pelo processador ARM e também com o DSP. Com a Equação 3.1,
que traz o valor da potência (P) consumida na placa, através do cálculo da corrente elétrica
sobre R13, multiplicado pela voltagem do circuito, correspondente ao valor de ADCIN5.
(3.1)
Na decodificação utilizando-se do processador ARM, com sucessivas leituras a cada 0,5
segundo, a potência média estimada foi de aproximadamente 2,48W. Com a utilização do
processador DSP constatou-se que a potência média estimada aumentou cerca de 6,41%,
chegando em aproximadamente 2,65W. Esse aumento é relativamente pequeno, em
comparação com o ganho de desempenho na utilização do DSP, deixando o processador
ARM ocioso em um percentual de tempo (16%), liberando-o para realização de outras tarefas.
Além disso, com o uso exclusivo do processador ARM não foi possível decodificar o vídeo
sem perdas de quadros.
P=ADCIN5∗( ADCIN5−ADCIN3)/ R13
31
Capítulo 4
Estudo de Caso
4.1 Contextualização: VANTs
De modo geral, um Veículo Aéreo Não Tripulado (VANT) é um tipo de sistema
embarcado que consiste em uma aeronave que é capaz de realizar diversos tipos de missões,
mas que não precisa de uma tripulação para voar. [16].
As principais atividades ou áreas de aplicação dos VANTs, de modo geral, são [49]:
• Monitoramento agrícola e ambiental;
• Segurança e setor militar;
• Defesa Civil;
• Investigações de fenômenos atmosféricos;
• Comunicações
Apesar de terem áreas variadas, as aplicações de caráter militar ainda são as mais presentes
no contexto dos VANTs. A principal vantagem proporcionada por um VANT é a
possibilidade da substituição da presença física humana em áreas de potenciais riscos à vida.
Assim, normalmente, os VANTs são projetados para realizar tarefas perigosas e repetitivas,
nessas áreas de risco.
Além disso, os VANTs são considerados como sistemas embarcados críticos, pois caso
ocorram falhas nesses sistemas, as consequências podem ser trágicas e perigosas.
Considerando um VANT sobrevoando uma área habitada ou inflamável, os riscos de uma
falha pode ocasionar uma queda ou colisão, podendo afetar vidas humanas. Um relato de uma
colisão entre um VANT e uma aeronave militar, no espaço aéreo do Afeganistão, resultando
em um pouso de emergência por parte da aeronave, pode ser visualizado em [50].
32
O INCT-SEC (Instituto Nacional de Ciência e Tecnologia em Sistemas Embarcados
Críticos), criado pelo Ministério de Ciência e Tecnologia em parceria com o CNPq (Conselho
Nacional de Desenvolvimento Científico e Tecnológico), entre outras instituições,
desenvolveram o VANT Tiriba, cujas aplicações se encontram nas áreas de monitoramento
ambiental, agrícola e de defesa civil. Ele conta com câmeras fotográficas de alta definição,
sensores, câmaras termais e de vídeo nesta tarefa [51]. Na Figura 4.1 pode ser visualizada a
foto do Tiriba.
Figura 4.1: Foto da decolagem do Tiriba [51].
Internamente, o modo de funcionamento de um VANT se divide em módulos para a
realização de determinadas tarefas, para que o voo não tripulado seja possível. Na Figura 4.2
pode ser visualizado o diagrama de blocos do Tiriba, contendo os seus módulos ou unidades
de processamento.
Figura 4.2: Diagrama de blocos do Tiriba [51].
A descrição das principais unidades do VANT encontra-se a seguir [51]:
• Unidade de pressão (ou barométrica): é a unidade responsável pelo monitoramento
das velocidades vertical, horizontal e também da altitude do avião.
• Unidade inercial: esse subsistema tem a função de determinar a orientação
(posicionamento no espaço) da aeronave.
33
• Unidade de navegação: realiza o controle, o gerenciamento da missão e
principalmente a navegação da aeronave, de acordo com a rota que o avião deve
sobrevoar.
• Unidade de controle: basicamente é responsável pelo controle dos atuadores da
aeronave, permitindo o voo da mesma. Para isso, essa unidade recebe os comandos
e informações de direção por parte da unidade de navegação.
Entretanto, a fase de projeto de um sistema como o Tiriba é complexa, sendo necessário a
consideração de alguns aspectos além dos requisitos dos sistemas embarcados em geral.
Como se trata de uma aeronave de pequeno porte, a arquitetura utilizada para o
processamento das unidades tem impacto no peso da aeronave, fator que determina se a
aeronave será capaz ou não de voar.
O consumo de energia pela arquitetura utilizada é um fator que também interfere nesse
aspecto, pois deve ser utilizada uma bateria para suprimento de energia para as unidades de
processamento. Assim, se o consumo for alto, a capacidade da bateria deverá ser maior, e
consequentemente as suas dimensões serão maiores.
Por outro lado, o sistema deverá ser capaz de processar as informações das unidades
corretamente, com requisito de tempo real, para que a aeronave possa ter o controle sobre a
dinâmica do seu voo.
Assim, é importante que durante essa fase de projeto sejam feitas essas considerações.
Outro fator relevante é o custo do sistema final para saber se ele será viável ou não. Dessa
forma, a utilização de recursos para simular o funcionamento de sistemas desse tipo tendem a
auxiliar no processo do desenvolvimento de protótipos desses sistemas.
4.2 ArduPilotMega: Plataforma Arduino para VANTs
Atualmente está disponível no mercado um kit denominado ArduPilotMega (APM) [52],
para ser embarcado em um aeromodelo para voo autônomo da mesma, incluindo não somente
aeromodelos tradicionais, mas também multicópteros (quadricópteros, hexacópteros e
octocópteros, com 4, 6 e 8 hélices respectivamente). Basicamente, esse kit é composto de
duas placas, uma é o controlador Arduino Compatible ATMega2560 (na Figura 4.3), e a
segunda é a placa Ardupilot Mega 1 IMU Shield (na Figura 4.4).
34
Figura 4.3: Foto da placa controladora ATMega2560 [52].
Figura 4.4: Foto da placa IMU Shield [52].
O kit APM está disponível na DIY Drones Store, por $250 (GPS incluso) [53]. As
respectivas características das placas, estão descritas a seguir:
• ATMega2560: baseada no processador Atmega de 16 MHz, com dois
processadores com performance de 32 MIPS, é a placa controladora designada para
utilização com aeronaves autônomas. Suporta waypoints 3-D, possui um
mecanismo de controle de falha de hardware, usando circuito separado, com a
capacidade de reiniciar o processador principal (ATMega328) durante o voo. Essa
placa pode ser alimentada tanto por bateria ou através do receptor RC.
35
• IMU Shield: Essa placa provê uma série de sensores necessários para a navegação
autônoma da aeronave. Inclui sensores de pressão e temperatura, acelerômetro de 3
eixos, reguladores de voltagem, suporte a um módulo GPS (Global Positioning
System) e sensor de velocidade do ar.
Dessa forma, de acordo com [53,54], conectando essas placas, juntamente com um módulo
GPS incorporado à elas, é possível dar autonomia de voo a um aeromodelo ou a um
multicóptero. Entretanto, é necessário que os códigos-fonte dos algoritmos de controle sejam
compilados e carregados na ATMega2560. Além disso, pode-se perceber que a capacidade de
processamento desta placa é reduzida, principalmente com o intuito de economizar energia.
4.3 ArduPlane Software In The Loop (SITL)
O ArduPlane é um software de código aberto de controle de autonomia de voo para
pequenas aeronaves [12]. Ele permite que, através da sua compilação SITL, seja realizada
uma simulação de um voo autônomo sem se utilizar do hardware físico.
A compilação SITL realiza a simulação do hardware que seria utilizado em um VANT real
no nível de registradores, e assim o funcionamento dos drivers dos componentes físicos
normalmente usados em um voo real ocorrerá de forma semelhante na simulação.
O Arduplane se utiliza da biblioteca JSBSim [55], cuja função é de fornecer um modelo
para a dinâmica de voo e permitindo a simulação de uma aeronave em operação. Através de
diferentes modelos de componentes físicos, essa biblioteca, escrita em código C++, permite
coletar dados de altitude, velocidade, coordenadas (latitude e longitude) iniciais e direção da
aeronave que está sendo simulada. Opcionalmente, dados como direção e velocidade do vento
podem ser adicionados.
A simulação SITL, apesar de não executar sobre o processador real, sobrepõe algumas
limitações das simulações Hardware In The Loop (HITL), que são: a impossibilidade de se
utilizar de recursos como depuração de código e verificações de memória.
A organização geral dos componentes e a integração entre eles em um ambiente de
simulação ArduPlane-SITL pode ser visto na Figura 4.5:
36
Figura 4.5: Esquemático da Arquitetura do ArduPlane-SITL [12].
Para visualização da aeronave e da simulação do voo, pode ser usado o software
FlightGear, que recebe as informações do voo emulando uma conexão serial sobre o
protocolo UDP do núcleo do JSBSim. Para as trocas de mensagens, como por exemplo na
inserção dos pontos (waypoints) da trajetória a ser percorrida pela aeronave, é utilizado o
protocolo MAVLink [55].
Além disso, podem ser repassadas as informações da telemetria através do protocolo
MAVLink para outros sistemas, como o APM Planner [56], que possui a vantagem de
permitir a visualização do voo sobre o globo terrestre a partir das coordenadas do voo
recebidas, bem como informações de estado, como altura, dados do acelerômetro, trajetória da
rota percorrida, e até mesmo enviar comandos ao ArduPlane. Na Figura 4.6 pode ser
visualizado um screenshot do APM Planner recebendo os dados relacionados ao voo
simulado, através da execução do ArduPlane, neste caso em uma arquitetura x86.
37
Figura 4.6: Screenshot da simulação de um voo através do APM Planner para visualização do voo.
Dados como velocidade, altitude das coordenadas do voo simulado são úteis para entender
o comportamento do aeromodelo em operação. Esses dados da telemetria são repassados ao
APM Planner através de uma conexão TCP com o ArduPlane, pela porta 5763. Além disso,
pode ser usado o APM Planner no planejamento de rotas para a simulação de um voo, onde os
waypoints gerados podem ser carregados no ArduPlane. Na Figura 4.7 essa funcionalidade
pode ser visualizada.
Assim, a partir da conexão entre o APM Planner e o ArduPlane, é possível visualizar
simulações verificando a rota que o VANT percorre com relação ao planejamento do voo, em
tempo real.
38
Figura 4.7: APM Planner utilizado para criação de uma rota para um voo simulado.
4.4 Avaliação do SITL-ArduPlane na BeagleBoard-xM
A compilação SITL do software ArduPlane, com a intenção de simular um voo autônomo
de um VANT foi avaliada nos seguintes termos:
• Funcionamento: avaliou-se o comportamento da simulação do ArduPlane adaptada
para a placa BeagleBoard-xM.
• Desempenho: avaliou-se o desempenho da execução do ArduPlane na BeagleBoard-
xM;
• Potência: foi avaliado o consumo de potência por parte do DM3730, na execução do
ArduPlane na mesma placa de desenvolvimento;
Porém é necessário que o código do ArduPlane seja compilado para a placa BeagleBoard-
xM, modificando os parâmetros no código do SITL para que a comunicação entre o
ArduPlane (executado na placa) e os demais componentes da estrutura, como o simulador
físico (JSBSim), telemetria e o APM Planner, executados no host PC, seja realizada através
da interface de rede escolhida.
39
A Figura 4.8 mostra o esquemático do ambiente de simulação utilizado para realizar as
avaliações. A estrutura para execução em um ambiente desktop (Figura 4.5) foi modificada e
adaptada para permitir a execução do ArduPlane na BeagleBoard-xM. No entanto foi
utilizado um ambiente desktop, que atua como uma Estação Base da simulação, pois os
comandos para o ArduPlane são dados pela estação.
Figura 4.8: Esquemático da organização do ambiente de simulação
Os componentes executados na Estação Base que se comunicam com o ArduPlane na
BeagleBoard-xM são:
• JSBSim: fornece um modelo para a dinâmica de voo, permitindo a simulação do
modelo físico de um VANT. Envia pacotes com informações de estado da aeronave ao
ArduPlane através da porta UDP 5501, e recebe valores relacionados aos atuadores
simulados através da porta UDP 5502.
• MAVProxy [60]: é a GCS (Ground Control Station) propriamente dita, permite o
envio de comandos e recebimento de dados para VANTs em geral. Utiliza o protocolo
MAVLink para o envio dos pacotes. Se conecta com o ArduPlane através da porta
TCP 5760, para as informações da telemetria, e envia os comandos relacionados ao
voo pela porta UDP 5501.
40
• APM Planner: possui diversas funcionalidades, desde permitir a visualização do voo
simulado sobre o globo, como permitir uma conexão com o ArduPlane através da
porta TCP 5763. Esta conexão permite que o APM Planner envie comandos (e receba
dados do voo) ao VANT simulado.
As conexões entre os componentes executados na Estação e na BeagleBoard-xM podem
ser emuladas sobre um cabo USB OTG, que fornece energia e permite uma conexão IP com a
BeagleBoard-xM. A distribuição Linux Ubuntu foi utilizada tanto na BeagleBoard-xM,
quanto na Estação Base.
Neste contexto, uma simulação completa de uma missão, a partir do executável
Arduplane.elf (bloco vermelho, na Figura 4.8), tem o início no momento em que a conexão
entre o ArduPlane e os componentes da Estação Base for completada. O fluxo de execução de
uma simulação completa de uma missão pode ser visualizado na Figura 4.9.
Figura 4.9: Esquemático do fluxo de execução de uma simulação completa
Primeiramente, o ArduPlane espera por uma conexão com uma Estação Base. Após a
inicialização dos componentes lógicos (calibrar atuadores, definir altitude inicial do VANT,
entre outros), é possível enviar comandos de entrada ao ArduPlane através do MAVProxy ou
através de outra GCS. É necessário em seguida repassar uma missão ao ArduPlane, com
waypoints e seus respectivos comandos associados. Assim, através do comando 'auto' do
MAVProxy, a simulação do voo é iniciada.
41
4.4.1 Avaliação do Funcionamento
A avaliação do funcionamento do ArduPlane na BeagleBoard-xM foi realizada com o
intuito de validar o uso do ambiente de simulação adaptado para a execução do ArduPlane na
placa.
Nesta avaliação foram utilizadas três missões de teste (missao_1.txt, missao_2.txt e
missao_3.txt, cuja lista de waypoints se encontra no Apêndice A) para o plano de voo do
VANT simulado. As missões possuem quantidade de waypoints variável, e foram elaboradas
através do APM Planner. As missões 2 e 3, juntamente com a missão 1, foram utilizadas na
avaliação do funcionamento do ArduPlane na placa, e as duas missões podem ser vistas na
Figura 4.10, onde a missão 2 se refere à Figura 4.10 a) e a missão 3 à Figura 4.10 b). A
missão 1 foi escolhida para as análises de desempenho e consumo de potência, cujo plano de
voo pode ser visualizado na Figura 4.11.
Na Figura 4.11, o waypoint “Home” é a posição inicial do VANT, cujas coordenadas
geográficas, para a missão 1 (em amarelo) são: latitude -24,9870319366455; longitude:
-53,4522857666016. A altitude inicial foi especificada em 756 metros, com relação ao nível
do mar.
Figura 4.10: Planos de voo das missões 2 e 3, utilizadas na análise do funcionamento do ArduPlane
42
Figura 4.11: Plano de voo utilizado para as avaliações de desempenho e potência do ArduPlane
A altitude e a direção (heading) são repassadas ao ArduPlane através do JSBSim, durante a
inicialização da simulação. Ainda na inicialização, opcionalmente pode ser repassado também
através do JSBSim parâmetros relacionados ao vento, para tornar a simulação mais realista.
Esses parâmetros são divididos em velocidade, direção e nível de turbulência. Neste caso os
valores 5 m/s, 180 graus e 0.2 de turbulência foram definidos para a missão 1. A velocidade
média do VANT também é especificada na inicialização, porém ela varia durante a simulação.
O tempo médio de inicialização, avaliando-se 3 simulações da missão 1, foi de 33.9883
segundos. A partir disso, a missão pode ser carregada, e então a simulação do voo pode ser
iniciada, normalmente, através de um comando “auto”, enviado pelo console do MAVProxy.
A partir disso, o ArduPlane realiza os cálculos para buscar uma trajetória até o próximo
waypoint, um a um, até cumprir a missão repassada a ele. Na Figura 4.12, pode ser
visualizada a trajetória percorrida pelo VANT simulado. Pode-se perceber que a rota
percorrida (linha em azul) não corresponde exatamente ao planejamento (linhas amarelas),
devido aos cálculos aproximados realizados pelo ArduPlane. Porém esse comportamento
também é verificado em simulações do ArduPlane-SITL padrão para desktop.
43
Figura 4.12: Visualização da rota percorrida pelo VANT na simulação da missão 1
Ao alcançar o waypoint 3 (Figura 4.12), o avião entra em modo RTL (Return to Launch),
que significa que o mesmo irá retornar ao ponto de origem, ou seja, o waypoint “Home”. O
tempo médio entre as 3 simulações avaliadas para cumprir a missão 1, desde a decolagem até
o VANT entrar em modo RTL, foi de 230 segundos aproximadamente.
As simulações das missões 2 e 3 foram executadas com o intuito de validar o
comportamento do VANT simulado, ou seja, se a rota percorrida com relação ao plano de voo
foi satisfatória. A Tabela 4.1 traz informações sobre a execução de 3 simulações para cada
uma das 3 missões utilizadas neste estudo.
A Tabela 4.1 mostra informações de 3 simulações para cada uma das 3 missões de teste,
em relação aos waypoints do planejamento da missão e também o tempo aproximado de
duração do voo. Nas simulações da missão 1, todos os waypoints foram percorridos pelo
VANT e então o mesmo passou a atuar no modo RTL (Return to Launch), dirigindo-se para o
ponto inicial (waypoint “Home”) da simulação.
44
Tabela 4.1: Informações sobre o comportamento dos voos simulados das missões de teste
Wayponts percorridos
Simulações Missão 1 Simulações Missão 2 Simulações Missão 3
Home OK OK OK Home OK OK OK Home OK OK OK
2 OK OK OK 2 OK OK OK 2 OK OK OK
3 OK OK OK 3 OK Perdeu Perdeu 3 Perdeu OK Perdeu
4 - - - 4 OK OK OK 4 OK OK OK
RTL OK OK OK RTL OK OK OK RTL OK OK OK
Tempo de voo
Simulações Missão 1 Simulações Missão 2 Simulações Missão 3
Tempo: 237s 246s 207s Tempo: 93s 75s 59s Tempo: 74s 72s 89s
Entretanto, nas simulações das missões 2 e 3, constatou-se que o waypoint 3 não foi
percorrido corretamente pelo VANT, em duas das três simulações avaliadas. A verificação de
que houve perda de um waypoint ocorre quando o VANT circundar o waypoint de destino em
mais de 300 graus. A partir disso, o VANT desiste deste waypoint e segue para o próximo. No
trecho do código-fonte do ArduPlane, localizado na Figura 4.13, é possível visualizar esta
verificação, realizada através da variável “loiter_sum”. Porém esse comportamento avaliado
nas missões 2 e 3 não afetou o restante da simulação, pois os waypoints seguintes foram
percorridos corretamente.
Figura 4.13: Trecho do código-fonte do ArduPlane
Já com relação ao tempo de voo, o mesmo foi variável entre as simulações de todas as
missões avaliadas. O tempo foi medido a partir do envio do comando 'auto' do MAVProxy
45
para o ArduPlane, porém a decolagem não é imediata e esse atraso de tempo foi considerado
na avaliação, fato que contribuiu para variar o tempo de voo simulado.
4.4.2 Avaliação do Desempenho
De maneira semelhante à análise de desempenho do H.264 na BeagleBoard-xM (Seção
3.3.2), avaliou-se o desempenho do ArduPlane em execução na mesma placa de
desenvolvimento.
O desempenho foi analisado em termos de utilização de CPU, neste caso o processador
ARM da placa. Novamente, o aplicativo Vmstat foi utilizado para a análise de utilização de
CPU.
A análise de desempenho foi dividida em duas partes: a análise da inicialização do
ArduPlane e a da missão propriemente dita (voo simulado). Esta análise foi comparada com
uma outra compilação do ArduPlane, na qual foi utilizada uma flag de otimização do GCC
(flag O3). Foram realizados três testes para as duas partes de cada análise, para se obter uma
média do desempenho. Na parte da simulação do voo, a missão 1 (missao_1.txt) foi utilizada.
A Figura 4.14 mostra o gráfico da média de utilização de CPU, onde pode-se comparar a
análise do desempenho do ArduPlane compilado de forma padrão com a análise do
ArduPlane otimizado. A versão do GCC utilizada nas compilações foi a versão 4.6.1, para a
arquitetura destino arm-linux-gnueabi para a família de arquiteturas armv7. Na avaliação
constatou-se que houve um pequeno ganho de desempenho por parte da compilação
otimizada, 3,84% na inicialização e 0,585% durante a execução da missão.
Figura 4.14: Gráfico da utilização do processador ARM, na execução do ArduPlane na BeagleBoard-xM
46
Na inicialização, a utilização da CPU foi de 57,91% e na inicialização do ArduPlane
otimizado a utilização foi de 54,65%, em média. Durante a missão, devido a uma maior
quantidade de cálculos para determinar a rota do voo simulado, bem como aceleração,
direção, entre outros, foi exigido maior processamento. Dessa forma, a utilização de CPU
durante a simulação da missão, em média, alcançou 65,215% (ArduPlane) e 64,630%
(ArduPlane otimizado).
O baixo ganho de desempenho pode ser explicado por dois motivos: a utilização de CPU
relativamente baixa do ArduPlane sem ser otimizado mostra que o código utiliza pouco
processamento. Nas simulações da missão, a média do percentual de utilização “us” foi de
(20,45%). Além disso, constatou-se que outros fatores também podem influenciar no
desempenho da simulação em si, como desempenho da rede, por exemplo. Como o ArduPlane
aguarda a chegada dos pacotes pelas portas para processar, uma redução no desempenho da
rede pode influenciar no desempenho da simulação.
Com a utilização do software Gprof [61] é possível avaliar estimativas de tempo de
execução de uma aplicação, onde o tempo total é dividido entre todas as funções do código,
relacionadas à quantidade de chamadas que essas funções sofreram durante a execução.
O Gprof é normalmente utilizado para identificar problemas de desempenho em
aplicações. Com a utilização dele é possível verificar quais funções dentro do código-fonte de
uma aplicação não estão com desempenho esperado, para que então seja avaliado se é viável
otimizar a execução dessas funções.
Neste cenário, o Gprof foi utilizado na execução do ArduPlane para avaliar a viabilidade
de se reescrever partes do código para a execução no processador DSP, visto que todo o
ArduPlane é executado no ARM, neste trabalho.
No Apêndice B, o arquivo de resultado do Gprof na execução do ArduPlane pode ser
visualizado. A avaliação deste arquivo mostrou que não é viável a utilização do DSP, pois em
todas as funções no código do ArduPlane não há a necessidade de muito processamento.
Como essas funções do código-fonte ocupam um percentual pequeno do tempo total de
execução, a utilização do DSP provavelmente acarretaria em uma perda de desempenho,
tendo em vista que o tempo de comunicação entre os processadores pode ser maior do que o
tempo de processamento das funções.
A função “timer_handler(int)” do ArduPlane, possui o maior percentual de tempo de
execução, em torno de 55%. No entanto, a partir dessa função é que são chamadas todas as
47
demais funções do código, que ocupam um pequeno percentual do tempo total de execução.
Isso diminui a possibilidade de se obter ganhos de desempenho com a migração de partes do
código para o DSP.
4.4.3 Avaliação do consumo de Potência
A análise do consumo de potência pela execução do ArduPlane na BeagleBoard-xM
utilizou os métodos utilizados na análise de consumo de potência do H.264 (Seção 3.3.2). Os
dados coletados em duas etapas: durante a inicialização e durante a missão (voo simulado).
Foi utilizada a ferramenta I2c-tools nas medições via software sobre o componente MADC
da placa. Com sucessivas leituras, com um intervalo de 0.5 s, os valores dos componentes
ADCIN5 e ADCIN3 foram coletados, e aplicando a Equação 3.1, obteve-se a potência
consumida por parte do MPSoC DM3730.
Vale ressaltar que foi considerado apenas o consumo de potência do DM3730 da placa,
sem considerar outros componentes conectados pela USB ou por outras interfaces. Durante a
inicialização a potência média consumida foi aproximadamente 2,34 W, enquanto que durante
o voo simulado a média foi aproximadamente 2,38 W. A média para ambos os casos
considerou 3 simulações efetuadas.
Avaliando o consumo de potência por parte da compilação otimizada do ArduPlane na
BeagleBoard-xM, não foi possível afirmar que houve redução ou aumento no consumo de
potência, pois os dados coletados são muito próximos.
Um fato importante é analisar o consumo de potência relacionando com a alimentação da
placa através de uma bateria. Considere as especificações da bateria NOK-N97, disponível em
[62] com as seguintes características:
• Capacidade: 1900 mAh (mili-ampere por hora);
• Tensão: 4,2V;
• Tamanho: 11 x 7 x 2,2 (cm)
• Peso: 85 g;
Assim, é possível realizar uma estimativa da duração dessa bateria conectada à
BeagleBoard-xM. A média do consumo de potência pelo MPSoC da placa foi de 2,38 W
durante o voo simulado da missão 1. É necessário primeiramente converter esse valor para a
unidade utilizada pela capacidade da bateria (mAh).
48
Para isso, através da Equação 4.1 obtém-se a corrente elétrica (I) no valor de 566,6 mA
amperes, aproximadamente, dividindo-se a potência (P) consumida (2,38 W) pela tensão (T)
de 4,2 V utilizada pela placa. Assim, utilizando-se da capacidade da bateria descrita acima, o
tempo de duração da bateria através da execução do ArduPlane na BeagleBoard-xM seria de
aproximadamente 3,35 horas.
(4.1)
Obviamente que esses dados são estimados, pois a tensão utilizada pela placa não é
exatamente 4,2 V, e ainda que foi utilizado o valor médio do consumo de potência, deve-se
levar em consideração, ao acoplar uma bateria em um VANT, aspectos relacionados ao peso
da mesma e suas dimensões. Dependendo da bateria e do modelo do VANT, o voo pode ficar
prejudicado ou ainda ser impossibilitado.
49
I =P /T
Capítulo 5
Conclusões e Trabalhos Futuros
5.1 Conclusões
As arquiteturas MPSoC Heterogêneas são utilizadas no desenvolvimento de sistemas
embarcados por atenderem a alguns dos requisitos desses sistemas, principalmente ao
desempenho e ao consumo de potência.
Neste trabalho foram mostradas as características dos sistemas embarcados, bem como
aspectos relacionados ao desenvolvimento destes. Ambientes de programação desktop e
placas de desenvolvimento auxiliam na construção e validação desses sistemas.
Uma avaliação da decodificação de vídeos do padrão H.264 foi realizada, utilizando a
placa de desenvolvimento BeagleBoard-xM nesta tarefa. Apesar da decodificação de vídeos
requerer um desempenho elevado, a placa conseguiu um desempenho satisfatório na
decodificação utilizando o processador DSP. Entretanto, utilizando-se apenas o processador
ARM nesta tarefa ocasionou perdas de quadros.
As perdas de quadros podem ser explicadas pelo fato de que o experimento considerou
todos os componentes da decodificação e os componentes externos a ela, como por exemplo a
renderização do vídeo na tela, tornando a demanda por processamento sobre o processador
ARM muito elevada. Em contrapartida, utilizando-se do DSP para a decodificação do vídeo, e
o ARM para os outros componentes externos, o desempenho satisfatório foi alcançado.
Com relação ao consumo de potência, houve um aumento de 6,41% quando o DSP foi
utilizado na decodificação. Entretanto, os ganhos de desempenho foram maiores, pois além da
decodificação sem perdas de quadros, a utilização do DSP diminuiu a carga no processador
ARM, liberando-o para a execução de outras tarefas, por possuir, em média, 16% de tempo
ocioso durante a decodificação.
50
Utilizando-se das métricas deste experimento, foi possível avaliar o desempenho e
consumo de potência da execução do software ArduPlane, como estudo de caso principal
deste trabalho. O ArduPlane realiza o controle de navegação de um VANT em operação, por
meio de simulações, atráves de sua compilação SITL adaptada para a placa BeagleBoard-xM.
Primeiramente, a validação do comportamento da simulação do voo do VANT foi
necessária, com o intuito de verificar a viabilidade da utilização da placa de desenvolvimento
para a execução do ArduPlane. Foram realizadas 3 missões de voo, com rotas diferentes, e o
VANT conseguiu completá-las. Porém, a simulação do pouso do VANT não foi verificada,
apenas a decolagem e o voo foram considerados nas simulações.
Após isso, o desempenho do ArduPlane e o consumo de potência durante a execução do
mesmo foram avaliados, utilizando-se das mesmas métricas que foram usadas na avaliação da
decodificação de vídeos no padrão H.264.
Com relação ao desempenho, foram comparadas duas versões do ArduPlane, com dois
tipos diferentes de otimização realizadas na fase de compilação pelo GCC. A versão
otimizada obteve um pequeno ganho de desempenho, em média, 3,84% na inicialização da
simulação e 0,585% durante o voo simulado. Este fato pode ser explicado devido ao
ArduPlane ser desenvolvido originalmente para uma arquitetura baseada no processador
Arduino, que possui capacidade de processamento bem inferior comparada à BeagleBoard-
xM, e assim o código não necessita de otimizações para executar de maneira satisfatória na
placa.
Utilizando-se do Gprof foi verificado que não é viável reestruturar o código do ArduPlane
para obter paralelismo, através da utilização do processador DSP, pelo fato de que o código
não realiza operações que requerem grande poder de processamento. Assim, ao invés de um
ganho de desempenho, a utilização do DSP neste caso acarretaria em um overhead maior na
comunicação entre os processadores, diminuindo o desempenho.
Além disso, entre as duas versões do ArduPlane avaliadas não houve diferença
significativa no consumo de potência, pois a utilização do processador também possuiu pouca
diferença entre as versões. A estimativa do consumo de potência foi avaliada considerando
apenas o consumo por parte do MPSoC DM3730 da placa, sem considerar periféricos
conectados. Através dessa estimativa também calculou-se a duração de uma bateria, supondo
que a mesma fosse conectada à placa. A estimativa de duração foi realizada com a
51
justificativa de que um VANT real se utiliza uma bateria, necessária para o funcionamento do
controle de navegação do mesmo.
O objetivo principal do estudo de caso foi alcançado, de verificar a possibilidade da
utilização da BeagleBoard-xM para a execução do ArduPlane, em um ambiente de simulação.
Com as análises realizadas foi constatado que o comportamento das simulações se mostrou
satisfatório.
5.2 Trabalhos Futuros
Algumas alternativas podem ser exploradas com relação aos dois estudos de caso avaliados
neste trabalho, como trabalhos futuros.
Com relação à avaliação da decodificação de vídeos H.264, os resultados obtidos na parte
do desempenho da decodificação são válidos, porém podem ser avaliados de outras formas.
Um exemplo é avaliar o impacto no desempenho da decodificação utilizando-se de vídeos de
teste com diferentes características, como a taxa de bit, resolução de imagem e taxa de
quadros por segundo.
No estudo de caso da simulação do ArduPlane na BeagleBoard-xM, um requisito
importante no contexto dos sistemas embarcados críticos é a tolerância a falhas, o qual se
encontrou fora do escopo deste trabalho, e portanto não foi avaliado.
Uma outra avaliação possível é a inclusão de novas funcionalidades ao ArduPlane, como a
gravação de vídeos a partir de uma câmera, utilizando o processador DSP da placa, sem
alterar a funcionalidade de controle autônomo do ArduPlane.
Além disso, a simulação não considerou alterações no cenário de forma dinâmica, como
por exemplo o parâmetro relacionado ao vento, que permaneceu o mesmo durante cada voo
simulado, pois este parâmetro é repassado ao JSBSim no início da simulação.
Todas as simulações avaliadas são relacionadas à compilação Software In The Loop do
ArduPlane. Porém o ArduPlane dispõe de uma compilação Hardware In The Loop, criada
para a arquitetura ArduPilotMega. Poderia ser avaliado uma compilação HITL do ArduPlane
adaptada para a BeagleBoard-xM, necessitando que os sensores e atuadores sejam acoplados à
placa, visto que a mesma não os possui.
52
Apêndice A
Arquivos do Planejamento do Voo Simuladomissao_1.txt
missao_2.txt
missao_3.txt
53
Apêndice B
Arquivo resultado GPROF
Arquivo_1.txt
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
55.30 25.39 25.39 timer_handler(int)
4.62 27.51 2.12 main
3.79 29.25 1.74 3252581 0.00 0.00 millis
2.50 30.40 1.15 2388777 0.00 0.00 desktop_serial_select_setup(fd_set*, int*)
2.33 31.47 1.07 1983318 0.00 0.00 noise_generator
2.18 32.47 1.00 4214553 0.00 0.00 ADC_UDR2::operator=(unsigned char)
1.92 33.35 0.88 491629 0.00 0.00 Matrix3<float>::from_euler(float, float, float)
1.92 34.23 0.88 245813 0.00 0.00 sitl_update_barometer(float)
1.59 34.96 0.73 245813 0.00 0.01 sitl_update_adc(float, float, float, double, double, double, double,
double, double, float)
1.05 35.44 0.48 512115 0.00 0.00 select_check(int)
1.02 35.91 0.47 1983318 0.00 0.00 gyro_drift
1.02 36.38 0.47 1341376 0.00 0.00 Vector3<float>::Vector3()
0.96 36.82 0.44 491626 0.00 0.00 Matrix3<float>::operator*(Vector3<float> const&) const
0.91 37.24 0.42 4214553 0.00 0.00 ADC_SPI_transfer(unsigned char)
0.91 37.66 0.42 1074832 0.00 0.00 micros
0.91 38.08 0.42 245813 0.00 0.02 sitl_update_compass(float, float, float)
0.76 38.43 0.35 247913 0.00 0.02 AP_ADC_ADS7844::read(unsigned int)
0.68 38.74 0.31 245813 0.00 0.00 AP_Baro_BMP085_HIL::setHIL(float, float)
0.63 39.03 0.29 4214553 0.00 0.00 ADC_UDR2::operator int()
0.63 39.32 0.29 568330 0.00 0.00 Vector3<float>::operator*(Vector3<float> const&) const
54
0.63 39.61 0.29 245813 0.00 0.02 heading_to_mag(float, float, float)
0.61 39.89 0.28 245813 0.00 0.00 rand_vec3f()
0.52 40.13 0.24 2388777 0.00 0.00 loop()
0.52 40.37 0.24 245813 0.00 0.00 airspeed_sensor(float)
0.50 40.60 0.23 253036 0.00 0.00 sitl_simulator_output()
0.48 40.82 0.22 556781 0.00 0.00 Vector3<float>::length() const
0.46 41.03 0.21 790016 0.00 0.00 FastSerial::write(unsigned char)
0.44 41.23 0.20 2336834 0.00 0.00 Vector3<float>::Vector3(float, float, float)
0.44 41.43 0.20 253036 0.00 0.00 sitl_fdm_input()
0.39 41.61 0.18 245813 0.00 0.00 runInterrupt(unsigned char)
0.39 41.79 0.18 245813 0.00 0.00 AP_Compass_HIL::setHIL(float, float, float)
0.37 41.96 0.17 247911 0.00 0.00 RC_ICR4::operator int()
0.35 42.12 0.16 1966504 0.00 0.00 ADC_UDR2::set(unsigned char, float)
0.35 42.28 0.16 245813 0.00 0.00 Matrix3<float>::transposed() const
0.33 42.43 0.15 247911 0.00 0.00 failsafe_check(unsigned int)
0.33 42.58 0.15 247911 0.00 0.00 APM_RC_APM1::_timer4_capt_cb()
0.30 42.72 0.14 789892 0.00 0.00 comm_send_ch(mavlink_channel_t, unsigned char)
0.28 42.85 0.13 641988 0.00 0.00 sei
0.28 42.98 0.13 248571 0.00 0.00 convert_body_frame(double, double, double, double, double,
double*, double*, double*)
0.28 43.11 0.13 245815 0.00 0.00 Vector3<float>::operator/=(float)
0.26 43.23 0.12 272920 0.00 0.00 Vector3<float>::operator-(Vector3<float> const&) const
0.24 43.34 0.11 926359 0.00 0.00 check_connection(tcp_state*)
0.24 43.45 0.11 315108 0.00 0.00 Vector3<float>::operator+(Vector3<float> const&) const
0.24 43.56 0.11 253036 0.00 0.02 AP_TimerProcess::run()
0.20 43.65 0.09 714041 0.00 0.00 crc_accumulate
0.20 43.74 0.09 617725 0.00 0.00 DataFlash_Class::WriteByte(unsigned char)
0.20 43.83 0.09 257363 0.00 0.00 Matrix3<float>::Matrix3()
0.20 43.92 0.09 257362 0.00 0.00 Matrix3<float>::Matrix3(Vector3<float>, Vector3<float>,
Vector3<float>)
0.20 44.01 0.09 78363 0.00 0.01 _mavlink_send_uart
0.17 44.09 0.08 12076 0.01 0.01 AP_ADC_ADS7844::Ch6(unsigned char const*, float*)
0.17 44.17 0.08 2311 0.03 0.10 AP_GPS_UBLOX::read()
0.15 44.24 0.07 390381 0.00 0.00 Vector3<float>::operator*=(float)
0.15 44.31 0.07 245813 0.00 0.00 Vector3<float>::operator()(float, float, float)
0.13 44.37 0.06 344525 0.00 0.00 Vector3<float>::operator*(float) const
0.13 44.43 0.06 253037 0.00 0.00 sitl_update_gps(double, double, float, double, double, bool)
0.13 44.49 0.06 115700 0.00 0.00 RC_Channel::pwm_to_angle()
0.13 44.55 0.06 63984 0.00 0.00 PID::get_pid(int, unsigned short, float)
55
0.11 44.60 0.05 622589 0.00 0.00 DataFlash_APM1::BufferWrite(unsigned char, unsigned short,
unsigned char)
0.11 44.65 0.05 249823 0.00 0.00 AP_ParamV<Vector3<float>, (ap_var_type)5>::get() const
0.11 44.70 0.05 36228 0.00 0.00 AP_InertialSensor_Oilpan::_gyro_apply_std_offset(float)
0.11 44.75 0.05 11549 0.00 0.01 AP_AHRS_DCM::drift_correction(float)
0.07 44.78 0.03 1150370 0.00 0.00 AP_ParamT<short, (ap_var_type)2>::operator short&()
0.07 44.81 0.03 388952 0.00 0.00 cli
0.07 44.84 0.03 245813 0.00 0.00 Vector3<float>::normalize()
0.07 44.87 0.03 179655 0.00 0.00 GCS_MAVLINK::stream_trigger(GCS_MAVLINK::streams)
0.07 44.90 0.03 99963 0.00 0.00 APM_RC_APM1::InputCh(unsigned char)
0.07 44.93 0.03 52300 0.00 0.02 mavlink_send_message(mavlink_channel_t, ap_message,
unsigned short)
0.07 44.96 0.03 43777 0.00 0.00 RC_Channel::calc_pwm()
0.07 44.99 0.03 36228 0.00 0.00 AP_InertialSensor_Oilpan::_accel_apply_std_offset(float)
0.07 45.02 0.03 26121 0.00 0.00 crc_accumulate_buffer
0.07 45.05 0.03 23098 0.00 0.00 Vector3<float>::operator%(Vector3<float> const&) const
0.07 45.08 0.03 11549 0.00 0.01 set_servos()
0.07 45.11 0.03 11549 0.00 0.01 Log_Write_Raw()
0.07 45.14 0.03 11549 0.00 0.00 AP_AHRS_DCM::euler_angles()
0.04 45.16 0.02 46196 0.00 0.00 RC_Channel_aux::output_ch(unsigned char)
0.04 45.18 0.02 45783 0.00 0.00 pgm_read_pointer(void const*)
0.04 45.20 0.02 31992 0.00 0.00 RC_Channel::angle_to_pwm()
0.04 45.22 0.02 29202 0.00 0.00 comm_get_txspace(mavlink_channel_t)
0.04 45.24 0.02 29202 0.00 0.04 mavlink_try_send_message(mavlink_channel_t, ap_message,
unsigned short)
0.04 45.26 0.02 27899 0.00 0.00 comm_get_available(mavlink_channel_t)
0.04 45.28 0.02 26121 0.00 0.04 _mav_finalize_message_chan_send
0.04 45.30 0.02 26116 0.00 0.00 geofence_enabled()
0.04 45.32 0.02 23876 0.00 0.00 AP_ADC_ADS7844::Ch(unsigned char)
0.04 45.34 0.02 15373 0.00 0.00 GPS::status()
0.04 45.36 0.02 12076 0.00 0.02 AP_InertialSensor_Oilpan::update()
0.04 45.38 0.02 11651 0.00 0.00 AP_InertialSensor_Oilpan::get_accels(float*)
0.04 45.40 0.02 11579 0.00 0.00 control_failsafe(unsigned short)
0.04 45.42 0.02 11549 0.00 0.00 safe_asin(float)
0.04 45.44 0.02 11549 0.00 0.04 medium_loop()
0.04 45.46 0.02 11549 0.00 0.00 read_airspeed()
0.04 45.48 0.02 11549 0.00 0.00 calc_airspeed_errors()
0.04 45.50 0.02 11549 0.00 0.05 AP_AHRS_DCM::update()
0.04 45.52 0.02 10664 0.00 0.00 calc_nav_roll()
56
0.04 45.54 0.02 2758 0.01 0.05 send_vfr_hud(mavlink_channel_t)
0.04 45.56 0.02 2310 0.01 0.01 Compass::null_offsets()
0.02 45.57 0.01 136343 0.00 0.00 FastSerial::available()
0.02 45.58 0.01 104149 0.00 0.00 FastSerial::read()
0.02 45.59 0.01 94930 0.00 0.00 byte_swap_4
0.02 45.60 0.01 92632 0.00 0.00 RC_Channel::set_pwm(int)
0.02 45.61 0.01 85504 0.00 0.00 DataFlash_Class::WriteLong(int)
0.02 45.62 0.01 74928 0.00 0.00 AP_ParamA<float, (unsigned char)6, (ap_var_type)6>::operator[]
(unsigned char)
0.02 45.63 0.01 67587 0.00 0.00 byte_swap_2
0.02 45.64 0.01 52246 0.00 0.02 GCS_MAVLINK::send_message(ap_message)
0.02 45.65 0.01 23931 0.00 0.00 IMU::get_gyro()
0.02 45.66 0.01 12263 0.00 0.01 gcs_update()
0.02 45.67 0.01 12104 0.00 0.00 APM_RC_APM1::OutputCh_current(unsigned char)
0.02 45.68 0.01 11974 0.00 0.00 AP_InertialSensor_Oilpan::get_gyros(float*)
0.02 45.69 0.01 11579 0.00 0.00 RC_Channel::pwm_to_range()
0.02 45.70 0.01 11553 0.00 0.00 calc_bearing_error()
0.02 45.71 0.01 11549 0.00 0.00 check_short_failsafe()
0.02 45.72 0.01 11549 0.00 0.01 update_current_flight_mode()
0.02 45.73 0.01 11549 0.00 0.22 fast_loop()
0.02 45.74 0.01 11549 0.00 0.00 Matrix3<float>::rotate(Vector3<float> const&)
0.02 45.75 0.01 10664 0.00 0.00 calc_throttle()
0.02 45.76 0.01 10664 0.00 0.00 calc_nav_pitch()
0.02 45.77 0.01 10664 0.00 0.01 stabilize()
0.02 45.78 0.01 3275 0.00 0.00 geofence_check(bool)
0.02 45.79 0.01 3174 0.00 0.00 AP_Baro_BMP085_HIL::get_pressure()
0.02 45.80 0.01 2758 0.00 0.04 mavlink_msg_attitude_send
0.02 45.81 0.01 2310 0.00 0.01 read_barometer()
0.02 45.82 0.01 965 0.01 0.01 navigate()
0.02 45.83 0.01 833 0.01 0.06 send_raw_imu1(mavlink_channel_t)
0.02 45.84 0.01 833 0.01 0.05 send_raw_imu3(mavlink_channel_t)
0.02 45.85 0.01 833 0.01 0.05 mavlink_msg_raw_imu_send
0.02 45.86 0.01 820 0.01 0.01 APM_RC_APM1::clearOverride()
0.02 45.87 0.01 724 0.01 0.07 mavlink_delay(unsigned long)
0.02 45.88 0.01 76 0.13 0.13 AP_Param::find_by_header(AP_Param::Param_header, void**)
0.02 45.89 0.01 36 0.28 0.28 AP_Param::scan(AP_Param::Param_header const*, unsigned
short*)
0.02 45.90 0.01 20 0.50 0.50 AP_Param::check_group_info(AP_Param::GroupInfo const*,
unsigned short*, unsigned char)
57
0.02 45.91 0.01 1 10.00 21.94 AP_GPS_Auto::_detect()
0.00 45.91 0.00 351421 0.00 0.00 AP_ParamT<signed char, (ap_var_type)1>::operator signed
char&()
0.00 45.91 0.00 335917 0.00 0.00 AP_ParamT<short, (ap_var_type)2>::get() const
0.00 45.91 0.00 299076 0.00 0.00 AP_ParamT<float, (ap_var_type)4>::operator float&()
0.00 45.91 0.00 245869 0.00 0.00 pgm_read_byte
0.00 45.91 0.00 100776 0.00 0.00 sitl_gps_read(int, void*, unsigned int)
0.00 45.91 0.00 74928 0.00 0.00 DataFlash_Class::WriteInt(short)
0.00 45.91 0.00 69294 0.00 0.00 AP_IMU_INS::_calibrated(unsigned char, float)
0.00 45.91 0.00 52782 0.00 0.00 APM_RC_APM1::OutputCh(unsigned char, unsigned short)
0.00 45.91 0.00 47674 0.00 0.00 AP_ParamT<signed char, (ap_var_type)1>::get() const
0.00 45.91 0.00 36905 0.00 0.00 IMU::get_accel()
0.00 45.91 0.00 34647 0.00 0.00 AP_AHRS_DCM::renorm(Vector3<float> const&,
Vector3<float>&)
0.00 45.91 0.00 34647 0.00 0.00 Vector3<float>::is_nan()
0.00 45.91 0.00 29494 0.00 0.00 mavlink_get_channel_status
0.00 45.91 0.00 29202 0.00 0.00 FastSerial::txspace()
0.00 45.91 0.00 26408 0.00 0.00 crc_init
0.00 45.91 0.00 26121 0.00 0.00 crc_calculate
0.00 45.91 0.00 24526 0.00 0.00 GCS_MAVLINK::update()
0.00 45.91 0.00 23098 0.00 0.03 GCS_MAVLINK::data_stream_send()
0.00 45.91 0.00 21328 0.00 0.00 geofence_stickmixing()
0.00 45.91 0.00 14280 0.00 0.00 Vector3<float>::operator+=(Vector3<float> const&)
0.00 45.91 0.00 13422 0.00 0.00 AP_AHRS_DCM::get_gyro()
0.00 45.91 0.00 12439 0.00 0.00 wrap_180(long)
0.00 45.91 0.00 11813 0.00 0.05 gcs_send_message(ap_message)
0.00 45.91 0.00 11800 0.00 0.00 AP_AnalogSource_ADC::read()
0.00 45.91 0.00 11785 0.00 0.00 RC_Channel::range_to_pwm()
0.00 45.91 0.00 11579 0.00 0.01 read_radio()
0.00 45.91 0.00 11549 0.00 0.00 Log_Write_Attitude(short, short, unsigned short)
0.00 45.91 0.00 11549 0.00 0.06 gcs_data_stream_send()
0.00 45.91 0.00 11549 0.00 0.02 AP_IMU_INS::update()
0.00 45.91 0.00 11549 0.00 0.00 AP_AHRS_DCM::accel_adjust(Vector3<float>&)
0.00 45.91 0.00 11549 0.00 0.00 AP_AHRS_DCM::check_matrix()
0.00 45.91 0.00 11549 0.00 0.01 AP_AHRS_DCM::matrix_update(float)
0.00 45.91 0.00 11549 0.00 0.01 AP_AHRS_DCM::normalize()
0.00 45.91 0.00 11549 0.00 0.00 AP_InertialSensor_Oilpan::sample_time()
0.00 45.91 0.00 11549 0.00 0.00 GPS::acceleration()
0.00 45.91 0.00 11549 0.00 0.00 IMU::get_delta_time()
58
0.00 45.91 0.00 11549 0.00 0.00 Compass::use_for_yaw()
0.00 45.91 0.00 11549 0.00 0.00 Matrix3<float>::is_nan()
0.00 45.91 0.00 11549 0.00 0.00 Matrix3<float>::to_euler(float*, float*, float*)
0.00 45.91 0.00 11549 0.00 0.00 Matrix3<float>::operator+=(Matrix3<float> const&)
0.00 45.91 0.00 11549 0.00 0.00 Vector3<float>::is_inf()
0.00 45.91 0.00 11549 0.00 0.00 Matrix3<float>::operator+(Matrix3<float> const&) const
0.00 45.91 0.00 10664 0.00 0.00 calc_nav_yaw(float)
0.00 45.91 0.00 10664 0.00 0.00 crash_checker()
0.00 45.91 0.00 10664 0.00 0.00 throttle_slew_limit()
0.00 45.91 0.00 10431 0.00 0.00 delay
0.00 45.91 0.00 10431 0.00 0.00 delayMicroseconds
0.00 45.91 0.00 6090 0.00 0.00 RC_Channel::norm_output()
0.00 45.91 0.00 5937 0.00 0.00 byte_swap_8
0.00 45.91 0.00 3823 0.00 0.00 AP_AHRS_DCM::get_dcm_matrix()
0.00 45.91 0.00 3373 0.00 0.00 comm_receive_ch(mavlink_channel_t)
0.00 45.91 0.00 3373 0.00 0.00 mavlink_get_channel_buffer
0.00 45.91 0.00 3373 0.00 0.00 mavlink_parse_char
0.00 45.91 0.00 3143 0.00 0.00 AP_ParamT<int, (ap_var_type)3>::operator int&()
0.00 45.91 0.00 3142 0.00 0.00 AP_ParamT<float, (ap_var_type)4>::get() const
0.00 45.91 0.00 2976 0.00 0.00 gps_send(unsigned char, unsigned char*, unsigned short)
0.00 45.91 0.00 2906 0.00 0.00 AP_GPS_UBLOX::_parse_gps()
0.00 45.91 0.00 2758 0.00 0.04 sitl_simstate_send(unsigned char)
0.00 45.91 0.00 2758 0.00 0.04 mavlink_simstate_send(unsigned char, float, float, float, float,
float, float, float, float, float)
0.00 45.91 0.00 2758 0.00 0.04 send_attitude(mavlink_channel_t)
0.00 45.91 0.00 2758 0.00 0.04 send_simstate(mavlink_channel_t)
0.00 45.91 0.00 2758 0.00 0.04 mavlink_msg_simstate_send
0.00 45.91 0.00 2758 0.00 0.04 mavlink_msg_vfr_hud_send
0.00 45.91 0.00 2512 0.00 0.00 mavlink_update_checksum
0.00 45.91 0.00 2511 0.00 0.00 digitalWrite
0.00 45.91 0.00 2341 0.00 0.00 AP_Baro_BMP085_HIL::read()
0.00 45.91 0.00 2312 0.00 0.00 safe_sqrt(float)
0.00 45.91 0.00 2312 0.00 0.10 GPS::update()
0.00 45.91 0.00 2312 0.00 0.00 Compass::calculate(Matrix3<float> const&)
0.00 45.91 0.00 2311 0.00 0.00 AP_Compass_HIL::read()
0.00 45.91 0.00 2311 0.00 0.00 AP_AHRS::set_compass(Compass*)
0.00 45.91 0.00 2310 0.00 0.12 update_GPS()
0.00 45.91 0.00 2310 0.00 0.01 update_alt()
0.00 45.91 0.00 2310 0.00 0.01 Log_Write_GPS(int, int, int, int, int, int, int, unsigned char,
59
unsigned char)
0.00 45.91 0.00 2310 0.00 0.00 update_commands()
0.00 45.91 0.00 2310 0.00 0.00 update_GPS_light()
0.00 45.91 0.00 2310 0.00 0.00 calc_altitude_error()
0.00 45.91 0.00 2310 0.00 0.00 Log_Write_Nav_Tuning()
0.00 45.91 0.00 2310 0.00 0.00 Log_Write_Control_Tuning()
0.00 45.91 0.00 2310 0.00 0.00 calc_gndspeed_undershoot()
0.00 45.91 0.00 2309 0.00 0.00 slow_loop()
0.00 45.91 0.00 2251 0.00 0.00 AP_Param::find_var_info_group(AP_Param::GroupInfo const*,
unsigned char, unsigned char, unsigned char, unsigned char*, AP_Param::GroupInfo const**, unsigned char*)
0.00 45.91 0.00 2123 0.00 0.00 process_next_command()
0.00 45.91 0.00 1844 0.00 0.00 pgm_read_byte
0.00 45.91 0.00 1760 0.00 0.00 Vector3<short>::Vector3(short, short, short)
0.00 45.91 0.00 1700 0.00 0.00 AP_ParamV<Vector3<float>,
(ap_var_type)5>::set(Vector3<float>)
0.00 45.91 0.00 1552 0.00 0.00 AP_AHRS_DCM::get_gyro_drift()
0.00 45.91 0.00 1547 0.00 0.04 send_extended_status1(mavlink_channel_t, unsigned short)
0.00 45.91 0.00 1547 0.00 0.04 mavlink_msg_sys_status_send
0.00 45.91 0.00 1514 0.00 0.00 memcheck_available_memory()
0.00 45.91 0.00 1513 0.00 0.04 send_gps_raw(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.04 send_meminfo(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.04 send_location(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.04 send_radio_in(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.05 send_radio_out(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.00 send_fence_status(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.00 geofence_send_status(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.04 send_current_waypoint(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_rc_channels_raw_send(mavlink_channel_t,
unsigned int, unsigned char, unsigned short, unsigned short, unsigned short, unsigned short, unsigned short,
unsigned short, unsigned short, unsigned short, unsigned char)
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_servo_output_raw_send(mavlink_channel_t,
unsigned int, unsigned char, unsigned short, unsigned short, unsigned short, unsigned short, unsigned short,
unsigned short, unsigned short, unsigned short)
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_global_position_int_send(mavlink_channel_t,
unsigned int, int, int, int, int, short, short, short, unsigned short)
0.00 45.91 0.00 1513 0.00 0.04 send_ahrs(mavlink_channel_t)
0.00 45.91 0.00 1513 0.00 0.00 AP_AHRS_DCM::get_error_rp()
0.00 45.91 0.00 1513 0.00 0.00 AP_AHRS_DCM::get_error_yaw()
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_ahrs_send
60
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_global_position_int_send
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_gps_raw_send
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_meminfo_send
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_rc_channels_raw_send
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_servo_output_raw_send
0.00 45.91 0.00 1513 0.00 0.04 mavlink_msg_waypoint_current_send
0.00 45.91 0.00 1449 0.00 0.04 send_nav_controller_output(mavlink_channel_t)
0.00 45.91 0.00 1449 0.00 0.04 mavlink_msg_nav_controller_output_send
0.00 45.91 0.00 1429 0.00 0.00 eeprom_open
0.00 45.91 0.00 1301 0.00 0.00 AP_Param::type_size(ap_var_type)
0.00 45.91 0.00 1215 0.00 0.00 DataFlash_APM1::BufferToPage(unsigned char, unsigned short,
unsigned char)
0.00 45.91 0.00 1123 0.00 0.00 eeprom_read_block
0.00 45.91 0.00 967 0.00 0.00 get_bearing(Location*, Location*)
0.00 45.91 0.00 964 0.00 0.00 get_distance(Location*, Location*)
0.00 45.91 0.00 961 0.00 0.00 update_navigation()
0.00 45.91 0.00 886 0.00 0.00 update_crosstrack()
0.00 45.91 0.00 882 0.00 0.00 verify_nav_wp()
0.00 45.91 0.00 882 0.00 0.00 verify_commands()
0.00 45.91 0.00 882 0.00 0.00 verify_nav_command()
0.00 45.91 0.00 882 0.00 0.00 verify_condition_command()
0.00 45.91 0.00 864 0.00 0.00 AP_Baro_BMP085_HIL::get_temperature()
0.00 45.91 0.00 833 0.00 0.04 send_raw_imu2(mavlink_channel_t)
0.00 45.91 0.00 833 0.00 0.04 send_servo_out(mavlink_channel_t)
0.00 45.91 0.00 833 0.00 0.04 mavlink_msg_rc_channels_scaled_send(mavlink_channel_t,
unsigned int, unsigned char, short, short, short, short, short, short, short, short, unsigned char)
0.00 45.91 0.00 833 0.00 0.00 AP_IMU_INS::ax()
0.00 45.91 0.00 833 0.00 0.00 AP_IMU_INS::ay()
0.00 45.91 0.00 833 0.00 0.00 AP_IMU_INS::az()
0.00 45.91 0.00 833 0.00 0.00 AP_IMU_INS::gx()
0.00 45.91 0.00 833 0.00 0.00 AP_IMU_INS::gy()
0.00 45.91 0.00 833 0.00 0.00 AP_IMU_INS::gz()
0.00 45.91 0.00 833 0.00 0.00 AP_Baro_BMP085_HIL::get_raw_temp()
0.00 45.91 0.00 833 0.00 0.00 AP_Baro_BMP085_HIL::get_raw_pressure()
0.00 45.91 0.00 833 0.00 0.00 Compass::get_offsets()
0.00 45.91 0.00 833 0.00 0.00 Compass::get_declination()
0.00 45.91 0.00 833 0.00 0.00 AP_ParamV<Vector3<float>, (ap_var_type)5>::operator
Vector3<float>&()
0.00 45.91 0.00 833 0.00 0.04 mavlink_msg_rc_channels_scaled_send
61
0.00 45.91 0.00 833 0.00 0.04 mavlink_msg_scaled_pressure_send
0.00 45.91 0.00 833 0.00 0.04 mavlink_msg_sensor_offsets_send
0.00 45.91 0.00 772 0.00 0.00 update_servo_switches()
0.00 45.91 0.00 771 0.00 0.00 update_aux_servo_function(RC_Channel_aux*,
RC_Channel_aux*, RC_Channel_aux*, RC_Channel_aux*)
0.00 45.91 0.00 771 0.00 0.00 readSwitch()
0.00 45.91 0.00 771 0.00 0.00 read_control_switch()
0.00 45.91 0.00 770 0.00 0.00 check_long_failsafe()
0.00 45.91 0.00 769 0.00 0.00 update_events()
0.00 45.91 0.00 769 0.00 0.00 wrap_360(long)
0.00 45.91 0.00 578 0.00 0.00 strncpy_P
0.00 45.91 0.00 552 0.00 0.00 AP_Param::next(AP_Param::ParamToken*, ap_var_type*)
0.00 45.91 0.00 546 0.00 0.00 AP_Param::next_scalar(AP_Param::ParamToken*, ap_var_type*)
0.00 45.91 0.00 494 0.00 0.04 send_heartbeat(mavlink_channel_t)
0.00 45.91 0.00 494 0.00 0.04 mavlink_msg_heartbeat_send
0.00 45.91 0.00 434 0.00 0.00 _mav_put_int8_t_array
0.00 45.91 0.00 434 0.00 0.00 mav_array_memcpy
0.00 45.91 0.00 400 0.00 0.05 AP_Param::find_var_info(unsigned char*, AP_Param::GroupInfo
const**, unsigned char*)
0.00 45.91 0.00 387 0.00 0.00 AP_Param::next_group(unsigned char, AP_Param::GroupInfo
const*, bool*, unsigned char, unsigned char, AP_Param::ParamToken*, ap_var_type*)
0.00 45.91 0.00 379 0.00 0.00 pgm_read_word
0.00 45.91 0.00 364 0.00 0.00 mav_var_type(ap_var_type)
0.00 45.91 0.00 364 0.00 0.04 mavlink_msg_param_value_send(mavlink_channel_t, char const*,
float, unsigned char, unsigned short, unsigned short)
0.00 45.91 0.00 364 0.00 0.09 GCS_MAVLINK::queued_param_send()
0.00 45.91 0.00 364 0.00 0.00 AP_Param::cast_to_float(ap_var_type)
0.00 45.91 0.00 364 0.00 0.05 AP_Param::copy_name(char*, unsigned int, bool)
0.00 45.91 0.00 364 0.00 0.04 mavlink_msg_param_value_send
0.00 45.91 0.00 287 0.00 0.00 GCS_MAVLINK::handleMessage(__mavlink_message*)
0.00 45.91 0.00 287 0.00 0.00 mavlink_start_checksum
0.00 45.91 0.00 230 0.00 0.05 one_second_loop()
0.00 45.91 0.00 230 0.00 0.00 Log_Write_Current()
0.00 45.91 0.00 175 0.00 0.00 eeprom_read_byte
0.00 45.91 0.00 174 0.00 0.00 AP_ParamT<short, (ap_var_type)2>::cast_to_float()
0.00 45.91 0.00 144 0.00 0.00 AP_ParamT<short,
(ap_var_type)2>::set_and_save_ifchanged(short)
0.00 45.91 0.00 128 0.00 0.00 DataFlash_APM1::BufferRead(unsigned char, unsigned short)
0.00 45.91 0.00 116 0.00 0.00 AP_ParamT<signed char, (ap_var_type)1>::cast_to_float()
62
0.00 45.91 0.00 95 0.00 0.00 AP_Param::duplicate_key(unsigned char, unsigned char)
0.00 45.91 0.00 89 0.00 0.00 flash_leds(bool)
0.00 45.91 0.00 88 0.00 0.00 AP_ParamT<short, (ap_var_type)2>::AP_ParamT(short)
0.00 45.91 0.00 78 0.00 0.00 pgm_read_byte_far
0.00 45.91 0.00 74 0.00 0.00 eeprom_write_byte
0.00 45.91 0.00 72 0.00 0.00 AP_ParamT<float, (ap_var_type)4>::cast_to_float()
0.00 45.91 0.00 60 0.00 0.04 mavlink_msg_statustext_send
0.00 45.91 0.00 59 0.00 0.00 AP_ParamT<signed char, (ap_var_type)1>::AP_ParamT(signed
char)
0.00 45.91 0.00 54 0.00 0.04 send_statustext(mavlink_channel_t)
0.00 45.91 0.00 52 0.00 0.00 AP_Param::find_by_header_group(AP_Param::Param_header,
void**, unsigned char, AP_Param::GroupInfo const*, unsigned char, unsigned char)
0.00 45.91 0.00 44 0.00 0.00 memcpy_P
0.00 45.91 0.00 39 0.00 0.00 eeprom_read_dword
0.00 45.91 0.00 36 0.00 0.00 DataFlash_APM1::ReadStatus()
0.00 45.91 0.00 36 0.00 0.00 DataFlash_APM1::WaitReady()
0.00 45.91 0.00 35 0.00 0.00 _MAV_RETURN_float
0.00 45.91 0.00 35 0.00 0.00 AP_Param::eeprom_write_check(void const*, unsigned short,
unsigned char)
0.00 45.91 0.00 35 0.00 0.33 AP_Param::save()
0.00 45.91 0.00 33 0.00 0.00 AP_ParamT<float, (ap_var_type)4>::AP_ParamT(float)
0.00 45.91 0.00 32 0.00 0.00 Vector3<float>::zero()
0.00 45.91 0.00 31 0.00 0.00 DataFlash_APM1::PageToBuffer(unsigned char, unsigned short)
0.00 45.91 0.00 31 0.00 0.00 DataFlash_Class::GetFileNumber()
0.00 45.91 0.00 31 0.00 0.00 DataFlash_Class::StartRead(short)
0.00 45.91 0.00 29 0.00 0.00 mavlink_check_target(unsigned char, unsigned char)
0.00 45.91 0.00 29 0.00 0.00 DataFlash_Class::GetFilePage()
0.00 45.91 0.00 28 0.00 0.03 mavlink_send_text(mavlink_channel_t, gcs_severity, char
const*)
0.00 45.91 0.00 28 0.00 0.03 GCS_MAVLINK::send_text(gcs_severity, prog_char_t const*)
0.00 45.91 0.00 24 0.00 0.00 _MAV_RETURN_uint16_t
0.00 45.91 0.00 21 0.00 0.00 pinMode
0.00 45.91 0.00 20 0.00 0.00 PID::reset_I()
0.00 45.91 0.00 20 0.00 0.00 Vector3<short>::Vector3()
0.00 45.91 0.00 18 0.00 0.00 BetterStream::_vprintf(unsigned char, char const*, std::__va_list)
0.00 45.91 0.00 18 0.00 0.00 BetterStream::_printf_P(char const*, ...)
0.00 45.91 0.00 18 0.00 0.00 eeprom_write_dword
0.00 45.91 0.00 18 0.00 0.00 mavlink_msg_request_data_stream_decode
0.00 45.91 0.00 18 0.00 0.00 mavlink_msg_request_data_stream_get_req_message_rate
63
0.00 45.91 0.00 18 0.00 0.00 mavlink_msg_request_data_stream_get_req_stream_id
0.00 45.91 0.00 18 0.00 0.00 mavlink_msg_request_data_stream_get_start_stop
0.00 45.91 0.00 18 0.00 0.00 mavlink_msg_request_data_stream_get_target_component
0.00 45.91 0.00 18 0.00 0.00 mavlink_msg_request_data_stream_get_target_system
0.00 45.91 0.00 16 0.00 0.05 gcs_send_text_fmt(prog_char_t const*, ...)
0.00 45.91 0.00 13 0.00 0.00 resetPerfData()
0.00 45.91 0.00 13 0.00 0.05 gcs_send_text_P(gcs_severity, prog_char_t const*)
0.00 45.91 0.00 13 0.00 0.00 get_cmd_with_index(int)
0.00 45.91 0.00 13 0.00 0.01 Log_Write_Performance()
0.00 45.91 0.00 11 0.00 0.00 pgm_read_byte
0.00 45.91 0.00 9 0.00 0.00 Log_Write_Cmd(unsigned char, Location*)
0.00 45.91 0.00 8 0.00 0.00 RC_Channel::RC_Channel()
0.00 45.91 0.00 8 0.00 0.00 APM_RC_APM1::enable_out(unsigned char)
0.00 45.91 0.00 8 0.00 0.00 AP_ParamT<short, (ap_var_type)2>::set(short)
0.00 45.91 0.00 7 0.00 0.00 PID::PID(float const&, float const&, float const&, short const&)
0.00 45.91 0.00 7 0.00 0.33 AP_ParamT<signed char, (ap_var_type)1>::set_and_save(signed
char)
0.00 45.91 0.00 7 0.00 0.00 AP_ParamT<signed char, (ap_var_type)1>::set(signed char)
0.00 45.91 0.00 7 0.00 0.33 AP_ParamT<short, (ap_var_type)2>::set_and_save(short)
0.00 45.91 0.00 6 0.00 0.00 set_nonblocking(int)
0.00 45.91 0.00 6 0.00 0.00 set_cmd_with_index(Location, int)
0.00 45.91 0.00 6 0.00 0.04 mavlink_msg_statustext_send(mavlink_channel_t, unsigned char,
char const*)
0.00 45.91 0.00 6 0.00 0.00 AP_Param::add_vector3f_suffix(char*, unsigned int, unsigned char)
0.00 45.91 0.00 5 0.00 0.00 reset_I()
0.00 45.91 0.00 5 0.00 0.04 GCS_MAVLINK::queued_waypoint_send()
0.00 45.91 0.00 5 0.00 0.00 Menu::Menu(char const*, Menu::command const*, unsigned char,
bool (*)())
0.00 45.91 0.00 5 0.00 0.00 Compass::null_offsets_enable()
0.00 45.91 0.00 5 0.00 0.00 AP_ParamT<short, (ap_var_type)2>::operator=(short)
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_decode
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_autocontinue
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_command
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_current
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_frame
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_param1
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_param2
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_param3
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_param4
64
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_seq
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_target_component
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_target_system
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_x
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_y
0.00 45.91 0.00 5 0.00 0.00 mavlink_msg_waypoint_get_z
0.00 45.91 0.00 5 0.00 0.04 mavlink_msg_waypoint_request_send
0.00 45.91 0.00 4 0.00 0.00 update_loiter()
0.00 45.91 0.00 4 0.00 0.05 process_nav_cmd()
0.00 45.91 0.00 4 0.00 0.05 handle_process_nav_cmd()
0.00 45.91 0.00 4 0.00 0.00 set_mode(unsigned char)
0.00 45.91 0.00 4 0.00 0.00 FastSerial::begin(long)
0.00 45.91 0.00 4 0.00 0.33 RC_Channel::set_dead_zone(int)
0.00 45.91 0.00 4 0.00 0.00 AP_Declination::get_lookup_value(unsigned char, unsigned char)
0.00 45.91 0.00 4 0.00 0.00 RC_Channel_aux::RC_Channel_aux()
0.00 45.91 0.00 4 0.00 0.00 DataFlash_Class::ReadByte()
0.00 45.91 0.00 4 0.00 0.00 Compass::null_offsets_disable()
0.00 45.91 0.00 4 0.00 0.00 AP_Param::first(AP_Param::ParamToken*, ap_var_type*)
0.00 45.91 0.00 3 0.00 0.51 demo_servos(unsigned char)
0.00 45.91 0.00 3 0.00 0.00 set_next_WP(Location*)
0.00 45.91 0.00 3 0.00 0.00 Log_Write_Mode(unsigned char)
0.00 45.91 0.00 3 0.00 0.00 reset_crosstrack()
0.00 45.91 0.00 3 0.00 0.00 do_nav_wp()
0.00 45.91 0.00 3 0.00 0.00 FastSerial::begin(long, unsigned int, unsigned int)
0.00 45.91 0.00 3 0.00 0.00 FastSerial::FastSerial(unsigned char, unsigned char volatile*,
unsigned char volatile*, unsigned char volatile*, unsigned char volatile*, unsigned char, unsigned char, unsigned
char)
0.00 45.91 0.00 3 0.00 1.63 RC_Channel::save_eeprom()
0.00 45.91 0.00 3 0.00 0.00 RC_Channel::set_angle(int)
0.00 45.91 0.00 3 0.00 0.05 GCS_MAVLINK::_count_parameters()
0.00 45.91 0.00 3 0.00 0.00 BetterStream::BetterStream()
0.00 45.91 0.00 3 0.00 0.00 Print::print(char, int)
0.00 45.91 0.00 3 0.00 0.00 Print::print(long, int)
0.00 45.91 0.00 3 0.00 0.00 Print::Print()
0.00 45.91 0.00 3 0.00 0.00 Stream::Stream()
0.00 45.91 0.00 3 0.00 0.33 Compass::save_offsets()
0.00 45.91 0.00 3 0.00 0.00 mavlink_msg_param_request_list_decode
0.00 45.91 0.00 3 0.00 0.00 mavlink_msg_param_request_list_get_target_component
0.00 45.91 0.00 3 0.00 0.00 mavlink_msg_param_request_list_get_target_system
65
0.00 45.91 0.00 2 0.00 0.00 sitl_gps_pipe()
0.00 45.91 0.00 2 0.00 0.04 send_gps_status(mavlink_channel_t)
0.00 45.91 0.00 2 0.00 0.00 tcp_start_connection(unsigned int, bool)
0.00 45.91 0.00 2 0.00 0.00 FastSerial::set_blocking_writes(bool)
0.00 45.91 0.00 2 0.00 0.00 FastSerial::flush()
0.00 45.91 0.00 2 0.00 0.00 GCS_MAVLINK::init(FastSerial*)
0.00 45.91 0.00 2 0.00 0.00 GCS_MAVLINK::GCS_MAVLINK()
0.00 45.91 0.00 2 0.00 0.00 BetterStream::print_P(prog_char_t const*)
0.00 45.91 0.00 2 0.00 0.01 AP_ADC_ADS7844::Init(AP_PeriodicProcess*)
0.00 45.91 0.00 2 0.00 0.00 AP_TimerProcess::resume_timer()
0.00 45.91 0.00 2 0.00 0.00 AP_TimerProcess::suspend_timer()
0.00 45.91 0.00 2 0.00 0.00 AP_TimerProcess::register_process(void (*)(unsigned int))
0.00 45.91 0.00 2 0.00 0.00 DataFlash_Class::find_last_page()
0.00 45.91 0.00 2 0.00 0.00 Arduino_Mega_ISR_Registry::register_signal(int, void (*)())
0.00 45.91 0.00 2 0.00 0.00 GPS::GPS(Stream*)
0.00 45.91 0.00 2 0.00 0.00 AP_ParamT<float, (ap_var_type)4>::set(float)
0.00 45.91 0.00 2 0.00 0.00 AP_ParamT<int, (ap_var_type)3>::cast_to_float()
0.00 45.91 0.00 2 0.00 0.00 GCS_Class::init(FastSerial*)
0.00 45.91 0.00 2 0.00 0.00 GCS_Class::GCS_Class()
0.00 45.91 0.00 2 0.00 0.00 Vector3<float>::operator/(float) const
0.00 45.91 0.00 2 0.00 0.04 mavlink_msg_gps_status_send
0.00 45.91 0.00 2 0.00 0.04 mavlink_msg_waypoint_ack_send
0.00 45.91 0.00 1 0.00 0.01 _GLOBAL__sub_I_Serial
0.00 45.91 0.00 1 0.00 0.00 _GLOBAL__sub_I_rcout_addr
0.00 45.91 0.00 1 0.00 0.03 sitl_setup()
0.00 45.91 0.00 1 0.00 0.00 memcheck_init()
0.00 45.91 0.00 1 0.00 0.00 sitl_setup_adc()
0.00 45.91 0.00 1 0.00 0.01 __static_initialization_and_destruction_0(int, int)
0.00 45.91 0.00 1 0.00 0.00 __static_initialization_and_destruction_0(int, int)
0.00 45.91 0.00 1 0.00 81.25 setup()
0.00 45.91 0.00 1 0.00 0.10 init_home()
0.00 45.91 0.00 1 0.00 1.31 init_rc_in()
0.00 45.91 0.00 1 0.00 5.29 trim_radio()
0.00 45.91 0.00 1 0.00 0.00 init_rc_out()
0.00 45.91 0.00 1 0.00 0.00 setup_timer()
0.00 45.91 0.00 1 0.00 0.00 update_auto()
0.00 45.91 0.00 1 0.00 0.00 map_baudrate(signed char, unsigned int)
0.00 45.91 0.00 1 0.00 0.33 init_commands()
0.00 45.91 0.00 1 0.00 1.13 zero_airspeed()
66
0.00 45.91 0.00 1 0.00 81.25 init_ardupilot()
0.00 45.91 0.00 1 0.00 2.89 init_barometer()
0.00 45.91 0.00 1 0.00 59.17 startup_ground()
0.00 45.91 0.00 1 0.00 20.40 load_parameters()
0.00 45.91 0.00 1 0.00 0.00 read_alt_to_hold()
0.00 45.91 0.00 1 0.00 0.02 Log_Write_Startup(unsigned char)
0.00 45.91 0.00 1 0.00 52.32 startup_IMU_ground(bool)
0.00 45.91 0.00 1 0.00 0.00 reset_control_switch()
0.00 45.91 0.00 1 0.00 0.00 do_RTL()
0.00 45.91 0.00 1 0.00 0.00 setup_fdm()
0.00 45.91 0.00 1 0.00 37.87 AP_IMU_INS::_init_gyro(void (*)(unsigned long), void (*)(bool))
0.00 45.91 0.00 1 0.00 9.28 AP_IMU_INS::init_accel(void (*)(unsigned long), void (*)(bool))
0.00 45.91 0.00 1 0.00 8.95 AP_IMU_INS::_init_accel(void (*)(unsigned long), void (*)(bool))
0.00 45.91 0.00 1 0.00 0.00 AP_IMU_INS::get_gyro_drift_rate()
0.00 45.91 0.00 1 0.00 38.21 AP_IMU_INS::init(IMU::Start_style, void (*)(unsigned long), void
(*)(bool), AP_PeriodicProcess*)
0.00 45.91 0.00 1 0.00 0.00 AP_IMU_INS::AP_IMU_INS(AP_InertialSensor*)
0.00 45.91 0.00 1 0.00 0.00 ModeFilter<short, (unsigned char)5>::ModeFilter(unsigned char)
0.00 45.91 0.00 1 0.00 0.00 Parameters::Parameters()
0.00 45.91 0.00 1 0.00 0.00 RC_Channel::set_apm_rc(APM_RC_Class*)
0.00 45.91 0.00 1 0.00 0.00 RC_Channel::set_range(int, int)
0.00 45.91 0.00 1 0.00 0.00 APM_RC_APM1::Init(Arduino_Mega_ISR_Registry*)
0.00 45.91 0.00 1 0.00 0.00 APM_RC_APM1::setHIL(short*)
0.00 45.91 0.00 1 0.00 0.00 APM_RC_APM1::APM_RC_APM1()
0.00 45.91 0.00 1 0.00 0.00 AP_AHRS_DCM::reset(bool)
0.00 45.91 0.00 1 0.00 0.00 AP_AHRS_DCM::AP_AHRS_DCM(IMU*, GPS*&)
0.00 45.91 0.00 1 0.00 0.00 AP_GPS_Auto::init()
0.00 45.91 0.00 1 0.00 21.94 AP_GPS_Auto::read()
0.00 45.91 0.00 1 0.00 0.00 AP_GPS_Auto::AP_GPS_Auto(FastSerial*, GPS**)
0.00 45.91 0.00 1 0.00 0.00 RangeFinder::RangeFinder(AP_AnalogSource*, Filter<short>*)
0.00 45.91 0.00 1 0.00 0.00 APM_RC_Class::APM_RC_Class()
0.00 45.91 0.00 1 0.00 0.00 AP_GPS_UBLOX::init()
0.00 45.91 0.00 1 0.00 0.00 AP_GPS_UBLOX::AP_GPS_UBLOX(Stream*)
0.00 45.91 0.00 1 0.00 0.01 BetterStream::println_P(prog_char_t const*)
0.00 45.91 0.00 1 0.00 0.00 AP_ADC_ADS7844::AP_ADC_ADS7844()
0.00 45.91 0.00 1 0.00 0.00 AP_Compass_HIL::AP_Compass_HIL()
0.00 45.91 0.00 1 0.00 0.00 AP_Declination::get_declination(float, float)
0.00 45.91 0.00 1 0.00 0.00 DataFlash_APM1::CardInserted()
0.00 45.91 0.00 1 0.00 0.00 DataFlash_APM1::Init()
67
0.00 45.91 0.00 1 0.00 0.00 DataFlash_APM1::DataFlash_APM1()
0.00 45.91 0.00 1 0.00 0.00 AP_AnalogSource::AP_AnalogSource()
0.00 45.91 0.00 1 0.00 0.00 AP_TimerProcess::set_failsafe(void (*)(unsigned int))
0.00 45.91 0.00 1 0.00 0.00 AP_TimerProcess::init(Arduino_Mega_ISR_Registry*)
0.00 45.91 0.00 1 0.00 0.00 AP_TimerProcess::AP_TimerProcess(unsigned char)
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::StartWrite(short)
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::SetFileNumber(unsigned short)
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::find_last_log()
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::start_new_log()
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::ReadLong()
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::NeedErase()
0.00 45.91 0.00 1 0.00 0.00 DataFlash_Class::DataFlash_Class()
0.00 45.91 0.00 1 0.00 0.00 FilterWithBuffer<short, (unsigned char)5>::reset()
0.00 45.91 0.00 1 0.00 0.00 FilterWithBuffer<short, (unsigned char)5>::FilterWithBuffer()
0.00 45.91 0.00 1 0.00 0.00 AP_InertialSensor::AP_InertialSensor()
0.00 45.91 0.00 1 0.00 0.00 AP_Baro_BMP085_HIL::init(AP_PeriodicProcess*)
0.00 45.91 0.00 1 0.00 0.00 AP_Baro_BMP085_HIL::AP_Baro_BMP085_HIL()
0.00 45.91 0.00 1 0.00 0.00 AP_PeriodicProcess::AP_PeriodicProcess()
0.00 45.91 0.00 1 0.00 0.00 AP_AnalogSource_ADC::AP_AnalogSource_ADC(AP_ADC*, int,
float)
0.00 45.91 0.00 1 0.00 0.00 AP_InertialSensor_Oilpan::get_gyro_drift_rate()
0.00 45.91 0.00 1 0.00 0.01 AP_InertialSensor_Oilpan::init(AP_PeriodicProcess*)
0.00 45.91 0.00 1 0.00 0.00 AP_InertialSensor_Oilpan::AP_InertialSensor_Oilpan(AP_ADC*)
0.00 45.91 0.00 1 0.00 0.00
AP_RangeFinder_MaxsonarXL::AP_RangeFinder_MaxsonarXL(AP_AnalogSource*, Filter<short>*)
0.00 45.91 0.00 1 0.00 0.00 Arduino_Mega_ISR_Registry::init()
0.00 45.91 0.00 1 0.00 0.00 IMU::IMU()
0.00 45.91 0.00 1 0.00 0.00 Print::println()
0.00 45.91 0.00 1 0.00 0.00 AP_ADC::AP_ADC()
0.00 45.91 0.00 1 0.00 0.00 Filter<short>::reset()
0.00 45.91 0.00 1 0.00 0.00 Filter<short>::Filter()
0.00 45.91 0.00 1 0.00 0.00 AP_AHRS::set_centripetal(bool)
0.00 45.91 0.00 1 0.00 0.00 AP_AHRS::AP_AHRS(IMU*, GPS*&)
0.00 45.91 0.00 1 0.00 0.00 Compass::set_orientation(Rotation)
0.00 45.91 0.00 1 0.00 0.00 Compass::set_initial_location(long, long)
0.00 45.91 0.00 1 0.00 0.00 Compass::init()
0.00 45.91 0.00 1 0.00 0.00 Compass::Compass()
0.00 45.91 0.00 1 0.00 0.00 Matrix3<float>::operator()(Vector3<float>, Vector3<float>,
Vector3<float>)
68
0.00 45.91 0.00 1 0.00 0.00 RC_ICR4::RC_ICR4()
0.00 45.91 0.00 1 0.00 0.00 ADC_UDR2::ADC_UDR2()
0.00 45.91 0.00 1 0.00 10.01 AP_Param::check_var_info()
0.00 45.91 0.00 1 0.00 0.33 AP_Param::load()
0.00 45.91 0.00 1 0.00 10.01 AP_Param::setup(AP_Param::Info const*, unsigned char, unsigned
short)
0.00 45.91 0.00 1 0.00 10.06 AP_Param::load_all()
0.00 45.91 0.00 1 0.00 0.00 AP_Param::AP_Param()
0.00 45.91 0.00 1 0.00 0.00 SPIClass::setClockDivider(unsigned char)
0.00 45.91 0.00 1 0.00 0.00 SPIClass::begin()
0.00 45.91 0.00 1 0.00 0.33 AP_ParamT<int, (ap_var_type)3>::set_and_save(int)
0.00 45.91 0.00 1 0.00 0.00 AP_ParamT<int, (ap_var_type)3>::set(int)
0.00 45.91 0.00 1 0.00 0.00 AP_ParamT<int, (ap_var_type)3>::AP_ParamT(int)
0.00 45.91 0.00 1 0.00 0.00 AP_ParamV<Vector3<float>, (ap_var_type)5>::AP_ParamV()
0.00 45.91 0.00 1 0.00 0.00 operator new(unsigned int)
0.00 45.91 0.00 1 0.00 0.00 digitalRead
0.00 45.91 0.00 1 0.00 0.04 mavlink_msg_action_ack_send
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_action_decode
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_action_get_action
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_action_get_target
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_action_get_target_component
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_clear_all_decode
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_clear_all_get_target_component
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_clear_all_get_target_system
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_count_decode
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_count_get_count
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_count_get_target_component
0.00 45.91 0.00 1 0.00 0.00 mavlink_msg_waypoint_count_get_target_system
% the percentage of the total running time of the time program used by this
function.
cumulative seconds a running sum of the number of seconds accounted for by this function and
those listed above it.
self seconds the number of seconds accounted for by this function alone. This is the
major sort for this listing.
69
calls the number of times this function was invoked, if this function is profiled,
else blank.
self ms/call the average number of milliseconds spent in this function per call, if this
function is profiled, else blank.
total ms/call the average number of milliseconds spent in this function and its descendents
per call, if this function is profiled, else blank.
name the name of the function. This is the minor sort for this listing. The index
shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would
appear in the gprof listing if it were to be printed.
70
Glossário
Frame Sinônimo para “quadro” ou imagem fixa de um vídeo.
Screenshot Termo que significa uma captura de “ecrã” ou captura de tela.
Waypoint Ponto ou lugar determinado em um mapa, contendo coordenadas e descrição.
Template Modelo de documento contendo apenas dados de apresentação visual do
mesmo.
Chip Circuito eletrônico integrado.
Cross-Compiler Compilador com a capacidade de gerar código executável para plataforma
diferente da qual ele executa.
Design Idealização, Criação, Concepção, elaboração ou especificação de algo.
Desktop Termo utilizado na computação relacionando a um computador de mesa.
Thread Fluxo único de controle sequencial dentro de um programa.
71
Referências Bibliográficas
[1] MARVEDEL, P. Embedded System Design. Netherland: Springer, 2006. ISBN 978-0-
387-29237-3.
[2] ENGBLOM, J. Embedded Systems Computer Architecture. Uppsala University. Extended
Abstract, ESSES, 2003. Disponível em: <http://www.securistreet.com/dri/mcu/
esses03-embeddedcomparch.pdf>
[3] WOLF, W.; JERRAYA, A. A.; MARTIN, G. Multiprocessor System-on-Chip (MPSoC)
Technology. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions,
vol.27, no.10, pp.1701-1713, Oct. 2008.
[4] WOLF, W. The Future of Multiprocessor Systems-on-Chip. In: Design Automation
Conference (DAC'04), 2004, pp. 681-685.
[5] HELMIG, J. Developing core software technologies for TI's OMAPTM platform. Texas
Instruments Inc., 2002.
[6] DUTTA, S.; JENSEN, R.; RIECKMANN A. Viper: A Multiprocessor SOC for Advanced
Set-Top Box and Digital TV Systems. IEEE Design and Test of Computers,
September/October 2001, pp. 21-31.
[7] Intel. Product Brief: Intel IXP2850 Network Processor. 2002. Disponível em
<http://www.intel.com>.
[8] ST-Ericsson. ST-Ericsson Nova A9500 application processor. 2012. Disponível em:
<http://www.stericsson.com/products/a9500-nova.jsp>
[9] OLIVEIRA, T. F. Desenvolvimento de Aplicações para Sistemas Embutidos: um Estudo
da Plataforma J2ME. Dissertação (Doutorado) — Universidade Tiradentes, Aracaju, 2006.
[10] CAMPOSANO, R.; WOLF, W. Design Automation for Embedded Systems. Jan. 1996
Volume 1, pp 5-50.
72
[11] MOREIRA, E. Mercado de smartphones no Brasil tem crescimento de 84%.
Disponível em: <http://www.techtudo.com.br/noticias/noticia/2012/03/mercado-de-smart
phones-no-brasil-tem-crescimento-de-84.html>. Acessado em Maio, 2012.
[12] ArduPlane-SITL. ArduPlane-SITL Introduction. Disponível em: <http://code .
google.com/p/ardupilot-mega/wiki/SITL>
[13] Arduino Mega 2560. Arduino Mega 2560 Overview. Disponível em: <http://
www.jameco.com/Jameco/Products/ProdDS/2121113.pdf>
[14] Ardupilot. ArduPilot Mega Manual. Disponível em: <http://code.google.com/
p/ardupilot-mega/wiki/home?tm=6>
[15] Beagleboard.org. Especificação da plataforma de desenvolvimento Beagleboard-xM.
Disponível em: http://beagleboard.org/hardware-xM>
[16] STEINER, E.; MASIERO, P; BONIFACIO, R; Gerenciando Variabilidades no Modelo
Simulink de um VANT com as Ferramentas Pure::variants e Hephaestus. USP - Universidade
de São Paulo. São Paulo, SP, 2012.
[17] Samsung. Samsung SmartTV ES8000. Disponível em: <http://www.samsung-smarttv
.com>
[18] Sistema Brasileiro de TV Digital. Recomendações para o Modelo de Referência (SW)
Codificador e Decodificador de Vídeo H.264/AVC, Brazil, 2006.
[19] Intel. Delivering leading-edge commercial technology for the defense and government
agencies. Disponível em: <http://download.intel.com/design/embedded/military/321728.pdf
#iid=4217>
[20] MAGALHAES, P. S.; Biometria e Autenticação. Universidade do Minho, Guimarães,
PT, 2003. Disponível em: <http://repositorium.sdum.uminho.pt/bitstream/1822/2184/1/capsi
.pdf>
[21] Projeto Casa inteligente. Núcleo de Inovações Tecnológicas da Universidade Estadual
do Oeste do Paraná – UNIOESTE. Disponível em: <http://projetos.unioeste.br/
campi/nit/index.php?option=com_content&task=view&id=105& temid=137 >
73
[22] OYAMADA, M. S.; GIRON, A. A.; MARTINI, J. A.; Introduction to embedded systems
and platform-based design. Conferência Brasileira em Sistemas Embarcados Críticos –
CBSEC-2012. Campinas, SP, 21-25 de Maio, 2012.
[23] CARRO, L.; WAGNER, F. R.; Sistemas Computacionais Embarcados. Instituto de
Informática da Universidade Federal do Rio Grande do Sul. Disponível em: <http://www .
das.ufsc.br/~cancian/pessoal/arquivos/se_sistemas_embarcados.pdf>
[24] LEE, M. T. C. Et al. Power analysis and minimization techniques for embedded DSP
software. Very Large Scale Integration (VLSI) Systems,1997. IEEE Transactions on, [s. n.],
1997, vol.5,pp.123-135.
[25] Eletronics Components Distributing – DIGIKEY US. Disponível em: <http://www .
digikey.com/>
[26] Embest Technology Co. Disponível em: <http://www.armkits.com/company/
companymain.asp>
[27] Texas Instruments, Inc. OMAP 3530/25 Applications Processor White paper. Dallas,
TX, 2009.
[28] Texas Instruments, Inc. Code Composer Studio (CCStudio) Integrated Development
Environment (IDE) v5. Dallas, TX, 2009. Disponível em: <http://www.ti.com/tool/ccstudio>
[29] Texas Instruments Incorporated. Disponível em: <http://www.ti.com/tool/ ccstudio >
[30] Texas Instruments, Inc. TI SYS/BIOS v6.33 Real-time Operating System User's Guide.
Dallas, TX, 2009.
[31] ARM Ltd. Architeture and Implementation of the ARM® Cortex™-A8 Microprocessor
White paper. Cambridge, UK, 2005.
[32] DIGI-KEY Corporation. Kit Dev BeagleBoard-xM. Disponível em: <http://www .
digikey.com/product-search/en?FV=ffec6be5>
[33] Texas Instruments, Inc. TMS320C64x/C64x+ DSP: CPU and Instruction Set – Reference
Guide. Dallas, TX, 2009.
[34] ARM Holdings Company Profile. Disponível em: <http://www.arm.com/about/
company-profile/index.php>
74
[35] ARM Ltd. ARM Architecture Reference Manual - ARM®v7-A and ARM®v7-R edition.
Cambridge, UK, Abril, 2007.
[36] HACHMANN, D. R. Distribuição de tarefas em MPSoC Heterogêneo: estudo de caso
no OMAP3530. Trabalho de Conclusão de Curso: Ciência da Computação, UNIOESTE,
Cascavel, 2011. Monografia.
[37] EYRE, J.; BIER, J. The evolution of dsp processors. Signal Processing Magazine, IEEE,
v. 17, n. 2, p. 43 –51, mar 2000.
[38] MOSHE, Y.; PELEG, N.; Implementations of h.264/avc baseline decoder on different
digital signal processors. In: ELMAR, 2005. 47th International Symposium. [s.n.], 2005. p.37
– 40.
[39] Texas Instruments, Inc. TMS320C64x/C64x+ DSP: CPU and Instruction Set – Reference
Guide. Dallas, TX, 2009.
[40] Texas Instruments, Inc. DM3730, DM3725 Digital Media Processors. Dallas, TX, 2011.
[41] Texas Instruments, Inc. Fixed-Point Digital Signal Processor. Dallas, TX, 2009.
[42] MARPE, D.; WIEGAND, T.; GORDON, S. H.264/MPEG4-AVC Fidelity Range
Extensions: Tools, Profiles, Performance, and Application Areas. IEEE International
Conference on In Image Processing, 2005. IEEE International Conference on, Vol. 1, 2005
pp. I-593-6.
[43] MANOEL, E. T. Codificação de Vídeo H.264 - Estudo de Codificação Mista de
Macroblocos. Dissertação (Mestrado) - Universidade Federal de Santa Catarina – UFSC,
Florianópolis, SC, 2007.
[44] MEENDERINCK, C. et al. Parallel Scalability of H.264, Delft University of
Technology, 2008.
[45] RAJA, G.; MIRZA, M. J.; In-loop Deblocking Filter for H.264/AVC Video.
International Conference on Signal Processing, Robotics and Automation (ISPRA'06), 2006.
Wiscosin, USA, 2006, pp 235-240.
[46] Gstreamer Open Source Multimedia Framework. Disponível em: <http://gstreamer .
freedesktop.org>
75
[47] Gstreamer elements to use DSP algorithms. Disponível em: <http://code.google.com
/p/gst-dsp/>
[48] BeagleBoard.org. BeagleBoard-xM Rev C System Reference Manual. Richardson, TX,
2010.
[49] SOUSA, J. D. De; Simulação e Desenvolvimento de um Veículo Aéreo Autônomo de
Quatro Rotores. Dissertação (Mestrado), Faculdade de Engenharia da Universidade do Porto,
PT, Julho 2011.
[50] U.S. Says Drone, Cargo Plane Collide Over Afghanistan. Wall Street Journal,
Disponível em: <http://online.wsj.com/article/SB1000142405311190348090457651208121
5848332.html?mod=googlenews_wsj>
[51] Kalinka R. L. J. C. Branco, et al. Tiriba - a new approach of UAV based on model
driven development and multiprocessors. Robotics and Automation (ICRA), 2011 IEEE
International Conference, [s. n.], 2011, pp.1-4, 9-13.
[52] APM Main Board. Disponível em: <http://code.google.com/p/ardupilot-mega/>
[53] Full ArduPilot Mega 1 kit. DRYDRONEs – The amateur UAV superstore. Disponível
em: <http://code.google.com/p/ardupilot-mega/wiki/Get>
[55] JSBSim Reference Manual – An Open Source, platform-independent, flight dinamics
model in C++. Disponível em: <http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf>
[55] Micro Air Vehicle Communication Protocol – MAVLink. Disponível em: <http://
qgroundcontrol.org/mavlink/start>
[56] APM Mission Planner. Disponível em: <http://code.google.com/p/ardupilot-mega/
wiki/DownloadCode>
[57] ARM Linux For Developers. Disponível em: <http://www.cs.utah.edu/dept/old/tex
info/as/gprof.html>
[58] GCC, The GNU Compiler Collection. Disponível em: <http://gcc.gnu.org/>
[59] Optimization in GCC. The Linux Journal. Disponível em: <http://www.linuxjournal
.com/article/7269>
[60] MAVProxy – Console app GCS for UAVs. Disponível em: <http://qgroundcontrol .
org/ mavlink/mavproxy_startpage >
76
[61] GNU Profiler – Gprof. Disponível em: <http://www.cs.utah.edu/dept/old/texinfo/
as/gprof.html>
[62] Bateria NOK-N97. Disponível em: <http://www.compraspelanet.com.br/ecommerce _
site/produto_20475_6600_Bateria-de-Litio-1900mAh-para-o-Nokia-N97-42V-BL-4D>
77
