Em uma rede doméstica, escolar, industrial ou de laboratório, o endereço IP quase sempre é atribuído automaticamente por DHCP, ou seja, pelo roteador. Hoje o ESP32 pode receber 192.168.0.34; amanhã, depois de reiniciar o roteador, pode receber 192.168.0.51. Isso cria um problema simples, mas muito comum: se eu hospedo uma página web, uma API REST, um painel de configuração ou um serviço TCP dentro do ESP32, como acesso esse serviço sem ficar procurando o IP no monitor serial ou na lista de clientes do roteador?

É aqui que entra o mDNS, sigla para Multicast DNS. Ele permite que dispositivos em uma rede local sejam encontrados por nome, sem depender de um servidor DNS tradicional. Em vez de acessar:

http://192.168.0.34

http://192.168.0.34

podemos acessar algo como:

http://esp32-sensor.local

http://esp32-sensor.local

A documentação oficial da Espressif descreve o mDNS como um serviço UDP multicast usado para descoberta de hosts e serviços na rede local. Ela também destaca que, em versões atuais do ESP-IDF, o componente mDNS foi movido para um repositório separado e pode ser adicionado ao projeto com idf.py add-dependency espressif/mdns. (Espressif Systems)

No contexto de sistemas embarcados, isso é extremamente útil porque evita que o dispositivo precise ter uma interface complexa apenas para informar seu endereço IP. Um sensor ambiental, um controlador de relé, um gateway Modbus, um nó MQTT local ou um pequeno servidor HTTP embarcado podem ser encontrados diretamente por nome. Isso reduz atrito na instalação, melhora a experiência do usuário e facilita testes em bancada.

Em termos de arquitetura embarcada, o mDNS se encaixa como uma camada de descoberta de serviço dentro da comunicação do sistema. Ele não substitui TCP, UDP, HTTP, MQTT ou WebSocket; ele apenas ajuda os outros dispositivos a descobrirem onde determinado serviço está rodando. Essa separação é importante: o mDNS resolve o problema de localização local, enquanto o protocolo da aplicação resolve o problema de troca de dados.

Essa abordagem também conversa bem com boas práticas de projeto embarcado. Em sistemas com poucos recursos, como microcontroladores, normalmente buscamos reduzir dependências manuais, simplificar configuração e tornar o sistema mais robusto em campo. Bruce Powel Douglass destaca que sistemas embarcados costumam operar sob restrições severas de memória, processamento, custo, energia e confiabilidade, o que torna importante escolher soluções arquiteturais que otimizem o sistema sem adicionar complexidade desnecessária.

No caso do ESP32, o uso do mDNS é especialmente interessante porque esse microcontrolador já possui conectividade Wi-Fi integrada e é muito usado em projetos IoT. Em vez de exigir que o usuário descubra o IP do dispositivo, podemos registrar um nome como meu-dispositivo.local e, opcionalmente, anunciar serviços como _http._tcp, _mqtt._tcp ou outro serviço local. Assim, um computador, celular ou outro nó da rede pode encontrar o dispositivo de maneira mais natural.

Portanto, o mDNS não é apenas uma “comodidade”. Ele melhora a implantação, facilita manutenção, reduz erros humanos e torna o produto mais amigável. Em protótipos, ele acelera testes. Em produtos, ele reduz suporte técnico. Em laboratórios, ele permite trabalhar com vários dispositivos sem decorar IPs. Em sistemas distribuídos, ele pode ajudar os nós a se descobrirem localmente sem depender da internet.

The post mDNS no ESP32 — tornando dispositivos IoT fáceis de encontrar na rede local first appeared on MCU & FPGA.

O que é Baud Rate

O termo baud representa a quantidade de símbolos transmitidos por segundo em um canal de comunicação. Em sistemas simples, como UART (Universal Asynchronous Receiver/Transmitter), cada símbolo geralmente corresponde a um bit, e por isso, na prática, baud rate costuma ser tratado como equivalente a bits por segundo (bps).

No entanto, tecnicamente, eles não são sempre iguais. Em sistemas mais complexos (como modulações QAM), um único símbolo pode carregar múltiplos bits. Mas no contexto mais comum em microcontroladores — como STM32, ESP32 ou RP2040 — temos:

1 baud ≈ 1 bit por segundo

Origem do termo

O nome baud vem de Émile Baudot, engenheiro francês que desenvolveu um dos primeiros sistemas de telegrafia digital no século XIX. Seu sistema utilizava códigos binários para transmitir caracteres, sendo um dos precursores diretos da comunicação digital moderna.

Na época, a preocupação principal era sincronizar transmissor e receptor em meios físicos limitados, como linhas telegráficas. Essa limitação influenciou diretamente as primeiras taxas padronizadas que ainda vemos hoje.

Como o Baud Rate é utilizado na prática

Em sistemas modernos, especialmente embarcados, o baud rate é fundamental em protocolos como:

• UART (comunicação serial clássica)
• RS-232, RS-485 (ambientes industriais)
• Comunicação com módulos (GPS, GSM, Bluetooth)
• Bootloaders e debug via terminal serial

Cada taxa define quanto tempo dura cada bit, o que impacta diretamente:

• sincronização entre dispositivos
• tolerância a ruído
• distância da comunicação
• consumo de energia

Por exemplo, em 9600 baud, cada bit dura aproximadamente 104 µs, enquanto em 115200 baud, dura apenas 8.68 µs, exigindo maior precisão de clock.

Entendendo a diferença entre velocidade teórica e real

Na tabela fornecida, aparecem dois valores importantes:

• Speed (bytes/s) → taxa teórica considerando 8 bits por byte
• Actual speed (bytes/s) → taxa real considerando overhead da UART

Esse overhead vem do formato típico de transmissão:

1 bit de start + 8 bits de dados + 1 bit de stop = 10 bits por byte

Ou seja:

A eficiência real é de aproximadamente 80% (8/10)

Tabela de Baud Rates

Abaixo está a tabela organizada com os dados fornecidos:

Velocidades mais usadas e seus contextos

Na prática, algumas taxas se tornaram padrão de mercado:

9600 baud
Muito utilizado em sistemas legados, sensores simples e comunicação robusta em ambientes com ruído. Ideal quando confiabilidade é mais importante que velocidade.

19200 e 38400 baud
Utilizados em sistemas industriais e automação, oferecendo bom equilíbrio entre velocidade e estabilidade.

57600 baud
Comum em comunicação com módulos embarcados intermediários (GPS, modems antigos).

115200 baud
O padrão mais usado atualmente para debug serial, comunicação com PCs e bootloaders. É rápido o suficiente para logs e transferência moderada de dados.

230400 a 921600 baud
Usados em aplicações mais exigentes, como:

• streaming de dados de sensores
• comunicação com displays
• transferência de arquivos
• aplicações IoT de maior throughput

Porém, nessas velocidades, entram desafios importantes:

• precisão do clock (erro percentual)
• interferência eletromagnética
• qualidade do layout de PCB

Considerações de Engenharia

Ao escolher o baud rate em um projeto embarcado, você deve considerar:

• Clock do sistema: erros de divisão podem gerar falhas de sincronização
• Comprimento do cabo: quanto maior, menor deve ser a taxa
• Ambiente: ruído industrial exige taxas menores
• Buffer e DMA: taxas altas exigem melhor gestão de dados

Uma decisão errada aqui pode gerar desde perda de dados até travamentos intermitentes difíceis de depurar.

The post Baud Rate: o que é, origem, tabela completa e como escolher a taxa ideal na comunicação serial first appeared on MCU & FPGA.

A combinação do FreeRTOS com a pilha de rede lwIP (Lightweight IP) é hoje uma das arquiteturas mais comuns em sistemas embarcados conectados, especialmente em microcontroladores Cortex-M (STM32, NXP, RP2040 com stack externa, ESP32 quando abstraído), onde há restrição severa de memória, tempo real e consumo energético. O FreeRTOS fornece o modelo concorrente determinístico (tarefas, prioridades, sincronização), enquanto o lwIP entrega uma implementação enxuta da pilha TCP/IP, compatível com IPv4, IPv6, TCP, UDP, ICMP, ARP, DHCP, DNS e HTTP, entre outros protocolos.

O ponto crítico — e frequentemente negligenciado — é que o lwIP não é apenas uma biblioteca de rede, mas sim um framework cooperativo que precisa ser corretamente integrado ao modelo de execução do RTOS. Dependendo da configuração (RAW API, Netconn API ou BSD Sockets API), o lwIP pode operar de forma event-driven, thread-safe ou thread-aware, exigindo decisões arquiteturais bem fundamentadas. Uma escolha inadequada costuma resultar em deadlocks, stack overflow, perda de pacotes, latências imprevisíveis ou até hard faults difíceis de diagnosticar.

Em sistemas com FreeRTOS, o lwIP normalmente é encapsulado em uma ou mais tarefas dedicadas, além de callbacks executados a partir de interrupções (ETH IRQ, DMA RX/TX) ou timers de software. Isso cria um ambiente híbrido onde código de interrupção, tarefas e a pilha TCP/IP precisam cooperar com rigor: uso correto de semáforos, mutexes, mailboxes (queues), buffers e prioridades. O entendimento dessa interação é essencial para construir aplicações robustas como servidores HTTP, MQTT brokers/clients, WebSockets, OTA, Modbus/TCP, Profinet sobre TCP/IP, entre outras.

Nesta série de artigos, este material assume um cenário típico e realista:

• FreeRTOS rodando como sistema operacional principal
• lwIP configurado com TCP/IP thread dedicada
• Interface Ethernet (MAC + PHY) ou driver de rede equivalente
• Comunicação entre tarefas da aplicação e a pilha de rede
• Ênfase em boas práticas, arquitetura correta e exemplos práticos em C

Nas próximas seções, vamos avançar progressivamente, começando pela arquitetura interna do lwIP quando integrado ao FreeRTOS, passando pelas formas de integração (RAW, Netconn e Sockets), até chegar a exemplos completos como servidor HTTP, cliente TCP e sincronização entre tarefas da aplicação e a pilha de rede.

Arquitetura do lwIP em sistemas com FreeRTOS

Quando o lwIP é integrado a um sistema com FreeRTOS, ele deixa de ser apenas uma pilha TCP/IP “passiva” e passa a fazer parte ativa do modelo concorrente do sistema. O ponto central dessa arquitetura é a chamada TCP/IP thread (normalmente criada por tcpip_init()), que se torna o contexto exclusivo e soberano para quase todas as operações internas do lwIP. Isso significa que estruturas críticas como PCB (Protocol Control Blocks), buffers pbuf, timers TCP e estados de conexão não são thread-safe por padrão e devem ser manipulados apenas dentro desse contexto controlado.

Na prática, o lwIP organiza seu funcionamento em três grandes domínios de execução: interrupções de hardware, TCP/IP thread e tarefas da aplicação. As interrupções normalmente vêm do driver Ethernet (IRQ do MAC ou DMA RX/TX), cujo papel é mínimo: sinalizar que há pacotes recebidos ou buffers liberados, evitando qualquer processamento pesado. Essas interrupções acordam a TCP/IP thread por meio de semaphores ou mailboxes, garantindo que todo o processamento de protocolos ocorra fora do contexto de ISR, preservando determinismo e estabilidade do sistema.

A TCP/IP thread funciona como um dispatcher de eventos de rede. Ela processa pacotes recebidos, executa timers periódicos (TCP retransmission, ARP aging, DHCP renewal), gerencia conexões e chama callbacks registrados pela aplicação. É aqui que reside uma armadilha comum: callbacks do lwIP não executam no contexto da task da aplicação, mas sim dentro da TCP/IP thread. Isso exige extremo cuidado ao acessar recursos compartilhados, como filas do FreeRTOS, buffers globais ou drivers de periféricos, sob pena de criar condições de corrida difíceis de rastrear.

As tarefas da aplicação, por sua vez, nunca devem acessar diretamente estruturas internas do lwIP, exceto quando se utiliza APIs explicitamente thread-safe (como Netconn ou Sockets). Quando a arquitetura é bem desenhada, as tasks da aplicação se comunicam com a TCP/IP thread usando mensagens, filas ou chamadas assíncronas, mantendo uma separação clara entre lógica de negócio e infraestrutura de rede. Esse desacoplamento é um dos fatores-chave para escalabilidade e manutenibilidade do firmware.

Do ponto de vista conceitual, pense no lwIP como um ator central que serializa todo o tráfego de rede, enquanto o FreeRTOS fornece o orquestrador de concorrência ao redor dele. Quando esse modelo é respeitado, o sistema se comporta de forma previsível mesmo sob carga elevada de rede. Quando é violado — por exemplo, chamando funções RAW do lwIP a partir de tasks arbitrárias — os sintomas surgem como bugs intermitentes, travamentos aleatórios ou degradação severa de desempenho.

Na próxima seção, vamos entrar em um dos pontos mais críticos e confusos para quem trabalha com lwIP:
as três APIs disponíveis (RAW API, Netconn API e BSD Sockets API), explicando quando usar cada uma, suas vantagens, limitações e impactos diretos na arquitetura FreeRTOS.

As APIs do lwIP no contexto do FreeRTOS: RAW, Netconn e Sockets

Um dos pontos que mais geram confusão — e erros arquiteturais — no uso do lwIP com FreeRTOS é a existência de três APIs distintas, cada uma com modelos mentais, custos e implicações completamente diferentes. A escolha da API não é apenas uma questão de preferência sintática; ela define como as tasks interagem com a pilha TCP/IP, quais garantias de thread-safety existem e qual será o impacto em latência, uso de memória e complexidade do sistema.

A RAW API é a forma mais direta e eficiente de usar o lwIP. Ela é totalmente event-driven, baseada em callbacks, e opera exclusivamente no contexto da TCP/IP thread. Não existe bloqueio, não existem semáforos implícitos, nem cópia adicional de buffers. Cada evento de rede — conexão estabelecida, dados recebidos, erro ou fechamento — dispara uma função de callback registrada previamente. Isso torna a RAW API ideal para sistemas com restrições severas de RAM e tempo real rígido, mas ao custo de maior complexidade cognitiva. Em sistemas FreeRTOS, a RAW API não deve ser chamada diretamente a partir de tasks da aplicação; qualquer interação precisa ser mediada por mensagens ou funções como tcpip_callback().

Já a Netconn API atua como uma camada intermediária entre a RAW API e o modelo tradicional de threads. Ela encapsula a lógica baseada em callbacks dentro de uma API bloqueante e thread-safe, usando mailboxes e semaphores internos. Para o desenvolvedor FreeRTOS, isso significa poder escrever código sequencial — netconn_accept(), netconn_recv(), netconn_write() — dentro de uma task, sem violar as regras internas do lwIP. O custo disso é um pequeno aumento de consumo de memória e latência, além de menos controle fino sobre eventos de baixo nível. Em projetos industriais, a Netconn API costuma ser um equilíbrio muito saudável entre robustez e simplicidade.

A BSD Sockets API, por sua vez, é a mais familiar para quem vem do mundo Linux ou POSIX. Ela oferece funções como socket(), bind(), listen(), accept(), recv() e send(), com semântica muito próxima à de sistemas operacionais completos. Internamente, ela é construída sobre a Netconn API, herdando suas características e custos. Em FreeRTOS, a Sockets API facilita a portabilidade de código legado e acelera o desenvolvimento inicial, mas frequentemente induz a arquiteturas pobres, com tasks bloqueantes demais, pilha grande e baixa previsibilidade temporal se não for bem planejada.

A decisão correta normalmente segue este raciocínio: se o sistema é altamente restrito e orientado a eventos, use RAW API; se precisa de clareza, robustez e integração limpa com FreeRTOS, use Netconn; se o foco é portabilidade e velocidade de desenvolvimento, a Sockets API pode ser aceitável — desde que o impacto em recursos seja cuidadosamente controlado. Em sistemas críticos, misturar APIs sem critério é uma receita certa para problemas difíceis de depurar.

Na próxima seção, vamos aprofundar exatamente como o FreeRTOS e o lwIP se comunicam internamente, explorando mailboxes, semaphores, timers e a função tcpip_init(), com diagramas conceituais e exemplos práticos em C.

Integração interna entre FreeRTOS e lwIP: mailboxes, semáforos e tcpip_init()

A espinha dorsal da integração entre FreeRTOS e lwIP é o mecanismo de mensagens assíncronas que garante que todo o processamento da pilha TCP/IP ocorra em um único contexto controlado. Esse contexto é criado pela chamada a tcpip_init(), responsável por inicializar o lwIP e criar a TCP/IP thread, além de suas estruturas de sincronização internas. Entender exatamente o que acontece aqui é essencial para evitar violações de thread-safety e erros sutis de concorrência.

Quando tcpip_init() é chamada, o lwIP cria internamente uma task do FreeRTOS (normalmente chamada de tcpip_thread) e associa a ela uma mailbox principal. Essa mailbox funciona como uma fila de mensagens do RTOS, por onde chegam eventos como pacotes recebidos, timers expirados ou callbacks solicitados por outras tasks. O modelo é deliberadamente serial: a TCP/IP thread processa uma mensagem por vez, garantindo que as estruturas internas do lwIP nunca sejam acessadas concorrentemente.

As interrupções de rede (por exemplo, RX DMA do Ethernet MAC) não processam protocolos diretamente. Em vez disso, elas apenas notificam o sistema — geralmente liberando um semáforo ou enviando um ponteiro de buffer para uma mailbox. O driver Ethernet, então, acorda a TCP/IP thread, que passa a processar os pacotes no contexto correto. Esse desenho é fundamental para manter latência previsível e evitar execução de código pesado em ISR, algo especialmente crítico em sistemas com FreeRTOS.

Para permitir que tasks da aplicação interajam com o lwIP sem violar esse modelo, o lwIP fornece funções como tcpip_callback() e tcpip_try_callback(). Essas funções permitem que uma task qualquer solicite a execução de uma função dentro da TCP/IP thread, de forma assíncrona. Esse padrão é a base de arquiteturas seguras quando se utiliza a RAW API, pois impede acessos diretos às estruturas internas da pilha a partir de múltiplos contextos.

A Netconn e a Sockets API se apoiam nesse mesmo mecanismo, mas encapsulam toda essa complexidade. Quando uma task chama netconn_recv(), por exemplo, o que acontece por baixo dos panos é um diálogo entre mailboxes internas, semáforos e a TCP/IP thread. A task da aplicação fica bloqueada de forma controlada, enquanto o lwIP continua operando normalmente. Isso explica por que essas APIs são thread-safe, mas também por que consomem mais RAM e stack.

Um erro clássico em projetos é tentar “otimizar” esse fluxo acessando diretamente buffers, chamando funções RAW a partir de tasks comuns ou usando mutexes do FreeRTOS para proteger estruturas do lwIP. Essa abordagem não funciona e quebra premissas internas do stack. O modelo correto não é proteger o lwIP com mutexes, mas respeitar o confinamento de contexto imposto pela TCP/IP thread.

Na próxima seção, vamos aplicar esses conceitos de forma concreta, construindo um exemplo prático de inicialização do lwIP com FreeRTOS, incluindo criação de tarefas, configuração do driver Ethernet e verificação do fluxo de dados.

Exemplo prático: inicialização do lwIP em um sistema FreeRTOS

Nesta seção vamos sair do plano conceitual e entrar no código real, mostrando como um sistema típico FreeRTOS + lwIP é inicializado. O objetivo aqui não é apenas “fazer funcionar”, mas entender por que cada passo existe, qual o contexto de execução envolvido e quais são os erros clássicos que devem ser evitados.

Assumiremos um cenário bastante comum em projetos industriais:

• FreeRTOS já inicializado
• Interface Ethernet com driver próprio (MAC + PHY)
• lwIP configurado para uso com TCP/IP thread dedicada
• Uso futuro de Netconn ou Sockets API

5.1 Ordem correta de inicialização

A ordem de inicialização é crítica. Um erro frequente é criar tasks de aplicação que usam rede antes do lwIP estar totalmente operacional.

A sequência correta, em alto nível, é:

1. Inicializar hardware básico (clock, GPIO, PHY, MAC)
2. Inicializar o lwIP (tcpip_init)
3. Configurar interface de rede (netif)
4. Subir a interface (netif_set_up)
5. Só então criar tasks da aplicação que usam rede
6. Iniciar o scheduler do FreeRTOS

Essa ordem garante que nenhuma task tente acessar a pilha TCP/IP fora do contexto correto.

5.2 Inicializando o lwIP (tcpip_init)

O primeiro ponto de integração direta entre FreeRTOS e lwIP é a chamada a tcpip_init():

#include "lwip/tcpip.h"

static void lwip_init_done(void *arg)
{
    /* Callback chamado quando a TCP/IP thread está pronta */
    (void)arg;
}

void lwip_stack_init(void)
{
    tcpip_init(lwip_init_done, NULL);
}

#include "lwip/tcpip.h"

static void lwip_init_done(void *arg)
{
    /* Callback chamado quando a TCP/IP thread está pronta */
    (void)arg;
}

void lwip_stack_init(void)
{
    tcpip_init(lwip_init_done, NULL);
}

O que acontece aqui, de fato:

• O lwIP cria internamente a TCP/IP thread como uma task do FreeRTOS
• São criadas mailboxes internas para troca de mensagens
• Timers internos do TCP/IP são registrados
• O callback lwip_init_done() é executado no contexto da TCP/IP thread, não na task chamadora

Esse detalhe é importante: qualquer código executado nesse callback já está em um contexto seguro para chamadas RAW, caso necessário.

5.3 Configuração da interface de rede (netif)

Após a inicialização do lwIP, precisamos registrar a interface de rede:

#include "lwip/netif.h"
#include "lwip/ip_addr.h"
#include "lwip/dhcp.h"

static struct netif netif_eth;

void netif_config(void)
{
    ip4_addr_t ipaddr;
    ip4_addr_t netmask;
    ip4_addr_t gw;

    IP4_ADDR(&ipaddr, 0, 0, 0, 0);   /* DHCP */
    IP4_ADDR(&netmask, 0, 0, 0, 0);
    IP4_ADDR(&gw, 0, 0, 0, 0);

    netif_add(&netif_eth,
              &ipaddr,
              &netmask,
              &gw,
              NULL,
              ethernetif_init,
              tcpip_input);

    netif_set_default(&netif_eth);
    netif_set_up(&netif_eth);

    dhcp_start(&netif_eth);
}

#include "lwip/netif.h"
#include "lwip/ip_addr.h"
#include "lwip/dhcp.h"

static struct netif netif_eth;

void netif_config(void)
{
    ip4_addr_t ipaddr;
    ip4_addr_t netmask;
    ip4_addr_t gw;

    IP4_ADDR(&ipaddr, 0, 0, 0, 0);   /* DHCP */
    IP4_ADDR(&netmask, 0, 0, 0, 0);
    IP4_ADDR(&gw, 0, 0, 0, 0);

    netif_add(&netif_eth,
              &ipaddr,
              &netmask,
              &gw,
              NULL,
              ethernetif_init,
              tcpip_input);

    netif_set_default(&netif_eth);
    netif_set_up(&netif_eth);

    dhcp_start(&netif_eth);
}

Aqui aparecem alguns pontos arquiteturais importantes:

• ethernetif_init é o driver de baixo nível, responsável por integrar MAC/PHY ao lwIP
• tcpip_input garante que pacotes recebidos sejam entregues à TCP/IP thread, e não processados no contexto errado
• O uso de DHCP é opcional, mas comum em sistemas conectados

Essa função normalmente é chamada após tcpip_init() e antes da criação das tasks de aplicação.

5.4 Criação das tasks da aplicação

Somente depois que a pilha está pronta é que criamos tasks que usam rede:

void network_task(void *argument)
{
    /* A partir daqui, é seguro usar Netconn ou Sockets API */
    for (;;)
    {
        /* Lógica de rede */
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_start(void)
{
    xTaskCreate(network_task,
                "NetTask",
                1024,
                NULL,
                tskIDLE_PRIORITY + 2,
                NULL);
}

void network_task(void *argument)
{
    /* A partir daqui, é seguro usar Netconn ou Sockets API */
    for (;;)
    {
        /* Lógica de rede */
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_start(void)
{
    xTaskCreate(network_task,
                "NetTask",
                1024,
                NULL,
                tskIDLE_PRIORITY + 2,
                NULL);
}

Note que:

• A task não interage diretamente com estruturas RAW
• O tamanho da stack já precisa considerar buffers de rede
• A prioridade deve ser pensada em conjunto com a TCP/IP thread

Um erro comum é dar prioridade muito baixa para a TCP/IP thread e alta para tasks de aplicação, o que resulta em timeouts, perda de pacotes e conexões instáveis.

5.5 Erros clássicos nesta fase

Alguns problemas recorrentes que surgem exatamente nesse ponto:

• Criar sockets antes do netif_set_up
• Chamar funções RAW a partir de tasks comuns
• Executar processamento pesado no driver Ethernet (ISR)
• Stack insuficiente para tasks de rede
• Prioridade inadequada da TCP/IP thread

Todos esses erros levam a sintomas difíceis de diagnosticar, como travamentos aleatórios ou falhas intermitentes de comunicação.

Na próxima seção, vamos construir um exemplo completo de servidor TCP/HTTP, mostrando como uma task FreeRTOS usa a Netconn ou Sockets API corretamente, com explicação detalhada de cada chamada.

Exemplo completo: servidor TCP usando Sockets API em uma task FreeRTOS

Aqui vamos montar um servidor TCP simples (estilo “echo server” + base para HTTP) rodando em uma task do FreeRTOS usando a BSD Sockets API do lwIP. A ideia é te dar um esqueleto real que funciona em 80% dos firmwares conectados: uma task aceita conexões, recebe dados, responde e fecha. Em seguida, vou apontar onde normalmente você evolui para HTTP, MQTT, Modbus/TCP etc.

6.1 Requisitos e premissas

Para usar Sockets no lwIP você normalmente precisa ter (no lwipopts.h):

• LWIP_SOCKET=1
• LWIP_NETCONN=1 (sockets geralmente dependem dela)
• LWIP_TCP=1
• LWIP_DNS=1 (se quiser resolver nomes)
• LWIP_DHCP=1 (se usar DHCP)

E lembrar do modelo: a task de sockets é sua, mas o lwIP continua processando rede na TCP/IP thread.

6.2 Código do servidor TCP (com comentários didáticos)

#include "FreeRTOS.h"
#include "task.h"

#include "lwip/sockets.h"
#include "lwip/inet.h"
#include <string.h>
#include <stdio.h>

/* Ajuste conforme sua aplicação */
#define SERVER_PORT     5000
#define RX_BUF_SIZE     1024
#define LISTEN_BACKLOG  4

static void tcp_server_task(void *arg)
{
    (void)arg;

    int listen_fd = -1;
    int client_fd = -1;

    struct sockaddr_in addr;
    struct sockaddr_in client_addr;
    socklen_t client_len = sizeof(client_addr);

    /* Buffer local: cuidado com stack! */
    char rx_buf[RX_BUF_SIZE];

    /* 1) Criar socket TCP */
    listen_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (listen_fd < 0) {
        /* Em sistemas embarcados: logue e reinicie a task ou sinalize falha */
        vTaskDelete(NULL);
    }

    /* 2) Preencher estrutura de endereço */
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(SERVER_PORT);
    addr.sin_addr.s_addr = htonl(INADDR_ANY); /* escuta em todas interfaces */

    /* 3) Bind: amarra o socket à porta */
    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    /* 4) Listen: coloca em modo servidor */
    if (listen(listen_fd, LISTEN_BACKLOG) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    for (;;)
    {
        /* 5) Accept: bloqueia esperando cliente */
        client_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_len);
        if (client_fd < 0) {
            /* Se accept falhar, normalmente você continua tentando */
            vTaskDelay(pdMS_TO_TICKS(100));
            continue;
        }

        /* 6) Loop de recepção */
        for (;;)
        {
            int n = recv(client_fd, rx_buf, sizeof(rx_buf) - 1, 0);
            if (n <= 0) {
                /* n == 0 -> cliente fechou; n < 0 -> erro */
                break;
            }

            rx_buf[n] = '\0';

            /* 7) Aqui entra a lógica da aplicação.
                  Para um echo server: devolve os bytes recebidos. */
            send(client_fd, rx_buf, n, 0);

            /* Exemplo: se quiser encerrar ao receber "quit" */
            if (strncmp(rx_buf, "quit", 4) == 0) {
                break;
            }
        }

        /* 8) Fecha conexão do cliente */
        closesocket(client_fd);
        client_fd = -1;
    }
}

/* Função de arranque */
void start_tcp_server(void)
{
    /* Stack precisa ser dimensionada: sockets + buffer local */
    xTaskCreate(tcp_server_task,
                "TCPServer",
                2048,                  /* ajuste real conforme seu MCU/heap */
                NULL,
                tskIDLE_PRIORITY + 2,  /* prioridade média */
                NULL);
}

#include "FreeRTOS.h"
#include "task.h"

#include "lwip/sockets.h"
#include "lwip/inet.h"
#include <string.h>
#include <stdio.h>

/* Ajuste conforme sua aplicação */
#define SERVER_PORT     5000
#define RX_BUF_SIZE     1024
#define LISTEN_BACKLOG  4

static void tcp_server_task(void *arg)
{
    (void)arg;

    int listen_fd = -1;
    int client_fd = -1;

    struct sockaddr_in addr;
    struct sockaddr_in client_addr;
    socklen_t client_len = sizeof(client_addr);

    /* Buffer local: cuidado com stack! */
    char rx_buf[RX_BUF_SIZE];

    /* 1) Criar socket TCP */
    listen_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (listen_fd < 0) {
        /* Em sistemas embarcados: logue e reinicie a task ou sinalize falha */
        vTaskDelete(NULL);
    }

    /* 2) Preencher estrutura de endereço */
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(SERVER_PORT);
    addr.sin_addr.s_addr = htonl(INADDR_ANY); /* escuta em todas interfaces */

    /* 3) Bind: amarra o socket à porta */
    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    /* 4) Listen: coloca em modo servidor */
    if (listen(listen_fd, LISTEN_BACKLOG) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    for (;;)
    {
        /* 5) Accept: bloqueia esperando cliente */
        client_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_len);
        if (client_fd < 0) {
            /* Se accept falhar, normalmente você continua tentando */
            vTaskDelay(pdMS_TO_TICKS(100));
            continue;
        }

        /* 6) Loop de recepção */
        for (;;)
        {
            int n = recv(client_fd, rx_buf, sizeof(rx_buf) - 1, 0);
            if (n <= 0) {
                /* n == 0 -> cliente fechou; n < 0 -> erro */
                break;
            }

            rx_buf[n] = '\0';

            /* 7) Aqui entra a lógica da aplicação.
                  Para um echo server: devolve os bytes recebidos. */
            send(client_fd, rx_buf, n, 0);

            /* Exemplo: se quiser encerrar ao receber "quit" */
            if (strncmp(rx_buf, "quit", 4) == 0) {
                break;
            }
        }

        /* 8) Fecha conexão do cliente */
        closesocket(client_fd);
        client_fd = -1;
    }
}

/* Função de arranque */
void start_tcp_server(void)
{
    /* Stack precisa ser dimensionada: sockets + buffer local */
    xTaskCreate(tcp_server_task,
                "TCPServer",
                2048,                  /* ajuste real conforme seu MCU/heap */
                NULL,
                tskIDLE_PRIORITY + 2,  /* prioridade média */
                NULL);
}

6.3 Pontos críticos (onde a maioria erra)

A primeira armadilha é stack. Repare que rx_buf[1024] está na stack da task. Em Cortex-M, 2 KB de stack pode ficar apertado se você começar a montar respostas HTTP grandes, fazer parsing pesado ou usar printf. Uma prática robusta é mover buffers grandes para heap/estático e deixar stack para variáveis pequenas.

A segunda armadilha é bloqueio infinito. accept() e recv() bloqueiam. Isso pode ser OK em um servidor dedicado, mas se você precisa de shutdown limpo, watchdog cooperativo ou multiplexar atividades, você vai querer timeouts via setsockopt() com SO_RCVTIMEO e SO_SNDTIMEO, ou usar select() para multiplexar.

A terceira armadilha é “fazer tudo nessa task”. Em firmware sério, o servidor de sockets vira um front-end que entrega payloads para outras tasks via queues (produtor/consumidor), mantendo o servidor leve e previsível. Caso contrário, você mistura rede + lógica de negócio + acesso a periféricos no mesmo contexto e cria latência ruim e travamentos em cascata.

6.4 Melhorando com timeouts (essencial para robustez)

Um exemplo direto para evitar travar em recv():

struct timeval tv;
tv.tv_sec = 5;
tv.tv_usec = 0;
setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

struct timeval tv;
tv.tv_sec = 5;
tv.tv_usec = 0;
setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

Com isso, recv() retorna erro após 5 s sem dados, e você pode encerrar a conexão ou apenas continuar.

Na próxima seção, vamos fazer exatamente o que transforma esse exemplo em arquitetura “de produção”:

• Task de sockets como Gatekeeper
• Entrega de dados para uma fila FreeRTOS
• Um ou mais consumidores processando requisições
• Resposta retornando ao cliente de forma segura

Arquitetura de produção: servidor de sockets como Gatekeeper + filas FreeRTOS (produtor/consumidor)

Quando você coloca lwIP + FreeRTOS em um produto real, a pergunta não é “como abrir um socket”, mas sim: como garantir previsibilidade, isolamento de falhas e escalabilidade quando há múltiplas conexões, parsing de protocolo, acesso a periféricos e regras de negócio rodando ao mesmo tempo. O padrão mais sólido aqui é tratar a task de rede como um Gatekeeper (porteiro): ela faz o mínimo necessário (I/O de rede e framing básico), empacota mensagens e entrega para a aplicação via Queue. As tasks de aplicação, por sua vez, consomem essas mensagens e devolvem respostas por um caminho igualmente controlado.

A razão técnica é simples: a pilha de rede precisa de tempo de CPU para manter conexões (ACKs, retransmissões, janelas TCP), e isso pode ser prejudicado se você faz parsing pesado, acesso a flash, escrita em SD, controle de motores ou logs complexos dentro da mesma task que está segurando o socket. Além disso, erros na lógica de negócio não podem derrubar a infraestrutura de rede. Com Gatekeeper + filas, você desacopla os domínios: rede continua estável, aplicação pode reiniciar tasks de processamento, e o sistema ganha uma arquitetura “defensiva”.

A seguir, vamos montar um exemplo funcional e didático. Ele não é “o menor possível”: ele é “o mais correto possível” para firmware.

7.1 Estruturas de mensagem e filas

Vamos definir duas filas:

• rxQueue: mensagens recebidas da rede para a aplicação
• txQueue: respostas da aplicação para serem transmitidas pela task de rede

Cada mensagem precisa carregar, no mínimo:

• identificador da conexão (socket do cliente ou um handle abstrato)
• payload (bytes recebidos)
• tamanho
• metadados (opcional: IP/porta, timestamp etc.)

#include "FreeRTOS.h"
#include "queue.h"
#include <stdint.h>

#define MAX_PAYLOAD 512

typedef struct
{
    int client_fd;                 /* Identifica a conexão */
    uint16_t len;
    uint8_t payload[MAX_PAYLOAD];  /* Mensagem "copiada" para trânsito seguro */
} NetMessage_t;

static QueueHandle_t rxQueue;
static QueueHandle_t txQueue;

void net_queues_init(void)
{
    rxQueue = xQueueCreate(8, sizeof(NetMessage_t));
    txQueue = xQueueCreate(8, sizeof(NetMessage_t));
}

#include "FreeRTOS.h"
#include "queue.h"
#include <stdint.h>

#define MAX_PAYLOAD 512

typedef struct
{
    int client_fd;                 /* Identifica a conexão */
    uint16_t len;
    uint8_t payload[MAX_PAYLOAD];  /* Mensagem "copiada" para trânsito seguro */
} NetMessage_t;

static QueueHandle_t rxQueue;
static QueueHandle_t txQueue;

void net_queues_init(void)
{
    rxQueue = xQueueCreate(8, sizeof(NetMessage_t));
    txQueue = xQueueCreate(8, sizeof(NetMessage_t));
}

Observação crítica: aqui estamos usando cópia de payload. Em sistemas mais exigentes, você pode migrar para zero-copy com pbuf (RAW API) ou pool de buffers. Mas começar com cópia é geralmente a forma mais estável de construir algo robusto e debugar rápido.

7.2 Task Gatekeeper: recebe do socket e entrega na rxQueue

A task de rede agora vira uma “central de I/O”: aceita conexões, recebe dados e empacota mensagens para a fila.

#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"

#include "lwip/sockets.h"
#include "lwip/inet.h"
#include <string.h>

#define SERVER_PORT 5000

static void socket_gatekeeper_task(void *arg)
{
    (void)arg;

    int listen_fd;
    struct sockaddr_in addr;

    listen_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (listen_fd < 0) vTaskDelete(NULL);

    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(SERVER_PORT);
    addr.sin_addr.s_addr = htonl(INADDR_ANY);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    if (listen(listen_fd, 4) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    for (;;)
    {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd < 0) {
            vTaskDelay(pdMS_TO_TICKS(50));
            continue;
        }

        /* Exemplo simples: atende 1 cliente por vez.
           Em produção você pode criar uma task por cliente OU usar select(). */
        for (;;)
        {
            NetMessage_t msg;
            int n = recv(client_fd, msg.payload, MAX_PAYLOAD, 0);
            if (n <= 0) break;

            msg.client_fd = client_fd;
            msg.len = (uint16_t)n;

            /* Entrega para aplicação: se a fila estiver cheia, você precisa decidir política:
               - descartar
               - bloquear por tempo limitado
               - desconectar cliente
            */
            if (xQueueSend(rxQueue, &msg, pdMS_TO_TICKS(20)) != pdPASS) {
                /* Política simples: descarta e segue */
            }

            /* Antes de receber mais, veja se há resposta pronta para este cliente */
            NetMessage_t out;
            if (xQueueReceive(txQueue, &out, 0) == pdPASS) {
                if (out.client_fd == client_fd && out.len > 0) {
                    send(client_fd, out.payload, out.len, 0);
                } else {
                    /* Se veio resposta de outro cliente, em produção você
                       rotearia corretamente (mapa de conexões, etc.) */
                }
            }
        }

        closesocket(client_fd);
    }
}

void start_socket_gatekeeper(void)
{
    xTaskCreate(socket_gatekeeper_task,
                "NetGate",
                2048,
                NULL,
                tskIDLE_PRIORITY + 3, /* Um pouco acima da aplicação */
                NULL);
}

#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"

#include "lwip/sockets.h"
#include "lwip/inet.h"
#include <string.h>

#define SERVER_PORT 5000

static void socket_gatekeeper_task(void *arg)
{
    (void)arg;

    int listen_fd;
    struct sockaddr_in addr;

    listen_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (listen_fd < 0) vTaskDelete(NULL);

    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(SERVER_PORT);
    addr.sin_addr.s_addr = htonl(INADDR_ANY);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    if (listen(listen_fd, 4) < 0) {
        closesocket(listen_fd);
        vTaskDelete(NULL);
    }

    for (;;)
    {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd < 0) {
            vTaskDelay(pdMS_TO_TICKS(50));
            continue;
        }

        /* Exemplo simples: atende 1 cliente por vez.
           Em produção você pode criar uma task por cliente OU usar select(). */
        for (;;)
        {
            NetMessage_t msg;
            int n = recv(client_fd, msg.payload, MAX_PAYLOAD, 0);
            if (n <= 0) break;

            msg.client_fd = client_fd;
            msg.len = (uint16_t)n;

            /* Entrega para aplicação: se a fila estiver cheia, você precisa decidir política:
               - descartar
               - bloquear por tempo limitado
               - desconectar cliente
            */
            if (xQueueSend(rxQueue, &msg, pdMS_TO_TICKS(20)) != pdPASS) {
                /* Política simples: descarta e segue */
            }

            /* Antes de receber mais, veja se há resposta pronta para este cliente */
            NetMessage_t out;
            if (xQueueReceive(txQueue, &out, 0) == pdPASS) {
                if (out.client_fd == client_fd && out.len > 0) {
                    send(client_fd, out.payload, out.len, 0);
                } else {
                    /* Se veio resposta de outro cliente, em produção você
                       rotearia corretamente (mapa de conexões, etc.) */
                }
            }
        }

        closesocket(client_fd);
    }
}

void start_socket_gatekeeper(void)
{
    xTaskCreate(socket_gatekeeper_task,
                "NetGate",
                2048,
                NULL,
                tskIDLE_PRIORITY + 3, /* Um pouco acima da aplicação */
                NULL);
}

Por que esse desenho é bom? Porque o Gatekeeper mantém I/O simples e previsível: ele não interpreta protocolo nem acessa hardware. Ele apenas “empurra bytes”.

Crítica (importante): este exemplo atende um cliente por vez. Para múltiplos clientes, as duas opções típicas são:

1. uma task por conexão (mais simples, mas consome RAM/stack)
2. select() com um loop único multiplexando sockets (mais eficiente, mais complexo)

Na próxima seção eu te mostro os dois modelos, mas antes precisamos fechar o ciclo com o consumidor.

7.3 Task consumidora: processa mensagem e devolve resposta

Agora a lógica de aplicação recebe mensagens da rxQueue, interpreta e devolve uma resposta pela txQueue.

#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"
#include <string.h>

static void app_worker_task(void *arg)
{
    (void)arg;

    for (;;)
    {
        NetMessage_t in;
        if (xQueueReceive(rxQueue, &in, portMAX_DELAY) == pdPASS)
        {
            NetMessage_t out;
            memset(&out, 0, sizeof(out));

            out.client_fd = in.client_fd;

            /* Exemplo de "protocolo": comandos ASCII */
            if (in.len >= 4 && memcmp(in.payload, "ping", 4) == 0) {
                const char *resp = "pong\n";
                out.len = (uint16_t)strlen(resp);
                memcpy(out.payload, resp, out.len);
            } else {
                const char *resp = "unknown\n";
                out.len = (uint16_t)strlen(resp);
                memcpy(out.payload, resp, out.len);
            }

            /* Envia resposta para o Gatekeeper transmitir */
            (void)xQueueSend(txQueue, &out, pdMS_TO_TICKS(50));
        }
    }
}

void start_app_worker(void)
{
    xTaskCreate(app_worker_task,
                "AppWorker",
                2048,
                NULL,
                tskIDLE_PRIORITY + 2,
                NULL);
}

#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"
#include <string.h>

static void app_worker_task(void *arg)
{
    (void)arg;

    for (;;)
    {
        NetMessage_t in;
        if (xQueueReceive(rxQueue, &in, portMAX_DELAY) == pdPASS)
        {
            NetMessage_t out;
            memset(&out, 0, sizeof(out));

            out.client_fd = in.client_fd;

            /* Exemplo de "protocolo": comandos ASCII */
            if (in.len >= 4 && memcmp(in.payload, "ping", 4) == 0) {
                const char *resp = "pong\n";
                out.len = (uint16_t)strlen(resp);
                memcpy(out.payload, resp, out.len);
            } else {
                const char *resp = "unknown\n";
                out.len = (uint16_t)strlen(resp);
                memcpy(out.payload, resp, out.len);
            }

            /* Envia resposta para o Gatekeeper transmitir */
            (void)xQueueSend(txQueue, &out, pdMS_TO_TICKS(50));
        }
    }
}

void start_app_worker(void)
{
    xTaskCreate(app_worker_task,
                "AppWorker",
                2048,
                NULL,
                tskIDLE_PRIORITY + 2,
                NULL);
}

Aqui você ganhou algo decisivo: se o parsing for pesado, você pode criar vários workers consumidores (ou uma pool) sem mexer na task de rede. E se um worker travar, você pode reiniciá-lo sem derrubar a rede (principalmente se tiver Task Monitor/Watchdog como você já vem tratando na série).

7.4 Ajustes essenciais para “produção”

O exemplo acima é a forma didática mais direta, mas em firmware real você geralmente aplica melhorias:

• Roteamento de respostas por conexão: em vez de uma txQueue única, você cria uma fila por cliente (ou um mapa de conexões).
• Política de backpressure: se rxQueue enche, você reduz leitura do socket, aplica recv com timeout, ou desconecta cliente.
• Framing: TCP é stream, não pacote. Seu “comando” pode vir partido em múltiplos recv(). Então você implementa framing (por delimitador \n, por tamanho fixo, ou por header com length).
• Stack e heap: payload copiado custa RAM; quando necessário, migra para pool de buffers.

Na próxima seção, vamos atacar exatamente o que separa “demo” de “produto”:
TCP é stream — então precisamos de framing e parser robusto, além de timeouts e manuseio de múltiplos clientes.

TCP é stream: framing robusto + múltiplos clientes (task por conexão vs select())

Se tem um erro conceitual que derruba sistemas FreeRTOS + lwIP “do nada”, é tratar recv() como se cada chamada retornasse uma mensagem completa. TCP não entrega mensagens — entrega um fluxo (stream). Isso significa que um comando ping\n pode chegar como p, depois ing\n, ou pode chegar junto com outro comando colado, ou pode vir com bytes extras. Se você não implementar framing, sua aplicação vai funcionar em bancada e falhar sob carga, ruído de rede, latência variável ou retransmissões.

A solução arquitetural é definir um protocolo com framing claro. Os dois modelos mais comuns em firmware são: (1) delimitador (por exemplo \n) e (2) length-prefix (header com tamanho). Vou te mostrar os dois, e em seguida mostro como isso muda quando você tem múltiplos clientes: ou você cria uma task por conexão (simples, mais RAM) ou usa select() (eficiente, mais complexo).

8.1 Framing por delimitador (\n)

Esse é o mais simples: você acumula bytes num buffer até achar \n. Cada linha vira um comando. É ótimo para console TCP, debug remoto, protocolos ASCII e comandos humanos. O cuidado é evitar overflow: se o cliente mandar uma linha enorme sem \n, você precisa cortar, descartar ou desconectar.

Exemplo de acumulador por conexão:

#include <string.h>
#include <stdint.h>

#define LINE_BUF_SZ 256

typedef struct
{
    uint8_t buf[LINE_BUF_SZ];
    uint16_t used;
} LineFramer_t;

/**
 * @brief Alimenta o framer com bytes recebidos e extrai 0..N linhas completas.
 *        Retorna 1 quando extraiu uma linha, 0 quando ainda não tem linha.
 */
static int framer_try_get_line(LineFramer_t *f, const uint8_t *data, uint16_t len,
                               uint8_t *out_line, uint16_t *out_len)
{
    /* Copia com proteção */
    uint16_t space = (LINE_BUF_SZ - 1) - f->used;
    if (len > space) {
        /* Política simples: reset (em produção: desconectar cliente) */
        f->used = 0;
        return 0;
    }

    memcpy(&f->buf[f->used], data, len);
    f->used += len;
    f->buf[f->used] = 0;

    /* Procura delimitador */
    uint8_t *nl = (uint8_t*)memchr(f->buf, '\n', f->used);
    if (!nl) return 0;

    uint16_t line_len = (uint16_t)(nl - f->buf) + 1; /* inclui '\n' */
    memcpy(out_line, f->buf, line_len);
    *out_len = line_len;

    /* Remove a linha do buffer (shift) */
    uint16_t remaining = f->used - line_len;
    memmove(f->buf, &f->buf[line_len], remaining);
    f->used = remaining;

    return 1;
}

#include <string.h>
#include <stdint.h>

#define LINE_BUF_SZ 256

typedef struct
{
    uint8_t buf[LINE_BUF_SZ];
    uint16_t used;
} LineFramer_t;

/**
 * @brief Alimenta o framer com bytes recebidos e extrai 0..N linhas completas.
 *        Retorna 1 quando extraiu uma linha, 0 quando ainda não tem linha.
 */
static int framer_try_get_line(LineFramer_t *f, const uint8_t *data, uint16_t len,
                               uint8_t *out_line, uint16_t *out_len)
{
    /* Copia com proteção */
    uint16_t space = (LINE_BUF_SZ - 1) - f->used;
    if (len > space) {
        /* Política simples: reset (em produção: desconectar cliente) */
        f->used = 0;
        return 0;
    }

    memcpy(&f->buf[f->used], data, len);
    f->used += len;
    f->buf[f->used] = 0;

    /* Procura delimitador */
    uint8_t *nl = (uint8_t*)memchr(f->buf, '\n', f->used);
    if (!nl) return 0;

    uint16_t line_len = (uint16_t)(nl - f->buf) + 1; /* inclui '\n' */
    memcpy(out_line, f->buf, line_len);
    *out_len = line_len;

    /* Remove a linha do buffer (shift) */
    uint16_t remaining = f->used - line_len;
    memmove(f->buf, &f->buf[line_len], remaining);
    f->used = remaining;

    return 1;
}

Uso típico no loop do socket: você chama recv(), joga os bytes no framer e enquanto ele conseguir extrair linhas você envia para a fila (rxQueue).

8.2 Framing por header com tamanho (length-prefix)

Esse é o padrão de protocolos binários robustos. Você define, por exemplo:

• 2 bytes: len (big-endian)
• len bytes: payload

Vantagem: não depende de delimitador e funciona bem com binário. Desvantagem: você precisa validar tamanho, lidar com endianess e limites.

Estrutura de parsing por estados:

#include <stdint.h>
#include <string.h>

#define MAX_FRAME 512

typedef enum { ST_LEN1, ST_LEN2, ST_PAYLOAD } ParseState_t;

typedef struct
{
    ParseState_t st;
    uint16_t expected;
    uint16_t got;
    uint8_t payload[MAX_FRAME];
} LenFramer_t;

static void lenframer_init(LenFramer_t *f)
{
    f->st = ST_LEN1;
    f->expected = 0;
    f->got = 0;
}

/**
 * @brief Consome bytes e extrai frames completos. Retorna 1 quando extrai um frame.
 */
static int lenframer_feed(LenFramer_t *f, const uint8_t *data, uint16_t len,
                          uint8_t *out_payload, uint16_t *out_len)
{
    for (uint16_t i = 0; i < len; i++)
    {
        uint8_t b = data[i];

        switch (f->st)
        {
            case ST_LEN1:
                f->expected = ((uint16_t)b) << 8;
                f->st = ST_LEN2;
                break;

            case ST_LEN2:
                f->expected |= b;
                if (f->expected == 0 || f->expected > MAX_FRAME) {
                    /* Frame inválido: reset (em produção: desconectar) */
                    lenframer_init(f);
                    break;
                }
                f->got = 0;
                f->st = ST_PAYLOAD;
                break;

            case ST_PAYLOAD:
                f->payload[f->got++] = b;
                if (f->got >= f->expected) {
                    memcpy(out_payload, f->payload, f->expected);
                    *out_len = f->expected;
                    lenframer_init(f);
                    return 1; /* extraiu 1 frame */
                }
                break;
        }
    }
    return 0;
}

#include <stdint.h>
#include <string.h>

#define MAX_FRAME 512

typedef enum { ST_LEN1, ST_LEN2, ST_PAYLOAD } ParseState_t;

typedef struct
{
    ParseState_t st;
    uint16_t expected;
    uint16_t got;
    uint8_t payload[MAX_FRAME];
} LenFramer_t;

static void lenframer_init(LenFramer_t *f)
{
    f->st = ST_LEN1;
    f->expected = 0;
    f->got = 0;
}

/**
 * @brief Consome bytes e extrai frames completos. Retorna 1 quando extrai um frame.
 */
static int lenframer_feed(LenFramer_t *f, const uint8_t *data, uint16_t len,
                          uint8_t *out_payload, uint16_t *out_len)
{
    for (uint16_t i = 0; i < len; i++)
    {
        uint8_t b = data[i];

        switch (f->st)
        {
            case ST_LEN1:
                f->expected = ((uint16_t)b) << 8;
                f->st = ST_LEN2;
                break;

            case ST_LEN2:
                f->expected |= b;
                if (f->expected == 0 || f->expected > MAX_FRAME) {
                    /* Frame inválido: reset (em produção: desconectar) */
                    lenframer_init(f);
                    break;
                }
                f->got = 0;
                f->st = ST_PAYLOAD;
                break;

            case ST_PAYLOAD:
                f->payload[f->got++] = b;
                if (f->got >= f->expected) {
                    memcpy(out_payload, f->payload, f->expected);
                    *out_len = f->expected;
                    lenframer_init(f);
                    return 1; /* extraiu 1 frame */
                }
                break;
        }
    }
    return 0;
}

Esse modelo é extremamente estável em ambiente real porque mantém o protocolo bem definido.

8.3 Múltiplos clientes: duas arquiteturas

Agora vem o ponto de engenharia de firmware: como atender N conexões sem destruir RAM e sem perder previsibilidade.

Opção A — Uma task por conexão (modelo simples)

• Ao aceitar um cliente, você cria uma task dedicada para ele.
• Cada task tem seu framer + buffer + loop recv().
• Fácil de entender e depurar.
• Custo: cada task consome stack e TCB; em MCU pequeno isso vira limite rápido.

Padrão típico:

static void client_task(void *arg)
{
    int client_fd = (int)(intptr_t)arg;
    LineFramer_t fr;
    fr.used = 0;

    for (;;)
    {
        uint8_t tmp[128];
        int n = recv(client_fd, tmp, sizeof(tmp), 0);
        if (n <= 0) break;

        uint8_t line[LINE_BUF_SZ];
        uint16_t line_len;

        while (framer_try_get_line(&fr, tmp, (uint16_t)n, line, &line_len)) {
            /* aqui você empacota e manda para rxQueue */
        }
    }

    closesocket(client_fd);
    vTaskDelete(NULL);
}

static void client_task(void *arg)
{
    int client_fd = (int)(intptr_t)arg;
    LineFramer_t fr;
    fr.used = 0;

    for (;;)
    {
        uint8_t tmp[128];
        int n = recv(client_fd, tmp, sizeof(tmp), 0);
        if (n <= 0) break;

        uint8_t line[LINE_BUF_SZ];
        uint16_t line_len;

        while (framer_try_get_line(&fr, tmp, (uint16_t)n, line, &line_len)) {
            /* aqui você empacota e manda para rxQueue */
        }
    }

    closesocket(client_fd);
    vTaskDelete(NULL);
}

Opção B — select() (modelo eficiente)

• Uma única task monitora vários sockets ao mesmo tempo.
• Melhor uso de RAM (uma task só), bom para dezenas de conexões.
• Custo: mais complexo; exige tabela de conexões e estados por cliente.

Se seu firmware precisa escalar, select() costuma ser o caminho. Se precisa ser simples e você terá poucos clientes, task por conexão é perfeito.

8.4 Um detalhe que muita gente ignora: prioridade e latência

Não adianta ter framing perfeito se a task que atende sockets fica “no fim da fila” e perde janela TCP. Em geral, uma prática saudável é:

• TCP/IP thread: prioridade média-alta (depende do port e do vendor)
• Gatekeeper de sockets: prioridade logo abaixo da TCP/IP thread
• Workers de aplicação: prioridade média
• Logs/telemetria: prioridade baixa

Isso evita um cenário em que o processamento de aplicação “engole” a CPU e a rede degrada.

Na próxima seção, vamos fechar a arquitetura com os componentes que tornam isso resiliente em produto:

• timeouts completos (recv/send/connect/accept)
• keepalive TCP
• watchdog e task monitor aplicados ao domínio de rede
• política de backpressure quando filas enchem
• e um exemplo “quase HTTP” com parser mínimo

Robustez em rede: timeouts, keepalive, backpressure e integração com Task Monitor/Watchdog

Até aqui você já tem uma arquitetura correta. Agora entramos no que diferencia firmware de laboratório de firmware de campo: resiliência. Em sistemas FreeRTOS + lwIP, a maior parte das falhas em produção não vem de bugs óbvios, mas de bloqueios silenciosos, clientes mal-comportados, perda intermitente de link, filas saturadas e tarefas que parecem vivas, mas não fazem progresso. Esta seção trata exatamente desses pontos — com decisões práticas de engenharia.

9.1 Timeouts em sockets: nunca confie em bloqueios infinitos

Chamadas como accept(), recv() e send() bloqueiam por padrão. Em firmware, isso é perigoso: se um cliente trava no meio de uma transmissão, sua task pode ficar presa indefinidamente, impedindo shutdown limpo, watchdog cooperativo e diagnóstico.

A regra é simples: todo socket deve ter timeout.

static void socket_set_timeouts(int fd, int sec)
{
    struct timeval tv;
    tv.tv_sec = sec;
    tv.tv_usec = 0;

    setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
    setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv));
}

static void socket_set_timeouts(int fd, int sec)
{
    struct timeval tv;
    tv.tv_sec = sec;
    tv.tv_usec = 0;

    setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
    setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv));
}

Use isso logo após accept():

int client_fd = accept(listen_fd, NULL, NULL);
if (client_fd >= 0) {
    socket_set_timeouts(client_fd, 5); /* 5s é um bom ponto inicial */
}

int client_fd = accept(listen_fd, NULL, NULL);
if (client_fd >= 0) {
    socket_set_timeouts(client_fd, 5); /* 5s é um bom ponto inicial */
}

Com isso:

• recv() retorna < 0 após timeout
• você pode encerrar a conexão, reavaliar estado ou alimentar watchdog
• evita tarefas “zumbis”

9.2 TCP Keepalive: detectando clientes mortos

Em redes reais, cliente pode cair sem fechar socket (queda de Wi-Fi, cabo puxado, crash). O TCP keepalive permite detectar isso.

int enable = 1;
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &enable, sizeof(enable));

int idle = 10;    /* segundos ociosos antes do probe */
int interval = 5; /* intervalo entre probes */
int count = 3;    /* probes antes de declarar morto */

setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &idle, sizeof(idle));
setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &interval, sizeof(interval));
setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &count, sizeof(count));

int enable = 1;
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &enable, sizeof(enable));

int idle = 10;    /* segundos ociosos antes do probe */
int interval = 5; /* intervalo entre probes */
int count = 3;    /* probes antes de declarar morto */

setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &idle, sizeof(idle));
setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &interval, sizeof(interval));
setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &count, sizeof(count));

Nem todos os ports do lwIP suportam todas essas opções, mas quando disponíveis, reduzem drasticamente conexões zumbis.

9.3 Backpressure: o que fazer quando as filas enchem

Esse ponto é crítico e raramente tratado em exemplos. Se sua rxQueue enche, o sistema está dizendo que não consegue processar dados na mesma taxa em que recebe. Ignorar isso leva a latência crescente e colapso.

Existem quatro políticas clássicas:

1. Descartar mensagens novas
   Simples, mas pode quebrar protocolo.
2. Bloquear o Gatekeeper por tempo limitadoif (xQueueSend(rxQueue, &msg, pdMS_TO_TICKS(50)) != pdPASS) { /* timeout: decide política */ }
3. Parar de ler do socket temporariamente
   Com timeout em recv(), você simplesmente não chama recv por um ciclo.
4. Desconectar cliente agressivo (muito comum em produto)
   Se um cliente gera backpressure constante, ele é o problema.

Em firmware sério, a política 4 costuma ser a mais segura.

9.4 Integração com Task Monitor: detectar “tarefas vivas porém travadas”

Uma task bloqueada em recv() não parece travada para o scheduler — ela está em estado Blocked. Por isso, Task Monitor precisa ir além de “task rodando ou não”: precisa verificar progresso lógico.

Modelo simples: heartbeat por domínio.

volatile uint32_t net_heartbeat = 0;

void socket_gatekeeper_task(void *arg)
{
    for (;;)
    {
        net_heartbeat++;
        /* accept / recv / processamento */
    }
}

volatile uint32_t net_heartbeat = 0;

void socket_gatekeeper_task(void *arg)
{
    for (;;)
    {
        net_heartbeat++;
        /* accept / recv / processamento */
    }
}

O Task Monitor verifica:

static uint32_t last_net_hb = 0;

void task_monitor(void)
{
    if (net_heartbeat == last_net_hb) {
        /* rede não progrediu */
        /* ação: reiniciar task, reiniciar interface, logar */
    }
    last_net_hb = net_heartbeat;
}

static uint32_t last_net_hb = 0;

void task_monitor(void)
{
    if (net_heartbeat == last_net_hb) {
        /* rede não progrediu */
        /* ação: reiniciar task, reiniciar interface, logar */
    }
    last_net_hb = net_heartbeat;
}

Isso detecta:

• deadlocks
• starvation
• loops bloqueados por erro lógico

Muito mais eficaz que apenas checar se a task existe.

9.5 Watchdog cooperativo aplicado à rede

Nunca alimente o watchdog dentro da task de sockets diretamente. Isso mascara falhas. O correto é:

• task de rede atualiza estado/heartbeat
• task de supervisão decide se o sistema está saudável
• só ela alimenta o watchdog

Exemplo conceitual:

void supervisor_task(void *arg)
{
    for (;;)
    {
        if (net_ok && app_ok && sensors_ok) {
            feed_watchdog();
        }
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void supervisor_task(void *arg)
{
    for (;;)
    {
        if (net_ok && app_ok && sensors_ok) {
            feed_watchdog();
        }
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

Assim, falhas de rede resetam o sistema, em vez de ficarem ocultas.

9.6 Mini-HTTP: aplicação prática dos conceitos

Para fechar, um exemplo conceitual de servidor estilo HTTP minimalista:

• framing por \r\n\r\n
• timeout curto
• parsing mínimo
• resposta fixa

if (strstr(request, "GET /status")) {
    const char *resp =
        "HTTP/1.1 200 OK\r\n"
        "Content-Type: text/plain\r\n"
        "Connection: close\r\n"
        "\r\n"
        "OK\n";
    send(fd, resp, strlen(resp), 0);
}

if (strstr(request, "GET /status")) {
    const char *resp =
        "HTTP/1.1 200 OK\r\n"
        "Content-Type: text/plain\r\n"
        "Connection: close\r\n"
        "\r\n"
        "OK\n";
    send(fd, resp, strlen(resp), 0);
}

Em firmware, HTTP raramente precisa ser completo. Muitas vezes é só um protocolo humano para debug, status e configuração inicial. Quanto mais simples, mais confiável.

The post FreeRTOS com lwIP: Arquitetura, Boas Práticas e Exemplos Reais de Sistemas Embarcados em Rede first appeared on MCU & FPGA.

The post OTA, FOTA e SOTA em IoT: Diferenças, Riscos e Boas Práticas em Projetos Reais first appeared on MCU & FPGA.

Introdução

Redes de sensores sem fio e sistemas embarcados de baixo consumo formam a espinha dorsal de grande parte das aplicações modernas de Internet das Coisas (IoT), especialmente nos domínios industrial, ambiental e de infraestrutura crítica. Nesses cenários, os desafios não se restringem à aquisição de dados, mas envolvem de forma central como os nós se organizam, como compartilham o meio de comunicação e como preservam energia ao longo de anos de operação. É nesse contexto que surgem protocolos voltados à eficiência energética, à previsibilidade temporal e à confiabilidade da comunicação.

Protocolos como LEACH e PEGASIS emergem inicialmente no meio acadêmico como respostas diretas às limitações físicas dos nós sensores, propondo novas formas de organização da rede para reduzir o custo energético das transmissões. Esses trabalhos estabelecem fundamentos conceituais importantes, como agregação de dados, hierarquização e comunicação cooperativa, que influenciaram profundamente a evolução das Wireless Sensor Networks e, posteriormente, do IoT.

À medida que as aplicações avançam para ambientes industriais e de missão crítica, a necessidade de determinismo, robustez e interoperabilidade torna-se dominante. Técnicas como TDMA passam a ser adotadas como base estrutural, permitindo controle preciso do tempo, do consumo e da latência. Sobre esse alicerce, surgem protocolos industriais como 6TiSCH e WirelessHART, que consolidam esses princípios em padrões amplamente utilizados no Industrial IoT.

Este artigo apresenta uma análise progressiva desses protocolos, explorando seus conceitos fundamentais, modos de funcionamento e contextos de uso, com foco especial na relação direta entre arquitetura de rede, firmware embarcado e eficiência energética. Ao compreender essa trajetória, torna-se possível enxergar o IoT não como um conjunto de tecnologias isoladas, mas como o resultado de décadas de refinamento conceitual no campo das redes de sensores e sistemas embarcados distribuídos.

The post Protocolos para Redes de Sensores e IoT: LEACH, PEGASIS, TDMA, 6TiSCH e WirelessHART first appeared on MCU & FPGA.

Conceito, motivação e panorama geral

Em sistemas embarcados reais, dados seriais não chegam “limpos”. Há ruído elétrico, bytes perdidos, reinicializações assíncronas, buffers cheios e tarefas concorrentes. Protocolos auto-sincronizáveis surgem exatamente para resolver esse cenário: eles permitem recuperar o alinhamento do fluxo mesmo quando o receptor começa a ler no meio de um pacote, sem depender de resets globais ou estados externos.

Um protocolo é auto-sincronizável quando o receptor consegue, observando apenas o fluxo de bytes, reencontrar limites válidos de mensagem após erros. Isso contrasta com abordagens frágeis como “leia N bytes e confie”, que falham assim que um único byte se perde. Em UART, SPI em modo streaming, CDC-ACM, ou qualquer link byte-oriented, essa propriedade define se o sistema se recupera sozinho ou trava silenciosamente.

Nesta série, vamos analisar três abordagens amplamente usadas — SLIP, COBS e CBOR — não como “formatos bonitos”, mas como decisões de engenharia. Vamos discutir o que cada uma garante, o que não garante, onde usar, onde evitar, e como implementar corretamente em firmware de produção.

O que significa “auto-sincronização” na prática

Do ponto de vista do firmware, auto-sincronização implica três capacidades essenciais:

1. Delimitação inequívoca
   O receptor precisa identificar onde uma mensagem começa e termina, mesmo após bytes inválidos.
2. Recuperação após erro
   Um erro local (byte perdido, extra, corrompido) não pode invalidar todo o fluxo.
3. Parsing incremental (streaming)
   O protocolo deve permitir processamento byte-a-byte, sem exigir buffers gigantes ou leituras bloqueantes.

SLIP, COBS e CBOR resolvem esses pontos de formas fundamentalmente diferentes, e entender essas diferenças é o que separa firmware de laboratório de firmware industrial.

Visão geral dos protocolos que vamos estudar

Um erro comum é tratar CBOR como protocolo de transporte — ele não é. CBOR define como os dados são codificados, não como são enquadrados no fluxo. Por isso, em sistemas bem projetados, CBOR quase sempre aparece sobre COBS ou outro método de framing.

Boas e más decisões logo no início

Boas escolhas

• Pensar em framing antes de escrever o parser
• Separar claramente: transporte × serialização
• Assumir que bytes serão perdidos em algum momento

Más escolhas

• Usar scanf() ou parsing por strings
• Depender de timeouts para “adivinhar” fim de pacote
• Achar que CRC substitui framing (não substitui)

The post Protocolos auto-sincronizáveis em sistemas embarcados first appeared on MCU & FPGA.

Visão geral da solução no Zephyr para ESP32: ADC contínuo (DMA), VAD e pipeline produtor/consumidor

Quando você tenta fazer “captura de ruidos como da magnectostricção” a partir de ADC no ESP32 com o Zephyr, aparecem três problemas clássicos ao mesmo tempo:

1. aquisição contínua em alta taxa (idealmente com DMA para não “matar” a CPU),
2. delimitação de trechos úteis (detectar início/fim de fala para não processar silêncio), e
3. processamento em tempo real (calcular alguma métrica — aqui, a frequência principal — e jogar na UART).

A arquitetura mais robusta para isso, no mundo de sistemas em tempo real, é separar responsabilidades em threads com um canal bem definido de troca de dados (fila/ring buffer), exatamente o tipo de organização que livros de padrões para sistemas em tempo real tratam como base de escalabilidade e diagnósticos previsíveis.

O ponto crítico: “Zephyr puro” vs “driver contínuo do ESP-IDF”

O Zephyr tem um caminho bem canônico para ADC via DeviceTree + ADC API (por exemplo o sample adc_dt) (docs.zephyrproject.org) e possui binding específico para ADC do ESP32 (espressif,esp32-adc) (docs.zephyrproject.org). Isso resolve bem leituras “por amostra” e configurações padrão.

Só que voz por ADC normalmente pede stream contínuo, e no ecossistema Espressif a forma “oficial” para isso é o ADC Continuous Mode driver, que foi desenhado para conversões contínuas e leitura de resultados em buffer (tipicamente alimentado por DMA) (Espressif Systems). Na prática, para cumprir o requisito (“leitura contínua por DMA do ADC”), o caminho mais realista é:

• usar Zephyr como RTOS (threads, filas, logging/uart), mas
• usar o driver de ADC contínuo do ESP-IDF por baixo (como “módulo”/componente), expondo para o Zephyr uma API de aquisição contínua.

Isso evita reinventar o mecanismo de aquisição contínua e te dá taxas estáveis.

VAD no ESP32: duas realidades (hardware x software)

Aqui há uma nuance importante:

• ESP32-P4 tem módulo VAD em hardware documentado pela Espressif (Espressif Systems). Nesse caso, faz sentido “delimitar stream” com evento/flag do próprio periférico.
• Em vários outros ESP32 (ex.: ESP32 clássico, S3, etc.), é comum usar VAD por software vindo do ecossistema de áudio/speech da Espressif (ex.: ESP-SR/ADF). Há documentação de VAD em software no contexto dessas libs (espressif-docs.readthedocs-hosted.com).

Eu vou estruturar como se fosse uma pipeline genérica onde o “VAD” é um bloco que produz eventos VOICE_START/VOICE_END. A implementação desse bloco pode ser:

• hardware VAD (se for ESP32-P4), ou
• software VAD (ESP-SR/ADF) quando o chip não oferecer o periférico.

Pipeline proposta (alto nível)

A solução fica muito limpa com duas threads e um “canal” entre elas:

1. Thread Produtora (adc_stream_thread)
   • Inicializa ADC contínuo (driver do ESP-IDF) e começa a receber “frames” (blocos) de amostras.
   • Alimenta o bloco de VAD (hardware ou software).
   • Quando o VAD indicar fala ativa, empacota blocos de amostras e envia para a fila/ring buffer do consumidor.
   • Quando indicar fim da fala, envia um “marcador” (metadado) de fim de stream.
2. Thread Consumidora (dsp_uart_thread)
   • Recebe blocos do stream “recortado” pelo VAD.
   • Acumula um buffer mínimo (janela) e calcula a frequência principal (pitch/peak espectral) e imprime na UART.

Essa separação é a base para desempenho e previsibilidade: a thread de aquisição não fica “presa” em FFT/Goertzel; a thread de DSP não perde amostra porque alguém resolveu imprimir logs demais.

Onde o DeviceTree entra (mesmo usando ADC contínuo do ESP-IDF)

Mesmo que o “motor” de aquisição contínua venha do ESP-IDF, você ainda quer o DeviceTree como fonte única de verdade para:

• qual ADC está ativo,
• quais canais/pinos estão habilitados,
• ganho/atenuação/resolução,
• e a UART de saída (console).

O Zephyr já tem binding do ADC do ESP32 (docs.zephyrproject.org) e o modelo de amostragem por DT é bem estabelecido no sample adc_dt (docs.zephyrproject.org). A ideia prática é: o DT descreve os canais, e o o código traduz isso para a configuração do driver contínuo.

Na próxima seção), eu vou te entregar:

• um overlay .overlay de exemplo configurando ADC e um “nó” de aplicação com io-channels,
• o esqueleto completo das duas threads (produtor/consumidor) com filas,
• e o desenho do contrato de mensagens (bloco de amostras + eventos VAD).

The post Zephyr no ESP32: ADC Contínuo com DMA, VAD e Processamento de Sinais em Tempo Real first appeared on MCU & FPGA.

UART não é uma porta: é uma decisão de arquitetura

Para a maioria dos engenheiros, o primeiro contato com um microcontrolador envolve ligar um conversor USB-UART, abrir um terminal serial e enviar caracteres. Essa experiência inicial cria um vício conceitual perigoso: tratar UART como se fosse uma “porta de texto”, algo próximo de um printf() com fio. Esse modelo mental funciona em demos, provas de conceito e exemplos de datasheet — mas ele quebra imediatamente quando o sistema passa a existir no mundo real.

UART não é uma porta, não é um periférico isolado e definitivamente não é um canal confiável por definição. UART é apenas um mecanismo físico de serialização de bits, sem noção de mensagens, pacotes, estados, erros ou intenção semântica. Tudo o que faz sentido — início, fim, significado, validade, recuperação — precisa ser projetado em cima dela. Quando isso não é feito, o sistema não “falha de vez”; ele falha de forma intermitente, imprevisível e difícil de depurar.

Um teste simples revela rapidamente o nível de maturidade de um firmware: o que acontece quando um byte se perde? Se a resposta for “nunca acontece” ou “o terminal não mostra”, o sistema já está arquiteturalmente comprometido. Em sistemas reais há ruído elétrico, interrupções concorrentes, buffers cheios, clocks ligeiramente desalinhados, resets parciais e firmware sendo atualizado em campo. UART expõe todas essas fragilidades sem piedade.

O erro clássico: UART como “linha de printf”

O padrão mais comum — e mais frágil — de uso de UART é este:

// <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/274c.png" alt="❌" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Abordagem frágil e não determinística
void loop(void) {
    char cmd[32];
    scanf("%s", cmd);

    if (strcmp(cmd, "ON") == 0) {
        led_on();
    } else if (strcmp(cmd, "OFF") == 0) {
        led_off();
    }
}

// ❌ Abordagem frágil e não determinística
void loop(void) {
    char cmd[32];
    scanf("%s", cmd);

    if (strcmp(cmd, "ON") == 0) {
        led_on();
    } else if (strcmp(cmd, "OFF") == 0) {
        led_off();
    }
}

Esse código pressupõe coisas que não são garantidas pela UART:

• Que os dados chegam completos
• Que não há bytes extras ou truncados
• Que o buffer nunca estoura
• Que o alinhamento entre transmissor e receptor é perfeito
• Que ruído não existe
• Que o tempo não importa

Além disso, scanf() bloqueia a execução, mistura parsing com transporte, não detecta framing e não oferece nenhuma estratégia de recuperação. Funciona em bancada, falha em produção.

A mudança de mentalidade: UART como canal bruto

Um sistema robusto parte do princípio oposto:

UART não transporta comandos, transporta bytes.
Quem transporta mensagens é o protocolo que você desenha.

Isso muda completamente a arquitetura. Em vez de “ler comandos”, o firmware passa a:

1. Receber bytes de forma assíncrona
2. Bufferizar dados
3. Detectar início e fim de quadros
4. Validar integridade
5. Interpretar significado
6. Responder ou recuperar estado

Um primeiro passo correto é separar recepção de interpretação:

// <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/2705.png" alt="✅" class="wp-smiley" style="height: 1em; max-height: 1em;" /> UART tratada como stream bruto
#define RX_BUFFER_SIZE 128

volatile uint8_t rx_buffer[RX_BUFFER_SIZE];
volatile uint16_t rx_head = 0;

void USART_IRQHandler(void) {
    uint8_t byte = USART_ReadByte();
    rx_buffer[rx_head++] = byte;
    rx_head %= RX_BUFFER_SIZE;
}

// ✅ UART tratada como stream bruto
#define RX_BUFFER_SIZE 128

volatile uint8_t rx_buffer[RX_BUFFER_SIZE];
volatile uint16_t rx_head = 0;

void USART_IRQHandler(void) {
    uint8_t byte = USART_ReadByte();
    rx_buffer[rx_head++] = byte;
    rx_head %= RX_BUFFER_SIZE;
}

Aqui não há “comandos”, apenas dados crus entrando no sistema. Isso é proposital. O firmware assume que os bytes podem estar incompletos, desalinhados ou corrompidos — e projeta em cima disso.

A partir desse ponto, tudo o que vier depois — framing, parsing, validação — deixa de ser improviso e passa a ser engenharia deliberada.

UART como espelho do engenheiro

UART é brutal porque ela não esconde nada. Não há retransmissão automática, não há ordenação garantida, não há controle de fluxo implícito. Se o sistema funciona bem sobre UART, ele provavelmente funcionará bem sobre SPI, CAN, RS-485, TCP ou rádio. Se ele só funciona quando tudo dá certo, então ele não funciona.

Projetar bem sobre UART é um divisor de águas. É o ponto em que o engenheiro deixa de “fazer firmware” e começa a construir sistemas distribuídos embarcados, capazes de sobreviver ao mundo real.

The post UART não é Porta Serial: Como Projetar Protocolos Robustos em Sistemas Embarcados first appeared on MCU & FPGA.

Para mitigar esses problemas, diversos projetistas implementam técnicas de robustez que vão além do básico. Entre elas, destaca-se a combinação de resistores em série e diodos Schottky, aplicada individualmente em cada ramificação de módulo. Essa técnica protege contra curtos, limita corrente, reduz interferências eletromagnéticas, desacopla capacitâncias parasitas e, sobretudo, isola falhas de forma que nenhum módulo pode travar o barramento completo.

A topologia analisada neste artigo é ilustrada no circuito abaixo, no qual um Arduino Uno R3 se comunica com quatro dispositivos I²C (U1 a U4). Cada dispositivo é conectado por meio de um resistor em série (R1 a R4) e um diodo Schottky (D1 a D4), formando uma estrutura de proteção individual por ramificação. Essa abordagem aumenta significativamente a confiabilidade do barramento, mesmo na presença de cabos longos, dispositivos de procedência variada ou ambientes sujeitos a picos eletromagnéticos.

Resistores em Série no Barramento I²C (R1–R4)

Quando olhamos para o esquema, vemos que cada módulo I²C (U1, U2, U3, U4) não está ligado “direto” ao barramento SDA/SCL. Em vez disso, há sempre um resistor em série (R1, R2, R3, R4) entre o barramento principal e o pino correspondente do módulo.
Isso não é um mero detalhe: é uma escolha de projeto importante para proteção, estabilidade de sinal e robustez do sistema.

1.1 Função básica: limitar corrente em falhas

O I²C é um barramento “open-drain/open-collector”:

• Os dispositivos apenas puxam a linha para o nível baixo (0).
• O nível alto é obtido por meio dos resistores de pull-up.

Se, por algum motivo, um módulo entrar em falha e curto-circuitar SDA ou SCL para GND (ou mesmo para VCC), sem resistor série a corrente seria limitada somente pela resistência interna dos transistores – o que pode facilmente danificar o módulo, o microcontrolador ou ambos.

Com o resistor série, a corrente máxima é aproximada por:

\[
I_{máx} \approx \frac{V_{CC}}{R_{série}}
\]

Exemplo típico:

• \( V_{CC} = 5,\text{V} \)
• \( R_{série} = 220,\Omega \)

\[
I_{máx} = \frac{5}{220} \approx 22{,}7,\text{mA}
\]

Esse valor é alto, mas muitíssimo menor do que dezenas ou centenas de miliampères que poderiam circular num curto direto.
Na prática, essa limitação:

• Protege o driver de saída do Arduino.
• Impede que uma falha em um único módulo destrua o barramento todo.
• Dá tempo para o sistema detectar o problema (via watchdog, varredura de dispositivos, etc.) sem dano físico imediato.

1.2 Função de “damping”: redução de reflexões e ringing

Fisicamente, o conjunto fio + trilha + entrada do CI se comporta como um sistema RLC distribuído, com:

• Resistência série (do fio e do driver)
• Indutância parasita do cabo
• Capacitância parasita entre condutores e para o terra

Quando o driver muda o nível lógico (especialmente em bordas rápidas), o sinal pode “oscilar” (ringing), produzir overshoot e undershoot, ou mesmo reflexões ao longo do cabo.

O resistor em série aumenta a resistência vista pelo circuito e, em conjunto com a impedância característica do cabo ((Z_0)), ajuda a amortecer essas oscilações:

• sem resistor: \( R_{\text{total}} \approx R_{\text{driver}} \)
• com resistor: \( R_{\text{total}} \approx R_{\text{driver}} + R_{série} \)

Se fizermos:

\[
R_{\text{total}} ;\approx; Z_0
\]

o sistema tende a ficar criticamento amortecido, minimizando reflexões.

Não é preciso calcular (Z_0) exatamente em projetos simples, mas entender a ideia é importante: o resistor em série está “matando” parte da energia de alta frequência que causaria problemas de integridade de sinal.

1.3 Controle da constante de tempo RC por módulo

Cada ramificação do barramento possui sua capacitância própria:

• Capacitância dos pinos SDA/SCL do CI
• Capacitância do cabo local
• Parasitismos de trilha e conector

Sem resistor série, toda essa capacitância é vista diretamente pelo barramento.
Com o resistor série, criamos um pequeno filtro RC:

\[
\tau_{\text{ramo}} = R_{série} \cdot C_{\text{ramo}}
\]

Exemplo:

• \( R_{série} = 220,\Omega \)
• \( C_{\text{ramo}} = 20,\text{pF} \)

\[
\tau_{\text{ramo}} = 220 \cdot 20\times10^{-12} = 4{,}4,\text{ns}
\]

Esse valor é desprezível frente ao tempo de subida típico em I²C padrão (ordem de centenas de nanosegundos a microssegundos). Ou seja:

• Não atrapalha a velocidade de 100 kHz ou 400 kHz.
• Ajuda a “desacoplar” capacitâncias de cada módulo, evitando que um único dispositivo com capacitância alta degrade todo o barramento.

Na prática, escolhemos (R_{série}) num compromisso:

• Grande o suficiente para limitar corrente e amortecer ringing.
• Pequeno o suficiente para não degradar o tempo de subida global do barramento.

Valores usuais: 100 Ω a 470 Ω por linha e por módulo.

1.4 Efeito sobre o tempo de subida do barramento

O tempo de subida do I²C é dominado pelos resistores de pull-up e pela capacitância total vista pelo barramento:

\[
t_r \approx 0{,}8473 \cdot R_{pullup} \cdot C_T
\]

onde:

• \(C_T = C_{cabos} + \sum C_{entradas}\)

Os resistores em série quase não alteram diretamente essa equação, pois o pull-up continua ligado ao barramento principal.
O que eles fazem é:

• Reduzir o quanto da capacitância de cada ramo é de fato “sentida” nas bordas rápidas.
• Atuar como “isoladores suaves” entre o barramento comum e os módulos.

Resultado prático: maior número de módulos e cabos podem ser usados sem violar os tempos de subida especificados para o modo de operação (Standard, Fast, etc.).

1.5 Justificativa da escolha de valor (exemplo 220 Ω)

Vamos supor:

• I²C a 100 kHz
• VCC = 5 V
• Pull-up de 4,7 kΩ
• Múltiplos módulos, cada um com 20–30 pF
• Cabos com 100–200 pF no total

Queremos:

1. Corrente segura em falha
   • Com 220 Ω, vimos que o máximo é ~23 mA em curto.
   • Muitos CIs aguentam picos dessa ordem sem queimar instantaneamente.
2. Damping razoável
   • 220 Ω + resistência do driver (~20–30 Ω) já é suficiente para amortecer a maioria dos cabos curtos/médios.
3. Impacto mínimo na forma de onda em operação normal
   • O resistor só “aparece” quando há transição ou curto.
   • Durante nível estável, a queda de tensão é pequena, pois a corrente é baixa (corrente de pull-up).

Assim, o valor típico de 220 Ω é um bom compromisso entre:

• Proteção
• Integridade de sinal
• Simplicidade de cálculo
• Custo e disponibilidade (valor comercial padrão)

Diodos Schottky de Proteção no Barramento I²C (D1–D4)

Cada módulo I²C do circuito possui um diodo Schottky ligado entre o ramo individual do módulo e o barramento principal SDA/SCL.
O conjunto resistor série + diodo Schottky cria um mecanismo de proteção inteligente que aumenta a robustez do barramento, evitando travamentos e reduzindo efeitos de falhas.

Este capítulo explica em profundidade por que o diodo está ali, por que ele é do tipo Schottky, como ele se comporta eletricamente, e como sua escolha impacta a confiabilidade do sistema.

2.1 Motivação principal: evitar que um módulo defeituoso derrube o barramento inteiro

Em um barramento I²C padrão, se um único dispositivo entrar em falha e “grudar” SDA ou SCL em nível baixo (0 V), todo o sistema deixa de funcionar.
Isso é chamado de:

bus hanging ou bus lock

O diodo Schottky foi colocado justamente para impedir isso.

Suponha que o módulo U2 trave seu SDA em 0 V (falha interna).
Sem o diodo:

• O 0 V se propaga diretamente para o barramento.
• Todos os outros dispositivos ficam impedidos de enviar ou receber dados.
• O Arduino perde o controle de todo o barramento.

Com o diodo Schottky na configuração típica (ânodo no módulo, cátodo no barramento):

módulo ---- R ----+---- barramento
                       |
                      D (Schottky)
                       |
                   GND (via módulo)

módulo ---- R ----+---- barramento
                       |
                      D (Schottky)
                       |
                   GND (via módulo)

A linha do módulo pode cair a 0 V, mas o barramento só cai até a queda direta do diodo (~0,2 a 0,3 V).

Como o nível “LOW” em I²C é aceito até aproximadamente:

\[
V_{IL} \leq 0{,}3 \cdot V_{CC}
\]

E com Vcc=5 V:

\[
V_{IL} \leq 1{,}5,\text{V}
\]

Então, se o barramento cair para apenas 0,2 V, isso ainda é um LOW válido, e o master consegue recuperar o controle — especialmente se houver mecanismos como clock stretching ou re-varredura de dispositivos.

Em outras palavras:

A falha fica confinada apenas ao ramo do módulo defeituoso, e não contamina todo o barramento.

2.2 Como o Schottky atua eletricamente no instante da falha

Suponha:

• O módulo trava SDA em 0 V.
• O barramento está em nível alto (puxado por Rpull-up, ~5 V).
• A linha do módulo (lado depois do resistor) vai instantaneamente a 0 V.

A diferença de tensão passa a ser:

\[
V_{barramento} – V_{ramo} = 5,\text{V}
\]

Quando:

\[
V_{barramento} – V_{ramo} > V_f
\]

Onde \(V_f\) (queda direta) é:

• ~0,2–0,3 V (Schottky)
• ~0,6–0,7 V (diodo de silício comum)

Assim que essa condição se estabelece, o diodo conduz imediatamente, drenando para o módulo grande parte da corrente que iria para o barramento — ou seja:

• Protege o barramento
• Protege os outros módulos
• Minimiza a queda de tensão que o barramento sofre

O efeito prático é:

O barramento não vai a zero — fica “abaixo do ideal”, mas ainda dentro da faixa aceitável para LOW I²C.

2.3 Por que Schottky e não diodos comuns?

A escolha do Schottky é essencial por três características físicas:

1) Baixíssima queda de tensão direta ((V_f))

Enquanto um diodo de silício comum tem (V_f \approx 0{,}6) a 0,7 V:

\[
V_{f,\text{Si}} \approx 0.7,\text{V}
\]

O Schottky tem:

\[
V_{f,\text{Schottky}} \approx 0.2\text{–}0.3,\text{V}
\]

No contexto do I²C:

• Uma queda de 0,7 V derrubaria o barramento para valores próximos de LOW marginal.
• Já 0,2 V mantém o barramento operando dentro das margens elétricas com total segurança.

A norma I²C permite aproximadamente:

\[
V_{OL,max} = 0{,}4,\text{V}
\]

Portanto, o Schottky é a única escolha que garante operação dentro da especificação.

2) Corrente de saturação rápida e baixa capacitância

Schottys possuem:

• Capacitância muito baixa
  Importante para não prejudicar o tempo de subida SDA/SCL.
• Resposta extremamente rápida
  Essencial para proteger contra transientes.

Em I²C:

• Bordas não são rápidas como SPI, mas ainda assim a transitória causada por ruído ou falha precisa ser drenada antes de causar erro de leitura ou travamento.

3) Corrente reversa maior, mas controlável

Schottkys têm corrente reversa (leakage) maior, porém esse valor é:

• Da ordem de µA
• Bem pequeno comparado às correntes naturais de pull-up
• Completamente seguro dentro da operação I²C

O resistor série ajuda ainda a limitar qualquer efeito adverso dessa corrente reversa, tornando a combinação “R série + Schottky” ideal.

2.4 Análise matemática do efeito do diodo sobre o barramento

Suponha:

• Barramento em nível alto: (5,\text{V})
• Módulo em falha em (0,\text{V})
• Diodo conduz com (V_f = 0{,}25,\text{V})
• Resistor série em 220 Ω

A queda do barramento depende do divisor dinâmico formado por:

• Rpull-up
• Resistência efetiva do diodo (muito menor)
• Resistência série

Quando o diodo conduz, ele apresenta uma resistência dinâmica (r_d) pequena (alguns ohms).
O barramento sente algo como um divisor:

\[
V_{barramento} \approx \frac{R_{pull-up}}{R_{pull-up} + r_d + R_{série}} \cdot V_{CC}
\]

Se tomarmos, por exemplo:

• \(R_{pull-up} = 4700,\Omega\)
• \(R_{série} = 220,\Omega\)
• \(r_d = 5,\Omega\)

Então:

\[
V_{barramento} = \frac{4700}{4700 + 220 + 5} \cdot 5
= \frac{4700}{4925} \cdot 5
\approx 4{,}77,\text{V}
\]

O barramento praticamente não cai nada – a queda ocorre no ramo do módulo defeituoso.

Isso confirma matematicamente que:

O Schottky mantém o barramento íntegro mesmo com falha em um dos dispositivos.

2.5 Função adicional: proteção contra picos de tensão e ruído

Cabos longos, EMI e ESD podem gerar picos de tensão:

\[
V_{transiente} > V_{CC}
\]

O diodo Schottky, polarizado da forma como está, absorve excesso de tensão sempre que:

\[
V_{ramo} > V_{barramento} + V_f
\]

Ou seja, ele atua também como:

• Clamper contra sobretensão local
• Equalizador entre barramento e ramos
• Proteção coletiva contra ruído em qualquer módulo

2.6 Como o diodo interage com o resistor série

O par R + Schottky forma um circuito de proteção complementar:

1. O resistor limita corrente.
2. O diodo define um caminho seguro de desvio.

Se o módulo entra em curto:

• O resistor impede correntes destrutivas.
• O diodo impede o módulo de derrubar o barramento.

Se há ruído ou transiente:

• O diodo absorve picos.
• O resistor suaviza a energia e amortiza pulsos rápidos.

Se há capacitância excessiva num módulo:

• O resistor reduz o impacto no barramento.
• O diodo mantém a integridade do barramento caso a capacitância gere oscilações.

Essa combinação é muito usada em:

• Barramentos I²C industriais
• Sensores distribuídos
• Sistemas robustos tolerantes a falhas
• Aplicações automotivas de baixa velocidade

Conclusão

Os diodos Schottky desempenham três funções fundamentais:

1. Isolamento de falhas – evitando travamento total do barramento.
2. Clamping de tensão – protegendo contra picos ou ruído.
3. Proteção cooperativa com o resistor – mantendo o barramento íntegro.

Sua escolha é motivada por:

• Baixa queda direta (essencial para I²C)
• Alta velocidade
• Baixa capacitância
• Comportamento previsível em transientes

Essa estratégia permite que o sistema opere com vários módulos, longos cabos e falhas eventuais, sem travamento nem danos físicos.

Modelagem do Sistema, Síntese Técnica e Diretrizes de Dimensionamento

Tendo entendido separadamente o papel dos resistores em série e dos diodos Schottky, podemos agora consolidar o raciocínio em um modelo único que descreve matematicamente o comportamento do barramento, justificando cada escolha de componente e permitindo dimensionar adequadamente valores para aplicações reais. Este capítulo funciona como síntese técnica e guia de projeto.

3.1 Modelo elétrico equivalente de cada ramificação

Cada módulo I²C é visto pelo barramento principal através de três elementos:

1. R_série (220 Ω típico)
2. Diodo Schottky
3. Capacitância parasita + carga do CI

Um modelo simplificado pode ser representado assim:

      ┌───────────── Barramento SDA/SCL
      │
      R_série
      │
      +─── C_módulo (entrada CI)
      │
      D Schottky (ânodo no ramo, cátodo no barramento)
      │
   GND (referência do módulo)

      ┌───────────── Barramento SDA/SCL
      │
      R_série
      │
      +─── C_módulo (entrada CI)
      │
      D Schottky (ânodo no ramo, cátodo no barramento)
      │
   GND (referência do módulo)

Sob operação normal, o diodo fica reversamente polarizado e praticamente invisível.
A comunicação ocorre através do RC formado por:

\[
\tau = R_{série} \cdot C_{módulo}
\]

Nas transições, esse pequeno RC desacopla a capacitância do módulo e melhora a integridade de sinal.

Sob falha, o diodo passa a conduzir, criando um caminho alternativo que impede o módulo de derrubar o barramento.

3.2 Análise dos três estados possíveis

Estado 1 – Operação normal

• Correntes muito pequenas fluem no ramo.
• O resistor série é praticamente transparente.
• O diodo fica bloqueado.
• O tempo de subida é dominado por:

\[
t_r = 0{,}8473 \cdot R_{pull-up} \cdot C_{total}
\]

e não por R_série.

Estado 2 – Transientes / ruído

Se o ramo sofre sobretensão:

\[
V_{ramo} > V_{barramento} + V_f
\]

O Schottky conduz e “equaliza” tensões, evitando picos, protegendo o CI e melhorando EMC.

Se o barramento sofre ruído negativo (undershoot), o resistor série limita a corrente e remove energia do pulso.

Estado 3 – Falha em módulo (curto para GND)

• A linha do ramo fica em 0 V.
• O barramento tentaria cair a 0 V, mas o diodo entra na condução reversa:

\[
V_{barramento} \approx V_f = 0{,}2 \sim 0{,}3 V
\]

Esse valor ainda é considerado LOW válido pela especificação I²C.

O resistor série limita a corrente:

\[
I = \frac{V_{CC}}{R_{série}}
\]

Impedindo danos e mantendo o barramento operável.

3.3 A queda de tensão no barramento durante falha (análise mais precisa)

Para entender exatamente o quanto o barramento abaixa em caso de curto, podemos modelar como um divisor entre:

• Rpull-up
• Resistência dinâmica do diodo (r_d, típica 3 a 10 Ω)
• R_série

A tensão final é:

\[
V_{barr} \approx \frac{R_{pull-up}}{R_{pull-up}+R_{série}+r_d} \cdot V_{CC}
\]

Exemplo realista:

• (R_{pull-up} = 4{,}7 k\Omega)
• (R_{série} = 220 \Omega)
• (r_d = 5 \Omega)
• (V_{CC} = 5 V)

[
V_{barr} = \frac{4700}{4700 + 220 + 5} \cdot 5
\approx 4{,}77 V
]

Ou seja:

O barramento praticamente NÃO cai, mesmo com o módulo em curto!

E esta é a beleza da topologia: fixamos a queda no ramo, não no barramento.

3.4 Dimensão ideal dos resistores série

Regras práticas:

(1) Proteção contra falha

Para limitar a corrente a menos de 25 mA no pior caso:

\[
R_{série} \geq \frac{V_{CC}}{0{,}025}
\]

Para 5 V:

\[
R_{série} \geq 200\ \Omega
\]

Por isso 220 Ω é um valor tão comum.

(2) Impacto no tempo de subida

Para que o resistor série não atrapalhe a velocidade do I²C (até 400 kHz):

\[
R_{série} \cdot C_{entrada} \ll t_r
\]

Com:

• \(C_{entrada} \approx 15\text{–}30 pF\)
• \(t_r \approx 300\text{–}1000 ns\)

Então:

\[
R_{série} \ll \frac{t_r}{C_{entrada}}
\]

Exemplo:

\[
\frac{300 ns}{30 pF} = 10 k\Omega
\]

220 Ω está muito abaixo desse limite, logo não interfere no tempo de subida.

(3) Redução de ringing

Para cabos com:

• \(L \approx 500 nH\)
• \(C \approx 50 pF/m\)

Impedância característica aproximada:

\[
Z_0 \approx \sqrt{\frac{L}{C}}
\approx \sqrt{\frac{500 nH}{50 pF}}
\approx 100\ \Omega
\]

O resistor série deve ser da mesma ordem de grandeza.
Como o driver já oferece ~20–40 Ω internos, usamos:

\[
R_{série} \approx 100\Omega – R_{driver}
\]

E chegamos novamente a valores entre 100 e 220 Ω.

3.5 Dimensionamento ideal do diodo Schottky

Critérios:

(1) Baixa queda direta (V_f)

Deve atender:

\[
V_f < V_{OL,max}
\]

Na prática:

• I²C admite até 0,4 V para LOW
• Schottky típico oferece 0,2–0,3 V

(2) Capacitância baixa

Evitar impacto nas bordas:

\[
C_D < 20\ \text{pF}
\]

(3) Corrente de pico segura

Em falhas, a corrente é:

\[
I = \frac{V_{CC}}{R_{série}}
\approx 23 mA
\]

O diodo deve suportar isso confortavelmente, com folga.

(4) Tempo de resposta muito rápido

Absorver transientes antes que eles atinjam os CIs.

Diodos recomendados:

• BAT54
• 1N5819 (para correntes maiores, mas capacitância mais alta)
• RB751
• PMEG2010

3.6 Comparação com outras técnicas de proteção

A solução adotada no circuito analisado é uma das mais equilibradas para:

• projetos maker,
• sensores distribuídos,
• robótica,
• telemetria,
• automação residencial,
• painéis e cabos longos.

Diretrizes Práticas de Projeto, Recomendações de Uso e Exemplos de Dimensionamento

Este capítulo final reúne regras práticas, cenários de aplicação e exemplos concretos de cálculo para orientar o uso correto da topologia resistor série + diodo Schottky em projetos reais com barramento I²C.
Aqui é onde a teoria se traduz em procedimentos de engenharia aplicáveis ao dia a dia.

4.1 Quando essa topologia é recomendada

O uso de resistores série e diodos Schottky é extremamente útil quando o barramento I²C opera sob uma ou mais das seguintes condições:

Múltiplos dispositivos distribuídos em cabos longos

Tipicamente mais de 30–40 cm por ramificação.

Ambientes com ruído elétrico significativo

Como motores, solenoides, inversores, relés, rádios ou fontes chaveadas próximas.

Alta confiabilidade é necessária

Sistemas que não podem parar caso um único módulo apresente falha.

Uso de sensores ou placas com qualidade variável

Módulos de baixa procedência podem sofrer falhas de linha ou travamentos esporádicos.

A topologia física contém ramificações (“stubs”) no barramento

Cada stub adiciona capacitância, reflexões e risco de travamento.

Há troca frequente de módulos (plug and play)

Evita danos causados por ligações incorretas ou conexões intermitentes.

4.2 Quando não é necessário usar esta topologia

A solução é exagero se:

• O barramento é muito curto (poucos centímetros).
• O número de dispositivos é baixo (1 ou 2).
• A aplicação é extremamente sensível ao tempo de borda (raríssimo em I²C ≤ 400 kHz).
• Há buffers dedicados I²C (P82B96, TCA4311, PCA9515, etc.)

Em tais casos, resistores série podem até trazer pequenas vantagens, mas não são indispensáveis.

4.3 Guia completo para escolher o valor de R_série

A escolha correta depende de três fatores:
(1) corrente máxima aceitável,
(2) qualidade de sinal,
(3) capacitância do ramo.

4.3.1 Critério de segurança (corrente de curto)

Queremos:

\[
I_{máx} \le 25,mA
\]

Logo:

\[
R_{série} \ge \frac{V_{CC}}{0,025}
\]

Para:

4.3.2 Critério de integridade de sinal (amortecimento)

Se o cabo do ramo tem:

• Indutância típica: 500 nH/m
• Capacitância típica: 40–60 pF/m

Impedância característica aproximada:

\[
Z_0 \approx \sqrt{\frac{L}{C}} \approx 100,\Omega
\]

O resistor deve ser próximo de:

\[
R_{série} + R_{driver} \approx Z_0
\]

Como o driver do microcontrolador já tem ~20–50 Ω, adicionamos:

\[
R_{série} \approx 100 – R_{driver} \approx 100 – 30 = 70,\Omega
\]

Mas como precisamos também do critério de segurança (≥200 Ω), optamos por:

Valor ideal: 150 a 330 Ω

O valor clássico é 220 Ω pelo excelente compromisso.

4.3.3 Critério de atraso

O resistor não deve comprometer o tempo de subida:

[
R_{série} \cdot C_{ramo} \ll t_r
]

Com I²C Standard Mode (t_r ≈ 1000 ns) e C=30 pF:

[
R_{máx} \ll \frac{1000ns}{30pF} \approx 33k\Omega
]

Ou seja, 220 Ω está muito longe de prejudicar o desempenho.

4.4 Guia completo para escolher o diodo Schottky

Critérios fundamentais:

1) Queda direta deve ser menor que o LOW permitido

\[
V_f < 0{,}4,V
\]

Schottky típico: 0,2–0,3 V → atende perfeitamente.

2) Capacitância baixa

\[
C_D < 20\ pF
\]

Para não “roubar” corrente do pull-up e nem prejudicar bordas.

3) Corrente de pico suficiente

Suporta:

\[
I_{pico} \approx \frac{V_{CC}}{R_{série}} \approx 23,mA
\]

Qualquer Schottky padrão SMD atende.

4) Velocidade de comutação muito alta

Diodos comuns sofrem com recuperação reversa (reverse recovery), causando:

• Overshoot
• Oscilações
• Correntes negativas

O Schottky não apresenta recuperação reversa — ideal para I²C.

4.4.1 Diodos recomendados

Para I²C, BAT54 é o mais popular.

4.5 Exemplo completo de dimensionamento

Sistema hipotético:

• 4 módulos I²C (cada um com 25 pF)
• 1 metro de cabo por módulo (~50 pF/m)
• Tensão de operação: 5 V
• I²C a 100 kHz

1) Capacitância do ramo

\[
C_{ramo} = 25pF + 50pF = 75pF
\]

2) Resistência série (critério de segurança)

\[
R_{série} \ge \frac{5V}{25mA} = 200Ω
\]

Escolhemos 220 Ω.

3) Verificação de atraso:

\[
\tau = R_{série} \cdot C_{ramo}
= 220 \cdot 75pF = 16,5ns
\]

Muito menor que o limite (~1000 ns) → OK.

4) Verificação de amortecimento:

Impedância aproximada do cabo:

\[
Z_0 \approx 100Ω
\]

Com Rdriver ≈ 30 Ω:

\[
R_{total} = R_{driver} + R_{série}
= 30Ω + 220Ω
= 250Ω
\]

Acima de Z0 → subamortece levemente, o que é bom para ruído, sem risco de overshoot.

5) Escolha do diodo

Usamos BAT54:

• V_f = 0.24 V
• C_D = 10 pF
• Isup ≈ 200 mA (muito acima dos 23 mA de falha)

Resultado

Sistema robusto, tolerante a falhas, com integridade de sinal excelente.

4.6 Recomendações profissionais finais

Sempre usar resistores série ao conectar vários módulos distribuídos

Especialmente se os cabos forem longos ou de má qualidade.

Usar Schottky de baixa capacitância

Evite modelos “gordos” como 1N5819 quando puder.

Para cabos muito longos (>2 m), considerar buffers I²C

Como PCA9515 ou TCA9517.

Evitar “estrelas” em alta velocidade

Barramentos com muitos stubs podem exigir resistência maior.

Proteger fisicamente os cabos

Amarrar os pares SCL/SDA juntos reduz acoplamento de ruído.

Sempre medir a forma de onda com osciloscópio

A validação visual das bordas é parte essencial do processo.

4.7 Conclusão Final

A arquitetura do circuito analisado — resistores em série combinados com diodos Schottky — representa uma solução elegante e eficiente para aumentar a robustez do barramento I²C sem elevar muito o custo ou a complexidade. Esse método protege contra:

• Curto nos módulos
• Picos de tensão
• Capacitância excessiva
• Falhas internas de CI
• Ruído em cabos longos
• Travamentos (bus lock)

E tudo isso com impacto mínimo no desempenho elétrico e no tempo de subida do barramento.

The post Proteção Inteligente para Barramentos I²C: Como Resistores em Série e Diodos Schottky Aumentam a Confiabilidade de Sistemas Embarcados first appeared on MCU & FPGA.

Os iButtons da família Thermochron e Hygrochron representam uma das formas mais simples e confiáveis de implementar data loggers (registradores de dados) em aplicações industriais, laboratoriais e logísticas. Fabricados originalmente pela Dallas Semiconductor (hoje Maxim Integrated/Analog Devices), esses dispositivos encapsulam sensores de temperatura — e no caso da linha Hygrochron, também umidade relativa — dentro de um invólucro metálico de aço inoxidável no formato de uma pequena moeda. Esse encapsulamento robusto protege o circuito interno contra choques mecânicos, poeira, umidade e variações ambientais, tornando-os especialmente adequados para monitoramento de longo prazo.

O grande diferencial dos iButtons é a filosofia de uso baseada em missões: o usuário configura o dispositivo com um intervalo de amostragem (por exemplo, a cada 5 minutos), define alarmes ou limites de operação e, a partir daí, o iButton registra automaticamente os dados no seu próprio armazenamento interno, com carimbo de tempo (timestamp). Quando a missão termina, os dados são lidos via OneWire, um barramento extremamente simples que utiliza apenas um fio de dados e o retorno de terra.

Esses dispositivos são amplamente aplicados em monitoramento de transporte de alimentos e vacinas, controle ambiental de câmaras frias, rastreamento de temperatura em cadeias de suprimentos e até monitoramento de equipamentos industriais. A simplicidade do barramento OneWire permite integrá-los de forma prática em sistemas embarcados, como ESP32, STM32, AVR e outros microcontroladores populares.

A seguir, iniciaremos a apresentação dos principais modelos de Thermochron e suas características técnicas.

Modelos de Thermochron e Hygrochron iButtons

A família Thermochron é composta por vários modelos, cada um projetado para faixas de temperatura, resoluções e capacidades de memória específicas. Essa diversidade permite selecionar o dispositivo ideal para diferentes condições ambientais, desde monitoramento de produtos refrigerados até aplicações de alta temperatura. Já a família Hygrochron incorpora, além do sensor térmico, um sensor de umidade relativa, voltado para monitoramento ambiental completo.

A tabela a seguir resume os modelos Thermochron mais comuns e suas principais especificações técnicas. Essas características influenciam diretamente a precisão do monitoramento e a quantidade de dados que podem ser armazenados em uma única missão.

Modelos Thermochron:

Os modelos DS1921 são mais simples, voltados para aplicações gerais com baixa resolução e menor memória, enquanto a série DS1922 já oferece maior resolução, precisão aprimorada e memória superior. O DS1925L representa uma geração mais recente, com impressionantes 122 mil amostras — ideal para longas missões.

A linha Hygrochron, representada principalmente pelo DS1923, registra simultaneamente temperatura e umidade relativa. Ele utiliza o mesmo encapsulamento e protocolo OneWire, facilitando a integração em sistemas existentes.

Com essa visão geral dos modelos, podemos avançar para o capítulo seguinte, onde explicaremos como esses dispositivos funcionam como data loggers na prática.

Como os Thermochron e Hygrochron Funcionam como Data Loggers

O funcionamento dos Thermochron e Hygrochron como data loggers é baseado em um conceito simples e extremamente eficiente: a missão. Uma missão consiste em um conjunto de parâmetros configurados no dispositivo antes do início da coleta: intervalo de amostragem, limites de alarme, modo de operação de memória e eventuais ajustes de resolução. Após configurado, o iButton passa a registrar automaticamente os dados ambientais no seu armazenamento interno, sem depender de qualquer intervenção externa.

O microcontrolador interno do iButton registra cada amostra com um timestamp. Esse relógio interno pode ser sincronizado durante a inicialização da missão, garantindo que o histórico gerado possa ser analisado posteriormente de forma cronológica. A memória interna funciona como um buffer circular ou como uma memória linear, dependendo da configuração escolhida. No primeiro modo, quando a memória enche, os dados mais antigos são sobrescritos; já no modo linear, a gravação cessa ao atingir a capacidade total.

No caso dos modelos Hygrochron, os sensores de temperatura e umidade são registrados simultaneamente e armazenados de modo intercalado, mantendo a coerência temporal entre os dados. Essa característica os torna especialmente úteis em monitoramento ambiental em depósitos, galpões e transporte sensível.

A comunicação com o data logger é feita via barramento OneWire, que utiliza apenas um único fio de dados mais o retorno de terra. Toda a configuração e leitura dos dados é realizada por comandos trocados entre o microcontrolador hospedeiro (como um ESP32 ou STM32) e o iButton. O OneWire também fornece alimentação parasita para alguns modelos, eliminando a necessidade de fonte externa durante a comunicação.

Agora que entendemos como o processo de registro funciona, podemos seguir para o próximo capítulo, onde apresentaremos um exemplo de implementação prática com microcontrolador.

Exemplo Prático: Criando um Data Logger com Thermochron/Hygrochron e Microcontroladores

Para demonstrar o uso dos iButtons Thermochron e Hygrochron em um sistema real, vamos considerar uma implementação baseada em microcontroladores populares como ESP32 ou STM32. A lógica é essencialmente a mesma para qualquer plataforma, já que a comunicação ocorre por meio do protocolo OneWire, um barramento simples, robusto e amplamente suportado.

Nosso objetivo será apresentar um exemplo didático que:

1. Detecta um iButton no barramento OneWire.
2. Inicia uma missão configurando o intervalo de amostragem.
3. Lê periodicamente o status do dispositivo.
4. Faz a leitura completa dos dados registrados.

A seguir, apresento um pseudocódigo em estilo C, com foco na clareza para iniciantes, mas mantendo o rigor técnico necessário para compreensão do protocolo.

Pseudocódigo em C para um Data Logger com iButton

#include "onewire.h"
#include "thermochron.h"
#include <stdio.h>

// Exemplo: pino GPIO onde o OneWire está conectado
#define ONEWIRE_PIN 4

void app_main(void)
{
    onewire_bus_t ow;
    onewire_init(&ow, ONEWIRE_PIN);

    uint8_t rom[8];

    // Etapa 1: Procurar dispositivo no barramento
    if (!onewire_search(&ow, rom)) {
        printf("Nenhum iButton encontrado.\n");
        return;
    }

    printf("iButton encontrado! ROM = ");
    for (int i = 0; i < 8; i++) printf("%02X ", rom[i]);
    printf("\n");

    // Etapa 2: Iniciar missão
    thermochron_config_t config;
    config.sample_rate = 60;    // amostragem a cada 60 segundos
    config.start_delay = 0;     // iniciar imediatamente
    config.high_alarm = 30;     // alarme de temperatura alta (°C)
    config.low_alarm = 0;       // alarme de temperatura baixa (°C)

    if (!thermochron_start_mission(&ow, rom, &config)) {
        printf("Falha ao iniciar missão.\n");
        return;
    }

    printf("Missão iniciada com sucesso.\n");

    // Etapa 3: Aguardar coleta e verificar status
    while (1) {
        thermochron_status_t status;
        if (thermochron_read_status(&ow, rom, &status)) {
            printf("Amostras registradas: %d\n", status.samples);
            printf("Temperatura atual: %.2f°C\n", status.current_temp);
        }
        sleep(60);
    }

    // Etapa 4: Leitura completa da memória (após finalização)
    thermochron_log_t log;
    if (thermochron_read_log(&ow, rom, &log)) {
        for (int i = 0; i < log.count; i++) {
            printf("T%d = %.2f°C\n", i, log.values[i]);
        }
    }
}

#include "onewire.h"
#include "thermochron.h"
#include <stdio.h>

// Exemplo: pino GPIO onde o OneWire está conectado
#define ONEWIRE_PIN 4

void app_main(void)
{
    onewire_bus_t ow;
    onewire_init(&ow, ONEWIRE_PIN);

    uint8_t rom[8];

    // Etapa 1: Procurar dispositivo no barramento
    if (!onewire_search(&ow, rom)) {
        printf("Nenhum iButton encontrado.\n");
        return;
    }

    printf("iButton encontrado! ROM = ");
    for (int i = 0; i < 8; i++) printf("%02X ", rom[i]);
    printf("\n");

    // Etapa 2: Iniciar missão
    thermochron_config_t config;
    config.sample_rate = 60;    // amostragem a cada 60 segundos
    config.start_delay = 0;     // iniciar imediatamente
    config.high_alarm = 30;     // alarme de temperatura alta (°C)
    config.low_alarm = 0;       // alarme de temperatura baixa (°C)

    if (!thermochron_start_mission(&ow, rom, &config)) {
        printf("Falha ao iniciar missão.\n");
        return;
    }

    printf("Missão iniciada com sucesso.\n");

    // Etapa 3: Aguardar coleta e verificar status
    while (1) {
        thermochron_status_t status;
        if (thermochron_read_status(&ow, rom, &status)) {
            printf("Amostras registradas: %d\n", status.samples);
            printf("Temperatura atual: %.2f°C\n", status.current_temp);
        }
        sleep(60);
    }

    // Etapa 4: Leitura completa da memória (após finalização)
    thermochron_log_t log;
    if (thermochron_read_log(&ow, rom, &log)) {
        for (int i = 0; i < log.count; i++) {
            printf("T%d = %.2f°C\n", i, log.values[i]);
        }
    }
}

Explicação do Código

O código é estruturado para ser facilmente adaptado a frameworks como ESP-IDF ou HAL da STMicroelectronics:

• onewire_init() configura o GPIO no modo adequado para o barramento.
• onewire_search() encontra o iButton conectado e lê seu código ROM único de 64 bits.
• thermochron_start_mission() envia os comandos necessários para configurar a missão no Thermochron ou Hygrochron.
• thermochron_read_status() permite acompanhar o andamento da gravação, útil para sistemas embarcados que precisam exibir dados em tempo real.
• thermochron_read_log() extrai todos os valores armazenados ao final da missão.

Esse modelo é suficiente para construir sistemas reais de aquisição ambiental, podendo ser ampliado com RTC externo, armazenamento em SD card ou envio remoto via MQTT/WiFi.

Conclusão e Recomendações de Uso

Os Thermochron e Hygrochron iButtons representam uma solução extremamente prática, robusta e tecnicamente elegante para monitoramento ambiental em formato de data logger. Seu encapsulamento metálico, aliado ao protocolo OneWire, torna-os ideais para aplicações em que simplicidade de instalação, resistência física e confiabilidade são essenciais. A filosofia baseada em “missões” elimina a necessidade de supervisão contínua, permitindo que o dispositivo realize amostragens de maneira completamente autônoma ao longo de semanas ou meses.

A diversidade de modelos disponíveis permite escolher a solução exata para cada cenário: desde o DS1921, adequado a aplicações gerais e de baixo custo, até o DS1925L, com grande capacidade de memória para longas campanhas de medição. Para aplicações em que umidade também é um parâmetro crítico, o Hygrochron (como o DS1923) oferece monitoramento completo de ambiente em um único encapsulamento.

Do ponto de vista de implementação em sistemas embarcados, o barramento OneWire simplifica a conectividade e facilita a integração com plataformas como ESP32, STM32, AVR ou mesmo SBCs como Raspberry Pi. O exemplo apresentado demonstra que, com poucas funções de controle e leitura, é possível configurar uma missão, acompanhar sua execução e extrair os dados coletados de maneira ordenada e precisa.

Assim, seja para monitoramento de transporte de alimentos e vacinas, gestão ambiental de galpões, rastreamento térmico de equipamentos industriais ou projetos educacionais, os iButtons Thermochron e Hygrochron permanecem como ferramentas confiáveis e acessíveis para coleta de dados ambientais em escala compacta.

The post Thermochron e Hygrochron iButtons: Guia Completo de Uso, Modelos e Exemplo de Data Logger com OneWire first appeared on MCU & FPGA.