Durante atividades de desenvolvimento e validação em bancada, é bastante comum a necessidade de interagir com o barramento de forma rápida, seja para enviar mensagens específicas, acompanhar frames recebidos ou verificar o comportamento de um nó em teste. Nesses cenários, nem sempre é necessário recorrer, logo de início, a ferramentas profissionais completas. Em muitas situações, uma solução mais simples, acessível e adaptada ao contexto do projeto pode tornar o processo de depuração e integração muito mais ágil.
Foi a partir dessa necessidade que surgiu a proposta deste projeto: desenvolver um scanner para redes CAN (Controller Area Network) com interface web local usando ESP32. No caso do ESP32, o periférico utilizado é denominado TWAI (Two-Wire Automotive Interface), nomenclatura adotada pela Espressif para o controlador compatível com CAN clássico. Ao longo deste artigo, o termo CAN será usado para se referir ao barramento e às mensagens trafegadas, enquanto TWAI será usado ao tratar especificamente do periférico e da camada de firmware do ESP32.
A proposta consistiu em utilizar o próprio microcontrolador não apenas como interface de comunicação com o barramento, mas também como servidor web embarcado, disponibilizando uma interface acessível diretamente pelo navegador. Com isso, tornou-se possível reunir, em uma única solução, transmissão e recepção de frames, consulta de status e aplicação de configurações básicas, sem depender de software adicional no computador.
Ao longo do artigo, serão apresentados a motivação do projeto, a arquitetura adotada, a organização do firmware, os principais endpoints HTTP e os resultados obtidos em bancada. A montagem mostrada na Figura 1 antecipa essa proposta, reunindo o scanner baseado em ESP32 e o sistema sob teste em uma configuração prática para validação de comunicação.
Para quem quiser explorar a implementação completa, o código-fonte e a estrutura do projeto estão disponíveis no repositório publicado no GitHub.
Proposta do projeto
A ideia central do projeto foi transformar o ESP32 em uma ferramenta para interação personalizada com o barramento CAN. Ao iniciar, o dispositivo disponibiliza uma interface web local. A partir dela, é possível enviar frames CAN, visualizar frames recebidos, consultar o estado da interface e alterar parâmetros básicos de operação. Com isso, o fluxo de testes se torna mais direto e reduz a dependência de software adicional instalado no computador ou de aplicativos para smartphones.
O ESP32 é uma plataforma bastante adequada para esse tipo de aplicação porque reúne, em um único dispositivo, controlador TWAI compatível com CAN clássico, conectividade Wi-Fi, capacidade de hospedar um servidor HTTP simples e recursos suficientes para uma interface web embarcada leve. Na prática, isso permite construir uma ferramenta compacta, acessível e fácil de adaptar a diferentes cenários de teste.
Arquitetura da solução
A solução foi organizada em três módulos principais: um módulo de aplicação TWAI para gerenciar comunicação, status, transmissão e recepção de frames; um módulo Wi-Fi para configurar a rede local, colocando o ESP32 em modo Access Point; e um servidor HTTP responsável por entregar a interface web e os endpoints.
O fluxo geral da aplicação pode ser resumido conforme a arquitetura ilustrada na Figura 2. Nela, o navegador acessa a interface web local por meio de requisições HTTP via Wi-Fi, enquanto o ESP32 concentra os módulos de rede, servidor HTTP e lógica da aplicação TWAI. A partir dessa camada, os comandos e leituras são encaminhados ao driver TWAI e, já fora do microcontrolador, ao transceptor CAN, responsável pela interface física com o barramento.
Funcionalidades implementadas
A interface permite montar e transmitir frames manualmente, definindo identificador, formato, tipo de frame, DLC e payload. Isso torna a ferramenta útil para testes controlados de mensagens específicas, sem a necessidade de alterar o firmware a cada nova verificação. A interface de transmissão, ilustrada na Figura 3, permite configurar manualmente os principais campos do frame, tornando a ferramenta útil para simulação de mensagens e testes rápidos de integração.
Também foi implementada a leitura de frames recebidos, permitindo acompanhar o tráfego observado pela interface. Esse recurso ajuda a visualizar rapidamente o comportamento do barramento e a confirmar a recepção das mensagens esperadas. Além disso, o projeto oferece consulta de status e aplicação de configurações em tempo de execução, como baudrate e modo de operação, conforme ilustrado na Figura 5. A interface de recepção, ilustrada na Figura 4, apresenta as mensagens observadas no barramento e complementa a ferramenta com uma visualização simples e direta do tráfego recebido.
Interface web local e uso de IA generativa
Um ponto interessante do projeto foi a interface web local. Para muitos desenvolvedores embarcados, a parte de firmware, protocolo e hardware costuma ser mais familiar do que o desenvolvimento de interfaces em HTML, CSS e JavaScript. Nesse cenário, a IA generativa pode ajudar bastante na construção da camada web, principalmente em tarefas como estruturação inicial da página, organização visual da interface, criação de formulários e ajustes rápidos no JavaScript do frontend.
Ainda assim, o ponto mais importante continua sendo a base técnica da solução. A interface só funciona bem quando existe uma API HTTP clara e bem pensada por trás dela. Assim, embora a IA tenha sido útil para acelerar a parte visual, o núcleo do projeto permaneceu apoiado em conceitos fundamentais para sistemas embarcados conectados, como organização modular do firmware, definição de endpoints, tratamento de requisições HTTP e integração entre interface e aplicação.
Endpoints HTTP
A interface web se comunica com o firmware por meio de endpoints HTTP simples. Essa abordagem mantém a integração entre frontend e aplicação embarcada objetiva, além de facilitar futuras expansões da ferramenta.
No lado do ESP32, cada rota registrada no servidor HTTP está associada a um handler, isto é, uma função responsável por tratar a requisição recebida. Esses handlers fazem a ponte entre a interface web e a camada da aplicação TWAI, validando parâmetros, organizando os dados e chamando as funções internas do firmware.
De forma geral, o projeto utiliza quatro endpoints principais:
POST /api/can/send
recebe os dados de um frame e solicita sua transmissão;POST /api/can/config
recebe os parâmetros de configuração da interface CAN/TWAI;GET /api/can/rx
consulta frames recebidos e os disponibiliza para a interface;GET /api/can/status
retorna o estado atual da interface e da configuração aplicada.
Endpoint de envio de frames
No envio de frames, a interface web envia um JSON com os principais campos necessários para compor a mensagem CAN.
Exemplo de JSON recebido pela API de envio:
{
"id": 256,
"format": "standard",
"type": "data",
"dlc": 8,
"data": [1, 2, 3, 4, 5, 6, 7, 8]
}Esse conteúdo é tratado por um handler no servidor HTTP, responsável por validar o payload, montar a estrutura interna de transmissão e encaminhar a solicitação para a camada TWAI.
/* Handler de envio de frame */
receber requisição HTTP;
montar estrutura de transmissão;
encaminhar para a camada TWAI e responder em JSON;Endpoint de configuração
Para configuração da interface, o fluxo é semelhante. A interface envia os parâmetros desejados, o servidor valida os campos recebidos e repassa a configuração para a camada da aplicação.
Exemplo de JSON recebido pela API de configuração:
{
"baudrate": 500000,
"mode": "normal",
"filter": null,
"mask": null
}No firmware, essa requisição é tratada por um handler específico, responsável por interpretar baudrate, modo de operação e, quando aplicável, filtro e máscara.
/* Handler de configuração da interface */
receber requisição HTTP;
montar estrutura de configuração;
aplicar configuração na camada TWAI e retornar resposta em JSON;Endpoints de leitura
Além das rotas de envio e configuração, a aplicação também disponibiliza endpoints de leitura, usados pela interface web para atualização de dados.
O endpoint de recepção consulta os frames armazenados pela aplicação e os devolve em formato JSON para a interface. Já o endpoint de status retorna informações como modo atual, baudrate, estado da interface e parâmetros ativos de configuração.
/* Handler de leitura de frames RX */
consultar frames recebidos;
montar resposta JSON;
retornar dados para a interface;
/* Handler de leitura de status */
consultar status atual da aplicação;
montar resposta JSON;
retornar estado da interface e configuração;Com essa organização, a camada web permanece simples, enquanto o firmware concentra a lógica de validação, tratamento e acesso ao subsistema TWAI.
Estratégias de implementação
Do lado do firmware, algumas escolhas ajudaram a organizar melhor o projeto: centralização do acesso ao TWAI em um único módulo, desacoplamento entre camada HTTP e camada do driver, manutenção de um status interno para consulta da UI e uso de buffer para frames recebidos. Essas decisões contribuíram para tornar a solução mais estável e mais simples de evoluir.
Validação em bancada
A validação foi realizada em bancada, observando tanto o comportamento da interface quanto o tráfego real no barramento. Essa etapa foi importante para confirmar que o comportamento apresentado na UI correspondia ao que estava efetivamente acontecendo na comunicação.
A observação do barramento em um analisador lógico complementa a validação da interface web, confirmando em nível de sinal e protocolo o comportamento das mensagens transmitidas e recebidas, conforme ilustrado na Figura 6.
Resultados
O projeto se mostrou útil como ferramenta local para testes rápidos de comunicação, envio manual de frames, observação de mensagens recebidas e validação de integração em bancada. A solução não substitui produtos profissionais de análise de barramento, mas atende bem à proposta de uma ferramenta embarcada simples, prática e adaptável para desenvolvimento e validação.
Conclusão
O projeto mostra como o ESP32 pode ser usado não apenas como nó de comunicação, mas também como base para uma ferramenta de apoio ao desenvolvimento embarcado. Ao combinar TWAI, Wi-Fi, HTTP e uma interface web local, tornou-se possível construir uma solução compacta e funcional para testes de bancada. Além disso, o desenvolvimento reforça um ponto importante: mesmo quando a IA generativa acelera a camada web, a qualidade da solução continua dependendo de uma base sólida em arquitetura de firmware e comunicação HTTP.O repositório do projeto permanece disponível no GitHub para consulta da implementação, reprodução dos testes e futuras adaptações da solução.
