TEMA 5 - Projetos com Microcontroladores

Prévia do material em texto

DESCRIÇÃO
Aspectos de um projeto com microcontroladores; escolhas em função de aplicações críticas, do
mercado e das boas práticas de programação − com destaque para um projeto de Internet das
Coisas (IoT).
PROPÓSITO
Discutir sobre os aspectos de escolha em um projeto com microcontroladores é um exercício
primordial na formação do profissional, que irá atuar em equipes com pessoas com diferentes
visões, incluindo questões de custos, desempenho, qualidade, ética e perspectivas futuras da
aplicação.
PREPARAÇÃO
Não há pré-requisitos operacionais.
OBJETIVOS
MÓDULO 1
Reconhecer as plataformas de hardware e software para um projeto com microcontrolador
MÓDULO 2
Identificar as limitações dos microcontroladores para a especificação de projetos embarcados
de alto desempenho
MÓDULO 3
Empregar as boas práticas de programação para o desenvolvimento do software embarcado
nos microcontroladores
MÓDULO 4
Identificar microcontroladores para projetos de comunicação sem fio e Internet das Coisas (IoT)
INTRODUÇÃO
Projetar é a tarefa de definir a funcionalidade de um sistema e convertê-la em uma
implementação física, enquanto satisfaz certas métricas restritas e otimiza outras métricas do
projeto.
A funcionalidade da microeletrônica moderna e dos sistemas embarcados está se tornando
cada vez mais complexa. Obter uma funcionalidade é uma tarefa que demanda atenção aos
detalhes devido à grande variedade de cenários de ambiente possíveis que devem ser
respondidos de maneira adequada.
Não se trata apenas de obter a funcionalidade correta, mas também de criar uma
implementação física que satisfaça todas as restrições, pois há muitas métricas concorrentes e
fortemente restritas.
Ao tentar satisfazer algumas restrições, os projetistas podem enfrentar dificuldades que exigem
compensações. Como essas restrições competem entre si; ao melhorar uma restrição, causa a
piora de outra. É difícil, portanto, encontrar a solução ideal.
É impossível, por exemplo, projetar simultaneamente para alto desempenho, baixo consumo de
energia e tamanho pequeno. Essas três restrições não podem ser otimizadas
simultaneamente; a redução do tamanho prejudica o desempenho; melhorar o desempenho
aumenta a dissipação de energia. O projetista deve, então, encontrar esquemas que ajudem a
satisfazer algumas métricas sem degradar outras. Portanto, pode-se dizer que projetar é uma
questão de otimizar as restrições enquanto se mantém a funcionalidade total do sistema, os
seus requisitos e a especificação.
Neste tema, veremos como especificar um sistema embarcado de alto desempenho baseado
em microcontrolador, começando pelo entendimento dos fatores técnicos e gerenciais a
considerar como restrição no projeto, bem como as limitações dos dispositivos e as boas
práticas para programá-los. Dessa forma, será possível aprender a atuar em projetos de
sistemas embarcados, desde os simples aos de alto desempenho, com base nas métricas de
projeto que conduzem ao atingimento dos requisitos.
MÓDULO 1
 Reconhecer as plataformas de hardware e software para um projeto com
microcontrolador
O verdadeiro desafio que qualquer projetista enfrenta não é apenas prezar pela funcionalidade,
mas encontrar a implementação que pode otimizar simultaneamente grande número de
métricas desse projeto.
Mas o que são as métricas de um projeto?
 RESPOSTA
São uma medida dos recursos de uma implementação, como custo, tamanho, potência e
desempenho. Deve ter um tamanho que caiba em um único chip, deve executar rápido o
suficiente para processar dados em tempo real e consumir energia mínima para estender a
vida útil da bateria, por exemplo. Todos os sistemas de computação têm restrições nas
métricas de projeto, mas aquelas em um sistema embarcado podem ser especialmente
restritas.
Durante as fases de desenvolvimento de um projeto surgem muitos desafios que exigem
muitas decisões.
Algumas requerem o conhecimento da forma mais adequada de abordar a solução.
Outras requerem conhecimento das tecnologias disponíveis no mercado.
Assim, dependendo do projeto, a escolha de um modelo ou família de microcontrolador pode
ser uma decisão que envolve não só o(s) projetista(s), mas também profissionais de outros
departamentos que podem considerar custos, futuros projetos e perspectivas diversas de uma
empresa.
ANÁLISE E PROJETO
A melhor maneira de entender o efeito das métricas e restrições de um projeto é compreender
a diferença entre análise e projeto. Na escola, enfrentamos principalmente problemas de
análise.
Considere, por exemplo, o seguinte problema:
 EXEMPLO
Se um quilo de feijão custa R$10,00, um pão custa R$1,00, um litro de leite custa R$5,00 e um
quilo de carne custa R$50,00, calcule quanto dinheiro a Sra. X vai gastar para comprar quatro
quilos de feijão, um pão, um litro de leite e dois quilos de carne. Isso é o que chamamos de
problema de análise. Um professor está dando a uma criança um teste de sua habilidade de
usar multiplicação e adição. Tem uma única resposta.
Se esse exemplo for convertido em um problema de projeto, teremos: A Sra. X convidou quatro
pessoas. Ela quer gastar apenas R$30,00 na compra de comida para eles. O ingrediente da
refeição deve conter feijão, leite, pão e carne. É exigido da Sra. X que construa uma lista de
compras apropriada usando uma determinada lista de preços para diferentes itens alimentares.
O objetivo (a função) nesse exemplo é comprar mantimentos que custam R$30,00. As
restrições são:
Ter o suficiente para atender quatro pessoas.
A refeição deve incluir itens dos quatro grupos básicos.
Esse, portanto, não é um problema de resposta única. Tem muitas respostas possíveis,
dependendo do preço dos itens individuais, do apetite dos visitantes etc.
Na vida real, todos enfrentam esses problemas de projeto. Eles são mais comuns do que os de
análise. Para resolvê-los, precisamos usar multiplicação e adição como ferramentas para obter
possíveis respostas. A resolução de um problema de projeto requer capacidade de análise e
ocorre normalmente por tentativa e erro, até que uma solução aceitável seja alcançada.
MÉTRICAS COMUNS EM UM PROJETO
As métricas de projeto são características mensuráveis da implementação de um sistema.
Podem ser divididas em quatro grupos amplos com base nos fenômenos de projeto que
medem. São eles:
MÉTRICAS DE DESEMPENHO
Lidam com a velocidade do sistema e quanto tempo leva para executar a aplicação desejada.
MÉTRICAS DE CUSTO
Medem o custo, o custo unitário e o preço do produto. Incluem o custo de NRE (Non-Recurring
Engineering ou engenharia não recorrente). Esse é um custo monetário único para projetar o
sistema. Uma vez que este é projetado, qualquer número de unidades pode ser fabricado sem
incorrer em qualquer custo adicional; daí o termo não recorrente. O tempo para produzir o
protótipo, tempo para mercado e facilidade de uso são algumas das métricas que também
afetam o custo e o preço.
MÉTRICAS DE CONSUMO DE ENERGIA
Medem o consumo de energia do sistema. Essas métricas estão ganhando importância em
muitos campos, conforme os sistemas móveis alimentados por bateria se tornam
predominantes e a conservação de energia se torna mais significativa.
MÉTRICAS DE EFICÁCIA DO SISTEMA
Em muitas aplicações, como as militares, a eficácia do sistema na implementação de seu
objetivo é mais importante do que o custo. Confiabilidade, facilidade de manutenção,
adequação do projeto e flexibilidade estão relacionadas às métricas desse grupo.
Outras métricas incluem aquelas que podem orientar o projetista na escolha de muitos
componentes disponíveis no mercado. Facilidade de uso, suporte de software, segurança e
disponibilidade de fornecedores de segunda fonte são também métricas a se considerar.
RESTRIÇÕES E REQUISITOS DE UM
PROJETO
As restrições de projeto são aquelas que são impostas à solução. São normalmente impostas
pelo cliente, pela organização de desenvolvimento ou por regulamentações externas.
As restrições podem serimpostas ao hardware, ao software, aos dados, aos procedimentos
operacionais, às interfaces ou a qualquer outra parte do sistema.
Os exemplos podem incluir uma restrição de que o sistema deve usar hardware ou software
comercial predefinido, uso de um algoritmo particular ou implementar um protocolo de interface
específico.
As restrições de projeto representam os requisitos que são colocados no sistema −
normalmente uma combinação de demandas de diferentes pessoas em níveis diversos da
organização e do ambiente onde o sistema deve operar. Os requisitos podem ser funcionais ou
não funcionais.
REQUISITO FUNCIONAL
REQUISITO NÃO FUNCIONAL
REQUISITO FUNCIONAL
Descreve as funções − entradas, seu comportamento e saídas − que um sistema deve
executar. Pode ser um cálculo, manipulação de dados, interação com o usuário ou qualquer
outra funcionalidade específica.
REQUISITO NÃO FUNCIONAL
Define o atributo de qualidade de um sistema, um conjunto de padrões usados para julgar sua
operação específica. Exemplo: Quão rápido o sistema está pronto para executar uma medida?
Um requisito não funcional é, portanto, essencial. O seu não cumprimento pode resultar em
sistemas que não atendem às necessidades do usuário − funciona corretamente, mas é difícil
de usar, por exemplo.
A seguir, alguns requisitos não funcionais, descritos para software na IEEE 830-1998, mas que
são usados também em sistemas embarcados com microcontroladores:
DESEMPENHO
Geralmente, significa o tempo necessário para concluir uma tarefa (latência ou tempo de
resposta) ou o número de tarefas que podem ser processadas por unidade de tempo. Os
fatores que influenciam o rendimento e a latência incluem: A taxa de clock, o comprimento da
palavra, o número de registradores de uso geral, a variedade de instruções, a velocidade de
acesso à memória, a linguagem de programação e a disponibilidade de periféricos.
ENERGIA
É a quantidade de energia consumida pelo sistema. Tem um efeito direto na vida útil de uma
bateria. Ele determina os requisitos de resfriamento do chip; mais energia significa mais calor
e, portanto, a necessidade de mais resfriamento. A energia consumida por um dispositivo pode
afetar a confiabilidade geral do sistema e muitas outras métricas de projeto. Alguns
microcontroladores que podem entrar em estado de baixo consumo de energia e são eficientes
neste requisito são: A série STM32 da STMicroelectronics, a série Kinetis L da NXP, a série H8
Super Low Power da Renesas, a série PSoC 6 da Cypress, a série eXtreme Low Power PIC da
Microchip e a série MSP430 da Texas Instruments.
TOLERÂNCIA À TEMPERATURA
Dependendo do ambiente em que seus microcontroladores operam, dispositivos que suportem
temperaturas extremas podem ser úteis. Haverá um balanço entre tolerância e custo de
temperatura. Alguns microcontroladores tolerantes à temperatura incluem: A série STM32F103
da STMicroelectronics, a série Kinetis EA da NXP, RX24T e RX24U da Renesas, a série XMC
da Infineon, microcontroladores PIC e AVR da Microchip e a MSP430F2619S-HT da Texas
Instruments.
SEGURANÇA
A invasão por hackers está aumentando e é uma ameaça especialmente relevante para
microcontroladores usados em automóveis e em IoT. Em resposta, os fabricantes estão
implementando camadas de segurança, como criptografia e segurança física. Atualmente, os
usuários podem comprar microcontroladores certificados com os mais recentes padrões de
segurança com hardware seguro no chip. As empresas que oferecem microcontroladores de
segurança independentes incluem a STMicroelectronics (série ST33), Renesas (série AE-5 e
RS-4), Infineon (OPTIGA Trust e OPTIGA TPM), Cypress (PSoC 64), Microchip e Texas
Instruments (série MSP430).
CUSTO
Microcontroladores estão dentro de uma ampla faixa de preço, de cem unidades por alguns
dólares a alguns dólares por unidade. Para escalar, é necessário considerar o custo total
versus o poder de desempenho individual. Ao começar a trabalhar, deve-se atentar para a
existência de microcontroladores da mesma família com mais memória FLASH e SRAM ou
capacidade de interface com uma memória externa, para eventual expansão do projeto.
CONFIABILIDADE
É a probabilidade de que uma máquina ou produto possa funcionar continuamente, sem falhas,
por um intervalo de tempo especificado ao operar sob condições padrão. Maior confiabilidade
implica menos falhas e, consequentemente, menos tempo de inatividade e perda de produção.
DISPONIBILIDADE
Refere-se à probabilidade de que um sistema esteja operando. Às vezes, indica a possibilidade
de obter o mesmo produto de mais de um fabricante. Esse significado veio do fato de que
muitos dispositivos são feitos por mais de um fabricante. Esse tipo de disponibilidade,
preferencialmente chamado de “fornecedores de segunda fonte”, é importante quando o
projetista do sistema precisa considerar a confiabilidade e a longevidade do fornecimento.
MANUTENIBILIDADE
A capacidade de modificar o sistema após seu lançamento inicial, especialmente por
profissionais que não projetaram originalmente o sistema. É também a facilidade com que um
sistema de firmware ou componente pode ser modificado para corrigir falhas, melhorar o
desempenho ou outros atributos, ou se adaptar a um ambiente alterado.
TIME-TO-MARKET
É o tempo necessário para desenvolver um sistema até o ponto em que ele possa ser lançado
e vendido aos clientes. Os principais contribuintes são o tempo de projeto, o tempo de
fabricação e o tempo de teste.
PASSOS PARA A SELEÇÃO DE UM
MICROCONTROLADOR
Mesmo considerando os aspectos já mencionados, selecionar o microcontrolador certo para
um produto é uma tarefa de paciência. Não há apenas uma série de recursos técnicos a serem
considerados, mas também questões de negócio, como custo e prazos de entrega, que podem
paralisar um projeto.
 COMENTÁRIO
No início de um projeto, existe grande tentação de começar a selecionar um microcontrolador
antes que os detalhes do sistema tenham sido totalmente definidos, o que não é uma boa
ideia.
Antes de qualquer decisão, os engenheiros de hardware e software devem trabalhar os níveis
elevados do sistema, o diagrama de blocos e o fluxograma. Só então haverá informações
suficientes para começar a tomada de decisão sobre a seleção do microcontrolador.
Muitos profissionais, depois de alguns projetos, tendem a pautar a sua escolha por essas
experiências, desconsiderando outras famílias de microcontroladores com a qual têm pouca
familiaridade. Esse pode ser um comportamento aceitável, pois certamente a experiência conta
muito para a conclusão mais rápida e sem erros quando o profissional já conhece as
ferramentas envolvidas.
 ATENÇÃO
Porém, com avanços frequentes nos dispositivos, o ciclo de vida de um produto pode ser
prejudicado com o uso de um componente tão vital em risco de obsolescência ou sem atender
às demandas mais atuais em termos de interfaces, por exemplo.
A curva de aprendizado para uma equipe usar um novo dispositivo pode ser recompensada por
um produto final mais integrado e preparado para as novas necessidades. Portanto, decisões
de escolha de microcontroladores devem ser tomadas com participação ampla de profissionais
da empresa, sem deixar novas opções de fora nem modismos não testados suficientemente
tomarem a dianteira nesta escolha.
No vídeo a seguir, você observará os passos para seleção dos microcontroladores.
VERIFICANDO O APRENDIZADO
MÓDULO 2
 Identificar as limitações dos microcontroladores para a especificação de projetos
embarcados de alto desempenho
Os microcontroladores, como deve ser de seu conhecimento, são computadores de pequeno
porte usados em muitas coisas nunca antes imaginadas como possíveis há poucas décadas.
Esses computadores são “embutidos” em dispositivos, dando-lhes um desempenho que
melhora as suas funcionalidades. Esses dispositivos inteligentes podem fazer mais e mais
rápido do que nunca, mas nem todos os microcontroladores embarcados são criados de forma
a ter o mesmodesempenho e confiabilidade. Alguns têm mais exigências do que outros.
Muitos desses integram sistemas que devem ter capacidades extremas em várias dimensões:
Confiabilidade, alta velocidade de processamento, ser reconfigurável e flexibilidade operacional
em sistemas ditos críticos.
Esses sistemas críticos devem operar perfeitamente para proteger a vida, a propriedade, o
equipamento e o meio ambiente.
MICROCONTROLADORES EM SISTEMAS
CRÍTICOS EMBARCADOS
Um sistema embarcado é um computador com funções de controle específicas, podendo ser
parte de um sistema de computador maior ou um dispositivo autônomo. Pode conter os
processadores programáveis, que são os microcontroladores, ou os processadores de sinal
digital (DSPs), e a maioria deles deve operar dentro de restrições de tempo real.
O sistema embarcado poucas vezes é um dispositivo de uso geral, como no caso de
smartphone. Geralmente, é usado em aplicações especializadas, como: Máquinas de lavar,
telefones, fornos de micro-ondas, automóveis e também em muitos tipos diferentes de
sistemas críticos embarcados.
Os sistemas críticos embarcados são definidos para aplicações das forças armadas, transporte
ferroviário, controle médico, industrial, exploração espacial, aviação, instrumentação nuclear e
muitas outras indústrias.
Mas com que precisão é definido um “sistema crítico embarcado”? E por que a definição
importa?
 RESPOSTA
São assim chamados aqueles que atuam em sistemas críticos para a vida ou para a
segurança, em que a falha ou mau funcionamento pode resultar em:
Lesões graves a pessoas.
Perda ou dano grave ao equipamento.
Dano ambiental.
Essas definições de "crítico para a vida" ou "crítico para a segurança", quando designadas aos
sistemas embarcados, podem resultar em exigências para os dispositivos eletrônicos desses
sistemas, como:
Gerenciar entrada e saída em alta velocidade.
Envolver processamento em tempo real.
Ser ambientalmente restritos a tamanho, peso e potência consumida.
Possuir taxa de falha muito baixa em comparação a aplicações de baixo risco.
Existem normas e guias que estabelecem orientações e requisitos para atingimento de
sistemas críticos com alta confiabilidade em cada área particular.
A norma IEC 61508 é um exemplo, direcionada a dispositivos elétricos, eletrônicos e
eletrônico-programáveis (Electrical/Electronic/Programmable Electronic − E/E/PE) com
aplicação industrial em sistemas relacionados à segurança funcional. A norma tem aplicação
em uma ampla área de sistemas com funções críticas baseadas em dispositivos embarcados,
como freios de automóveis e aparelhos médicos de auxílio à vida.
Além da IEC (International Electrotechnical Commission), outras organizações como a ISO
(International Organization for Standardization) e a ITU (International Telecommunication
Union) desenvolvem normas e guias internacionais para áreas com sistemas críticos, definindo
critérios e requisitos para áreas particulares como ferrovias e aviação.
 SAIBA MAIS
De acordo com essas normas, alguns sistemas críticos embarcados devem sobreviver em
ambientes adversos: Choques e vibrações severas, radiação ionizante em taxas elevadas −
como no espaço e em temperaturas extremas, de baixas a altas −, entre outros.
Dessa forma, a definição de sistema crítico embarcado é importante para permitir uma
especificação correta dos dispositivos, incluindo os microcontroladores, que o compõem.
Vamos examinar algumas das exigências em especificações mais comuns nesse tipo de
sistema:
CONFIABILIDADE
Os sistemas críticos embarcados estão sendo projetados tendo a confiabilidade como
requisito principal do projeto.
 ATENÇÃO
Esse requisito define a habilidade de um item em manter a execução de uma função como
especificado, sobre dadas condições operacionais e ambientais e por um período de tempo
indicado.
A confiabilidade é uma questão da mais alta prioridade nas infraestruturas que apoiam a nossa
sociedade, com muitos sistemas complexos cujas funções necessitamos proteger e manter em
funcionamento, sejam estas para um avião, uma planta nuclear, um equipamento de terapia
com radiação ou um sistema de frenagem de um trem.
A confiabilidade pode ter o seu foco em propriedades diferentes, dependendo do sistema e das
funções desempenhadas. Probabilidade de produzir os resultados requisitados, tempo de
resposta alcançado, graus de tolerância a falhas ou de prevenção de intrusões deliberadas em
sistemas são algumas dessas propriedades em que se busca confiabilidade.
Além de utilizarem componentes de modelos especiais, eles atingem os níveis desejados de
confiabilidade e tempo médio entre falhas por meio de redundância, ou seja, mais de um
dispositivo realizando a mesma função para o caso de falha de algum deles.
DETERMINISMO
Os sistemas críticos embarcados são altamente determinísticos, devendo executar em tempo
real as respostas aos eventos.
Quando um evento é detectado, uma resposta em tempo previsível deve ser aplicada.
O determinismo desempenha um papel fundamental na limitação da latência e no
gerenciamento da capacidade de resposta dos sistemas embarcados em tempo real. Quanto
mais determinista for o sistema, mais consistente será sua capacidade de resposta. Um fator
primário que afeta esse requisito é quantas interrupções um sistema deve tratar
simultaneamente. Em geral, aumentar o número de interrupções no sistema prejudicará seu
determinismo.
 EXEMPLO
Considere, por exemplo, um sistema com uma única interrupção que termina em 50 ciclos. A
latência para tal interrupção, então, é consistentemente da ordem de 50 ciclos. Observe que
mesmo as interrupções mais simples levam cerca de 50 ciclos no momento em que o
microcontrolador salva o seu estado atual para um número limitado de registradores, acessa
um periférico, salva os dados e restaura o seu estado.
No entanto, não é a perspectiva de lidar com uma única interrupção que cria a maioria dos
problemas para os desenvolvedores em termos de determinismo e latência. Em vez disso, o
difícil desafio de cumprir prazos em tempo real surge quando muitas interrupções acontecem
ao mesmo tempo. Por exemplo, se uma interrupção de prioridade mais alta é introduzida no
sistema que é concluída em 75 ciclos, a latência da primeira interrupção é afetada, pois a
tarefa de prioridade mais alta pode interromper. A latência agora varia de 50 a 125 ciclos para a
tarefa de prioridade mais baixa.
 ATENÇÃO
Conforme mais interrupções são introduzidas, a latência para interrupções de prioridade mais
baixa aumenta à medida que o determinismo diminui. Uma tarefa de 50 ciclos pode ser
interrompida várias vezes e exigir da ordem de 100 a 1000 ciclos para ser concluída. Esse
fator é importante porque nem todas as interrupções podem ser de alta prioridade, umas
em relação às outras.
O determinismo afeta, portanto, diretamente a capacidade de resposta, confiabilidade e
precisão. Se um desenvolvedor souber que a latência está fixada em 50 ou 500 ciclos, isso
pode ser levado em consideração durante o processamento. No entanto, quando a latência
pode variar de 50 a 500 ciclos, o melhor que os desenvolvedores podem fazer é assumir uma
latência típica, como 200 ciclos, e suportar qualquer variação como erro. Além disso, a latência
do pior caso pode começar a se aproximar das limitações de prazo em tempo real e ameaçar a
confiabilidade do sistema. Reduzir o número potencial de interrupções simultâneas, mesmo as
de baixa frequência, pode aumentar substancialmente o determinismo do sistema.
PROCESSAMENTO DE SINAL DE ALTA FREQUÊNCIA
A geração de sinais está se tornando uma tarefa mais comum em uma ampla gama de
aplicações embarcadas.
Os sinais são usados para gerar som, gerenciar um regulador conversor de tensão, controlar
atuadores em aplicações industriais e servir a uma infinidade de outras funções.
Quanto mais alta a frequência do sinal, maior a carga na CPU quando as interrupções são
empregadas e maior o potencial de aumento dalatência para outras tarefas. Logo, para
eventos com maior frequência de ocorrência, a carga da CPU se torna uma consideração
importante.
 EXEMPLO
Por exemplo, um sensor de alta velocidade precisa ter amostras coletadas antes que a próxima
amostra esteja pronta, para evitar a perda de dados. Sendo assim, um medidor de fluxo,
sistema de posicionamento de múltiplos eixos ou sistema de instrumentação coletando 5
milhões de amostras por segundo para medições rápidas e precisas consumirá dezenas a
centenas de milhões de ciclos a cada segundo apenas para essa coleta. Por esse motivo,
muitos sistemas podem usar um microcontrolador separado para gerenciar sensores ou
motores de alta frequência individuais.
As aplicações de computação do futuro se tornarão ainda mais dependentes de sistemas
críticos embarcados à medida que continuarem a aumentar o alcance dos sistemas
autônomos. Estes representam o próximo grande passo na fusão de máquinas, computação,
sensoriamento e software para criar sistemas inteligentes capazes de interagir com as
complexidades do mundo real. Devem, portanto, ter grande capacidade em desempenho e
confiabilidade, exigindo essa capacidade dos sistemas críticos embarcados.
MERCADO E CARACTERÍSTICAS DE
MICROCONTROLADORES PARA
APLICAÇÕES CRÍTICAS
Os fabricantes de microcontroladores têm dedicado bastante espaço nos últimos anos para o
desenvolvimento de modelos para aplicações críticas de segurança (safety critical
applications).
Os microcontroladores Hercules TMS470M/TMS570M e RM4x da Texas Instruments de 16/32
bits são dispositivos que seguem nessa linha. Também alguns modelos de PIC, como o
PIC12F1612 e o PIC16F1613. Outros fabricantes que lançaram modelos para aplicações
críticas foram a NXP com a série NXP LPC17xx, como LPC1769 e LPC1788, a Freescale, com
os modelos Kinetis K20, e a Renesas, com o modelo V850.
Mas quais são as diferenças principais desses modelos?
 RESPOSTA
Em geral, esses modelos seguem normas, como a IEC 61508 (Segurança Funcional de
Sistemas Elétricos/Eletrônicos/Eletrônicos Programáveis Relacionados à Segurança). Essas
normas reconhecem a necessidade de proteção contra falhas aleatórias e sistemáticas em
sistemas críticos de segurança.
As falhas aleatórias geralmente são falhas de componentes e estão relacionadas à
confiabilidade e aos números de FIT (falhas no tempo). As sistemáticas são geralmente falhas
de método de projeto de software e hardware. Ou seja, são causadas por um projeto imperfeito
quanto ao atendimento de um sistema crítico.
Essas falhas tornam-se erros quando uma delas resulta em uma perda da função de
segurança ou viola uma meta de segurança.
 COMENTÁRIO
Falhas sistemáticas frequentemente surgem de erros nos processos de desenvolvimento,
fabricação ou operação. Exemplos: Falha em verificar a funcionalidade projetada, escapes de
teste de fabricação ou operação de um produto fora dos parâmetros garantidos.
Falhas no software também são consideradas sistemáticas, pois este é totalmente
determinístico e, embora desafiador, pode ser formalmente comprovado como correto antes da
implementação do produto. O gerenciamento de falhas sistemáticas é obtido por meio de
processos robustos que incluem verificações e balanços em cada atividade de
desenvolvimento.
O principal método usado para mitigar as falhas de ambos os tipos é o autoteste, tanto em
hardware quanto no software que está rodando. Alguns dos recursos de teste nesses modelos
especiais de microcontroladores, voltados para aplicações críticas de segurança, são os
seguintes:
TEMPORIZADOR DE LIMITE DE HARDWARE
A operação do temporizador de limite de hardware é uma extensão da operação normal e
permite, por exemplo, que este seja redefinido com base em um sinal externo. O reset também
pode ser de um sinal analógico porque a saída do comparador analógico pode ser usada para
zerar o temporizador. É um recurso útil para checagem de falhas e garantia de temporizações
precisas.
VERIFICAÇÃO DE REDUNDÂNCIA CÍCLICA COM
VARREDURA DE MEMÓRIA (CRC/SCAN)
O CRC com varredura de memória é um gerador de verificação CRC implementado por
hardware e configurável por software. O CRC pode ser controlado por software, mas, no modo
de varredura de memória, pode ser configurado para varrer automaticamente a memória
FLASH procurando por danos, com a faixa de interesse sob o controle do usuário. O uso mais
comum é no modo intermitente na inicialização − verificando efetivamente a integridade do
programa antes de executá-lo, em vez de tentar detectar a corrupção da memória flash em
tempo real, que pode parar o programa.
CRONÔMETRO DE WATCHDOG EM JANELAS (WWDT)
A versão em janela é uma adição aos cronômetros de watchdog que já existem há muitos anos
nos microcontroladores. Enquanto um cronômetro de watchdog normal simplesmente expira se
não for apagado dentro do período de tempo limite (causando uma reinicialização do
processador), a versão em janela também reinicializará o processador quando for apagado
muito cedo . O tamanho da janela é de 12,5% a 100% do tempo do período de watchdog. Em
100%, este é o normal, já existente.
ILHA SEGURA
O conceito de ilha segura inclui a implementação de mecanismos de segurança de hardware
para as memórias flash e SRAM internas. Em um sistema típico, a flash é usada como
memória de instrução da CPU e a SRAM fornece memória de dados da CPU. Ambas, bem
como a conexão entre elas e a CPU, devem estar funcionando corretamente para garantir a
operação correta do software. O diagnóstico de tempo de execução primário para SRAM e
flash é a lógica ECC (código de correção de erros) nos dados aumentados por endereço e
paridade de controle. A tecnologia ECC é uma forma bem aceita e eficaz de detectar falhas
aleatórias. Ela codifica os dados de uma forma que permite aos sistemas não apenas detectar
quando a memória foi corrompida, mas também corrigir erros de bit único, se desejado, para
que a operação do sistema possa continuar ininterrupta.
Assista, no vídeo a seguir, como derrubar as limitações no desempenho dos
microcontroladores.
VERIFICANDO O APRENDIZADO
MÓDULO 3
 Empregar as boas práticas de programação para o desenvolvimento do software
embarcado nos microcontroladores
A criação de código-fonte (implementação de código) é uma tarefa inevitável para o
desenvolvimento de software embarcado. O sucesso ou o fracasso dessa tarefa afeta muito a
qualidade do software resultante.
Diz-se que a linguagem C, a linguagem de programação mais comumente usada para o
desenvolvimento de software embarcado, oferece aos programadores uma flexibilidade de
escrita relativamente extensa.
A variedade de programas escritos em C, portanto, tende a refletir claramente a diferença no
nível de habilidade de codificação entre programadores experientes e menos experientes. Não
é desejável que o código-fonte varie muito em qualidade, dependendo das habilidades e
experiência de codificação individuais dos programadores.
 VOCÊ SABIA
Para evitar que esse risco leve a sérios problemas de qualidade, empresas com visão de futuro
estão trabalhando proativamente em direção à padronização de seus códigos-fonte,
estabelecendo convenções de codificação a serem seguidos em toda a organização ou grupo.
PROBLEMAS COM RELAÇÃO ÀS
CONVENÇÕES DE CODIFICAÇÃO
A convenção de codificação é o conjunto organizado de estilos (ou regras) de escrita de código
que precisam ser seguidas para manter a qualidade. No entanto, existem vários problemas em
seu uso atual, incluindo aqueles mencionados a seguir:
A necessidade de regras não é compreendida. Os métodos apropriados para lidar com a
violação destas também não são amplamente compartilhados.
Existem regras muito numerosas para aprender. No entanto, as existentes não são
abrangentes o suficiente para cobrir todo o escopo da codificação.
Uma vez que ferramentas altamente confiáveis que podem verificar completa e
precisamente se o código escrito está em conformidade com as regras relevantesestão
indisponíveis, os engenheiros devem revisar o código manualmente por meio de
verificação visual, que é um fardo pesado.
Devido a tais circunstâncias, existem, de fato, algumas convenções de codificação
estabelecidas em nível de organização ou departamento que perderam seu significado e não
são mais estritamente observadas. No entanto, as organizações que as possuem, não importa
o tipo de formato em que as preparem, são pelo menos melhores do que aquelas sem nenhum.
Ainda há algumas empresas que não conseguem chegar a um consenso sobre a convenção
de codificação a ser seguida internamente e estão confiando em grande parte nos julgamentos
individuais dos programadores para decidir como o código-fonte deve ser escrito.
ESCRITA DE CÓDIGO C EFICIENTE PARA
MICROCONTROLADORES
A preocupação em escrever um código eficiente ou, em outras palavras, otimizado para a
plataforma a qual se destina, é permanente para programadores e projetistas, principalmente
quando se trabalha com programas que rodam em sistemas operacionais.
 DICA
No caso de microcontroladores, a experiência de muitos programadores mostra que essa
preocupação deve ser colocada em segundo plano. Digamos que vale a ideia de qualquer
outro desenvolvimento de software: Não otimize até que saiba que precisa, e então não otimize
até que saiba o que precisa otimizar. Escreva o código para que seja confiável, legível e fácil
de manter primeiro. A otimização prematura é mais um problema em sistemas embarcados.
Coisas que se precisa considerar e estar ciente em sistemas embutidos são aquelas que irão
fazê-los parar de funcionar, de formas inesperadas, e não apenas torná-los lentos.
A seguir algumas delas:
STACK DE PILHA
Normalmente tem-se apenas um pequeno tamanho de pilha. Deve-se estar ciente qual é a
utilização desta em todos os momentos. Problemas de pilha causam alguns dos defeitos mais
inesperados e difíceis de resolver.
ALOCAÇÃO DINÂMICA DE MEMÓRIA
Existem várias razões para não usar alocação dinâmica de memória em um sistema
embarcado:
É importante não se descobrir repentinamente sem memória.
Fragmentação − Os sistemas embarcados podem funcionar durante anos, o que pode
causar grande desperdício de memória devido à fragmentação.
Não é realmente necessária. A alocação de memória dinâmica permite reutilização da
mesma memória para fazer coisas diferentes em momentos distintos. Os sistemas
embarcados tendem a fazer a mesma coisa o tempo todo.
Rapidez − A alocação de memória dinâmica é relativamente lenta e fica mais devagar
conforme a memória fica fragmentada.
Ao usar a mesma memória dinâmica para diferentes threads e interrupções, as rotinas de
alocação/liberação precisam executar o bloqueio, o que pode causar problemas de
interrupção de serviço.
A alocação dinâmica de memória torna muito difícil depurar, especialmente com algumas
das ferramentas de depuração limitadas disponíveis no sistema embarcado. Ao alocar
coisas estaticamente, é possível saber onde as coisas estão o tempo todo, o que significa
que é muito mais fácil inspecionar o estado de algo.
INTERRUPÇÕES DE HARDWARE
É necessário saber como lidar com elas de maneira segura e oportuna e como fazer um código
reentrante seguro. Por exemplo, as bibliotecas padrão C geralmente não são reentrantes,
portanto, não devem ser usadas dentro de manipuladores de interrupção.
ASSEMBLY, OU LINGUAGEM DE MONTAGEM
São raros os casos em que seja necessário mesclar Assembly e C. No máximo, uma pequena
quantidade (embutida) é necessária para obter algo que C simplesmente não pode fazer.
O PADRÃO MISRA-C
Embora seguir padrões de programação pareça sempre ser tedioso e cerceador, ainda é uma
das melhores escolhas para seguir boas práticas de programação, em particular para sistemas
embutidos que operam em áreas críticas, como a automobilística.
O MISRA-C é um padrão de desenvolvimento de software em linguagem C desenvolvido pela
Associação de Confiabilidade de Software da Indústria Automotiva (Motor Industry Software
Reliability Association).
Embora tenha foco em sistemas embarcados automotivos, possui práticas que podem ser
estendidas também para outras áreas que operam sistemas críticos.
Com sua primeira versão em 1998, o MISRA-C teve a sua última versão em 2012 e vem se
tornando um padrão para empresas de sistemas embarcados. Essas empresas pretendem
utilizar melhores práticas no desenvolvimento de software seguro e portável em linguagem C.
As diretrizes da MISRA-C estão preocupadas com aspectos de C que impactam na segurança
e proteção dos sistemas, sejam embutidos ou autônomos: Eles definem um subconjunto da
linguagem C no qual a chance de cometer erros é reduzida.
As diretrizes proíbem o comportamento indefinido crítico e restringem o uso de comportamento
definido pela implementação e extensões do compilador. Eles também limitam o uso de
recursos de linguagem que podem ser facilmente mal utilizados ou mal interpretados. No geral,
as diretrizes são projetadas para melhorar a confiabilidade, legibilidade, portabilidade e
manutenção.
Existem dois tipos de diretrizes MISRA-C:
DIRETIVA
REGRA
DIRETIVA
Uma diretriz na qual as informações relativas à conformidade geralmente não estão totalmente
contidas no código-fonte − requisitos, especificações, projetos, todos devem ser levados em
consideração. Ferramentas de análise estática podem auxiliar na verificação da conformidade
com as diretivas, se fornecidas com informações extras não derivadas do código-fonte.
REGRA
Uma diretriz na qual as informações sobre conformidade estão totalmente contidas no código-
fonte. Descontando a indecisão, as ferramentas de análise estática devem, em princípio, ser
capazes de verificar o cumprimento da norma.
 SAIBA MAIS
O padrão possui mais de 150 regras divididas em mais de 20 categorias. Veja Algumas
regras.
VERIFICAÇÃO E VALIDAÇÃO EM SISTEMAS
EMBARCADOS
Normalmente, damos o nome de “garantia de qualidade” à função de desenvolvimento de
software envolvida no teste ou verificação de um produto depois de construído.
Mas é realmente possível garantir que um bom produto seja construído em primeiro lugar?
Muito improvável.
Uma pergunta mais profunda pode ser: É possível testar a qualidade em um produto? Sim,
basta construir uma peneira de teste tão apertada que nenhum produto ruim possa passar por
ela. Então rejeita-se sistematicamente tudo que não passa.
 COMENTÁRIO
A ideia por trás dessa abordagem é que, eventualmente, o pessoal de desenvolvimento
começará a descobrir que precisa criar bons produtos e mude a maneira de fazer as coisas.
Apesar de não ser o ideal para a melhoria do processo de software, é um cenário muito comum
nas empresas de software atualmente, incluindo as de embarcados.
Construir um software de qualidade conforme ele está sendo desenvolvido é muito mais eficaz
do que tentar testá-lo depois de construído. As técnicas de verificação e validação (V&V)
podem ser aplicadas em todo o ciclo de vida do produto para ajudar a garantir que o software
correto está sendo construído e que ele está sendo construído corretamente.
Aplicar essas técnicas em software embarcado busca a alta qualidade do produto final.
O foco da verificação e a validação é detectar defeitos o mais cedo possível após eles serem
introduzidos e removê-los na origem. Isso não apenas torna a remoção de defeitos mais
https://stecine.azureedge.net/repositorio/projetos_com_microcontroladores/docs/algumas_regras.pdf
barata, mas também fornece uma confiança muito maior de que a qualidade está sendo
incorporada ao produto, em vez de tentar filtrá-la antes do envio.
A verificação e a validação têm funções diferentes no desenvolvimento de um projeto. A
validação está preocupada em construir o produto certo, e a verificação, em construir o produto
da maneira certa.
As definições a seguir ajudam a entender o foco da verificação e da validação:
DEFINIÇÃO # 1
DEFINIÇÃO # 2
DEFINIÇÃO # 3
DEFINIÇÃO # 1
Validação é a determinação da exatidãodo programa final ou software produzido a partir de um
projeto de desenvolvimento em relação às necessidades e aos requisitos do usuário.
Geralmente é realizada pela averiguação de cada estágio do ciclo de vida de desenvolvimento
de software.
A verificação é definida como a demonstração de consistência, integridade e correção do
software em cada estágio e entre cada estágio do ciclo de vida de desenvolvimento.
Essas definições indicam que a validação se preocupa principalmente em garantir que os
requisitos foram atendidos pelo produto final. A verificação está, então, preocupada com a
tradução e a rastreabilidade de cada estágio de desenvolvimento para seu estágio dependente.
Em outras palavras, pode-se demonstrar que o projeto deriva corretamente dos requisitos e
que a validação é comumente obtida por meio da verificação de cada fase.
DEFINIÇÃO # 2
A verificação envolve a avaliação do software durante cada fase do ciclo de vida para garantir
que ele atenda aos requisitos definidos na fase anterior. A validação envolve testar o software
ou sua especificação no final do esforço de desenvolvimento para garantir que ele atenda aos
seus requisitos (que faça o que deve). Embora tenham definições separadas, é possível obter
o máximo benefício usando-as sinergicamente e tratando 'V&V' como uma definição integrada.
DEFINIÇÃO # 3
O teste de software é um elemento de um tópico mais amplo que costuma ser referido como
verificação e validação (V&V). A primeira se refere ao conjunto de atividades que garantem que
o software implementa corretamente uma função específica. A última se refere a um conjunto
diferente de atividades que garantem que o software que foi construído seja rastreável aos
requisitos do cliente.
ATIVIDADES DE V&V
Grande número de elementos pode ser verificado durante as atividades de V&V, mas quatro
são particularmente importantes: Integridade, consistência, viabilidade e testabilidade.
INTEGRIDADE
Significa que um produto de trabalho está completo em relação ao seu antecessor. Ou seja,
não há itens marcados como “TBD” (a ser determinado), referências inexistentes ou ausência
de itens de especificação (particularmente casos especiais não considerados), funções e
produtos. Se um produto de trabalho anterior identifica uma função ou recurso, então o produto
de trabalho que está sendo revisado deve ter seu tratamento análogo da mesma função ou
recurso.
CONSISTÊNCIA
Significa que o produto de trabalho não cria requisitos conflitantes. Ela pode ser interna
(significando dentro do próprio produto de trabalho) e externa (com respeito a outro produto de
trabalho). Por exemplo, uma função pode ter uma definição de valores de saída que conflita
com os valores de entrada de outra função que ela chama. Cada função pode ser internamente
correta, mas o defeito na especificação se tornará evidente quando as duas forem integradas
posteriormente no ciclo de vida do produto.
VIABILIDADE
Está relacionada principalmente à capacidade de entregar um produto de trabalho que
depende daquele que está sendo revisado. Por exemplo, um requisito pode ser internamente
consistente e correto do ponto de vista do usuário, mas não ser viável para construir dado o
nível de recursos humanos alocados para o produto. Da mesma forma, uma especificação
pode exigir um determinado nível de desempenho por um módulo que quase certamente não é
alcançável dada a tecnologia disponível. A viabilidade também deve explorar questões de
risco, sejam eles relacionados a questões técnicas, custo ou cronograma, ambiente ou
interações entre o sistema e outros sistemas ou usuários.
TESTABILIDADE
Está relacionada à capacidade de realizar testes específicos em produtos de trabalho
apropriados. Em particular, um produto de trabalho deve ser específico, inequívoco e
quantitativo ou não pode ser testado. Por exemplo, imagine uma especificação que afirma: “O
algoritmo de classificação deve ser o mais rápido possível.” Tal requisito não pode ser testado
em um produto de trabalho, porque nenhuma medida objetiva existe para determinar se um
teste foi aprovado ou reprovado. Prestar atenção à testabilidade não só torna o produto mais
testável (obviamente), mas de maior qualidade (seja ele testado ou não), porque designers e
codificadores terão que esclarecer essas questões antes que o produto final seja construído,
em vez de descobrir o problema mais tarde. Além disso, a capacidade de teste inclui a
identificação de “critérios de saída”, que ajudam os engenheiros a saber quando o produto foi
testado em um nível suficiente antes do envio.
As atividades de V&V buscam, ao final, uma certificação adequada ao produto que integra o
software do sistema embarcado. Ou seja, a geração de um certificado que apoia a afirmação
de que o software foi:
Desenvolvido de uma certa maneira.
Exibirá algum conjunto de características desejáveis de tempo de execução.
Terá alguma outra característica estática embutida nele.
 EXEMPLO
Por exemplo, o certificado poderia simplesmente declarar que um tipo específico de teste foi
aplicado e em que grau ou meticulosidade.
Para algumas aplicações a certificação é imperativa. Nenhum país permite a operação de uma
usina nuclear sem certificação dos diversos sistemas que a integram, por exemplo. Mas,
mesmo para aplicações menos críticas, ela pode trazer vantagens e desvantagens:
VANTAGENS
DESVANTAGENS
VANTAGENS
A certificação pode influenciar o mercado − Os requisitos mínimos que todo software
deve satisfazer podem aumentar o nível geral de confiabilidade ou reduzir os custos de
uso.
Certificação como base para obtenção de garantia.
Transferência de risco do usuário ou fornecedor para a autoridade de certificação.
Garantias de comportamento do produto (funcional, não funcional).
DESVANTAGENS
Adicionar custos desnecessários e atrasos aos projetos.
Dar confiança injustificada no comportamento do sistema.
Impedir flexibilidade, inovação e interoperabilidade, pois os certificados podem ser
definidos de forma bastante restrita.
Conheça as boas práticas de programação para microcontroladores no vídeo abaixo:
VERIFICANDO O APRENDIZADO
MÓDULO 4
 Identificar microcontroladores para projetos de comunicação sem fio e Internet das
Coisas (IoT)
A expressão Internet das Coisas (Internet of Things – IoT) tem nos acompanhado nos últimos
anos para indicar oportunidades de negócios e grande conjunto de equipamentos ligados de
alguma forma à internet.
Mas o que temos realmente de oportunidade para quem virá a trabalhar com
microcontroladores em sistemas embarcados? Quais os caminhos mais curtos para se integrar
nessas oportunidades?
O QUE É A INTERNET DA COISAS?
A IoT é uma rede de objetos físicos (como dispositivos vestíveis, eletrodomésticos, sistemas de
segurança, pessoal e veículos comerciais, nanotecnologia, equipamentos de fabricação e
muito mais) incorporados com componentes inteligentes (como microcontroladores,
armazenamento de dados, software, sensores, atuadores etc.) e conectados a outros
dispositivos e sistemas pela internet.
Na escala micro, as "coisas" podem ser indivíduos, componentes, como uma unidade de
iluminação inteligente em um edifício comercial de escritórios, ou o próprio edifício, como um
item em um portfólio de ativos sendo monitorados. O valor da IoT está nos dados que são
coletados e, em seguida, analisados para fornecer ideias ou ações. Para garantir a integridade
desses dados, todo o sistema deve ser seguro e gerenciado. Uma parte vital disso é a escolha
do protocolo de conectividade.
A sustentabilidade do sistema depende de ele ser capaz de transmitir dados de modo confiável
em uma variedade de distâncias e através de uma ampla gama de materiais, da forma mais
eficiente em energia possível. O elemento de eficiência é fundamental porque muitos − talvez a
maioria − dos aplicativos IoT irão depender de sensores alimentados por bateria, sensor
embutido em um veículo elétrico, enterrado em um colheitas do agricultorou instalado dentro
de uma ponte ou edifício.
 ATENÇÃO
Os dispositivos IoT podem coletar, armazenar, compartilhar dados e executar funções de
controle, como em medidores inteligentes e lâmpadas, veículos autônomos e sofisticados
equipamentos industriais − aumentando o uso de inteligência artificial e aprendizado de
máquina (machine learning).
SOLUÇÕES PARA IOT
As soluções para IoT ajudam a fornecer e a gerenciar as partes díspares da IoT, como
dispositivos, sensores, segurança, redes e plataformas.
Sensores fornecem a dispositivos e objetos do dia a dia funcionalidades que podem ser
conectadas. Muitos dispositivos IoT agora são projetados com vários sensores para reunir uma
variedade de dados, que podem ser coletados, analisados e utilizados.
Conforme a IoT se expande, mais empresas estão usando soluções de sistema em um chip
para economizar espaço e melhorar a integração. As medidas de segurança que protegem os
dispositivos e as redes IoT de ataques estão sendo incorporadas com mais frequência às
operações centrais por meio de uma arquitetura de segurança. A plataforma IoT deve ter base
flexível, segura e eficiente, que abranja conectividade, dispositivo e gerenciamento de dados.
Para acompanhar o rápido desenvolvimento de novos dispositivos IoT, as empresas estão
aproveitando as soluções que oferecem sistemas operacionais avançados e em tempo real,
dispositivos de baixo consumo de energia e recursos de segurança incorporados. As soluções
para IoT podem incluir, mais especificamente: Soluções de tecnologia, de gerenciamento de
dispositivos e de segurança.
A IoT é o principal impulsionador da transformação digital, possibilitando que as empresas
reinventem produtos, serviços, operações internas e modelos de negócios.
As soluções de IoT permitem que as organizações aproveitem facilmente os benefícios da IoT
como uma rede robusta, segura e poderosa de dispositivos, edifícios e infraestrutura
conectados. Com dados acessíveis e transparentes da extremidade da rede, as empresas
podem obter ideias sobre a eficiência operacional e novas fontes de receita. Uma solução IoT
também pode criar comunicações contínuas entre dispositivos e funcionários.
Dentro do universo de soluções para IoT, o dispositivo principal de tecnologia é o
microcontrolador com interfaces sem fio integradas.
MICROCONTROLADORES NA IOT
Uma visão geral de um sistema IoT é mostrada na Figura 1, que inclui os seguintes
componentes principais:
 Figura 1 – Visão geral de um sistema de IoT.
Entenda um pouco mais:
Sensores
Eles são usados para monitorar o ambiente para que os
dados de detecção possam ser gerados. Esses dados podem
ser processados localmente ou carregados na nuvem para
armazenamento seguro.
Comunicação
Os dispositivos podem ser interconectados entre si e ter a
capacidade de se interconectar com a internet. Protocolos de
comunicação como ZigBee, Bluetooth e Wi-Fi podem ser
usados nesse componente.
Microcontroladores Eles fazem todos os dispositivos funcionarem juntos como um
sistema para fornecer os serviços inteligentes. Os dados de
detecção são enviados ao microcontrolador para
processamento e estes geram sinais para os atuadores.
Dessa forma, todo o sistema pode ser controlado até o estado
de destino.
Atuadores
São usados para manipular o ambiente. Os atuadores são
uma espécie de dispositivo transdutor, pegando um sinal
elétrico como entrada e convertendo-o em um movimento
físico mecânico.
Interfaces de
usuário
O sistema IoT deve fornecer serviços inteligentes para seus
usuários finais, e as interações entre eles devem ser de forma
adequada.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Todo o sistema IoT deve ser incorporado com inteligência embutida para melhorar a eficiência
da colaboração. Assim, o microcontrolador para IoT deve ser equipado com técnicas
inteligentes para coordenar todos os componentes para trabalharem juntos de forma eficiente.
O microcontrolador pode ser considerado o “cérebro” do sistema IoT, pois pode buscar dados
de sensores, analisar dados com técnicas de inteligência computacional e gerar os comandos
finais de controle.
O objetivo final de um microcontrolador para IoT é fornecer serviços inteligentes aos usuários.
Isso é determinado pela maneira como ele interage com outros componentes − interação com
sensores, com atuadores e com os usuários. Portanto, além do projeto elaborado de
componentes de hardware, os serviços que um microcontrolador para IoT fornece também
devem ser esclarecidos.
A estrutura de software adequada para implementar o microcontrolador para IoT é mostrada na
Figura 2. As funcionalidades do software do microcontrolador podem ser divididas em quatro
camadas, incluindo o sensoriamento, a comunicação, o controle e a aplicação.
 Figura 2 – Estrutura de software para IoT.
Veja um pouco mais:
CAMADA DE SENSORIAMENTO
Na camada de sensoriamento ou detecção, o microcontrolador interage com dispositivos
terminais, como sensores e atuadores. Essa camada inclui a seleção de tipos de sensores de
acordo com os diferentes tipos de tarefas. Os dados do sensor são as entradas do
microcontrolador. O atuador recebe o sinal de saída do microcontrolador e executa as ações
correspondentes.
CAMADA DE COMUNICAÇÃO
Inclui as interfaces e os protocolos, por onde o microcontrolador costuma interagir com outros
componentes, como sensores, atuadores e a nuvem. Existem várias possibilidades de
interfaces, como ethernet, Wi-Fi, bluetooth, ZigBee e GPRS.
CAMADA DE CONTROLE
Como já é conhecida, é o componente central de um microcontrolador. Nessa camada, o
microcontrolador deve armazenar e analisar os dados recebidos. Inclui, portanto, as seguintes
funcionalidades: Recepção de dados do sensor, análise de dados, interface com a nuvem e
unidades de atuação.
CAMADA DE APLICAÇÃO
Existem duas funcionalidades básicas: O monitoramento de estado e o controle remoto. O
primeiro pode rastrear o estado dos sensores, atuadores e do microcontrolador em si. O
segundo fornece um mecanismo para controlar remotamente os ajustes dos sensores e os
atuadores.
MODELOS DE MICROCONTROLADORES
PARA IOT
Para determinar qual microcontrolador funcionará melhor com seu projeto, é necessário
conhecer o que eles fazem e alguns dos seus principais recursos. Dentro dessas
características, a camada de comunicação é essencial. É assim que a aplicação se conecta à
internet via Wi-Fi, ethernet ou outros meios. Esse é um aspecto importante das aplicações de
IoT.
 COMENTÁRIO
Na escolha de um microcontrolador para conectar sensores à nuvem, o consumo de energia é
muito importante, especialmente quando o dispositivo precisa depender de algo como uma
bateria ou energia solar. Essa especificação lhe dirá, por padrão, o quão demandador de
energia pode ser o microcontrolador.
As ferramentas de desenvolvimento já existentes para a plataforma escolhida, a comunidade
de desenvolvedores, são também importantes. Facilita muito o desenvolvimento quando existe
um conjunto maduro de ferramentas, documentação e suporte da comunidade para ajudar a
criar programas que serão executados no microcontrolador selecionado para sua aplicação IoT.
Um dos desafios iniciais é integrar seus dados em uma nuvem. Nesse ponto, será preciso
utilizar protocolos como o MQTT (MQ Telemetry Transport). Esse é o principal protocolo de
mensagens leves para sensores e pequenos dispositivos móveis, otimizado para redes TCP/IP.
SISTEMAS OPERACIONAIS EM
MICROCONTROLADORES PARA IOT
A facilidade de integrar um sistema operacional (SO) na internet leva muitas soluções para IoT
empregarem essa abordagem. Mas soluções sem SO têm se tornado mais econômicas e de
menos consumo de energia.
Podemos definir três abordagens com respeito a sistemas operacionais e microcontroladores:
BARE METAL
Significa que não há, de fato, nenhum sistema operacional. Essa é a abordagem original para
trabalhar com microcontroladores, e ainda é a mais popular porqueé econômica e eficiente. A
principal desvantagem dessa opção, no caso de IoT, é que ela fornece menos suporte para o
desenvolvedor do software no caso de acesso à internet.
RTOS
Significa "sistema operacional de tempo real". Um sistema RTOS fornece garantias exatas em
relação ao tempo em que as operações serão concluídas, trazendo o que há de bom no Bare
Metal, que não possui sistema operacional. Evidentemente, um microcontrolador para rodar um
RTOS precisa ser de alto desempenho.
LINUX
É muito mais fácil de programar e conectar-se à internet. Ele se comporta mais como um
"computador real", o que é ótimo por muitas razões. No entanto, por causa disso, não fornece
garantias de determinismo no tempo de execução. Raspberry Pi e BeagleBone estão nesta
solução.
MICROCONTROLADORES COM
COMUNICAÇÃO SEM FIO
Alguns consideram os microcontroladores com comunicação sem fio integrada o futuro da
utilização em massa desses dispositivos.
Assim como não se concebe atualmente um microcontrolador sem comunicação serial, a
comunicação sem fio pode vir a ser padrão pela necessidade de todo sistema microcontrolado
de se integrar em rede em futuro próximo.
O chip ESP32 da Espressif, por isso, é chamado por alguns como o chip do futuro. Em vez de
usar um microcontrolador e placas adicionais (shields) para Wi-Fi e módulos bluetooth para
construir coisas conectadas, usar um único chip como o ESP32 pode parecer tudo o que um
projetista deseja. Junta-se a isso a possibilidade de usar a conhecida IDE do Arduino, uma
grande comunidade de suporte e custo baixo. Temos então uma solução quase completa para
IoT.
Vejamos algumas características desses chips:
• Núcleo duplo (Dual core) 
O predecessor do ESP32, o ESP8266, tem um processador embutido. No entanto, devido à
multitarefa envolvida na atualização da pilha Wi-Fi, a maioria dos aplicativos usa um
microcontrolador separado para processamento de dados, sensores de interface e
entrada/saída digital. Com o ESP32, porém, talvez não seja necessário um microcontrolador
adicional. Isso porque ele possui microprocessadores Tensilica LX6 de 32 bits Dual-Core,
operando em 160 ou 240MHz e realizando até 600MIPS (Milhões de Instruções Por Segundo).
Os dois núcleos são denominados CPU de protocolo (PRO_CPU) e CPU de aplicativo
(APP_CPU). Ou seja, basicamente o processador PRO_CPU lida com Wi-Fi, bluetooth e outros
periféricos internos como SPI, I2C, ADC etc. O APP_CPU é deixado de fora para o código do
aplicativo. Essa diferenciação é feita no Espressif Internet Development Framework (ESP-IDF)
− o framework oficial de desenvolvimento de software para o chip. Arduino e outras
implementações para o desenvolvimento são baseadas no ESP-IDF, que usa o freeRTOS para
alternar entre os processadores e a troca de dados entre eles.
O ESP32 implementa o protocolo TCP/IP e o protocolo WLAN MAC 802.11. Isso significa que o
ESP32 pode falar com a maioria dos roteadores Wi-Fi quando usado no modo de estação
(cliente). Também é possível configurar para que ele atue como um ponto de acesso de uma
rede IEEE 802.11.
Além disso, o ESP32 também suporta o Wi-Fi Direct, que é uma boa opção para conexão peer-
to-peer sem a necessidade de um ponto de acesso. O Wi-Fi Direct é mais fácil de configurar e
as velocidades de transferência de dados são muito melhores do que o bluetooth. Isso poderia
ser usado para configurar projetos baseados em ESP32 a partir de um telefone/tablet que
suporte Wi-Fi direto.
O chip não apenas suporta o mais recente padrão Bluetooth (Bluetooth Low Energy – BLE), ele
também suporta bluetooth clássico. Basicamente significa que pode falar com telefones/tablets
antigos e novos. Esse pode ser um dos melhores recursos, especialmente ao se projetar um
dispositivo que precise trabalhar com telefones/tablets existentes e novos no mercado.
O ESP32 possui uma lista completa de periféricos, como temporizadores e watchdog, relógio
de tempo real, ADC e sensores incorporados, Conversor Digital para Analógico (DAC), sensor
de toque, Coprocessador de Baixo Consumo (Ultra Low Power − ULP), Interface MAC
Ethernet, Controlador SD/ SDIO/MMC, Transmissor Receptor Universal Assíncrono (UART),
Interface I2C e SPI, contador de pulsos, Modulação de Largura de Pulso (PWM), dentre outros.
 EXEMPLO DE CONEXÃO WI-FI COM ESP32:
O código para conectar um ESP32 em uma rede Wi-Fi, usando o IDE do Arduino, é simples
como o descrito a seguir:
 
#include "WiFi.h" 
 
const char* ssid = "NomeDaRede"; 
const char* password = "SenhaDaRede"; 
 
void setup() { 
Serial.begin(115200); 
WiFi.begin(ssid, password); 
while (WiFi.status() != WL_CONNECTED) { 
delay(500); 
Serial.println("Conectando a rede WiFi…"); 
} 
Serial.println("Conectado na rede WiFi."); 
} 
void loop() {} 
 
Existem diversos exemplos para que, passo a passo, tenha-se acesso às facilidades de
integrar aplicações e sensores na rede e na nuvem, com MQTT, por exemplo. O ESP32 é uma
boa escolha para iniciar os estudos de IoT.
Neste vídeo, apresentamos o potencial de emprego de microcontroladores para a IoT.
VERIFICANDO O APRENDIZADO
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Neste tema, discutimos alguns aspectos que conduzem às escolhas dentro de um projeto de
sistema embarcado com microcontroladores, considerando as métricas para esses sistemas e
as limitações desses dispositivos em aplicações críticas e de alto desempenho.
Descrevemos as boas práticas para programação de sistemas com microcontroladores e as
atividades básicas para a verificação e validação de softwares embarcados. Por fim, avaliamos
também as alternativas mais atuais para microcontroladores em aplicações de Internet das
Coisas.
 PODCAST
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. IEEE recommended
practice for software requirements specifications.In: IEEE Std 830-1998, pp.1-40, 20 Oct.
1998, doi: 10.1109/IEEESTD.1998.88286.
MONK, S. Programação com Arduino: Começando com sketches. 1. ed. Porto Alegre:
Bookman, 2017.
MOTOR INDUSTRY SOFTWARE RELIABILITY ASSOCIATION. MISRA C: 2012 guidelines for
the use of the C language in critical systems. March. 2013, ISBN 978-1-906400-10-1.
Amendment 1, April 2016. Addendum 2, April 2016. Technical Corrigendum 1, June 2017.
OLIVEIRA, A. S. de; ANDRADE, F. S. de. Sistemas embarcados: Hardware e firmware na
prática. 1. ed. São Paulo: Érica, 2010.
PECKOL, J. K. Embedded systems: A contemporary design tool. 1. ed. New Jersey: Wiley,
2019.
ZANCO, W. da S. Microcontroladores PIC18 com linguagem C: Uma abordagem prática e
objetiva. São Paulo: Érica, 2010.
EXPLORE+
Para saber mais sobre os assuntos tratados neste tema, leia:
O artigo Medição remota de parâmetros elétricos usando IoT baseada no
microcontrolador ESP32, publicado no X Encontro Científico de Física Aplicada, realizado
em maio de 2019, na Universidade Federal do Espírito Santo (UFES).
O artigo Inovação no agronegócio utilizando IoT, publicado no site do Instituto Mauá de
Tecnologia, sobre as possibilidades de aplicação de IoT no agronegócio.
Uma revisão de literatura referente ao desenvolvimento de sistemas embarcados no
artigo publicado no site da Universidade Federal de Pelotas (UFPel): Desenvolvimento de
sistemas embarcados usando alto nível de abstração.
CONTEUDISTA
Marcos Santana Farias
 CURRÍCULO LATTES
javascript:void(0);