Neste artigo, exploramos o desenvolvimento de uma ferramenta embarcada de código aberto dedicada a solucionar os desafios de validação e depuração de testes de longa duração em sistemas de Internet das Coisas (IoT). Construída com base no microcontrolador ESP32-S3 e no framework ESP-IDF, a solução atua simultaneamente como um data logger de armazenamento local e um gateway de telemetria remota.
Ao longo do texto, abordaremos as principais decisões de arquitetura de software que viabilizaram o projeto. Entre os destaques, explicaremos o uso prático do FreeRTOS para garantir a previsibilidade na aquisição de dados concorrentes, a estruturação otimizada de mensagens em arquivos binários para salvamento em cartão SD, e o roteamento dinâmico via protocolo MQTT (Message Queuing Telemetry Transport) para observabilidade remota. Além disso, demonstraremos como a criação de scripts auxiliares em Python transforma esse hardware em uma plataforma bidirecional completa de diagnóstico, permitindo ao desenvolvedor monitorar e interagir com equipamentos em campo de forma robusta e confiável.
Contextualização
O avanço da IoT tem impulsionado o desenvolvimento de sistemas embarcados cada vez mais complexos, exigindo metodologias eficazes para a validação e verificação de firmware. Durante o desenvolvimento, o comportamento do software muitas vezes só pode ser avaliado de forma confiável após longos períodos de operação contínua, o que torna inviável a realização de testes exclusivamente manuais.
Executar checagens experimentais de longa duração apresenta desafios consideráveis, pois pequenas falhas de comunicação ou interrupções na aquisição podem comprometer todo um ensaio. Diante disso, a ausência de mecanismos automáticos de coleta e supervisão dificulta a identificação de falhas intermitentes e anomalias que surgem apenas após horas ou dias de uso.
Os Melhores Treinamentos sobre Sistemas embarcados e IoT
Cursos com professores qualificados para acelerar sua carreira e projetos
Uma Abordagem Focada em Observabilidade
Para solucionar as limitações dos testes de longa duração, uma saída eficiente é introduzir uma ferramenta auxiliar dedicada exclusivamente a observar e registrar o comportamento do dispositivo em teste. Em vez de depender de cabos seriais conectados a um computador no ambiente de campo, é possível empregar um sistema embarcado que atua como data logger e gateway de depuração.
Essa ferramenta captura eventos assíncronos, como mensagens de UART ou mudanças de estado em pinos GPIO, gerados pelo equipamento monitorado, registra esses eventos de forma confiável e os disponibiliza para análise posterior ou em tempo real. Ao adotar uma arquitetura de software modular, baseada no framework ESP-IDF e no sistema operacional de tempo real FreeRTOS, o dispositivo consegue isolar o fluxo principal de aquisição de dados das rotinas de conectividade e configuração.
Hardware Personalizado e a Escolha do ESP32-S3
Para materializar essa ferramenta, o hardware foi desenvolvido especificamente para esse propósito, montado a partir de um esforço coletivo acadêmico. O coração dessa placa é o microcontrolador ESP32-S3FH4R2, uma escolha estratégica devido à sua arquitetura interna e recursos integrados.
Esse chip é uma solução do tipo System-in-Package (SiP), o que significa que ele possui 4 MB de memória Flash e 2 MB de PSRAM integrados ao próprio encapsulamento. Essa alta disponibilidade de memória é um diferencial fundamental para um data logger, pois permite a alocação de buffers extensos para tarefas críticas de captura e processamento de dados concorrentes (como lidar com múltiplas UARTs ativas simultaneamente), dispensando a necessidade de componentes externos de RAM.
Além disso, a conectividade Wi-Fi nativa do chip eliminou a necessidade de módulos de rede externos no layout da placa, mantendo o hardware compacto e otimizado.
Outro grande trunfo de hardware adotado no projeto foi a exploração do subsistema IO/MUX. Esse mecanismo interno do ESP32-S3 permite mapear dinamicamente as funções dos periféricos (como RX/TX da UART ou canais de interrupção GPIO) para quase qualquer pino físico da placa. Na prática, isso confere à ferramenta uma extrema flexibilidade: o usuário pode reconfigurar via software quais bornes da placa atuarão como porta de comunicação serial ou como entrada digital para captura de alarmes, adaptando o hardware a diferentes cenários de teste sem precisar alterar o circuito físico.
Decisões de Arquitetura e o Papel do MQTT
Um dos grandes diferenciais no desenvolvimento de uma ferramenta moderna de depuração é a forma como os dados são extraídos do campo. Para isso, a adoção do protocolo MQTT (Message Queuing Telemetry Transport) foi uma decisão arquitetural central.
O MQTT baseia-se no modelo publish/subscribe (publicador/subscritor), operando excepcionalmente bem sob condições de alta latência. Essa escolha arquitetural permite um desacoplamento completo entre o dispositivo que gera os logs (o data logger) e o cliente remoto que os consome.
Os dados adquiridos são organizados em tópicos hierárquicos distintos (ex: datalogger/1/uart/2), segmentando eventos de diagnóstico e variáveis de processo de forma lógica. Além de publicar eventos, o módulo MQTT da ferramenta permite a assinatura de tópicos de comando (datalogger/cmd/+), possibilitando a atuação remota sobre o hardware, como a reconfiguração de pinos ou o envio de comandos seriais para o equipamento em teste, transformando a ferramenta em um canal bidirecional completo.
Estruturação de Dados para Armazenamento Local Binário
Embora a telemetria via MQTT forneça visibilidade em tempo real, a resiliência do sistema em caso de perda de conexão depende do armazenamento local persistente em um cartão SD via barramento de alta velocidade SDMMC. Para padronizar o registro e garantir máxima eficiência na gravação, foi essencial adotar uma estruturação rigorosa dos dados em linguagem C, salvando os logs no formato binário sequencial.
Criou-se uma estrutura de mensagem única (sd_log_msg_t), composta por um cabeçalho fixo (contendo timestamp de alta resolução em microssegundos e a identificação do periférico) e um bloco de dados dinâmico (union), que muda dependendo se a origem foi a UART ou um pino GPIO.
Para garantir consistência na gravação binária e prever o tamanho exato dos pacotes na memória externa, utilizou-se o atributo __attribute__((packed)). Esse comando instrui o compilador GCC a não inserir bytes de preenchimento (padding) automáticos entre os campos da struct.
#define PACKED __attribute__((packed))
typedef struct PACKED sd_log_hdr_s
{
uint32_t header;
uint64_t time_us;
uint8_t log_type;
uint8_t periph_num;
} sd_log_hdr_t;
typedef struct PACKED sd_log_uart_s
{
uint16_t data_len;
uint8_t data[MAX_UART_PKT];
} sd_log_uart_t;
typedef struct PACKED sd_log_gpio_s
{
uint8_t level;
uint8_t edge;
} sd_log_gpio_t;
typedef struct PACKED sd_log_msg_s
{
sd_log_hdr_t log_header;
union
{
sd_log_uart_t uart;
sd_log_gpio_t gpio;
};
} sd_log_msg_t;Essa abordagem garante uma rastreabilidade completa dos eventos (mesmo em microsegundos) e reduz expressivamente o volume de armazenamento necessário frente a soluções baseadas em gravação de texto (ASCII).
Configuração Dinâmica via Portal Captivo
Em sistemas voltados para a Internet das Coisas, a flexibilidade de adaptação a diferentes ambientes de teste é fundamental. Para evitar a necessidade de recompilar o firmware a cada nova alteração de cenário, a arquitetura do sistema conta com um subsistema independente de configuração e persistência de dados em memória flash interna.
Quando ativado, esse modo levanta um portal captivo (Captive Portal), permitindo que o usuário parametrize o dispositivo diretamente pelo navegador de um smartphone ou computador. As configurações definidas são armazenadas de forma persistente na memória não volátil (NVS) do microcontrolador.
O portal captivo desenvolvido abrange duas frentes principais de configuração:
Portal de Configuração de Rede
O módulo Wi-Fi foi projetado para oferecer resiliência. Durante a inicialização, o sistema busca na memória NVS por credenciais de rede previamente salvas. Caso não encontre uma configuração válida, o dispositivo cria sua própria rede e disponibiliza o portal captivo.
Nessa interface web, o usuário pode atualizar a lista de redes disponíveis, inserir o SSID e a senha, ou simplesmente assinalar a opção de “Modo Offline”. Essa funcionalidade garante que, na ausência de conectividade, a operação principal de data logging local no cartão SD continue funcionando de forma ininterrupta e confiável.
Portal de Configuração de Hardware
O grande diferencial prático da ferramenta reside na sua integração com o subsistema IO/MUX do ESP32-S3 por meio do portal de hardware. Essa interface web permite que o usuário reconfigure dinamicamente as funções dos pinos físicos da placa sem alterar uma única linha de código-fonte.
Pelo portal, o desenvolvedor pode habilitar as instâncias de UART, definir a taxa de transmissão (baud rate), o caractere delimitador de mensagem (‘\0’, NULL, ou ‘\n’, LF) e rotear digitalmente quais pinos atuarão como RX e TX. O mesmo se aplica aos pinos de GPIO, onde é possível habilitar interrupções, definir modos de operação e acionar resistores internos de pull-up ou pull-down. Essa abordagem maximiza a utilidade da ferramenta em laboratório, permitindo que ela se molde perfeitamente a diferentes equipamentos sob teste.
Scripts em Python para Interação e Análise
Uma ferramenta de depuração atinge seu potencial máximo quando é acompanhada de utilitários que facilitam o trabalho do engenheiro. Como complemento ao firmware em C do ESP32-S3, foram desenvolvidas ferramentas de apoio em Python.
Decodificador de Logs Binários (log_processor.py): Por utilizar formato binário visando eficiência, é necessário decodificar os dados contidos no cartão SD para leitura humana. O script lê o arquivo bruto, extrai os cabeçalhos, separa os logs de cada periférico e converte os payloads para texto estruturado e legível, preservando perfeitamente a linha do tempo (timestamps) de todos os eventos.
Monitoramento e Interação via MQTT: Scripts adicionais foram criados para realizar a subscrição e o envio de parâmetros. O script de subscrição permite monitorar no terminal do computador o fluxo de logs despachados pelo datalogger remotamente em tempo real. Já o de interação serve para injetar comandos remotos via publicação de mensagens, o que viabiliza, por exemplo, enviar comandos “AT” para um dispositivo em campo através da UART da ferramenta de diagnóstico.
Ao unir o hardware robusto do ESP32-S3, as práticas modernas de arquitetura baseadas em RTOS e MQTT, e scripts utilitários focados na experiência de validação, esse projeto transforma um microcontrolador em um poderoso aliado no laboratório e no campo. O código-fonte completo (hardware, firmware e scripts de software) está disponível no repositório do GitHub.
