Porque É Que o delay() Estraga Projetos de Arduino na Sala de Aula (e Como Ensinar millis() aos Alunos)
A utilização de delay() coloca o microcontrolador em suspensão, cegando sensores e bloqueando motores. Veja como o modelo mental do cronómetro ensina temporização não bloqueante aos alunos da Fase Sénior.
A função delay() estraga os projetos de Arduino na sala de aula porque paralisa o microcontrolador por completo. Durante toda a duração da pausa, o processador não faz nada: não consegue ler um sensor de colisão, não pode verificar a leitura de distância de um sensor de ultrassons e não consegue responder a um botão de paragem. Se um robô com rodas estiver a avançar quando atinge um atraso de dois segundos, continuará a mover-se às cegas contra uma parede durante dois segundos inteiros antes de executar a sua instrução seguinte.
Para corrigir isto com alunos do 7.º ao 9.º ano, não precisa de ensinar multithreading, interrupções de temporizadores por hardware ou máquinas de estados orientadas a objetos. Precisa apenas de um modelo mental único e concreto: olhar para o relógio de pulso em vez de dormir uma sesta.
A Anatomia de um Erro Típico na Sala de Aula
Em praticamente todos os planos de aula introdutórios de robótica, a Lição 1 é o habitual LED a piscar:
digitalWrite(13, HIGH);
delay(1000);
digitalWrite(13, LOW);
delay(1000);Funciona, dá aos alunos uma gratificação instantânea e coloca uma mina concetual que explode três semanas depois. Na Lição 4, quando se pede aos alunos que construam uma passagem de peões (fazer piscar uma luz e detetar o premir de um botão) ou um rover que desvia de obstáculos (rodar motores e ler distâncias), o código deles desmorona-se.
O aluno escreve um ciclo que verifica o botão de pressão, liga um besouro (buzzer) e chama delay(1000). Quando prime o botão, a placa normalmente ignora-o. Porquê? Porque o processador estava ocupado a contar ciclos mortos dentro do atraso. O dedo do utilizador premiu e soltou o interruptor durante os 99% do ciclo em que o chip estava funcionalmente a dormir.
Num ATmega328P a 16 MHz, chamar delay(1000) desperdiça 16 milhões de ciclos de relógio a executar instruções vazias em assembly. O robô não está a executar multitarefa; está congelado.
O Modelo Mental do Relógio de Pulso
Antes de mostrar código aos alunos, afaste-os dos ecrãs para uma demonstração de cinco minutos. Peça a um voluntário para realizar uma tarefa: “Bate palmas de três em três segundos, mas se eu deixar cair esta caneta, apanha-a antes de chegar ao chão.”
Primeiro, faça com que simulem o delay(): diga-lhes que, para contar três segundos, têm de fechar os olhos e contar em silêncio até três de cabeça. Deixe cair a caneta ao segundo dois. Vão falhar todas as vezes. Os seus sensores estavam desligados enquanto cronometravam o tempo.
A seguir, apresente-lhes o modelo não bloqueante: diga-lhes para manterem os olhos bem abertos, olharem para o relógio de parede da sala de aula (ou para um relógio de pulso digital) e continuarem a observar a sua mão. Eles verificam o tempo: se já passaram três segundos desde a última palma, batem palmas. Se a caneta cair, reagem instantaneamente.
Isto muda o conceito de temporização de uma ação (“espera dois segundos”) para uma comparação (“já passou tempo suficiente?”).
O Padrão Essencial: Três Perguntas
Assim que os alunos compreenderem o relógio na parede, apresente a função millis(). Explique que o millis() é simplesmente um cronómetro interno que começou a contar no milissegundo exato em que o Arduino foi ligado à corrente. Nunca para e nunca suspende o código.
Cada evento não bloqueante pode ser reduzido a três perguntas simples dentro do ciclo contínuo:
- Que horas são agora? (Ler o cronómetro:
currentTime = millis()) - Quando é que realizei esta ação pela última vez? (Consultar o registo guardado:
previousTime) - Já passou o tempo necessário? (Fazer a subtração:
currentTime - previousTime >= interval)
Se a resposta à terceira pergunta for afirmativa, execute a ação e atualize o registo: defina previousTime = currentTime. Se a resposta for negativa, ignore a ação e avance de imediato. Como o ciclo termina numa fração de milissegundo, a placa fica livre para ler sensores de ultrassons, verificar fins de curso e consultar sensores de seguimento de linha milhares de vezes por segundo.
Ensinar a Sintaxe sem Sobrecarregar os Principiantes
Para alunos do 7.º e 8.º ano, a estrutura repetitiva em C++ associada a unsigned long cria frequentemente uma sobrecarga cognitiva. Em escolas que seguem o currículo oficial de Programação e Robótica da Fase Sénior, os alunos trabalham habitualmente em ambientes baseados em blocos ou em editores híbridos.
Se estiver a ensinar com blocos (como ambientes Arduino baseados no Scratch), a transposição é simples: introduza um bloco de “temporizador” e uma variável com o nome last_time_checked. Evite completamente o bloco “espera 1 segundo” assim que forem introduzidas as primeiras entradas.
Se estiver a ensinar C++ textual para Arduino, não lance o exemplo padrão BlinkWithoutDelay nos ecrãs dos alunos sem apoio pedagógico gradual. O exemplo oficial do Arduino combina dois conceitos distintos em simultâneo: temporização não bloqueante e alternância de estado (inverter a variável de estado de um LED). É por isso que os alunos ficam confusos.
Separe a verificação de tempo da lógica. Utilize antes esta sequência:
- Demonstre a falha: Peça-lhes que executem um LED a piscar com
delay()enquanto tentam acionar um botão de paragem de emergência. Observe a frustração quando o botão não responde. - Apresente a variável de temporização: Mostre-lhes como imprimir
millis()no Monitor Série para que vejam os números a subir continuamente. Isto desmistifica a função — é apenas um conta-quilómetros do tempo. - Escreva o invólucro de temporização: Forneça um modelo estruturado onde a lógica de subtração esteja isolada do comportamento do robô.
| Approach | Processor State | Sensor Responsiveness | Suitability |
|---|---|---|---|
delay(1000) | Halted in busy-wait loop | Completely blind during delay | Single-task demos, Grade 4–6 intro |
millis() comparison | Free-running at full clock speed | Instant (sub-millisecond polling) | Robotics, rovers, interactive systems |
Garantir a Consolidação nos Projetos de Turma
Quando os alunos passam de rovers que se movem às cegas para rovers que consultam sensores continuamente, a sua experiência de depuração (debugging) muda. Em vez de ficarem a pensar porque é que um interruptor de colisão não conseguiu parar um motor DC, conseguem seguir a execução do código com clareza.
Se a sua escola estiver a estruturar uma progressão ao longo de vários períodos letivos, desde a lógica por blocos até à robótica física, contar com sequências didáticas estruturadas e esquemas de hardware verificados elimina as incertezas. A nossa equipa na Sheen Robotics for Schools trabalha com professores para alinhar estes conceitos de sistemas embebidos com os horários das aulas, garantindo que os alunos constroem modelos mentais sólidos antes que maus hábitos de programação se instalem.
Assim que um aluno compreende que um computador nunca deve ficar de olhos fechados a contar segundos, ultrapassa a barreira entre simplesmente executar scripts e escrever software reativo para o mundo real.
