Máquinas de estados no firmware

Um pressionamento aceito do botão inicia uma sinalização no LED integrado: ele acende por 1000 ms, apaga por 500 ms e acende novamente por 1000 ms. Ao fim, volta a ficar apagado.

Durante essa sequência, um novo pressionamento aceito cancela a sinalização e leva a aplicação de volta ao repouso. Manter o botão pressionado não cria comandos adicionais; a soltura também não muda diretamente a sequência.

A tabela é a especificação antes do código. Ela separa o que o LED mostra da situação em que a aplicação está.

Observe que REPOUSO e PAUSA deixam o LED apagado, mas não são o mesmo estado.

• Em REPOUSO, um pressionamento inicia o primeiro pulso.
• Em PAUSA, um pressionamento cancela a sequência e retorna ao repouso.

Portanto, a saída sozinha não informa o comportamento seguinte. A aplicação precisa guardar em qual etapa está, mesmo quando duas etapas comandam a mesma saída.

A cada passagem por loop(), a máquina precisa saber em que etapa da sinalização está. Essa informação é o estado da aplicação e permanece armazenada entre passagens.

Por exemplo, depois que um pressionamento inicia a sequência, o estado pode continuar como PRIMEIRO_PULSO durante muitas passagens por loop(). Ele não deve voltar automaticamente a REPOUSO no início de cada passagem.

Isso é diferente de ler o botão: a leitura é renovada frequentemente; o estado da máquina registra a etapa que ainda está em execução.

Para organizar a sequência, separe quatro informações que têm papéis diferentes:

• Estado da máquina: etapa atual da sinalização, como REPOUSO ou PRIMEIRO_PULSO.
• Evento de pressionamento: informa que um novo pressionamento válido foi aceito agora.
• Marca de entrada: instante millis() registrado quando a máquina entrou no estado atual.
• Estado estável do botão: informação do tratamento de rebote que diz se o botão continua pressionado ou solto.

O estado estável do botão pode permanecer “pressionado” por bastante tempo. Já o evento de pressionamento deve ser breve: ele ocorre uma vez na transição estável de solto para pressionado.

Imagine que o botão já foi aceito pelo tratamento de rebote e permanece pressionado.

Na passagem em que foi aceito, eventoPressionou vale true e a máquina pode iniciar a sequência. Nas passagens seguintes, enquanto o botão continua pressionado, o estado estável ainda indica “pressionado”, mas eventoPressionou deve voltar a false.

Assim, o mesmo toque não vira vários comandos. A máquina permanece na etapa que iniciou até ocorrer uma transição prevista. A soltura, por si só, não muda a sequência desta aplicação.

O botão está estável como pressionado há várias passagens por loop(). O evento de pressionamento já iniciou a sequência na passagem anterior. Nesta passagem, o evento deve continuar verdadeiro para iniciar a sequência novamente.

A variável de estado guarda em que etapa a aplicação está entre uma passagem e outra de loop(). Em vez de números como 0, 1 e 2, use um enum: os nomes documentam o comportamento e reduzem trocas acidentais entre valores sem significado.

Os quatro nomes vêm diretamente da tabela já definida: REPOUSO, PRIMEIRO_PULSO, PAUSA e SEGUNDO_PULSO. A variável começa em REPOUSO e não deve ser declarada dentro de loop(), pois seria reinicializada a cada passagem.

Use switch (estado) para traduzir cada linha da tabela em um case. Cada case contém somente as decisões válidas naquele estado.

A atribuição estado = PAUSA; altera a variável para as próximas passagens por loop(), mas não faz o switch voltar ao topo nesta mesma execução. Por isso, todo caso deve terminar em break: ele encerra a seleção atual e devolve o controle ao restante do programa.

Estrutura inicial da máquina. As condições temporizadas serão acrescentadas depois; aqui, observe como os nomes da tabela viram cases e como cada case é encerrado.

Uma passagem por loop() pode ocorrer muitas vezes enquanto a máquina continua no mesmo estado. Por isso, se o LED e a marca entradaEstado forem atualizados dentro do case a cada passagem, a ação de entrada será repetida sem que tenha havido transição.

Separe dois papéis:

• Ao entrar: registrar o instante de entrada e comandar a saída correspondente ao novo estado.
• Enquanto permanece: apenas consultar as condições que poderão levar a uma transição.

Assim, a marca temporal permanece fixa durante a permanência. Nos próximos passos, ela servirá de referência para verificar os prazos sem bloquear o loop.

Crie uma função para ser a única porta de mudança de estado. Ela recebe o próximo estado e o instante já observado na passagem atual. Primeiro, valida o destino; depois atualiza, em conjunto, o estado, a marca temporal e o LED.

O comando do LED não fica misturado à decisão de qual transição escolherá o próximo estado. Quem decide chama transicionarPara(...); a função aplica os efeitos da entrada.

Use esta função após as declarações do enum, de estado e de entradaEstado.

A inicialização não deve esperar uma transição que ainda não aconteceu. Em setup(), estabeleça explicitamente a condição inicial:

Complete a função de transição. As lacunas devem garantir que a marca é registrada e que o LED recebe o nível correspondente ao estado ativo ou inativo.

Nos estados temporizados, a máquina faz uma consulta curta: verifica se o intervalo contado desde entradaEstado já venceu.

agora - entradaEstado >= intervalo

Se a condição for falsa, não há transição nesta passagem. A função retorna, e o loop() pode continuar atendendo o botão e as demais tarefas. Não use delay() nem um laço de espera dentro de um case.

A marca entradaEstado foi registrada ao entrar no estado pela função transicionarPara(...), construída no step anterior.

Durante a permanência em um estado, a referência temporal deve ficar intacta. Atualizá-la em toda passagem deslocaria continuamente o início da contagem: a diferença agora - entradaEstado continuaria pequena e o prazo poderia nunca vencer.

A marca é atualizada somente na inicialização ou ao chamar transicionarPara(...). Quando ocorre uma transição, o mesmo instante agora observado nesta passagem passa a ser o início do intervalo seguinte.

Trecho para incluir nos cases temporizados de atualizarMaquina(...). A função transicionarPara(...) e a variável entradaEstado já foram definidas anteriormente.

Complete as condições temporais usando a duração do estado que está terminando. As lacunas representam os intervalos da tabela de comportamento.

Nos estados ativos — PRIMEIRO_PULSO, PAUSA e SEGUNDO_PULSO — um novo pressionamento aceito cancela a sequência e leva a aplicação para REPOUSO. Essa é uma política escolhida para esta sinalização.

Em uma passagem por loop(), podem estar verdadeiros tanto o evento de pressionamento quanto a condição de tempo decorrido. A máquina não tenta decidir qual ocorreu fisicamente “primeiro”: ela usa os valores observados naquela passagem e aplica uma prioridade definida no código.

Considere a atualização em um estado ativo. A cadeia if/else if torna as alternativas mutuamente exclusivas: se o cancelamento ocorrer, o teste de prazo não decide outra transição nessa mesma chamada.

Trecho para um estado ativo, como PRIMEIRO_PULSO

Complete a condição que deve ser avaliada primeiro em um estado ativo. Ela representa o evento momentâneo já produzido pelo tratamento de botão.

A integração mantém responsabilidades separadas: o loop() observa o tempo uma vez, o tratamento de rebote produz um evento momentâneo e a máquina decide se haverá transição. O LED é comandado apenas pela função transicionarPara(...), quando a máquina entra em um estado.

Assim, manter o botão pressionado não cria vários comandos, e não há delay() bloqueando novas leituras.

Parte 1 do sketch: declarações, protótipos e tratamento de rebote. Crie um único sketch na IDE e insira os blocos na ordem apresentada.

atualizarBotao() retorna true somente na passagem em que um pressionamento estável é aceito. Nas demais passagens, inclusive enquanto o botão continua pressionado, retorna false.

As variáveis do botão e da máquina são persistentes: foram declaradas fora das funções e não são reinicializadas pelo loop().

Parte 2 do sketch: a função de transição aplica a ação de entrada; a máquina decide qual transição é válida. Nos estados ativos, o evento de pressionamento é testado antes do prazo.

Parte 3 do sketch: complete a função da máquina e acrescente setup() e loop(). Depois de inserir as três partes no mesmo sketch, grave-o no Uno R3.

Com o sketch do step anterior gravado no Uno R3, compare a especificação com o LED integrado. Use somente a alimentação USB nesta prática.

Faça cada linha da tabela como uma execução independente: antes de iniciar o próximo caso, espere o LED ficar apagado em REPOUSO. Um novo pressionamento válido só pode existir após soltar o botão e pressioná-lo novamente.

Ao observar, considere as durações aproximadas: o loop detecta os prazos em passagens sucessivas, portanto não é esperado medir transições fisicamente exatas no milissegundo.

Teste o cancelamento em três execuções separadas. Em cada uma: comece em REPOUSO, pressione para iniciar, solte o botão, e faça um novo pressionamento durante o estado indicado.

• Em PRIMEIRO_PULSO, o LED está aceso no primeiro pulso.
• Em PAUSA, o LED está apagado entre os pulsos.
• Em SEGUNDO_PULSO, o LED está aceso no segundo pulso.

Nos três casos, o novo evento deve cancelar para REPOUSO, deixando o LED apagado. Depois do cancelamento, solte e pressione novamente: esse novo evento deve iniciar outro PRIMEIRO_PULSO. A pausa continua sendo um estado ativo, mesmo tendo a mesma saída apagada de REPOUSO.

A coincidência entre evento e prazo não precisa ser reproduzida manualmente. Rastreie uma passagem de atualizarMaquina(...) usando os mesmos nomes do sketch:

• estado é PRIMEIRO_PULSO;
• eventoPressionado é true;
• (unsigned long)(agora - entradaEstado) >= PULSO_MS também é verdadeiro.

A política da aplicação dá prioridade ao cancelamento. A cadeia mutuamente exclusiva deve produzir uma única chamada de transicionarPara(...): o LED termina apagado, pois o destino é REPOUSO.