sistemas embarcados V

Prévia do material em texto

Sistemas Embarcados
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. Tales Gouveia Fernandes
Revisão Textual:
Prof.ª Me. Sandra Regina Fonseca Moreira
Projetos de Sistemas Embarcados 
• Interrupções no Microcontrolador;
• Co-projeto de Hardware e Software;
• Particionamento Hardware e Software;
• Plataforma para Desenvolvimento.
• Observar projetos de hardware e software de sistemas embarcados;
• Reconhecer e perceber tecnicamente projetos de hardware e software de sistemas embarcados;
• Conhecer plataformas para auxílio no desenvolvimento de sistemas microcontrolados;
• Aprender sobre processos de projetos.
OBJETIVOS DE APRENDIZADO
Projetos de Sistemas Embarcados
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e de 
aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Projetos de Sistemas Embarcados 
Interrupções no Microcontrolador
Na unidade anterior, o desenvolvimento de software focado no firmware para 
microcontroladores foi o tema levantado, além de ter destacado duas linguagens de 
programação típicas para sistemas embarcados, a linguagem Assembly e a lingua-
gem C. Atrelado ao desenvolvimento do firmware e ao controle desempenhado 
por ele na plataforma de hardware, a qual é independente da linguagem de pro-
gramação utilizada, há um evento que se destaca e auxilia na atividade do sistema 
embarcado, o qual é chamado de interrupção. Basicamente interrupção é tratado 
e definido como um evento que obriga o microcontrolador a suspender suas ati-
vidades temporariamente, para atender exclusivamente uma rotina indicada pelo 
evento que o interrompeu. A interrupção também pode ser considerada um desvio 
de um ponto do software para outro preestabelecido.
Com isso, a interrupção é criada através de métodos utilizados para a verificação 
do estado de um pino ou terminal de entrada do microcontrolador. Um método 
comum é através da leitura frequente do nível de tensão nele presente, essa técnica 
é chamada de polling, a qual é considerada um método de fácil implementação.
Polling: pode ser definido, no âmbito dos sistemas embarcados, como uma verificação peri-
ódica, feita pela microcontrolador, do estado de seus periféricos para detectar quando uma 
ação precisa ser tomada.
Ex
pl
or
A Figura 1 ilustra o fluxograma de ações tomadas pelo microcontrolador e suas 
interfaces, quando se implementa a técnica de polling em um sistema embarcado.
Figura 1 – Fluxograma da técnica de polling em sistemas embarcados
Fonte: Acervo do Conteudista
Entretanto, esse método não se mostra adequado em situações que demandem 
uma resposta imediata do microcontrolador assim que houver uma mudança no 
nível de um terminal. Para esses casos, é recomendado que seja utilizada uma inter-
rupção, ou seja, a chamada de uma função auxiliar que só é executada se houver 
ocorrido um evento externo específico, como por exemplo, a sinalização de mudan-
ça do estado de um pino. Nesse caso, após a chamada da função auxiliar, o fluxo 
original do programa principal só será retomado quando a interrupção for concluí-
da. Como o próprio nome indica, uma interrupção serve para interromper a execu-
ção normal do programa principal e, imediatamente, tratar do evento que a gerou.
8
9
Além das interrupções provocadas pela alteração do nível de tensão do terminal, 
alguns microcontroladores, como o PIC16F84A, possuem várias outras fontes de 
interrupção, que podem ser configuradas e usadas a partir de informações obtidas 
consultando o respectivo datasheet.
Como exemplo, para utilizar as interrupções, o registrador INTCON.GIE deve 
ser ativado, ou seja, ativar o endereço 0BH, correspondendo ao INTCON, e o bit 7, 
correspondendo ao GIE do INTCON. O GIE funciona como uma espécie de chave 
geral de todas as interrupções, sendo assim, ao configurar zero no INTCON.GIE 
todas as interrupções serão desabilitadas simultaneamente. 
Outro tipo de interrupção que os microcontroladores geralmente disponibilizam 
são as interrupções de timer, sendo que elas ocorrem sempre que o contador do 
timer estoura, isto é, quando atinge o valor máximo e é incrementado de uma 
unidade. Por exemplo, o timer 0, correspondente ao endereço 01H, é um tempori-
zador de 8 bits, ou seja, seu contador está na faixa do 0 a 255. Quando o contador 
atingir 255, no próximo incremento ele estourará, tentará contar o número 256, 
retornando a zero e disparando a interrupção de timer 0. Para que essa interrupção 
funcione, deve-se ter INTCON.GIE configurado como 1, ou seja, chave geral ligada, 
INTCON.T0IE configurado como 1 para ligar o timer 0. Desta forma, sempre que 
houver o estouro do contador, o bit INTCON.T0IF estará em 1 e a rotina de trata-
mento dessa interrupção será acionada.
Esse tipo de interrupção é muito útil quando se deseja medir intervalos de tem-
po de forma precisa. Por exemplo, considerando um clock interno de 1 MHz, o 
ciclo de máquina correspondente será de 1 µs. Carregando o timer 0 com o valor 
250, após 5 ciclos de máquina, ou seja, 5 µs haverá a ocorrência da interrupção 
de timer, a qual poderá ser utilizada para incrementar um contador que contará de 
forma precisa em uma frequência de 5 µs em 5 µs.
Existe também um tipo de interrupção chamada de interrupção externa, a qual 
se torna uma interrupção alternativa útil, pois permite a detecção exata do instante 
em que os eventos externos acontecem, podendo ser esses uma ativação do sensor 
de presença, um ciclo completo de um eixo acoplado a um motor ou quando a 
tensão da rede chegou a nível próximo de zero.
Essa interrupção pode ser disparada pela borda de subida ou pela borda de 
descida do sinal. Essa seleção é feita configurando o registrador OPTION_REG.IN-
TDEG de endereço 81H.6. A interrupção é ativada fazendo com que INTCON.GIE 
seja 1, ou seja, chave geral ligada e INTCON.INTE seja 1, ou seja, INT EXT esteja 
ligada. Sempre que ocorrer uma transição de sinal no terminal correspondente, 
INTCON.INTF de endereço 0BH.1, indo para nível alto 1, a rotina de tratamento 
dessa interrupção será acionada. Consequentemente, antes de sair da rotina de 
interrupção, essa flag deverá ser colocado em nível baixo, zero. 
Por fim, é possível encontrar nos microcontroladores da família PIC16F84A 
interrupções como: interrupção de mudança de estado, queocorre quando algum 
pino muda de nível de sinal e interrupção de escrita na EEPROM, ocorrendo 
9
UNIDADE Projetos de Sistemas Embarcados 
quando se conclui a escrita na memória EEPROM. Há também interrupção de 
fim de conversão A/D, que ocorre quando se conclui a conversão de analógico 
para digital de sinais. Pode-se encontrar a interrupção de WDT, a qual ocorre no 
estouro do WatchDog Timer e o sistema é reinicializado.
Para ter uma compreensão mais prática de como utilizar e implementar as interrupções em 
um sistema embarcado, há um vídeo que exemplifica alguns casos de uso com interrupção. 
Disponível em: http://bit.ly/2Ixp8KH
Ex
pl
or
Co-projeto de Hardware e Software
Levando em conta a definição de De Micheli e Gupta (1997), os sistemas de en-
genharia podem ser considerados como um grupo de componentes com operações 
combinadas, a fim de desenvolver alguma tarefa. 
Um sistema consiste em um número de elementos, concretos ou não, que intera-
gem entre si e com o ambiente como uma unidade de trabalho. Podendo ser grande 
e complexo ou relativamente pequeno e simples. Um sistema fica inteiramente defi-
nido quando se conhecem: seus objetivos; seus limites; seu funcionamento interno.
Atualmente, a maioria dos sistemas projetados são eletrônicos ou possuem sub-
sistemas eletrônicos para monitoramento, controle e execução de tarefas ou pro-
cessos. Faz parte desses sistemas uma interface programável, que remete a compo-
nentes que são implementados via hardware, e também componentes que podem 
ser implementados exclusivamente via software.
Como visto nas unidades anteriores, o projeto do sistema está diretamente rela-
cionado a área de aplicação dele. Um projeto consiste em um esforço temporário 
com um objetivo pré-estabelecido, seja para criar um novo produto, serviço ou pro-
cesso. Tem início, meio e fim bem definidos, duração e recursos limitados, numa 
sequência de atividades relacionadas, as quais serão inseridas para definir priori-
dades e acompanhamento de desenvolvimento. Por sua vez, essas podem estar 
relacionadas ao desempenho, ao custo total do produto, ao grau de dificuldade de 
programação ou até mesmo à complexidade tecnológica de viabilizar o desenvolvi-
mento do projeto.
Sendo assim, surge uma possível definição de Co-projeto (do inglês Co-design) 
de hardware e software, que consiste em unir todos os objetivos, limites e funcio-
nalidades do sistema, explorando a interação existente entre os componentes de 
hardware e de software durante o seu desenvolvimento.
O sistema estabelecido e utilizado no fluxo de projeto do Co-projeto ou Co-Design 
de hardware e software teve seu início durante a década de 90. Nesse momen-
to estava claro que os microcontroladores não estariam disponíveis apenas como 
10
11
componentes discretos para sistemas a nível de placas, ou seja, a nível exclusiva-
mente de hardware, mas também como componentes programáveis via software e 
utilizados em qualquer projeto de Circuitos Integrados (CIs).
Embora o Co-projeto de hardware e software já tenha sido exercido desde a 
introdução do primeiro microcontrolador, com a evolução dos sistemas e a cria-
ção de modelagens de projetos, novas definições surgiram. Uma delas considera o 
 Co-projeto como o processo de criação simultânea e coordenada de um sistema de 
hardware eletrônico e componentes de software com base na descrição da funcio-
nalidade do sistema e na automatização do fluxo do projeto.
Um dos primeiros problemas de Co-síntese foi formulado como um progra-
ma linear inteiro misto, que determinava simultaneamente uma topologia de mul-
tiprocessador e uma programação com atribuição de tarefas para a arquitetura. 
 Desde então, o problema de particionar automaticamente tarefas ou processos em 
 hardware e software foi reconhecido como um tema indispensável no desenvolvi-
mento de projetos.
A Figura 2 apresenta as fases básicas de um Co-projeto de hardware e software . 
Inicialmente, tem-se a especificação do sistema a ser desenvolvido, seguida pelas 
transformações de projeto. Um particionamento é proposto e a síntese de hardware , 
de interface e a geração de código do firmware são desenvolvidas e, por fim, uma 
verificação do projeto encerra o processo.
Figura 2 – Fluxo simplifi cado de um Co-projeto de Hardware e Software
Fonte: Acervo do Conteudista
11
UNIDADE Projetos de Sistemas Embarcados 
Uma especificação funcional de comunicação dos módulos ou tarefas desenvol-
vidas em uma linguagem de programação C, que compõem o firmware, pode ser 
mapeada sobre uma determinada plataforma de hardware. Essa, por sua vez, consis-
te de uma Unidade de Processamento Central (do inglês Central Processing Unit – 
CPU) e um bloco de hardware ou circuito integrado de aplicação específica (do inglês 
Application Specific Integrated Circuits – ASIC) ASIC, com ambas as partes se co-
municando através de um barramento e utilizando uma memória compartilhada, ou 
registros, para a implementação de um buffer. Dessa forma, a plataforma principal já 
está definida, dependendo apenas do hardware que seria implementado.
Com o passar do tempo, o Co-projeto de hardware e software evoluiu, e houve 
a necessidade de integrar ao sistema embarcado tipos mais complexos de arquite-
turas de projeto, como por exemplo, incluir mais de uma CPU, evoluir a execução 
de programas single thread, ou seja, ao invés do firmware embarcado rodar linear-
mente, foi necessário estender os algoritmos à multiprogramação e ao multiproces-
samento. Além disso, a Co-simulação começou a se tornar uma importante área de 
pesquisa para a validação inicial de decisões de projeto.
É possível conciliar a ideia do Co-Projeto com o aprimoramento das tecnologias 
hoje presentes nos sistemas em um chip (do inglês System-on-a-chip SoC), o que 
tornou as etapas de simulação e verificação automática dos projetos mais complexas. 
Com isso, até atrasos temporais causados por transporte de dados das tarefas de co-
municação através de links de comunicação são considerados. Além do mais, através 
do mapeamento de tarefas de comunicação entre as funções dependentes de dados 
e transferência de informação, recursos de comunicação são introduzidos e fazem 
parte do problema de particionamento de hardware e software. Também as redes de 
comunicações complexas precisam ser consideradas para o desempenho e análise 
de custos, incluindo não só os barramentos do processador e conexões ponto-a-
-ponto, mas também da network-on-chip (NOC), que nada mais é do que um tipo de 
interconexão criada para realizar a comunicação interna entre os dispositivos de um 
SoC. Um exemplo de uma complexa arquitetura de multiprocessadores SoCs são os 
multiprocessor system-on-chip (MPSoC), ou também os multi-core system-on-chip. 
A comunicação de tarefas, nesse caso, pode envolver vários saltos e exigir encami-
nhamentos a serem determinados em cima do mapeamento de tarefas.
A complexidade e evolução dos dispositivos eletrônicos usados hoje em dia trou-
xe a necessidade imprescindível de ter o conhecimento de técnicas de Co-projeto de 
hardware e software. Desta forma, é quase uma obrigação para todos aqueles que 
querem se manter atualizados com os desafios cada vez mais complexos de projetos 
de sistemas eletrônicos no futuro. Isto não só se sustenta para projetistas de SoCs, 
mas também para engenheiros de software e hardware envolvidos no desenvolvi-
mento de sistemas distribuídos, como complexos sistemas automotivos em rede, 
aviônicos, sistemas de manufatura e sistemas embarcados em geral.
As variadas configurações de plataformas de hardware para implementação de 
sistemas embarcados levantam algumas questões relevantes e de interesse para o 
projeto do produto. Uma destas questões está relacionada à classificação de sua 
12
13
área de atuação. Uma unidade anterior exemplificou muitas dessas áreas, relacio-
nadas ao processamento de informação, à indústria de celulares, veículos e sistemas 
de telecomunicação, dentre outros. Além disso, esses sistemasembarcados podem 
ser distribuídos geograficamente como sistemas de telefonia, distribuídos localmen-
te como sistemas de controle de aviões, ou fixos, em estações de trabalho.
Outra questão importante e relacionada diretamente ao firmware diz respeito ao 
quão flexível será o software para disponibilizar funcionalidades a sistemas de apli-
cações que estão na camada subsequente. Como exemplo, um computador pessoal 
possui alto grau de flexibilidade, pois para as aplicações a plataforma de hardware é 
praticamente transparente, sendo perceptível apenas quando é feito um benchmark 
de desempenho. De modo geral, esse grau de flexibilidade não é suportado pelos 
sistemas embarcados, pois o firmware é disponibilizado pelo fabricante do produto, 
tendo assim apenas algumas funções programáveis. Os vários níveis de programa-
ção em um sistema envolvem a programação de hardware, de instruções ou de 
aplicações. O nível mais alto é o nível de aplicação cujo sistema já possui programas 
dedicados sendo executados e o usuário só programa para executar as tarefas. Já o 
nível de instruções está presente na maioria dos sistemas eletrônicos que possuem 
um conjunto específico de instruções. Um exemplo desses sistemas são os micro-
controladores, os quais rodam em linguagem de máquina o software de controle. 
Por fim, a programação de hardware permite que este seja modificado da forma 
que o usuário desejar para atender às suas necessidades. Como exemplos de pro-
gramação de hardware, tem-se os dispositivos de hardware configuráveis como as 
FPGA’s (do inglês Field Programmable Gate Array) ou algo como matriz de portas 
programáveis em campo. Nada mais são do que chips programáveis a nível de 
portas lógicas, que correspondem à unidade elementar de qualquer circuito digital.
Por fim, uma questão relevante diz respeito ao estilo de desenvolvimento de cir-
cuitos, o nível de integração e a tecnologia de produção. Um sistema deve possuir 
componentes de diferentes escalas de integração e vários tipos de tecnologia de 
fabricação. A escolha dos componentes afeta diretamente o desempenho final do 
sistema, custo e sua importância. O nível de desempenho implementado e espe-
rado do produto pode ser atingido conforme a utilização de memórias de leitura e 
escrita, além das interconexões programáveis.
Como definido nas primeiras unidades, geralmente sistemas embarcados regu-
lam componentes mecânicos via atuadores e recebem informações do meio exter-
no através de sensores. Sistemas de controle são geralmente sistemas de reação, 
pois reagem a estímulos gerados pelo ambiente. Sistemas de tempo real imple-
mentam funções que devem ser executadas em uma certa janela de tempo. Desta 
forma, as funções requeridas e a complexidade dos sistemas embarcados variam de 
acordo com sua aplicação. A utilização de microcontroladores faz com que o custo 
do projeto diminua consideravelmente e possibilita soluções flexíveis, ou seja, que 
se adaptam a várias situações, tornando-se soluções comerciais. No entanto, muitos 
sistemas de controle são complexos e de tempo real, exigindo assim uma alta vazão 
de dados e processamento, tornando-se projetos específicos com componentes que 
possuam grande capacidade de processamento.
13
UNIDADE Projetos de Sistemas Embarcados 
Quando se inicia um projeto de uma solução eletrônica, deve-se ter em mente 
que as funções podem ser implementadas tanto em hardware quanto em software. 
Porém, nesse caso, devem ser seguidas regras de design para garantir o desem-
penho das principais características dos sistemas desenvolvidos. As técnicas de 
testes para desenvolvimento devem ser utilizadas para testar e garantir que a opção 
escolhida realmente foi a melhor, ou se atingiu o desempenho mínimo requisitado 
e esperado.
Os possíveis problemas no Co-projeto de sistemas embarcados incluem mo-
delagem, validação e implementação. Essas operações são críticas devido a hete-
rogeneidade dos componentes que estão interagindo no sistema, além da imple-
mentação que deve otimizar os objetivos do projeto, fazendo necessário o uso do 
particionamento de hardware e software específico.
 A modelagem de sistemas embarcados pode ser homogênea, quando uma lin-
guagem de programação ou formalismo gráfico é utilizado para representação do 
particionamento hardware/software, ou heterogênea, que consiste no particiona-
mento a partir do próprio modelo que, em suas fases iniciais, possui componentes 
que podem ser expandidos e modificados para atingir o objetivo do projeto. Para 
melhor exemplificar essa modelagem, a Figura 3 ilustra uma metodologia que apre-
senta o particionamento do hardware e software sendo influenciado pelos objeti-
vos de desempenho e projeto, pela descrição de um modelo e sua simulação, além 
da tecnologia envolvida.
Figura 3 – Exemplo de metodologia de Co-projeto
Fonte: Acervo do Conteudista
Para melhor compreender e se familiarizar com as etapas e necessidades de um Co-projeto de 
hardware e software, esse vídeo exemplifica a elaboração de funcionalidades e requisitos de 
um projeto. Além disso, é ilustrado o modelo Business Model Canvas, cuja finalidade é mapear 
os principais itens que constituem o projeto de forma visual: https://youtu.be/RHYGng_OBtw
Ex
pl
or
14
15
Particionamento Hardware e Software
O principal problema encontrado no desenvolvimento de projetos para sistemas 
embarcados é a escolha de qual parte do sistema será implementada em hardware 
e qual parte do sistema será implementada em software. Esse problema é conheci-
do e tratado como particionamento hardware e software.
Essa etapa levantada no início do projeto é um ponto chave na questão do de-
senvolvimento e implementação do projeto de uma solução embarcada, pois as 
decisões tomadas nessa etapa do projeto irão influenciar o projeto até o final de sua 
execução, impactando diretamente na performance, na dificuldade de implementa-
ção, no custo final da solução e na tecnologia que terá de ser empregada.
Dado um conjunto de objetos funcionais e um conjunto de componentes do sis-
tema, um algoritmo de particionamento procura pela melhor partição. A melhor 
partição é a que atende às restrições de projeto. A Figura 4 ilustra a relação entre 
funcionalidade, software e hardware. Sendo que os componentes correspondem 
ao microcontrolador, chips ASIC (do inglês Application Specific Integrated Circuit) 
com instruções otimizadas para aplicação e memória. Já as Restrições são do tipo 
consumo de energia, restrições temporais, custos e peso.
Figura 4 – Defi nição de particionamento relacionando componentes e restrições
Fonte: Acervo do Conteudista
O particionamento de hardware e software trata da implementação das partes 
do projeto em módulos heterogêneos, ou seja, considera duas plataformas, uma de 
hardware e uma de software. A etapa de particionamento hardware e software 
nada mais é do que uma parte do Co-projeto, cujo objetivo principal é encontrar 
um particionamento que represente uma implementação que preencha todos os 
requisitos especificados, otimizando seu funcionamento e diminuindo ao máximo 
os custos e riscos, para se ter, ao final do projeto, a solução requisitada pelo cliente 
ou pela própria proposta inicial.
É comum propor um design específico a um projeto; o arquiteto do projeto deci-
de quais partes serão implementadas em hardware e quais partes serão contempla-
das pelo software, através da sua bagagem de conhecimento atrelado aos requisitos 
estabelecidos pelo negócio que utilizará o produto. A fim de automatizar este árduo 
processo, vários algoritmos e técnicas vêm sendo desenvolvidos e propostos em 
vários projetos de Co-design. Esses modelos e abordagens funcionam muito bem 
15
UNIDADE Projetos de Sistemas Embarcados 
nos ambientes de desenvolvimento para os quais foram projetados, porém, há tan-
tas diferenças entre os modelos que não é possível comparar objetivamente com 
métricas os resultados de cada proposta. 
Segundo Sipser (2006), o particionamento hardware e software,de modo ge-
ral, são considerados NP-Completos. Ser NP-Completos diz respeito a possuir ca-
racterísticas de otimização NP-Difíceis, com isso, o problema de particionamento 
 hardware e software se enquadra nessa classificação. A classe de problemas NP 
não possui algoritmos de resolução em tempo polinomial conhecidos que apre-
sentem o resultado exato para o problema, sendo então necessária a utilização de 
heurísticas como forma de encontrar soluções aceitáveis em tempo hábil.
Há uma área relacionada à teoria da complexidade computacional, que classifica a comple-
xidade de problemas como o subconjunto dos problemas NP de tal modo que todo problema 
em NP pode ser reduzido a termos de tempo polinomial, para um dos problemas NP-com-
pleto. É levado em conta que os problemas de NP-completo são os problemas mais difíceis 
de NP e muito provavelmente não formem parte da classe de complexidade P. A motivação 
desta redução está relacionada a encontrar uma maneira de resolver qualquer problema 
NP-completo rapidamente, ou seja, em tempo polinomial. Desta forma, é possível utilizar 
algoritmos que resolvam todos problemas NP rapidamente.
Ex
pl
or
No particionamento hardware e software, tanto a parte de hardware, quanto 
a parte de software podem ter diferentes níveis de granularidade. Um alto nível 
de granularidade significa que as tarefas ou os módulos de hardware possuem um 
grande número de especificações de funcionalidade ou comportamento. Já um 
nível baixo de granularidade significa que essas especificações estão em menor nú-
mero. Implementar sistemas em hardware traz um ganho em tempo de execução e 
gasto de energia elétrica, porém, consome espaço físico e gera alto custo de imple-
mentação. Em contrapartida, implementar sistemas em software diminui o custo 
financeiro de implementação, no entanto, possui um custo de manutenção maior, o 
tempo de execução acaba sendo mais alto e os microcontroladores consomem mais 
energia devido a prolongação de seu uso.
Os dois primeiros algoritmos propostos (LÓPEZ-VALLEJO & LÓPEZ, 2003) 
para resolver problemas de particionamento de hardware e software foram Cosyma 
e Vulcan. O algoritmo Cosyma utiliza a técnica de simulated anealling com boa 
granularidade e no algoritmo Vulca II, através de processos interativos, blocos de 
software são extraídos da versão totalmente de hardware como solução, conside-
rando a questão de tempo de execução. Além desses dois algoritmos, surgiu um 
algoritmo, o apresentado por Ptolomey, o qual possuía duas características impor-
tantes: a primeira está relacionada à capacidade de adaptar sua função objetivo 
para ser global ou para priorizar operações críticas; já a segunda característica diz 
respeito à consideração de possíveis implementações de hardware com formas 
diferentes uma da outra.
16
17
Alguns aspectos são comuns e geralmente levados em conta na maioria dos 
ambientes de projeto que necessitam desse particionamento. A especificação inicial 
do projeto é muito importante, pois fixa o nível de abstração exigida pela solução, 
o tipo de aplicação para a qual serão voltados o projeto e o modelo computacional 
escolhido como representação, juntamente com sua granularidade escolhida.
De maneira geral, as definições encontradas na literatura sobre o problema de 
particionamento possuem duas falhas, uma delas está relacionada ao comporta-
mento insatisfatório em situações que a entrada de dados se torna muito grande, 
devido ao custo de resolução estar na ordem exponencial de complexidade em 
relação ao número de tarefas e módulos de hardware. A segunda diz respeito às 
heurísticas utilizadas, as quais acabam divergindo com relação aos resultados espe-
rados. No entanto, a complexidade desse problema é difícil de se determinar.
A ideia de um modelo simplificado de particionamento é de definir formalmente 
vários tipos de particionamentos, para assim analisar a complexidade desses par-
ticionamentos formalmente. Com isso é possível obter como resultado algoritmos 
que possam ser utilizados para um grande número de projetos, ou seja, tornando-
-se um modelo genérico de uso.
Plataforma para Desenvolvimento
Tendo o intuito de complementar as ideias do Co-projto e Particionamento 
 hardware e software, será apresentando o ambiente de desenvolvimento do firmware 
para microcontroladores da família PIC, do fabricante Microchip.
O ambiente de desenvolvimento de software é o MPLAB, fornecido pela própria 
Microchip. Esta IDE, ambiente de desenvolvimento integrado (do inglês Integrated 
Development Environment) oferece ao desenvolvedor um conjunto de ferramentas 
que permitirá escrever código fonte tanto em Assembly como em C, compilar e 
testar o seu microcontrolador PIC. Além do MPLAB existe o MPLAB X, fornecido 
pelo mesmo fabricante, porém é baseado na IDE open-source NetBeans. Ambas 
as plataformas oferecem suporte ao desenvolvimento de firmwares para microcon-
troladores PIC de 8, 16 ou 32 bits.
Tendo desenvolvido o código fonte do firmware no editor do MPLAB, é possível 
então compila-lo pelo próprio compilador da IDE e ter seu binário com a extensão 
HEX, de hexadecimal, gerado. Com isso, esse código fonte poderá ser testado e 
simulado pelo MPLAB.
Executando a IDE, inicialmente irão aparecer duas janelas, uma sendo o Workspace 
e a outra o Output. A janela do Workspace é responsável por mostrar a estrutura 
dos arquivos associados ao projeto em andamento de desenvolvimento. Já a janela 
Output irá indicar as informações sobre os resultados do processo de compilação, 
debug e também de uma possível simulação.
17
UNIDADE Projetos de Sistemas Embarcados 
Para melhor clarificar a utilização da ferramenta, tudo será feito com base em 
um exemplo de criação de um firmware simples, o qual será desenvolvido em 
 Assembly e terá seu conteúdo salvo em um arquivo com a extensão ASM (do in-
glês Assembly Language Source Code File). Além disso, a IDE fornece suporte a 
criação de projetos com múltiplos arquivos desenvolvidos em diferentes linguagens 
de programação como ASM, C, BASIC e outros. Utilizando este recurso ou não, é 
necessário manter os arquivos do projeto em uma mesma pasta, para que assim a 
IDE possa reconhecer os recursos em desenvolvimento.
Para criar um projeto, deve-se acessar o menu Project, escolher New Project e, 
na sequência, a opção Project Wizard.
A próxima caixa de diálogo, chamada Step One, é responsável por selecionar 
qual será o microcontrolador que terá o firmware desenvolvido. No caso deste 
exemplo, será utilizado o PIC16F84A, pois é o mesmo utilizado nas unidades 
anteriores como referência na descrição dos recursos da família de microcontro-
ladores PIC. Na segunda caixa de diálogo, Step Two, será selecionado o com-
pilador, o qual gerará o binário do firmware. O compilador para linguagem 
Assembly disponível é o Microship MPASM Toolsuite. Já na terceira etapa, Step 
Three, será atribuído o nome do projeto e o local onde serão armazenados os 
arquivos. A quarta e penúltima etapa, Step Four, será para adicionar o arquivo 
com o código fonte ou mesmo um arquivo com extensão ASM que ainda não 
contenha o código fonte. Também é possível criar o projeto sem associar um 
arquivo para posteriormente criá-lo ou adicioná-lo diretamente no Workspace. 
Finalmente é apresentado o resumo da criação do projeto, Summary, com as 
especificações do microcontrolador utilizado, do compilador, e local de armaze-
namento do projeto.
Essa é uma sugestão de conteúdo que explora a criação de um projeto de firmware na IDE 
MPLAB utilizando a linguagem C de programação. É possível acompanhar o passo a passo de 
criação, elaboração e compilação de um código fonte: https://youtu.be/r3U5oO8eyXA.
Ex
pl
or
A Figura 5 ilustra a janela da IDE com o código fonte de teste já escrito em 
 Assembly e compilado. Quando se compila o código fonte, através do menu Project 
e opção Make, é possível que surja uma caixa de diálogo ao final, questionando se 
deseja que o projeto gere um código absoluto ou realocável(do inglês absolute or 
relocatable). Basicamente, a opção absolute significa que as variáveis de código e 
memória RAM serão alocadas exatamente como foi pré-definido na configuração 
do compilador. Já a opção relocatable dará autonomia para que o compilador 
possa alocar pedaços do código e variáveis da memória RAM em posições que es-
tiverem disponíveis, ou que forem convenientes. Geralmente, a opção relocatable 
é a escolhida, mas isso pode ser alterado a qualquer momento.
18
19
Figura 5 – Exemplo de implementação e compilação de um fi rmware em assembly utilizando a IDE MPLAB
Após utilizar o MPLAB para desenvolvimento do firmware, é possível utilizar o 
binário compilado em uma plataforma de projeto, simulação e teste de hardware 
chamada Proteus. A utilização de um software para simular um circuito eletrônico 
contribui para a organização de ideias durante o projeto, e é uma forma mais didá-
tica de entender o funcionamento do circuito.
O Proteus possui duas ferramentas chamadas ISIS e Ares. O ISIS tem a função 
de criar esquemas elétricos de circuitos eletrônicos, além de suportar a montagem e 
simulações desses circuitos no próprio ambiente. Essa ferramenta é muito utilizada 
na elaboração de protótipos digitais de hardware de sistemas embarcados, uma vez 
que após a criação digital é possível simular e integrar o hardware ao firmware 
para avaliação de uma previa execução. Se durante a etapa de testes do sistema 
embarcado digital forem encontrados erros de software ou hardware, é possível 
fazer correções rápidas, sem demandar custos adicionais. A etapa seguinte seria 
elaborar o protótipo físico do sistema embarcado, para assim testar e avaliar as 
possíveis interferências do meio que poderiam influenciar no funcionamento corre-
to do projeto. A utilização da placa protoboard, que permite adicionar ou remover 
componentes físicos sem soldá-los, facilita os testes mesmo antes de criar a placa do 
hardware protótipo. Já na criação do protótipo físico, a ferramenta ARES, perten-
cente ao Proteus. permite a elaboração e criação dos layouts de circuitos impres-
sos, que podem ser utilizados na criação das trilhas e disposição dos componentes 
eletrônicos na placa.
Utilizando a ferramenta ISIS do software Proteus foi possível elaborar o circuito 
digital com o PIC16F84A, um LED vermelho, dois resistores, um de 330 Ohms e 
outro de 10k Ohms, além de um botão de ativação e o indicativo do uso de uma 
fonte de 5 V. Este hardware corresponde ao firmware desenvolvido e compilado 
anteriormente na IDE MPLAB. A Figura 6 ilustra o esquema elétrico montado com 
os componentes citados.
19
UNIDADE Projetos de Sistemas Embarcados 
Figura 6 – Circuito elétrico simulado na plataforma Proteus
Fonte: Acervo do Conteudista
Considerando que a simulação ocorreu como o esperado, funcionou correta-
mente e a prototipagem física do sistema embarcado foi construída, será necessário 
a utilização do software e hardware de gravação do binário do firmware no micro-
controlador, no caso da família PIC. O software chama MicroBRN, que é ligado à 
placa de gravação via conexão usb. A Figura 7 ilustra a utilização do MicroBRN na 
gravação do firmware.
Figura 7 – Ilustração do uso do software MicroBRN para gravação do fi rmware no microcontrolador PIC
20
21
Por fim, a placa PicStart Plus com o suporte de encaixe do microcontrolador, 
o qual aceita qualquer PIC de até vinte terminais, e conexão usb para transferência 
de dados provenientes do computador com uso do software MicroBRN, ilustrados 
o link a seguir.
Ilustração da placa de gravação de firmware em um microcontrolador: http://bit.ly/2IBBq4J
Ex
pl
or
Para exemplificar a integração hardware e software na plataforma de simulação Proteus, 
o vídeo sugerido ilustra os passos iniciais da elaboração do circuito na ferramenta ISIS. 
 Disponível em: https://youtu.be/BMEPamon6P4
Ex
pl
or
21
UNIDADE Projetos de Sistemas Embarcados 
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Microchip
Download do ambiente de desenvolvimento MPLAB IDE da Microchip.
http://bit.ly/2Ix7wPa
 Vídeos
Iniciando um Projeto Eletronico – Canvas para detalhamento
Explicação sobre a elaboração de um co-projeto de hardware e software utilizando o 
modelo Business Model Canvas.
https://youtu.be/RHYGng_OBtw
Primeiro Projeto em Linguagem C | Curso PIC
Material de apoio a construção e elaboração de um firmware com a IDE MPLAB.
https://youtu.be/r3U5oO8eyXA
Microcontrolador Aula 1 – Ligação Pic no Proteus
Material de apoio para uso da ferramenta de simulação ISIS pertencente ao 
software Proteus.
https://youtu.be/BMEPamon6P4
Descubra o princípio de funcionamento das INTERRUPÇÕES dos microcontroladores
Uso de interrupções no projeto de sistemas embarcados.
http://bit.ly/2Ixp8KH
22
23
Referências
BINDAL, A. Electronics for Embedded Systems. Cham: Springer International 
Publishing, 2017.
DE MICHELI, G.; GUPTA, R, K. Hardware/Software Co-Design. Proceedings of 
the IEEE, v. 85, n. 3, 1997, p. 349-365.
HOLT, A.; HUANG, C. Y. Embedded Operating Systems A Practical Approach . 
2. edition. ed. Cham: Springer International Publishing AG, 2018.
LÓPEZ-VALLEJO, M.; LÓPEZ, J. C. On the Hardware-Software Partitioning 
Problem: System Modeling and Partitioning Techniques. ACM Transactions on 
 Design Automation of Electronic Systems, v. 8, n. 3, p. 269-297, 2003.
QIAN, K.; HARING, D. D.; CAO, L. Embedded Software Development with C. 
New York: Springer Science+Business Media, 2009.
SCHNEIDER DE OLIVEIRA, A.; SOUZA DE ANDRADE, F. Sistemas Embarcados 
Hardware e Firmware na Prática. 2. ed. São Paulo: Érica, 2010.
SIPSER, M. Introduction to The Theory of Computation. 2. Ed. Thomson, 2006.
23