Se a estação meteorológica ESP32 da sua sala de aula funciona na perfeição na bancada do laboratório durante o quarto tempo letivo, mas fica completamente inativa na manhã seguinte, o silício não está com defeito. Os microcontroladores não se degradam em vinte e quatro horas. Em vez disso, o software embebido de execução contínua falha quase sempre devido a dois problemas silenciosos e cumulativos: fragmentação da memória heap causada por operações dinâmicas de texto e quebras de rede não tratadas que prendem o processador num ciclo de bloqueio infinito.

Resolver estes problemas exige afastar-se dos atalhos de prototipagem rápida e adotar práticas padrão de engenharia de sistemas embebidos: buffers de memória de tamanho fixo, máquinas de estados de rede não bloqueantes e um temporizador watchdog por hardware.

Culpado 1: Strings Dinâmicas e Fragmentação da Heap

O ESP32 tem aproximadamente 320 KB de SRAM interna utilizável. Numa estação meteorológica que faz a leitura de sensores uma vez a cada dez segundos, o código escrito com a classe padrão String do Arduino aloca, redimensiona e liberta pequenos blocos de memória milhares de vezes por dia:

// O padrão que avaria silenciosamente o seu projeto:
String payload = "{\"temp\": ";
payload += String(temperature);
payload += ", \"humidity\": ";
payload += String(humidity);
payload += "}";
http.POST(payload);

Sempre que são criadas e concatenadas strings dinâmicas dentro de loop(), o runtime de C++ aloca espaço na heap. Como outras tarefas de sistema em segundo plano (como as pilhas de Wi-Fi e Bluetooth) alocam memória ao mesmo tempo, esta alocação e desalocação contínua transforma a heap num queijo suíço. A memória livre total pode ainda indicar 150 KB, mas o maior bloco livre contíguo encolhe para algumas centenas de bytes. Quando a pilha de Wi-Fi ou o serializador de JSON solicita subitamente um bloco contínuo de 2 KB para um pacote TCP, a alocação falha, retornando um apontador nulo que espoleta um pânico de kernel (kernel panic) silencioso ou uma falha fatal não tratada.

A solução: Utilizar buffers de pilha de tamanho fixo e snprintf. O firmware de microcontroladores deve alocar buffers estáticos ou na pilha (stack) cujo tamanho seja conhecido em tempo de compilação.

// Alternativa robusta e sem alocação na heap:
char payload[128];
snprintf(payload, sizeof(payload), 
         "{\"temp\":%.2f,\"humidity\":%.2f}", 
         temperature, humidity);
http.POST((uint8_t*)payload, strlen(payload));

Culpado 2: O Ciclo de Reconexão ao Wi-Fi Escolar

Nos ambientes escolares, o Wi-Fi raramente é estático. Os pontos de acesso renovam chaves de segurança, as concessões de DHCP expiram e cortes de energia locais ou transições de corte de carga (load-shedding) desligam brevemente os routers a montante, mesmo que a estação de IoT esteja a funcionar a bateria. Muitos tutoriais introdutórios sugerem reconectar ao Wi-Fi desta forma:

if (WiFi.status() != WL_CONNECTED) {
  WiFi.reconnect();
  while (WiFi.status() != WL_CONNECTED) {
    delay(500); // Fatal: bloqueia o processador indefinidamente
  }
}

Se o router reiniciar e demorar dois minutos a restabelecer a sub-rede local, este ciclo while congela a execução. Como o FreeRTOS executa a pilha de Wi-Fi e as tarefas de gestão do sistema em dois núcleos, bloquear o ciclo principal pode privar de recursos as tarefas de watchdog em segundo plano, levando a uma reinicialização de hardware imediata ou a um bloqueio permanente da tarefa.

A solução: Tratar a conectividade como uma máquina de estados não bloqueante. Nunca interrompa a execução à espera de uma ligação. Se o Wi-Fi estiver em baixo, registe os dados localmente na memória flash ou num cartão SD e tente restabelecer a ligação num intervalo programado sem interromper as leituras dos sensores.

Culpado 3: Ausência de Temporizadores Watchdog

Por mais limpo que o seu código seja, sensores de exterior, picos elétricos de compressores nas proximidades ou linhas de barramento I2C que deixem de responder (especialmente os omnipresentes sensores BME280 ou DHT22) podem arrastar um ESP32 para um bloqueio (deadlock) de hardware. Se um sensor não libertar a linha de relógio do I2C, a biblioteca wire padrão pode bloquear indefinidamente.

Um Temporizador Watchdog de Tarefas (TWDT) monitoriza ciclos críticos. Se o ciclo principal não "alimentar" ou não reiniciar o watchdog dentro de uma janela definida (por exemplo, 8 segundos), o ESP32 despoleta automaticamente um reinício forçado e recupera de forma autónoma.

#include <esp_task_wdt.h>

#define WDT_TIMEOUT_SECONDS 8

void setup() {
  // Inicializar o watchdog para um tempo limite de 8 segundos
  esp_task_wdt_init(WDT_TIMEOUT_SECONDS, true);
  esp_task_wdt_add(NULL); // Subscrever a thread atual
}

void loop() {
  // Reiniciar o temporizador watchdog em cada ciclo
  esp_task_wdt_reset();

  readSensors();
  sendTelemetry();
  
  // Evitar delay() longos; utilizar verificações não bloqueantes com millis()
}

Uma Nota Sobre a Estabilidade da Alimentação

Antes de assumir que um erro é puramente de software, inspecione a linha de alimentação de hardware. Um ESP32 consome breves picos de corrente de até 350–500 mA durante rajadas de transmissão Wi-Fi (calibração de RF e envio de pacotes). Se a placa for alimentada por um cabo USB fino ligado a um computador portátil ou por um carregador de tomada de 5V económico, as quedas de tensão abaixo do limiar de brownout de 2,7V fazem com que o detetor de brownout interno despolete um reinício abrupto.

• Coloque um condensador eletrolítico de 100 µF a 470 µF entre os pinos VIN e GND para absorver picos transitórios de corrente.
• Certifique-se de que o detetor de brownout está ativado na sua framework em vez de suprimido, uma vez que a subtensão corrompe a memória flash interna.

Se estiver a construir estações de monitorização prontas para o terreno para ciências ambientais ou para o recinto escolar, a nossa engenharia curricular no Sheen IoT disponibiliza estruturas de hardware modulares e padrões de firmware prontos para produção que evitam estas armadilhas clássicas de sala de aula.