Dados compartilhados entre interrupções e loop

Dois fluxos, uma memória

No Uno R3, o loop() executa normalmente até que uma interrupção do Timer1 seja atendida. A ISR executa, termina e o processador retorna ao ponto do loop() que foi interrompido.

Uma variável é compartilhada quando tanto a ISR quanto o fluxo principal a acessam — lendo, escrevendo ou ambos. Não importa se ela é global por conveniência: o que decide é o mapa de acessos.

Nos exemplos deste tutorial, considere o ATmega328P do Uno R3: há um único núcleo e as interrupções não se aninham. Assim, enquanto uma ISR está em execução, outra interrupção aguarda; mas a ISR ainda pode interromper o loop() entre instruções.

Use este pequeno firmware apenas para mapear os acessos; por enquanto, não altere o código. A ISR registra que houve um atendimento e solicita uma atualização. Já o loop() consulta essas informações e mantém seus próprios dados locais de trabalho.

Mapa de acessos

Uma linha de C/C++ não é uma zona protegida. Enquanto o loop() executa uma expressão que acessa um dado compartilhado, uma interrupção habilitada pode ser atendida entre instruções geradas para aquela expressão. Após a ISR, o loop() continua.

Por isso, ao encontrar uma variável acessada pela ISR, marque também todo ponto do loop() que a lê ou escreve. Essa marcação revela onde a ordem entre os dois fluxos pode influenciar o resultado.

Ainda não vamos decidir como tratar esses acessos. Primeiro, precisamos identificá-los com precisão.

Associe cada variável do exemplo ao seu mapa de acessos.

Uma variável pode ser compartilhada quando a ISR e o loop() a acessam. Mas isso, sozinho, não decide o uso de volatile.

Use volatile quando há acesso pelos dois fluxos e pelo menos um deles pode modificar a variável. Nesse caso, o valor pode mudar fora da sequência normal observada pelo outro fluxo. O compilador deve então manter as leituras e escritas previstas no código.

Se ISR e loop() apenas leem uma mesma variável que não é modificada por nenhum deles, ela pode ser compartilhada no mapa de acessos, mas não precisa de volatile por esse motivo.

No exemplo iniciado no passo anterior, a ISR altera eventos e atualizarLed. O loop() lê ambos; por isso, as duas declarações usam volatile.

amostraLocal recebe uma cópia de eventos, mas depois é acessada somente pelo loop(). Ela não pode mudar por ação da ISR e não precisa do qualificador.

Variáveis modificadas pela ISR e cópia local do loop

volatile cuida da visibilidade dos acessos: o compilador deve realizar as leituras e escritas previstas para um dado que pode mudar fora do fluxo em execução.

Ele não torna uma sequência de várias etapas em uma ação única e não impede o atendimento da ISR. Portanto, declarar eventos como volatile é necessário, mas não é uma proteção completa para toda forma de acesso a ele.

No ATmega328P do Uno R3, o processador trabalha naturalmente com unidades de 8 bits. Por isso, a leitura de uma variável uint16_t na SRAM pode exigir acessos separados aos seus dois bytes; uma variável de 32 bits pode exigir ainda mais acessos.

Se uma ISR atualizar o valor entre essas partes, o loop() pode combinar bytes obtidos em instantes diferentes. O resultado é uma leitura composta incoerente: um número que nunca esteve armazenado inteiro na variável compartilhada.

volatile continua necessário para que os acessos previstos sejam realizados, mas não transforma vários acessos em uma única ação nem impede a ISR de ser atendida entre eles.

Um valor de 16 bits ocupa dois bytes. Uma interrupção pode ocorrer depois que uma parte foi lida e antes da leitura da outra parte.

Considere uma hipótese didática explícita para rastrear o problema: o loop() lê primeiro o byte baixo e depois o byte alto. Essa não é uma ordem universal garantida para todo código C/C++ compilado; ela serve para mostrar uma intercalação possível.

O contador compartilhado começa em 0x00FF. O loop() lê o byte baixo, que vale 0xFF. Em seguida, a ISR incrementa o contador para 0x0100: o byte baixo passa para 0x00 e ocorre transporte para o byte alto, que passa para 0x01. Por fim, o loop() lê o byte alto.

A transição de 0x00FF para 0x0100 altera os dois bytes e deixa visível a origem da mistura.

Usando exatamente a hipótese didática da tela anterior, coloque em ordem os três acessos que produzem a leitura incoerente. O contador começa em 0x00FF.

Uma leitura coerente é uma fotografia de um único instante: ela pode ficar antiga logo depois se a ISR atualizar o contador. Isso não é o mesmo que uma leitura incoerente.

No exemplo, 0x00FF seria uma fotografia coerente anterior e 0x0100 uma fotografia coerente posterior. Já 0x01FF não é uma fotografia de nenhum instante completo. No próximo passo, será apresentada uma forma de obter uma cópia coerente antes de usar o valor no restante do loop().

Uma flag como eventoPendente pode ocupar 1 byte na SRAM do ATmega328P. Ler esse byte ou escrever nele é um acesso simples. Mas uma decisão como “se estiver ativa, faça algo e depois limpe” contém vários passos separados.

Entre a consulta e a limpeza, a ISR pode executar e sinalizar a flag outra vez. Portanto, o tamanho de 1 byte evita o problema de uma leitura multibyte incoerente, mas não torna a sequência inteira indivisível.

Trecho analisado: a ISR registra uma ocorrência, enquanto o loop responde a ela.

Considere que eventoPendente já vale true porque houve uma comparação anterior do Timer1. Uma intercalação possível é:

1. O loop avalia if (eventoPendente) e lê true.
2. Antes de chegar à atribuição seguinte, ocorre outra comparação; a ISR executa eventoPendente = true.
3. A ISR termina, e o loop continua.
4. O loop executa eventoPendente = false com base na decisão tomada no passo 1.

No final, a flag fica false. A sinalização do passo 2 foi apagada sem ser percebida em uma passagem posterior do loop.

Um contador de 16 ou 32 bits alterado pela ISR pode ser copiado pelo loop() enquanto a ISR o atualiza. Como o ATmega328P é um processador de 8 bits, essa cópia pode reunir partes de dois valores, como visto no passo anterior.

A solução é uma seção crítica curta: durante a cópia, as interrupções ficam desabilitadas. Assim, a ISR não se intercala nessa operação. Ao sair da seção, o estado anterior das interrupções é restaurado.

No AVR, inclua util/atomic.h e use ATOMIC_BLOCK(ATOMIC_RESTORESTATE).

ATOMIC_RESTORESTATE guarda como as interrupções estavam na entrada do bloco e restaura essa condição na saída. Portanto, se elas já estavam desabilitadas por outro motivo, o bloco não as habilita indevidamente ao terminar.

A ISR é a única escritora de ticks; o loop() apenas obtém uma cópia coerente.

Contador compartilhado e cópia protegida

Complete o cabeçalho e a região protegida. O objetivo é copiar ticks para ticksLocal sem permitir que a ISR atualize o contador no meio da cópia. A condição e o comando de saída devem continuar fora do bloco.

Se as interrupções estavam habilitadas ao entrar no mesmo bloco, elas estarão habilitadas após sua saída. Em ambos os casos, o bloco preserva a condição que encontrou.

A cópia local é um instantâneo coerente, não uma promessa de que o contador não mudará logo depois: a ISR pode executar assim que as interrupções voltarem a ser permitidas.

Uma flag compartilhada pode ser retirada sem perder uma sinalização que chegue depois da retirada. A ideia é curta:

1. copiar a flag compartilhada para uma variável local;
2. limpar a flag compartilhada;
3. só então decidir o trabalho com base na cópia local.

As etapas 1 e 2 precisam formar uma única operação protegida. O trabalho em si fica fora do bloco atômico.

Considere eventoPendente escrita pela ISR e consultada por loop(). A cópia local não é compartilhada: depois de receber o valor, ela pode ser usada normalmente fora da região protegida.

Retirada atômica de uma flag sinalizada pela ISR.

Complete as duas instruções que fazem a retirada da flag. A primeira guarda o sinal para esta passagem do loop(). A segunda libera a flag compartilhada para receber uma nova sinalização.

Rastreie esta sequência. Inicialmente, eventoPendente vale true.

• O loop entra no bloco atômico, copia true para atenderEvento e limpa eventoPendente para false.
• O bloco termina e as interrupções voltam ao estado anterior.
• A ISR ocorre depois e grava true em eventoPendente.
• O loop atende o trabalho porque atenderEvento é true.

Organize as consequências na ordem em que acontecem.

Uma flag responde a: “houve pelo menos uma ocorrência desde a última retirada?”. Se a ISR executar várias vezes enquanto a flag já vale true, a informação continua sendo apenas “sim”.

Um contador responde a: “quantos atendimentos da ISR ocorreram?”. Cada atendimento incrementa o valor, até o limite do tipo. Escolha pelo dado que o loop realmente precisa preservar.

Para consumir um lote, copie o contador compartilhado e zere-o no mesmo bloco atômico. Assim, o lote retirado fica em lote; um incremento da ISR depois do bloco permanece em atendimentos para uma passagem futura do loop().

O processamento do lote — decisões, cálculos e comandos de saída — fica fora do bloco. A região protegida só transfere a informação compartilhada.

Contador compartilhado incrementado pela ISR e lote local consumido pelo loop.

Há ainda dois níveis diferentes de informação:

1. Eventos do periférico: comparações físicas do Timer1.
2. Atendimentos da ISR: vezes que a rotina conseguiu executar.

Uma pendência de comparação no hardware é uma indicação, não uma fila. Se novas comparações ocorrerem enquanto uma pendência já está aguardando atendimento, elas podem se agregar. Portanto, contar execuções da ISR não recupera automaticamente todas as comparações físicas que não ficaram registradas separadamente.

Uma solução completa, com papéis separados

Neste firmware, o Timer1 gera atendimentos periódicos. A ISR registra cada atendimento com rapidez; o loop() transfere a quantidade acumulada e decide o estado do LED depois que as interrupções foram restauradas.

Mapa de acessos de atendimentos:

• ISR: lê e incrementa atendimentos.
• Loop: lê atendimentos ao copiar o lote e escreve 0 ao concluir a transferência.
• lote e ledAceso: pertencem somente ao loop().

Como a ISR pode modificar atendimentos fora da sequência normal do loop(), ele é volatile. Como a cópia e a zeragem são uma operação composta, ambas ficam na mesma seção crítica. O contador é apropriado porque a aplicação preserva quantos atendimentos da ISR ocorreram, e não apenas se houve algum.

Prática opcional no Uno R3: crie um sketch, grave-o na placa alimentada somente pelo USB e observe o LED integrado. A ISR só incrementa o contador. O loop() retira o lote protegido, aplica as alternâncias necessárias e comanda o LED fora da seção crítica.