Um micro-ondas conta o tempo, vigia a porta, lê o teclado e pisca o display — tudo aparentemente ao mesmo tempo, com um único núcleo que só sabe executar uma instrução de cada vez. O truque tem nome: interrupção. Este capítulo fecha a fase digital da série explicando como esse malabarismo funciona, o que significa “tempo real” na prática, e por que boa parte dos travamentos, botões que não obedecem e reinícios misteriosos nasce exatamente aqui.
Primeiro, o jeito ingênuo: ficar olhando
O programa mais simples que existe é um laço que roda para sempre: lê o botão, calcula, atualiza a saída, volta ao começo. Esse jeito de verificar tem nome — polling, ou consulta repetida. É o atendente que, a cada poucos segundos, levanta e vai até a porta ver se alguém chegou.
Funciona bem enquanto o programa é pequeno. O problema aparece quando o laço engorda. Se em algum ponto do ciclo o chip gasta trinta milissegundos atualizando um display, qualquer coisa que acontecer durante esses trinta milissegundos passa despercebida. Um botão apertado rápido some. Um pulso de sensor não é contado. E o defeito que isso produz é o pior de todos: intermitente e dependente do momento — funciona quando o técnico testa devagar, falha quando o cliente usa depressa.
Vale registrar que polling não é errado. Para coisas lentas e sem pressa — ler uma temperatura a cada segundo, checar um estado de menu — é a solução mais simples e mais segura. O que não dá é depender dele para eventos rápidos ou raros.
A interrupção: o hardware bate na porta
A alternativa é inverter a responsabilidade. Em vez de o núcleo perguntar “chegou alguém?”, o hardware avisa. É a campainha: o atendente fica trabalhando na mesa dele e só se levanta quando toca.
Na prática, um periférico — um pino, um timer, uma porta de comunicação — é configurado para sinalizar um evento. Quando ele ocorre, o hardware ergue um bit de sinalização, e o núcleo interrompe o que está fazendo, atende, e depois volta exatamente para onde parou. O programa principal nem toma conhecimento de que foi interrompido.
Aqui a série se costura. No capítulo dos registradores e do microcontrolador por dentro vimos que existe um contador de programa apontando para a próxima instrução. A interrupção mexe justamente nele: guarda o valor atual, carrega o endereço da rotina de atendimento e desvia. Quando a rotina termina, o valor guardado volta ao lugar e a execução retoma como se nada tivesse acontecido.
O que acontece por dentro, passo a passo
A sequência é sempre a mesma, e conhecê-la ajuda a entender o que pode dar errado:
- O evento ocorre e o hardware liga uma bandeira (flag) no registrador do periférico. A bandeira fica lá mesmo que ninguém olhe.
- O núcleo termina a instrução em curso. Ele não para no meio de uma instrução — por isso a resposta nunca é instantânea.
- O contexto é salvo: contador de programa e registradores essenciais vão para a pilha, para que nada se perca.
- O desvio é feito pelo vetor de interrupção, uma tabela em memória que diz, para cada fonte de evento, onde mora a rotina que a atende.
- A rotina de atendimento roda — é a famosa ISR, de interrupt service routine. É ela quem precisa limpar a bandeira; se não limpar, o hardware entende que o evento continua pendente e chama de novo, para sempre.
- O contexto é restaurado e a execução volta ao ponto exato de origem.
O tempo entre o evento e a primeira linha da ISR tem nome: latência de interrupção. Costuma ser de poucos microssegundos, mas não é fixo — depende de quanto falta da instrução atual, de quantos registradores precisam ser salvos e, principalmente, de haver outra interrupção sendo atendida naquele instante.
As fontes de interrupção que existem numa placa
| Fonte | O que dispara | Exemplo no aparelho |
|---|---|---|
| Pino externo | Borda de subida, de descida ou mudança de nível | Botão liga/desliga, sensor de porta aberta, alarme vindo de outro chip |
| Timer | A contagem chega ao valor programado | Base de tempo do relógio, varredura de display, ritmo do controle |
| Recepção serial | Chegou um byte pela UART, I2C ou SPI | Comando do controle remoto, dado do sensor, tráfego dos barramentos |
| Conversão do ADC | A leitura ficou pronta | Amostragem periódica de corrente ou temperatura |
| Comparador analógico | Uma tensão cruzou o limite | Proteção de sobrecorrente que precisa agir em microssegundos |
| Watchdog / falha de alimentação | O programa parou de dar sinal de vida, ou a tensão caiu | Reinício automático, salvamento de dados antes de apagar |
Repare que quase tudo o que os periféricos do capítulo anterior fazem termina numa interrupção. Eles trabalham sozinhos em hardware e só incomodam o núcleo quando têm resultado — é essa divisão de trabalho que permite a um chip modesto parecer que faz três coisas ao mesmo tempo.
Prioridade, e o que “tempo real” significa de verdade
Quando duas campainhas tocam juntas, alguém precisa decidir quem atende primeiro. Por isso as interrupções têm prioridade: a de maior prioridade pode até interromper a rotina da menor — o chamado aninhamento. Uma proteção de sobrecorrente fica no topo; a atualização de um display fica no fim da fila.
E aqui vale desfazer um mal-entendido comum. Tempo real não quer dizer rápido. Quer dizer previsível. Um sistema de tempo real é aquele que garante uma resposta dentro de um prazo. Se um airbag precisa disparar em cinco milissegundos, um sistema que responde em três milissegundos quase sempre — mas às vezes leva vinte — é um sistema falho, mesmo sendo veloz na média.
A variação do tempo de resposta tem nome próprio: jitter. É o inimigo silencioso. Um controle de motor com jitter alto produz trepidação; uma comunicação com jitter alto perde bytes; um display com jitter alto tremula. E, como o atraso muda a cada ciclo, o sintoma nunca é o mesmo duas vezes — outra receita de defeito “que ninguém consegue reproduzir”.
A regra de ouro: a ISR tem que ser curta
Existe uma disciplina que todo projeto sério segue: a rotina de interrupção só levanta a bandeira; o trabalho pesado fica para o laço principal. Ela anota que o evento aconteceu, guarda o dado mínimo, limpa a sinalização do hardware e sai.
O motivo é aritmético. Enquanto a ISR roda, o programa principal está parado e, dependendo da configuração, outras interrupções estão bloqueadas. Uma rotina longa demais atrasa todo mundo — e se outro evento da mesma fonte chegar antes de ela terminar, esse evento simplesmente se perde. Não há mensagem de erro: o pulso deixa de existir.
Duas armadilhas clássicas moram aí. A primeira é o dado compartilhado lido pela metade: se a ISR incrementa um contador de 16 bits e o programa principal lê esse contador num chip que só move 8 bits por vez, a leitura pode pegar a metade velha e a metade nova, produzindo um valor absurdo que aparece uma vez a cada tantas horas. A solução é ler com as interrupções momentaneamente desabilitadas — a chamada seção crítica.
A segunda é desabilitar interrupções por tempo demais para proteger essa leitura. Cada microssegundo com a campainha desligada é um microssegundo em que eventos podem escapar. Seção crítica se faz curta, sempre.
O botão que dispara três vezes
O exemplo mais didático de tudo isso cabe num botão. Contatos mecânicos não fecham de forma limpa: eles quicam por alguns milissegundos, abrindo e fechando várias vezes antes de estabilizar. Um pino configurado para interromper a cada borda vai enxergar cinco, dez, vinte eventos onde o dedo apertou uma única vez.
É esse o defeito de “menu que pula duas posições” ou “volume que sobe sozinho”. Existem três formas de tratar:
- No hardware, com um resistor e um capacitor formando um filtro RC que arredonda o quique — se esse capacitor secar, o botão volta a repetir. Motivo comum de aparelho antigo com teclado enlouquecido.
- Com um disparador Schmitt, cujos dois limiares de decisão já vimos nos níveis lógicos, transformando a subida lenta e suja numa borda única e firme.
- No software, ignorando novos eventos daquele pino por algumas dezenas de milissegundos após o primeiro.
Na bancada, isso dá uma pista útil: teclado que repete em aparelho que sempre funcionou raramente é problema de programa. O programa não mudou. O que mudou foi um componente do filtro ou o próprio contato, oxidado.
Onde isso vira defeito na bancada
| Sintoma | O que costuma estar por trás |
|---|---|
| Aparelho trava e só volta desligando da tomada | ISR que não limpou a bandeira e ficou sendo chamada sem parar, ou uma rotina esperando algo que nunca chega. O núcleo está vivo, mas nunca volta ao programa principal. |
| Reinício sozinho em intervalos regulares | Watchdog — o programa travou e o hardware reiniciou. O intervalo constante é a assinatura. Ver clock, reset e enable. |
| Botão que às vezes não responde | Laço principal longo demais tratando o botão por consulta, sem interrupção, ou seção crítica esticada. |
| Contagem de pulsos que erra pouco, sempre para menos | Eventos perdidos enquanto outra interrupção de prioridade maior era atendida. |
| Comunicação que falha só quando outra função está ativa | Interrupções concorrentes mal priorizadas: o barramento perde bytes enquanto o chip cuida de outra coisa. |
| Ruído elétrico causando disparos falsos | Um pino de interrupção é sensível a bordas — interferência num fio longo vira evento fantasma. Aqui o defeito é elétrico, não lógico. |
A última linha merece destaque: uma entrada de interrupção sem filtro, ligada a um chicote longo, conta pulsos que ninguém gerou. O sintoma parece firmware defeituoso e é, na origem, elétrico.
Como enxergar isso na bancada
Multímetro não ajuda aqui — ele entrega média, e interrupção é evento. As ferramentas úteis são outras:
- Osciloscópio em modo Single, armado na borda do pino suspeito. É assim que se vê o quique de um botão ou o pulso que chega do sensor. Vale reler o que medir na placa.
- Analisador lógico, quando o interesse é a ordem dos acontecimentos entre vários sinais — qual chegou antes, quanto tempo depois veio a resposta.
- Pino de depuração, o truque de quem projeta: o firmware liga um pino livre ao entrar na ISR e desliga ao sair. A largura do pulso na tela é o tempo de execução da rotina, medido, não estimado. É um recurso de desenvolvimento, e só existe se o projeto tiver previsto.
Onde comprar
Para observar na prática o que este capítulo descreve:
Como Associados da Amazon, recebemos por compras qualificadas feitas pelos links acima — você não paga nada a mais por isso.
Perguntas frequentes
Interrupção é a mesma coisa que multitarefa? Não, mas é a base dela. A interrupção atende um evento e devolve o controle. Multitarefa de verdade — vários programas revezando — se constrói em cima disso, usando um timer que interrompe periodicamente para trocar de tarefa. Num microcontrolador simples, o revezamento é feito à mão, com o laço principal cuidando do que as ISRs anotaram.
Dá para consertar um defeito de interrupção trocando peça? Depende de onde ele nasce. Se a causa é elétrica — contato quicando, capacitor de filtro seco, ruído num chicote —, sim, e é o caso mais comum na bancada. Se a causa é lógica, dentro do programa, não há peça a trocar: a saída é regravar o firmware com a versão correta do fabricante.
Por que o aparelho trava mas o display continua aceso? Porque o display costuma ser mantido por hardware ou por um periférico que segue funcionando sem o núcleo. Luz acesa não é prova de programa rodando — é prova de que a energia está lá. São coisas diferentes, e confundi-las faz muito técnico condenar a fonte à toa.
Todo microcontrolador tem interrupção? Praticamente todos, até os mais simples de oito bits. O que varia é a quantidade de fontes, se há níveis de prioridade e se uma pode interromper a outra. Chips maiores têm um controlador dedicado só para gerenciar essa fila.
Por que meu projeto no Arduino perde pulsos? Quase sempre porque o pulso está sendo lido por consulta dentro de um laço com espera. Trocar a leitura por interrupção de pino resolve a maioria dos casos — e a IDE do Arduino já oferece isso pronto. A segunda causa mais comum é uma rotina de atendimento longa demais.
Conclusão
A interrupção é o que separa um programa que procura acontecimentos de um que é avisado deles. O primeiro é simples e serve para o que é lento; o segundo é indispensável para o que é rápido, raro ou urgente. E tempo real, apesar do nome, não é uma questão de velocidade — é o compromisso de responder dentro de um prazo, sempre, inclusive no pior caso.
Na bancada, a lição prática é aprender a separar as duas naturezas. Travamento, botão desobediente e contagem errada podem vir da lógica, e aí não há peça a trocar. Mas podem vir da eletricidade — um contato quicando, um filtro ressecado, ruído entrando por um fio longo — e aí o conserto é físico e está ao alcance de quem tem osciloscópio. Perguntar de qual dos dois lados o defeito nasceu economiza muitas horas e muitas peças boas.
Com este capítulo a fase digital fica fechada. A partir do próximo, a série volta ao mundo contínuo com o componente que faz a ponte entre sensor e chip e que aparece em quase toda placa de áudio, medição e controle: o amplificador operacional — o que ele é, por que a realimentação transforma um ganho gigantesco em algo previsível, e como reconhecer suas montagens clássicas olhando a placa.
Veja também
- ADC, PWM e periféricos — o capítulo anterior: como o chip lê o mundo e age sobre ele.
- Clock, reset e enable — o watchdog e os sinais que fazem a placa acordar.
- Osciloscópio no diagnóstico — o modo Single, indispensável para capturar eventos únicos.
