Capítulo 01 Fundamento
Quando o software toca no mundo
Programar um sistema embarcado não é programar com menos memória. É programar sob restrições que não existem do outro lado — e a primeira é que não há como desfazer.
1.1 As cinco diferenças que mudam tudo
| Restrição | Do lado do servidor | Aqui |
|---|---|---|
| Reversão | Reverter a versão anterior em minutos | O motor já rodou. O relé já fechou. Não se desfaz |
| Tempo | Mais lento é pior | Mais lento pode ser errado — chegar tarde é falhar |
| Recursos | Acrescenta-se memória | Fixos e soldados. 64 KB são 64 KB para sempre |
| Energia | Vem da parede | Vem de uma bateria com um orçamento contado (cap. 8) |
| Acesso | Entra-se por SSH | O dispositivo está numa parede a 40 km, ou dentro de uma máquina em movimento |
Estas cinco explicam por que razão o ofício é conservador de uma forma que parece exagerada a quem vem do software de servidor: estados seguros definidos, cães de guarda, verificações redundantes, atualizações com reversão automática.
Não é cerimónia. É que o custo de uma falha não é uma página de erro — é um portão que fica aberto, uma bomba que não para, uma bateria que descarrega até o dispositivo morrer no terreno.
1.2 Três famílias, três conjuntos de regras
Microcontrolador nu
Sem sistema operativo, ou com um núcleo de tempo real mínimo. Kilobytes de memória, arranque em milissegundos, consumo de microamperes em repouso. Previsível ao ciclo. É o que está num termostato, num sensor de campo, num controlador de motor.
Linux embarcado
Um computador pequeno com sistema operativo completo. Megabytes de memória, arranque em segundos, consumo mil vezes maior. Confortável e menos previsível — há um escalonador entre o seu código e o mundo. É o que está num quiosque, numa câmara, num gateway.
Sistema misto
O arranjo mais comum em produtos sérios: um microcontrolador a tratar do que é crítico e temporizado, e um processador maior a tratar de rede, interface e lógica. Separa o que não pode falhar do que é conveniente.
Como escolher
Pela pergunta: existe algo que tenha de acontecer sempre dentro de um prazo? Se sim, essa parte pertence ao microcontrolador — mesmo que tudo o resto seja Linux.
1.3 O ciclo que estrutura quase todos estes sistemas
Tudo o resto — comunicação, energia, fiabilidade, segurança — é infraestrutura à volta deste ciclo. Quando um sistema embarcado se comporta mal, o problema está quase sempre num destes três sítios, ou no tempo que o ciclo demora (cap. 5).
1.4 O que esta apostila é
É sobre os princípios que não mudam com a placa: como ler um sensor sem acreditar nele, como comandar potência sem estragar nada, o que significa tempo real, controlo em malha fechada, orçamentos de energia, e como um dispositivo falha bem quando ninguém lá está.
Não é um manual de uma placa concreta — esses caducam. Os exemplos são genéricos e transferíveis. Para o lado prospectivo — para onde isto vai —, O Futuro da Robótica e do Trabalho Físico, de que esta apostila é o par técnico em falta.
Escolha um dispositivo à sua volta — termostato, fechadura, contador, brinquedo — e escreva como cada uma das cinco restrições de 1.1 se aplica. Depois pergunte: o que acontece se falhar a energia a meio de uma operação? É a pergunta que o capítulo 10 responde.
Capítulo 02 Fundamento
O que há dentro, e porque importa
Não é preciso saber eletrónica para programar isto, mas é preciso saber o suficiente sobre o que está por baixo — porque é aí que estão os erros que não se percebem.
2.1 As peças
| Peça | Faz | Onde morde |
|---|---|---|
| Núcleo | Executa instruções | Sem unidade de vírgula flutuante em muitos, cálculos com decimais custam caro |
| Memória volátil | Variáveis, pilha | Kilobytes. Estouro de pilha reinicia o dispositivo sem aviso |
| Memória de programa | O código, e constantes | Finita; tem ciclos de escrita limitados |
| Periféricos | Temporizadores, conversores, barramentos | Trabalham em paralelo com o núcleo — é o que torna tudo possível |
| Pinos | Ligam ao mundo | Corrente máxima por pino; ultrapassar destrói o chip |
Os periféricos trabalham sozinhos. Um temporizador continua a contar, um conversor continua a amostrar e um barramento continua a receber enquanto o núcleo faz outra coisa — e avisam por interrupção quando terminam.
Quem vem do software costuma escrever código que espera em ciclo por cada coisa. Funciona, e desperdiça tudo: o processador fica ocupado a não fazer nada, o consumo dispara, e o sistema deixa de conseguir responder a mais nada. Delegar aos periféricos é a diferença entre um protótipo e um produto.
2.2 Um pino de entrada não é um booleano
É a primeira surpresa de quem vem do software. Um pino que não está ligado a nada não lê false: lê o que houver no ar, e muda sozinho. Três consequências práticas:
- Resistência de encosto. Todo o pino de entrada precisa de ser puxado a um nível conhecido — para a alimentação ou para a massa — para que "não premido" signifique alguma coisa. A maior parte dos microcontroladores tem estas resistências por dentro e basta ativá-las.
- Ressalto de contactos. Um botão mecânico não fecha uma vez: fecha e abre várias vezes em poucos milissegundos. Sem tratamento, um toque conta como cinco. Corrige-se ignorando mudanças durante alguns milissegundos após a primeira.
- Níveis de tensão diferentes. Ligar um pino de 5 V a um chip de 3,3 V danifica-o. É o erro que mais hardware destrói.
2.3 Vírgula flutuante, e por que se evita
Em microcontroladores sem unidade de vírgula flutuante, cada operação com decimais é emulada por software — dezenas ou centenas de vezes mais lenta que uma operação com inteiros, e ocupa memória de programa considerável.
A prática habitual é trabalhar em inteiros com escala fixa: guardar milésimos de grau em vez de graus, ou décimos de milímetro em vez de milímetros. Converte-se para unidades humanas só na apresentação. É menos elegante e é o que permite caber no orçamento de tempo do capítulo 5.
2.4 Ferramentas: o que se usa quando não há ecrã
- Um LED. A ferramenta mais subestimada. Acender num ponto do código responde a "chegou aqui?" em segundos.
- Porta série. Imprimir valores. Cuidado: imprimir é lento e altera o tempo do sistema — pode fazer desaparecer o problema que se procura.
- Analisador lógico. Mostra o que aconteceu nos pinos, com tempos. É o que resolve os problemas de comunicação que o código não explica.
- Depurador por porta dedicada. Parar, inspecionar, avançar passo a passo — como no software normal, com a diferença de que parar um sistema que controla um motor tem consequências físicas.
- Um pino de diagnóstico. Truque clássico: ligar um pino no início de uma rotina e desligá-lo no fim. Com um analisador, vê-se exatamente quanto tempo demorou, sem alterar o comportamento.
Escreva a leitura de um botão com resistência de encosto e tratamento de ressalto, e conte quantas transições deteta com e sem tratamento ao premir dez vezes. É o "olá mundo" deste ofício e ensina mais que qualquer tutorial.
Capítulo 03 Núcleo
Ler o mundo: sensores e a arte de não acreditar neles
Um sensor não devolve a realidade. Devolve um número afetado por ruído, deriva, temperatura e pelo próprio ato de medir — e o trabalho é saber quanto disso descontar.
3.1 O caminho de um valor
Cada seta introduz erro. O número que chega ao código não é a temperatura — é o resultado de uma cadeia de transformações, cada uma com a sua imprecisão. Tratá-lo como verdade é a origem da maior parte dos comportamentos estranhos.
3.2 Os quatro erros que aparecem sempre
| Erro | Como se manifesta | O que fazer |
|---|---|---|
| Ruído | Leituras oscilam sem que nada mude | Filtrar (3.3) e amostrar mais que uma vez |
| Desvio de zero | Lê 2 °C quando devia ler 0 | Calibrar: medir num ponto conhecido e subtrair |
| Erro de escala | Certo a 0 °C, errado a 100 °C | Calibrar em dois pontos e ajustar a inclinação |
| Deriva | Muda com a temperatura, o tempo, a humidade | Recalibrar periodicamente, ou compensar com um segundo sensor |
Dois sensores do mesmo modelo, da mesma caixa, dão valores diferentes. A folha de características dá a tolerância, não o valor. Se a medição interessa, calibra-se cada unidade — e guarda-se a calibração na memória não volátil do dispositivo, não no código.
3.3 Filtrar sem estragar
Média móvel
Média das últimas N leituras. Simples, eficaz contra ruído aleatório. Custo: atraso proporcional a N — o valor filtrado reage tarde a mudanças reais.
Filtro exponencial
y = a·nova + (1−a)·y. Uma linha, uma variável, sem histórico. É o filtro mais usado em sistemas embarcados, e com boa razão: custa quase nada.
Mediana
Das últimas N. Insubstituível contra picos isolados — uma leitura absurda não a move, enquanto arruína uma média (Estatística I).
O compromisso
Sempre o mesmo: mais filtro, menos ruído, mais atraso. Num sistema de controlo, atraso causa oscilação (cap. 6). Filtrar de mais é um erro tão real como não filtrar.
3.4 A que ritmo amostrar
Se o sinal varia mais depressa do que a amostragem, o resultado não é uma versão grosseira do sinal: é um sinal diferente, falso, e convincente. É o efeito que faz as rodas parecerem andar para trás no cinema.
Regra: amostre a pelo menos o dobro da frequência mais rápida que existe no sinal — e na prática cinco a dez vezes, com margem. Se houver ruído de alta frequência, filtre-o antes de converter, em eletrónica; depois de amostrado, já não há como o separar.
3.5 Duas verificações que evitam desastres
- O valor é fisicamente possível? Uma temperatura de −200 °C num frigorífico é uma avaria do sensor, não uma leitura. Rejeite e conte quantas rejeições — se forem muitas, o sensor morreu.
- Mudou depressa de mais? Uma temperatura não sobe 30 graus em 100 ms. Um salto assim é ruído ou falha, e tratá-lo como real pode acionar um atuador sem motivo.
As duas juntas ocupam cinco linhas e apanham a maior parte das falhas de sensor no terreno — que raramente são "deixa de responder" e quase sempre são "passa a mentir".
Com um sensor parado, num ambiente estável, registe mil leituras. Calcule a média, o desvio-padrão e os extremos. Esse desvio é o seu ruído de base — e nenhuma variação menor que ele significa alguma coisa (Estatística I, cap. 3).
Capítulo 04 Núcleo
Agir no mundo: atuadores e potência
Um pino de microcontrolador comanda; não alimenta. Confundir as duas coisas é o erro que destrói mais hardware e o que produz as avarias mais difíceis de diagnosticar.
4.1 A separação fundamental
Um pino fornece tipicamente alguns miliamperes. Um motor pequeno consome centenas de miliamperes a vários amperes. A diferença é de duas a três ordens de grandeza.
Entre o pino e a carga há sempre alguma coisa: um transístor, um controlador de motor, um relé. O microcontrolador diz o que fazer; outro circuito fornece a energia. Ligar um motor diretamente a um pino não é uma simplificação — é uma avaria com data marcada.
4.2 Os atuadores e o que exigem
| Atuador | Comanda-se com | Cuidado |
|---|---|---|
| LED | Pino + resistência | Sem resistência, queima o LED, o pino, ou ambos |
| Relé | Transístor + díodo de proteção | Sem o díodo, o pico ao desligar destrói o transístor |
| Motor de corrente contínua | Controlador dedicado, com PWM | Corrente de arranque muito superior à nominal |
| Servo | Impulso de largura variável, a ritmo fixo | Alimentar à parte; o pico ao mover afunda a tensão do circuito |
| Motor passo a passo | Controlador com sequência | Perde passos sem avisar — não há confirmação de posição |
| Aquecedor, bomba, válvula | Relé ou transístor de potência | Cargas com inércia: continuam depois de desligar |
Motores e relés geram perturbações elétricas que voltam pela alimentação e corrompem as leituras dos sensores do mesmo circuito. É a causa de uma classe inteira de bugs que parecem de software: o valor lido salta exatamente quando o motor arranca.
Sinal de diagnóstico: se um problema só aparece com a carga ligada, é elétrico, não lógico. As respostas são alimentações separadas, condensadores de desacoplamento e — a mais barata — não amostrar sensores no instante em que se comuta potência.
4.3 PWM: como se faz "meio ligado"
Um pino digital só sabe estar ligado ou desligado. Para obter valores intermédios, liga-se e desliga-se muito depressa e varia-se a proporção de tempo ligado. A 50%, um LED parece a meia luz; um motor roda a meia velocidade.
- Use o periférico, não código. Gerar PWM em software desperdiça o processador e produz irregularidades audíveis. O temporizador faz isto sozinho, sem consumir ciclos (cap. 2).
- A frequência importa. Baixa de mais, um motor apita e um LED tremeluz. Alta de mais, o controlador aquece.
- Proporção não é velocidade. 50% de PWM não dá 50% da rotação — a relação não é linear e depende da carga. Se a velocidade tem de ser exata, é preciso medi-la e realimentar (cap. 6).
4.4 A regra de ouro dos atuadores
Todo o comando de potência deve ter uma condição de paragem que não depende da lógica principal:
- Tempo máximo. Uma bomba que só pode estar ligada 30 segundos desliga-se sozinha se o software encravar.
- Fim de curso. Um interruptor físico que corta a alimentação no extremo do percurso, independentemente do que o código pense.
- Limite de corrente. Se puxa mais do que devia, alguma coisa está bloqueada — pare.
- Estado seguro por omissão. Sem comando, o atuador fica na posição que causa menos dano.
Estes limites existem porque o software vai falhar, e o dano de um motor a rodar indefinidamente é físico. É o assunto do capítulo 10, e começa aqui, no desenho do circuito.
Para cada atuador de um sistema seu, escreva o que acontece se o processador congelar com o comando ativo. Se a resposta for perigosa em algum caso, falta um limite independente — e é anterior a qualquer melhoria de software.
Capítulo 05 Núcleo
Tempo real, e o custo de chegar tarde
Tempo real não significa rápido. Significa que existe um prazo, e que falhá-lo é um erro — mesmo que a resposta esteja certa.
5.1 A definição, e as duas variantes
Num sistema de tempo real, uma resposta certa entregue tarde é uma resposta errada. É a única diferença face ao software comum, e muda tudo o que se segue.
| Tempo real estrito | Tempo real tolerante | |
|---|---|---|
| Falhar o prazo | Falha do sistema | Degradação da qualidade |
| Exemplo | Disparo de airbag; comutação de motor | Reprodução de vídeo; leitura de temperatura ambiente |
| O que se garante | O pior caso | A média, com bom comportamento típico |
A última linha é a que mais custa a interiorizar: em tempo real estrito, o desempenho médio é irrelevante. O que interessa é o pior caso, e é sobre ele que se dimensiona.
5.2 As três arquiteturas
Ciclo principal
Um ciclo infinito que faz tudo por ordem. Simples e previsível se todas as tarefas forem curtas. Falha assim que uma tarefa demorar: tudo o resto espera.
Ciclo com interrupções
O ciclo trata do normal; interrupções tratam do urgente. É a arquitetura mais comum e chega para a maioria dos produtos.
Núcleo de tempo real
Tarefas com prioridades, escalonadas. Necessário quando há várias atividades com prazos diferentes. Custo: mais memória, e problemas de concorrência a sério.
Máquina de estados
Transversal às três, e o padrão mais valioso deste capítulo: em vez de esperar, o código regista em que estado está e volta depressa. Nunca bloqueia.
5.3 A regra que separa código embarcado de código normal
esperar(500) é a instrução mais destrutiva deste ofício. Durante meio segundo, o sistema não lê sensores, não responde a comandos, não trata de comunicação. Um botão premido nesse intervalo perde-se.
A alternativa é sempre a mesma: em vez de esperar, registar o instante em que se começou e verificar, a cada passagem do ciclo, se já passou o tempo. O código fica um pouco mais longo e o sistema passa a responder a tudo.
É esta transformação — de esperar para verificar se já — que converte um protótipo que funciona sozinho num produto que funciona com mais coisas a acontecer.
5.4 Interrupções: as três regras
- Curta. Uma rotina de interrupção faz o mínimo: guarda um valor, levanta uma bandeira, e sai. O trabalho pesado fica para o ciclo principal. Enquanto ela corre, tudo o resto está parado.
- Sem operações lentas. Nada de imprimir, nada de esperar, nada de comunicação. É a causa mais comum de sistemas que "às vezes travam".
- Variáveis partilhadas marcadas como voláteis, e acedidas com cuidado. Uma variável de 32 bits lida pelo ciclo principal enquanto a interrupção a atualiza pode ser lida meio antiga e meio nova. Este erro é raro, não reproduzível, e leva dias a encontrar.
5.5 O que se mede, e como
| Medida | O que revela | Como medir |
|---|---|---|
| Duração do ciclo | Se há folga | Pino de diagnóstico + analisador (cap. 2) |
| Pior caso, não a média | Se o prazo é cumprido sempre | Guardar o máximo observado e reportá-lo |
| Instabilidade (variação do intervalo) | Se o ritmo é regular | Registar o desvio entre execuções |
| Ocupação | Quanto do tempo está a trabalhar | Acima de 70%, o pior caso deixa de caber |
Deixe pelo menos 30% de folga. Não por conforto: porque o pior caso — a interrupção que chega no pior momento, o buffer cheio, o sensor que responde devagar — só acontece de vez em quando, e é precisamente o que tem de caber.
Encontre um esperar() no seu código e reescreva-o como máquina de estados. Meça a duração do ciclo antes e depois. É a mudança que mais melhora a capacidade de resposta de um sistema embarcado.
Capítulo 06 Núcleo
Controlo em malha fechada, sem misticismo
Comandar às cegas funciona até o mundo discordar. Medir o resultado e corrigir é o que separa um sistema que funciona no laboratório de um que funciona no terreno.
6.1 Malha aberta e malha fechada
| Malha aberta | Malha fechada | |
|---|---|---|
| Faz | Aplica um comando e espera que resulte | Mede o resultado e corrige continuamente |
| Exemplo | "Liga o aquecedor 10 minutos" | "Aquece até 21 °C e mantém" |
| Funciona quando | O sistema é previsível e as perturbações são pequenas | Sempre — a que custo é outra questão |
| Falha quando | Muda a carga, a temperatura, a bateria envelhece | Mal sintonizada: oscila ou é lenta |
Malha fechada exige um sensor fiável, um ciclo com ritmo regular e sintonia. Se malha aberta chega, use malha aberta — é mais simples, mais previsível e não oscila.
A pergunta que decide: o resultado depende de coisas que variam e que não controlo? Se sim, feche a malha. Se não, não invente.
6.2 Os três termos, e o que cada um faz mesmo
Proporcional
Corrige em proporção ao erro atual. Quanto maior o desvio, mais forte a correção. Sozinho, nunca chega exatamente ao alvo — fica um resto permanente, porque com erro zero a correção também é zero.
Integral
Acumula o erro ao longo do tempo. É o que elimina o resto permanente: se o desvio persiste, a correção vai crescendo até desaparecer. Em troca, torna o sistema mais lento a estabilizar e mais propenso a oscilar.
Derivativo
Reage à velocidade do erro. Trava antes de chegar, reduzindo o excesso. Amplifica ruído — e por isso é frequentemente deixado a zero em sistemas reais, o que é uma decisão legítima e não uma preguiça.
Na prática
A maior parte dos sistemas embarcados usa só proporcional e integral. É suficiente, é estável e é fácil de sintonizar. Comece por aí.
6.3 Sintonizar sem teoria
1. Ponha integral e derivativo a zero.
2. Aumente o proporcional até o sistema começar a oscilar, e depois reduza para cerca de metade.
3. Aumente o integral devagar até o resto permanente desaparecer. Se começar a oscilar, reduza.
4. Só acrescente derivativo se houver excesso a corrigir e o sinal for pouco ruidoso.
5. Teste com perturbações reais — abrir uma porta, acrescentar carga, mudar o alvo bruscamente. Um controlador sintonizado só em condições calmas não está sintonizado.
6.4 Os três erros de implementação
| Erro | Sintoma | Correção |
|---|---|---|
| Acumulação do integral | O atuador está no máximo, o erro persiste, o integral cresce sem limite — e quando o alvo é atingido, o sistema ultrapassa muito e demora a voltar | Limitar o integral, e parar de acumular quando o atuador está saturado. É a correção mais importante do capítulo |
| Ciclo irregular | Comportamento muda sem razão | O controlo assume intervalo constante. Corra-o a partir de um temporizador, não do ciclo principal (cap. 5) |
| Derivativo sobre sinal ruidoso | Atuador a tremer | Filtrar antes (cap. 3), ou pôr o derivativo a zero |
6.5 Histerese: a solução que muitas vezes basta
Para ligar e desligar — um aquecedor, uma bomba, uma ventoinha — não é preciso controlo proporcional. Basta duas fronteiras diferentes: liga abaixo de 20 °C, desliga acima de 22 °C.
Essa banda entre as duas é a histerese, e existe para impedir que o atuador comute mil vezes por minuto quando a leitura oscila em torno do alvo — o que desgasta relés, encurta a vida de compressores e faz barulho.
É a solução mais usada em produtos reais, e a que mais vezes é substituída desnecessariamente por um controlador completo. Pergunte primeiro se histerese chega.
Implemente um controlador proporcional-integral num sistema simples e sintonize-o pelos cinco passos de 6.3. Depois perturbe-o de propósito. Registe o excesso e o tempo até estabilizar, antes e depois de limitar o integral.
Capítulo 07 Prática
Comunicação: barramentos e redes
Dois problemas diferentes que se confundem: falar com os chips ao lado, e falar com um sistema a quilómetros. As restrições e as respostas são completamente distintas.
7.1 Dentro da placa
| Barramento | Fios | Bom para | Cuidado |
|---|---|---|---|
| UART | 2 | Ponto a ponto; consola de diagnóstico | Ambos os lados têm de concordar na velocidade; sem endereçamento |
| I²C | 2 | Muitos sensores no mesmo par de fios | Precisa de resistências de encosto; endereços colidem; um chip preso bloqueia o barramento todo |
| SPI | 4+ | Rápido: ecrãs, memórias, conversores | Um fio de seleção por dispositivo — gasta pinos depressa |
| CAN | 2 | Ambientes ruidosos; automóvel, industrial | Mais complexo; e é o que resiste a ruído a sério |
Muitos sensores lentos: I²C. Poucos dispositivos rápidos: SPI. Diagnóstico e ligação simples: UART. Ruído elétrico e distância dentro de uma máquina: CAN.
E uma nota de campo: quando um barramento I²C falha, na maioria das vezes o problema não é o código — são as resistências de encosto, o comprimento dos fios, ou dois dispositivos com o mesmo endereço. Um analisador lógico responde em minutos ao que o código não explica.
7.2 Para fora
| Tecnologia | Alcance | Débito | Energia | Onde encaixa |
|---|---|---|---|---|
| Wi-Fi | Dezenas de metros | Alto | Alto | Alimentado da rede elétrica |
| Bluetooth de baixa energia | Metros | Baixo | Muito baixo | Junto ao telemóvel; vestíveis |
| LoRa e afins | Quilómetros | Muito baixo | Muito baixo | Sensores de campo, anos a pilhas |
| Celular de baixa potência | Cobertura móvel | Baixo | Médio | Sem infraestrutura própria; contadores, frotas |
| Cabo | Fixo | Alto | Depende | Industrial, onde a fiabilidade domina |
Em dispositivos a bateria, a rádio é quase sempre o maior consumidor, e a decisão faz-se de trás para a frente: quantos bytes por dia, com que latência aceitável, e quanto isso custa em energia (cap. 8).
Um sensor que envia 20 bytes de hora a hora e dorme o resto do tempo dura anos com uma pilha. O mesmo sensor com Wi-Fi sempre ligado dura dias. A diferença não está no chip — está no perfil de utilização.
7.3 Como falar: mensagens em vez de pedidos
O padrão dominante em dispositivos ligados é publicação e subscrição: o dispositivo publica o que sabe num tópico, e quem quiser subscreve. Não precisa de saber quem o vai ler, não fica à espera de resposta, e sobrevive a estar desligado.
- Publique estado, não eventos. "A temperatura é 21,3" é reprocessável e idempotente; "a temperatura subiu" perde-se se a mensagem falhar.
- Carimbe o instante na origem. A mensagem pode chegar minutos depois; sem carimbo, não se sabe a que momento se refere.
- Assuma que a ligação cai. Guarde localmente e envie quando puder — e envie também o que ficou por enviar.
- Escolha o nível de garantia com intenção. Entrega garantida custa energia e memória; para uma leitura que se repete daqui a um minuto, perder uma não é grave.
- Não confie no relógio. Microcontroladores sem relógio dedicado perdem a hora ao reiniciar. Se o instante importa, sincronize — ou registe tempo relativo ao arranque e deixe o servidor converter.
Para um dispositivo seu, calcule quantos bytes envia por dia e com que frequência acorda a rádio. Depois estime o consumo (cap. 8). É frequente descobrir que enviar de dez em dez minutos em vez de a cada minuto multiplica a autonomia por cinco, sem perda de utilidade.
Capítulo 08 Núcleo
Energia: o orçamento que decide o produto
Num dispositivo a bateria, a autonomia não é uma característica — é a restrição que determina tudo o resto, desde o processador até ao intervalo de leitura.
8.1 A conta
Autonomia ≈ capacidade da bateria ÷ consumo médio.
Uma pilha de 2 000 mAh com um consumo médio de 10 mA dura cerca de 200 horas — pouco mais de oito dias. Com 10 µA de média, dura anos. A diferença entre um produto viável e um inviável está três ordens de grandeza abaixo daquilo que o protótipo consome.
E o consumo médio calcula-se somando os estados, cada um pelo tempo que dura:
Na tabela acima, transmitir ocupa 0,1% do tempo e 85% da energia. É o padrão típico, e tem uma consequência de desenho contraintuitiva: otimizar o código quase nunca aumenta a autonomia; reduzir transmissões quase sempre aumenta.
Antes de otimizar seja o que for, faça esta tabela. Ela diz onde vale a pena mexer, e costuma apontar para um sítio inesperado.
8.2 Dormir é a técnica principal
- O objetivo é dormir quase sempre. Um sensor de campo bem feito está desperto menos de 1% do tempo.
- Acordar por interrupção, não por espera. Um temporizador ou um pino acordam o processador; esperar em ciclo consome como se estivesse a trabalhar.
- Desligar o que não se usa. Periféricos, sensores e rádio têm de ser desligados explicitamente — não se desligam sozinhos, e um sensor esquecido ligado pode dominar o consumo.
- O tempo de acordar conta. Alguns modos de sono profundo demoram a recuperar e obrigam a reinicializar periféricos. Dormir mais profundo nem sempre gasta menos, se for preciso acordar com frequência.
- Cuidado com o pico. Transmitir puxa uma corrente instantânea alta; se a bateria não a fornecer, a tensão afunda e o dispositivo reinicia — a meio da transmissão, indefinidamente.
8.3 Baterias comportam-se pior do que a folha diz
| Facto | Consequência de desenho |
|---|---|
| A capacidade cai com o frio | Um dispositivo exterior tem menos autonomia no inverno — dimensione para o pior mês |
| A tensão desce ao longo da descarga | Nem toda a capacidade é utilizável; o sistema para antes de a bateria acabar |
| Correntes altas reduzem a capacidade efetiva | Picos custam mais do que a média sugere |
| Há autodescarga | Um dispositivo que dorme dois anos pode morrer sem nunca ter trabalhado |
| A capacidade degrada-se com os ciclos | Em recarregáveis, dimensione para o fim de vida, não para o primeiro dia |
8.4 Medir, em vez de estimar
Meça a corrente real ao longo de um ciclo completo de funcionamento, com um instrumento capaz de ver microamperes e picos de centenas de miliamperes ao mesmo tempo.
É quase garantido encontrar surpresas: um periférico que ficou ligado, uma resistência de encosto a drenar continuamente, um LED de alimentação esquecido a consumir mais do que todo o resto, um sensor que demora dez vezes mais a estabilizar do que a folha indica.
Nenhuma estimativa em papel substitui esta medição, e ela costuma poupar meses de suposições erradas.
Para um dispositivo a bateria, construa a tabela de 8.1: cada estado, a corrente, a fração de tempo. Some. Compare com a autonomia observada. Se não baterem certo, há um estado que não conhece — e encontrá-lo é o trabalho.
Capítulo 09 Método aplicado · Demo
Um sensor ruidoso a virar um comando estável
Role devagar. Uma leitura de temperatura que oscila percorre seis camadas até se tornar um comando que não estraga o compressor.
Duas linhas de código, e o compressor comuta trinta vezes por minuto
O código é o que qualquer pessoa escreveria: se está abaixo do alvo, liga; senão, desliga. Está logicamente correto e produz um produto que se avaria em meses.
A causa é o capítulo 3: as leituras oscilam à volta do alvo, e cada oscilação atravessa o limiar. O ruído do sensor transformou-se diretamente em desgaste mecânico — e nenhuma parte do código está errada.
O limiar de decisão estava dentro da banda de ruído
Antes de corrigir, medir: mil leituras num ambiente estável dão média 4,01 °C e desvio-padrão de 0,15 °C, com picos até meio grau (Estatística I, cap. 3).
Isso responde à pergunta central: qualquer variação inferior a isto não significa nada. E o limiar de decisão — 4,0 °C exatos — estava colocado no meio dessa banda, o que faz de cada decisão um lançamento de moeda.
Um filtro de uma linha corta o ruído a um terço
O filtro exponencial do capítulo 3 reduz o desvio de 0,15 para 0,05 °C, com uma linha de código e uma variável. Em troca, introduz cerca de dez segundos de atraso a acompanhar mudanças reais.
Num frigorífico, dez segundos não são nada — a inércia térmica é de minutos. Num controlo de motor seriam inaceitáveis. O filtro escolhe-se pela dinâmica do processo, não pela quantidade de ruído, e é por isso que não há um valor universal.
Dois limiares em vez de um, e o problema desaparece
Liga abaixo de 3,5 °C, desliga acima de 4,5 °C (cap. 6). Para comutar duas vezes, a temperatura tem agora de percorrer um grau inteiro — e um ruído de 0,05 °C não lá chega por acaso nenhum.
As comutações passam de trinta por minuto para umas quatro por hora. Nenhum controlador proporcional-integral foi necessário: para ligar e desligar, histerese é a resposta certa, e é a que mais vezes é substituída desnecessariamente por algo mais complicado.
O compressor tem regras que não vêm do sensor
Tempo mínimo ligado, para chegar a arrefecer alguma coisa. Tempo mínimo desligado, para a pressão igualar antes de arrancar de novo — arrancar contra pressão danifica o motor.
Estas regras vêm da folha de características do compressor, não da lógica de controlo, e sobrepõem-se a tudo o resto: mesmo que a temperatura peça, não se liga antes do tempo. É a regra do capítulo 4 — o atuador impõe limites que o software respeita, não negoceia.
E a escolha do estado seguro é uma decisão de produto
Se o sensor devolver valores impossíveis, rejeitam-se e contam-se; três inválidas seguidas declaram avaria (cap. 3). Aí é preciso escolher o que fazer, e não existe resposta técnica: desligar estraga a comida; manter ligado sem controlo pode congelar tudo ou queimar o compressor.
A escolha aqui — desligar e alarmar — justifica-se por o dano ser menor e reversível. É uma decisão de produto, e deve ficar escrita com a justificação, porque alguém a vai questionar dentro de dois anos. É a ponte para o capítulo 10.
Repare no percurso completo: duas linhas de código ingénuas tornaram-se seis camadas, e nenhuma delas é sofisticada. É a diferença entre um protótipo que funciona na bancada e um produto que dura anos no terreno — e cabe toda em cerca de quarenta linhas.
Aplique as seis camadas a um controlo do seu sistema: medir o ruído, filtrar, pôr histerese, respeitar os limites do atuador, e definir o estado seguro. Escreva a justificação do estado seguro numa frase — é a parte que ninguém escreve e a que mais falta faz depois.
Capítulo 10 Núcleo
Falhar bem
Um dispositivo no terreno vai falhar. A questão não é se — é o que acontece quando falha, e se alguém fica a saber.
10.1 As defesas, da mais barata à mais cara
| Mecanismo | Protege de | Custo |
|---|---|---|
| Estado seguro no arranque | Atuadores ativos durante o reinício | Nenhum — é desenho |
| Cão de guarda | Software encravado | Baixo; existe no chip |
| Deteção de tensão baixa | Comportamento errático com bateria fraca | Baixo; existe no chip |
| Limites independentes | Comando indevido (cap. 4) | Baixo |
| Registo de falhas persistente | Não saber porque reiniciou | Médio |
| Redundância | Falha de um componente | Alto — só onde se justifica |
É um temporizador independente que reinicia o dispositivo se o software não o "alimentar" regularmente. Protege contra o caso mais comum de todos: um ciclo que ficou preso à espera de algo que nunca chega.
O erro clássico é alimentá-lo numa interrupção — assim continua a ser alimentado mesmo com o programa principal encravado, e a proteção deixa de existir. Alimente-o no ciclo principal, e só depois de verificar que as tarefas essenciais correram.
10.2 Estado seguro: escolher antes, não durante
Para cada saída, é preciso decidir de antemão o que acontece quando o sistema reinicia, perde alimentação ou deteta avaria. E a resposta certa depende do dano, não da tecnologia:
- Um portão automático — parar é mais seguro do que continuar a fechar.
- Uma bomba de drenagem — parar pode inundar; talvez o seguro seja manter.
- Um aquecedor — desligado, sempre.
- Uma fechadura — depende de ser incêndio ou assalto, e é uma decisão de segurança, não de engenharia.
A escolha deve ser física sempre que possível: uma válvula que fecha por mola sem energia é mais fiável do que qualquer linha de código, porque não depende de o software chegar a executar.
10.3 Atualizar à distância sem perder o dispositivo
Uma atualização interrompida a meio — falta de energia, ligação perdida — não pode deixar o aparelho inutilizável, porque ninguém vai lá. O desenho que resolve isto:
- Duas partições. Escreve-se na inativa; a ativa continua intacta e a funcionar.
- Verificar antes de comutar. Assinatura e soma de verificação da imagem nova, antes de a marcar como boa.
- Reversão automática. Arranca na nova; se não confirmar que está viva dentro de N minutos, volta à anterior sozinha.
- Nunca atualizar durante uma operação crítica. Só em estado seguro conhecido.
- Faseamento. Atualizar 1% da frota primeiro. É a mesma prudência de DevOps, com a diferença de que aqui não se pode reverter à mão.
10.4 Saber o que aconteceu
Um dispositivo que reinicia sem deixar rasto é impossível de depurar. O mínimo que compensa:
- Guardar a causa do último reinício — o próprio chip regista se foi cão de guarda, tensão baixa, ou pedido normal. É a informação mais valiosa e a mais fácil de obter.
- Contador de reinícios em memória não volátil. Um dispositivo que reiniciou 4 000 vezes está a dizer alguma coisa.
- Um pequeno registo circular dos últimos eventos, que sobreviva ao reinício.
- Enviar isto com os dados normais. Um campo de estado em cada mensagem custa poucos bytes e evita deslocações ao terreno (Observabilidade & SRE).
10.5 Testar o que não acontece na bancada
Corte a alimentação em momentos aleatórios, cem vezes seguidas, e verifique que recupera sempre — incluindo a meio de uma escrita em memória.
Desligue o sensor com o sistema a funcionar.
Bloqueie o motor mecanicamente e veja se deteta.
Corte a rede durante horas e confirme que recupera e envia o atrasado.
Deixe correr uma semana — muitos erros só aparecem depois de um contador transbordar ou a memória fragmentar.
O último é o mais ignorado e o que mais problemas apanha: há falhas que só existem no tempo, e nenhum teste de dez minutos as encontra.
Automatize um corte de alimentação em instantes aleatórios e repita cem vezes. Registe quantas vezes o dispositivo não recuperou corretamente. Se for zero, tem um produto; se não, encontrou o trabalho da semana.
Capítulo 11 Prática
Segurança de dispositivos ligados
Um dispositivo embarcado é um computador ligado à internet, fisicamente acessível, que ninguém vigia e que vai durar dez anos. É o pior de todos os mundos.
11.1 O que torna isto diferente
| Facto | Consequência |
|---|---|
| O atacante pode ter o aparelho na mão | Pode abrir, ler a memória, ligar-se à porta de depuração |
| Vive dez anos ou mais | O que é seguro hoje pode não ser em 2036 |
| Ninguém olha para ele | Uma invasão pode passar anos sem ser notada |
| Há milhares iguais | Uma falha vale para toda a frota |
| Recursos escassos | Criptografia forte pode não caber, ou consumir energia a mais |
Credenciais iguais em todos os aparelhos. Uma palavra-passe de fábrica partilhada por toda a frota transforma uma descoberta única num acesso a milhões de dispositivos — e foi a origem das maiores redes de aparelhos comprometidos que existiram.
A correção é conhecida e barata: credencial única por dispositivo, gerada no fabrico, ou obrigação de a definir na primeira utilização. Vários países já o exigem por lei, e é o requisito mais fácil de cumprir de toda esta lista.
11.2 As sete medidas, por ordem de retorno
- 1 · Credenciais únicas por dispositivo. Elimina a classe inteira de ataques em massa.
- 2 · Atualizações assinadas. Se o dispositivo aceitar firmware não assinado, tudo o resto é decorativo — um atacante substitui o software e passa a ser dono do aparelho.
- 3 · Comunicação cifrada e autenticada, com verificação real do certificado do servidor. Cifrar sem verificar quem está do outro lado protege pouco.
- 4 · Portas de depuração desativadas na produção. É o acesso mais fácil para quem tem o aparelho na mão.
- 5 · Não guardar segredos partilhados em claro. Uma chave igual em toda a frota, extraída de um aparelho, compromete todos.
- 6 · Arranque verificado, onde o chip o suporte: só executa código assinado.
- 7 · Superfície mínima. Cada serviço aberto e cada funcionalidade que não usa é risco por nada.
As duas primeiras resolvem a maior parte do risco real e custam pouco. As últimas exigem hardware específico e valem a pena em produtos de maior consequência. Fazer as sete mal é pior do que fazer as duas primeiras bem, porque dá a impressão de que o assunto está tratado.
11.3 O problema dos dez anos
Um dispositivo instalado hoje pode ainda estar em serviço em 2036. Nesse período, algoritmos enfraquecem, certificados expiram e vulnerabilidades aparecem em bibliotecas que na altura eram seguras. Isso implica decisões que se tomam no desenho e não depois:
- Ter forma de atualizar — sem isso, uma vulnerabilidade descoberta em 2030 é permanente.
- Ter forma de trocar de certificados e de algoritmos, sem trocar de hardware.
- Prever o fim do serviço: o que acontece ao aparelho quando o servidor for desligado? Continuar a funcionar localmente é uma decisão de desenho, e a alternativa é transformar um produto pago em lixo.
- Assumir que o segredo será extraído de pelo menos um aparelho. O sistema deve continuar seguro para todos os outros.
11.4 E os dados das pessoas
Muitos destes dispositivos observam pessoas: presença, movimento, consumo, som, imagem. Aplicam-se os princípios habituais e um específico deste contexto — processar localmente sempre que possível. Um sensor que decide no próprio aparelho e envia apenas "há alguém na sala" é substancialmente diferente de um que envia áudio para a nuvem, e a diferença é de desenho, não de política de privacidade (IA Local & SLM).
Verifique se o seu dispositivo tem credencial única por unidade e se recusa firmware não assinado. Se falhar alguma das duas, é o trabalho mais urgente do projeto — e ambas se resolvem sem hardware novo.
Capítulo 12 Ofício
Do protótipo ao terreno
A distância entre "funcionou na bancada" e "funciona em mil sítios durante cinco anos" é onde a maior parte dos projetos morre — e quase nada dessa distância é código.
12.1 O que separa as duas coisas
| Protótipo | Produto |
|---|---|
| Um exemplar, na bancada, à temperatura ambiente | Mil exemplares, no terreno, de −10 °C a 50 °C |
| Alimentado do computador | Bateria que envelhece, ou rede elétrica com falhas |
| Componentes escolhidos por estarem disponíveis | Componentes que têm de existir daqui a cinco anos |
| Calibração no código | Calibração por unidade, gravada na produção |
| Reprogramado por cabo | Atualizado à distância, com reversão |
| "Funcionou" | "Funciona 99,9% do tempo, e sabemos quando não funciona" |
Se não puder ser testado em produção, não pode ser fabricado. Cada unidade precisa de um teste automático de saída: verificar sensores, atuadores, comunicação, gravar a calibração e a credencial única, e registar o resultado.
Isto desenha-se ao mesmo tempo que o produto — pontos de teste, um modo de fábrica, uma sequência de verificação. Acrescentado no fim, ou não cabe, ou obriga a refazer a placa.
12.2 As oito verificações antes de sair da bancada
1. Sobrevive a cem cortes de energia aleatórios (cap. 10).
2. Funciona uma semana seguida sem reiniciar.
3. Recupera de sensor desligado, motor bloqueado e rede em baixo.
4. A duração do pior ciclo cabe no prazo, com 30% de folga (cap. 5).
5. O consumo medido bate certo com a tabela de estados (cap. 8).
6. Cada atuador tem um limite independente do software (cap. 4).
7. Credencial única e firmware assinado (cap. 11).
8. A causa do último reinício é registada e transmitida.
12.3 Os erros que se repetem em todos os projetos
- Esperas espalhadas pelo código. Funcionam com uma tarefa e desmoronam com três (cap. 5).
- Acreditar no sensor. Sem verificação de plausibilidade, uma avaria vira comando (cap. 3).
- Ligar potência sem separação. Destrói hardware, e as avarias parecem de software (cap. 4).
- Adiar a energia para o fim. Descobrir na semana final que a autonomia é de dois dias obriga a refazer o produto (cap. 8).
- Não ter forma de atualizar. Condena o produto ao primeiro erro sério.
- Não registar nada. Uma avaria no terreno vira uma deslocação e um palpite.
- Testar só o caminho feliz. O terreno é feito de casos infelizes.
12.4 As cinco ideias que ficam
1 · Nunca esperar
Máquinas de estados em vez de esperas. É a transformação que converte protótipo em produto.
2 · Não acreditar no sensor
Medir o ruído, filtrar com intenção, verificar plausibilidade. Um número não é a realidade.
3 · Limites fora do software
Todo o atuador precisa de uma paragem que não dependa do código, porque o código vai falhar.
4 · A energia decide o produto
Faça a tabela de estados cedo. Ela costuma apontar para um sítio inesperado.
5 · Falhar de forma escolhida
Estado seguro decidido antes, escrito com justificação, e testado com cortes de energia a sério.
E uma sexta, de método
Meça antes de otimizar — o ruído, o tempo do ciclo, a corrente. Neste ofício a intuição erra mais do que noutros, porque o mundo físico não se comporta como se supõe.
12.5 Para onde ir a seguir
- O Futuro da Robótica e do Trabalho Físico — o par prospectivo desta apostila: para onde isto vai e o que decide a adoção.
- Linux & Shell Scripting — para os sistemas com Linux embarcado do capítulo 1.
- Observabilidade & SRE — os princípios de registo e alerta do capítulo 10, à escala de uma frota.
- DevOps, Docker & Kubernetes — entregas faseadas e reversíveis, que aqui são obrigatórias.
- Estatística I — Ver os Dados — para caracterizar ruído de sensores a sério.
- Código Legado e Refatoração — porque firmware antigo, sem testes e sem quem o perceba é o caso mais puro de código legado que existe.
Passe um projeto seu pelas oito verificações de 12.2 e conte quantas falha. Comece pela que falhar e for mais barata de corrigir. É raro passar às oito à primeira, e é essa a diferença entre a bancada e o terreno.