Período de atualização e orçamento de execução

Uma tarefa periódica tem instantes previstos para atualizar. O período programado (T) é a distância entre dois desses instantes previstos — não é, necessariamente, o tempo que o código leva para executar.

Nesta trilha, cada atualização terá prazo relativo igual ao período: se uma atualização era prevista para t₀, ela deve terminar até t₀ + T. Essa convenção facilita verificar se há tempo para a próxima atualização.

Leia uma atualização por quatro trechos:

• Período programado (T): distância entre instantes previstos consecutivos.
• Início efetivo: momento em que o código da atualização realmente começa.
• Duração de execução: do início efetivo ao fim daquela atualização.
• Intervalo real: distância entre os inícios efetivos de duas atualizações consecutivas.
• Prazo: janela do instante previsto até o limite para terminar.

Assim, duração e intervalo real começam em referências diferentes. Uma execução pode ser curta, mas começar atrasada porque outra atividade ocupou o processador antes dela.

Associe cada grandeza à definição correta.

Uma escolha inicial de período é uma hipótese de engenharia, não uma fórmula universal. Use as informações já conhecidas sobre o sinal e a dinâmica para comparar candidatos.

Considere dois critérios:

• Banda útil: o período precisa atender ao critério de amostragem que você já conhece. Isso evita aliasing, mas não define sozinho uma boa atualização.
• Dinâmica e atraso aceitável: pergunte quantas atualizações ocorrem durante a constante de tempo conhecida e se esperar até o próximo atendimento é aceitável para a aplicação.

Um período menor traz atualizações mais frequentes e potencialmente menor atraso de resposta. Em troca, deixa menos tempo para aquisição, cálculo, saída e as demais atividades do firmware.

Caso de comparação: um sinal tem banda útil de 5 Hz e o comportamento relevante possui constante de tempo conhecida de 200 ms. A aplicação aceita até cerca de 50 ms de espera até uma nova atualização.

Pelo critério mínimo de Nyquist, a taxa deve ser maior que 10 Hz; portanto, o período deve ser menor que 100 ms. Compare agora três candidatos. A coluna “atualizações por τ” é apenas uma forma de visualizar a dinâmica; ela não é uma regra de aprovação isolada.

No caso apresentado, qual justificativa sustenta melhor a escolha provisória de 50 ms?

Um período é um recipiente de tempo: tudo o que pode afetar a próxima atualização precisa caber nele. Comece separando a tarefa crítica — adquirir, calcular e atualizar a saída — das demais atividades que também disputam o processador.

Um orçamento preliminar não é uma medição: é uma estimativa declarada para orientar o projeto. Ele deve reservar tempo para variações, caminhos condicionais, interrupções e diagnósticos. Depois, os valores serão confrontados com medições no Uno.

Monte o orçamento em blocos. Inclua custos pequenos que costumam ser esquecidos: verificar se chegou o instante da tarefa, marcas de tempo para diagnóstico, interrupções e o restante do loop().

A comunicação serial deve ficar fora do trecho crítico sempre que possível, mas não fica fora do orçamento. Formatar e enviar uma mensagem pode consumir tempo ou bloquear; portanto, pode atrasar o início da atualização seguinte.

Para medir a duração de um trecho, capture uma marca de tempo imediatamente antes e outra imediatamente depois dele. A diferença entre as marcas é a duração observada.

No Uno R3, use marcas e diferenças sem sinal de 32 bits (uint32_t). Isso mantém o cálculo correto mesmo quando o contador de micros() retorna a zero.

A marca inicial deve ficar próxima do começo que você quer medir; a final, logo após o fim. Tudo que estiver entre elas — inclusive uma interrupção que ocorra nesse intervalo — compõe a duração observada.

Este padrão mede a duração da função tarefa(). O código não deve imprimir pela Serial dentro do trecho medido: comunicação e formatação também consomem tempo e devem ser orçadas separadamente.

No Uno R3 de 16 MHz, com a configuração padrão, micros() avança em passos de 4 µs. Portanto, uma duração lida como 0 significa apenas que o trecho ficou abaixo da resolução observável, ou caiu entre duas atualizações da contagem; não significa execução instantânea.

A própria leitura de micros() também tem custo. Para trechos muito curtos, a instrumentação e a quantização podem ser comparáveis ao tempo que você quer medir. Meça blocos significativos e interprete valores pequenos com prudência.

Em cada atualização, compare o instante previsto com a marca de início registrada pelo software, idealmente imediatamente antes ou depois da aquisição. A diferença é a latência de atendimento:

latência = início efetivo − instante previsto

Se a atualização estava prevista para 11.000 µs e começou em 11.100 µs, a latência foi 100 µs.

Essa marca descreve quando a tarefa realmente começou a ser atendida. Ela não é o instante em que uma mensagem de diagnóstico aparece no Monitor Serial: a transmissão e a formatação serial podem ocorrer bem depois e não devem virar a referência da aquisição.

Jitter é a variação desses tempos ao longo das atualizações. Um atraso constante de 100 µs em todas as chamadas é latência, mas não produz variação entre elas. Já atrasos de 0 µs, 100 µs e 50 µs indicam atendimento variável.

Também registre o intervalo real entre inícios consecutivos:

intervalo[i] = início[i] − início[i−1]

Para uma sequência observada, anote o menor intervalo, o maior intervalo e a amplitude: máximo − mínimo. São indicadores observados no ensaio, não uma garantia para todas as condições possíveis.

Considere período programado de 1.000 µs e prazo relativo também de 1.000 µs. Portanto, cada prazo termina 1.000 µs depois do respectivo instante previsto.

Para verificar o prazo, não basta comparar a duração com o período. Use:

latência + duração ≤ prazo relativo

Em B2: 100 µs + 920 µs = 1.020 µs. O prazo era 1.000 µs; o fim em 12.020 µs passou 20 µs do limite de 12.000 µs.

Assim, B2 começou atrasada e perdeu o prazo. Já A1 começou 100 µs atrasada, porém terminou em 10.800 µs, antes do limite de 11.000 µs: início atrasado não implica, sozinho, perda de prazo.

No registro B2, o início efetivo foi 11.100 µs, o instante previsto foi 11.000 µs e a duração foi 920 µs. O prazo termina em 12.000 µs.

A atualização terminou quantos microssegundos depois do prazo? Preencha somente o número.

Quando uma tarefa atrasa, definir a próxima agenda como agora + periodo desloca todas as liberações futuras. Um atraso isolado passa a determinar a cadência.

Mantenha nextDue como o próximo instante previsto. Ao encontrar uma ou mais liberações vencidas, avance essa referência em múltiplos inteiros do período. Assim, o atendimento atrasado não redefine os instantes planejados.

Use uma definição única: nextDue é sempre a próxima liberação prevista que ainda não foi atendida nem descartada.

Quando agora alcança nextDue, calcule:

elapsed = agora - nextDue

skipped = elapsed / PERIOD_US

skipped informa quantos períodos completos se passaram depois de nextDue. A liberação atendida é:

scheduled = nextDue + skipped × PERIOD_US

As skipped liberações anteriores são descartadas. Depois de atender scheduled, a nova referência é scheduled + PERIOD_US. A aquisição é feita agora; ela não reconstrói dados dos instantes descartados.

Trecho central com nextDue como próxima liberação pendente. Ele executa, no máximo, uma atualização em cada passagem pelo loop().

Há somente um if, não um laço que execute repetidamente a tarefa vencida. Mesmo que skipped seja 3 ou maior, ocorre no máximo uma atualização nesta passagem pelo loop().

discarded conta liberações que nem chegaram a executar. deadlineMisses conta outra coisa: uma atualização que foi executada, mas cujo end ficou depois de scheduled + PERIOD_US. Um descarte não é automaticamente uma perda de prazo da atualização atendida.

Monte apenas este ensaio de baixa energia: conecte o Uno R3 ao computador por USB, ligue A0 ao GND e não conecte motor, ponte H ou outra carga externa. O sketch lê A0, faz um cálculo simples e atualiza o LED integrado.

Com A0 no GND, a leitura tende a ficar próxima de zero; isso torna o sinal previsível para o primeiro teste. Abra a IDE Arduino, selecione sua placa e porta e deixe o Monitor Serial em 115200 baud.

Cole este primeiro bloco no início de um novo sketch.

Cole este segundo bloco depois do anterior. As marcas internas separam aquisição, cálculo e saída; a janela de start até end mede o trecho crítico completo, inclusive o custo dessas marcas e interrupções que ocorram nele.

Cole este bloco. A função recalcula o instante atual ao ser chamada, preserva a referência periódica e executa no máximo uma atualização. Se você inserir mais adiante uma perturbação antes da chamada desta função, ela ainda calculará os descartes a partir do instante atual.

Complete o sketch com este bloco. O relatório é dividido em três linhas curtas. Cada linha só é enviada se houver espaço suficiente no buffer serial para ela inteira; assim, o envio adiado evita bloquear a tarefa por falta de espaço. Clique em Verificar e depois em Carregar.

Cada conjunto de três linhas é um relatório:

• cont: n = atualizações atendidas; d = liberações descartadas; p = atualizações executadas que terminaram após o prazo.
• dur: aq = maior duração de aquisição; ca = maior duração do cálculo; sa = maior duração da atualização de saída; cr = maior duração do trecho crítico completo.
• tmp: la = maior latência; in = menor/maior intervalo entre inícios.

Todos os tempos são em microssegundos. O primeiro atendimento não entra em in, pois ainda não há início anterior. A formatação e a transmissão serial ficam fora de runTask(), mas pertencem ao orçamento: se consumirem tempo, podem atrasar o atendimento seguinte.

Compare ensaios sob condições declaradas, mantendo a mesma placa, montagem com A0 no GND e período de 10.000 µs. Mude uma condição por vez e registre cr, la, in, d e p.

Use quatro condições: operação básica; perturbação dentro da tarefa; perturbação antes da decisão do agendador; e relatórios seriais periódicos. Uma perturbação interna tende a elevar a duração crítica (cr). Uma perturbação antes da decisão tende a elevar a latência (la) e, se atravessar períodos, pode gerar descartes (d).

A comunicação serial fica fora do trecho crítico, mas não é gratuita: formatação e escrita ocupam o loop() e podem atrasar o próximo atendimento.

Faça os ensaios em execuções separadas, carregando o sketch a cada mudança de constante. A espera é proposital, finita e serve somente para testar as métricas.

Ensaio interno: use PERTURBAR_DENTRO_US = 3000 e PERTURBAR_ANTES_US = 0. A espera entra no trecho crítico completo, mas fica fora das janelas individuais de aquisição, cálculo e saída. Assim, cr deve crescer aproximadamente 3.000 µs, enquanto aq, ca e sa tendem a ficar próximos aos valores básicos.

Ensaio pré-atendimento: depois, use PERTURBAR_DENTRO_US = 0 e PERTURBAR_ANTES_US = 35000. A espera ocorre somente depois de três tarefas atendidas, para que existam inícios anteriores e posteriores para comparar.

Adicione este trecho junto às constantes e funções globais do sketch da etapa anterior. Para cada ensaio, altere somente os valores das duas constantes conforme a instrução desta tela.

Em runTask(), insira a primeira linha após o cálculo de latency e antes de t0 = micros(). Depois, substitua serveDueTask() por esta versão. A perturbação pré-atendimento só ocorre depois de três tarefas atendidas; portanto, o intervalo ampliado poderá ser comparado com o início anterior.

Compare a influência da comunicação sem deixar de obter um resumo. Execute duas vezes, sempre com PERTURBAR_DENTRO_US = 0 e PERTURBAR_ANTES_US = 0:

1. Use RELATORIOS_PERIODICOS = true: há relatórios durante cinco segundos e um último resumo ao fim.
2. Use RELATORIOS_PERIODICOS = false: as métricas são acumuladas em silêncio por cinco segundos e só então é emitido um resumo.

Em cada mudança, carregue o sketch novamente. A versão silenciosa não torna a comunicação “gratuita”; ela apenas remove os envios durante a janela para comparar seu efeito.

Faça todas estas edições: adicione as declarações globais; em setup(), acrescente a linha que inicializa testEnd; por fim, substitua loop() inteiro. A janela termina após 5 segundos nas duas condições.

É possível que as duas condições deem números parecidos: isso também é um resultado válido. Se a condição periódica aumentar la, o maior in, d ou p, a comunicação está disputando tempo com o próximo atendimento. A duração crítica cr pode permanecer semelhante, porque a emissão ocorre fora de runTask().

Antes de seguir para a validação, restaure PERTURBAR_DENTRO_US = 0, PERTURBAR_ANTES_US = 0 e remova ou desative a janela de teste, voltando ao loop() normal da etapa anterior.

O maior valor medido é uma evidência das condições exercitadas e do tempo do ensaio; não prova um limite garantido para todos os caminhos futuros, interrupções ou usos da comunicação.

Revise o orçamento com a condição relevante mais exigente: duração crítica, agendamento, instrumentação, demais atividades do loop() e comunicação. Preserve uma reserva explícita. Se descartes se repetirem em condições normais, reduza trabalho ou comunicação; reveja o período apenas se banda, dinâmica e atraso aceitável continuarem atendidos.

Feche o ensaio nas condições reais

Faça uma última execução sem as perturbações artificiais usadas para testar duração ou atraso. Mantenha o mesmo período, montagem e sketch que pretende usar como referência.

Registre as condições que importam: placa usada, alimentação por USB, sinais conectados, período configurado, duração aproximada do ensaio e se o Monitor Serial estava ativo. Então anote os maiores valores observados de duração e latência, os limites dos intervalos reais, descartes e perdas de prazo.

A conclusão deve separar duas afirmações:

• Evidência observada: o que ocorreu nas condições e no tempo ensaiados.
• Garantia: um limite demonstrado para todas as condições possíveis.

Mesmo que descartes e perdas de prazo sejam zero, isso é uma boa evidência para o ensaio realizado — não uma garantia absoluta.

Registro mínimo de decisão

Use este modelo no seu caderno técnico ou em um arquivo local. Preencha com os valores do seu ensaio final.

1. Período escolhido: _ µs ou _ ms.
2. Justificativa: dinâmica/banda considerada e atraso de atualização aceito.
3. Orçamento revisado: aquisição _; cálculo _; saída _; demais atividades _; margem ___.
4. Condições do ensaio: montagem, alimentação, duração, comunicação serial e caminhos de execução exercitados.
5. Métricas observadas: maior duração _; maior latência _; intervalo mínimo/máximo _ / _; descartes _; perdas de prazo _.
6. Política em atraso: atender no máximo uma vez por passagem, descartar liberações antigas, adquirir uma leitura nova e contar descartes.
7. Conclusão e limite: o que os dados apoiam; o que ainda não está garantido.

Prefira valores com unidade. Se ainda não mediu algum valor, registre isso como pendência, não como zero.

Quando o tempo não cabe

Se a duração, a latência ou as perdas de prazo mostrarem que a margem é insuficiente, não trate descartes como correção permanente. Escolha a ação que ataca a causa:

• Reduzir trabalho: simplificar cálculos, aquisição ou caminhos condicionais desnecessários.
• Limitar comunicação: reduzir formatação e envio serial; manter diagnósticos fora da tarefa crítica.
• Rever o período: só aumentar o período se a banda útil, a dinâmica e o atraso aceitável ainda permitirem.

Depois da mudança, refaça orçamento e medição. Diminuir a frequência de atualização apenas para "parar os atrasos" pode prejudicar o requisito do sinal ou da resposta do sistema.