Quando falamos em JavaScript, é comum imaginar navegadores, servidores Node.js, aplicações web, painéis administrativos e sistemas de automação em nuvem. Porém, nos últimos anos, surgiram engines específicas para permitir que partes de um firmware sejam escritas em JavaScript, mesmo em ambientes extremamente restritos, como microcontroladores com pouca memória RAM, pouca Flash e baixo poder de processamento. Essa abordagem não substitui C ou C++ em todos os cenários, mas abre uma possibilidade interessante: usar JavaScript como linguagem de controle, automação, prototipação ou scripting embarcado.

Em sistemas embarcados tradicionais, especialmente aqueles baseados em microcontroladores, C e C++ continuam sendo as linguagens dominantes porque oferecem controle direto sobre memória, registradores, interrupções, periféricos e tempo de execução. Esse domínio é essencial quando lidamos com temporização precisa, drivers, comunicação em baixo nível, controle de motores, aquisição de sinais, DSP ou sistemas de tempo real. O próprio Bruce Powel Douglass destaca que sistemas embarcados trabalham sob restrições severas de memória, energia, custo, desempenho, confiabilidade e segurança, o que torna a escolha da linguagem e da arquitetura uma decisão crítica de projeto.

A vantagem do JavaScript nesse contexto está principalmente na produtividade. Um código em JavaScript pode ser mais simples de escrever, testar e modificar do que um código equivalente em C, especialmente quando o objetivo é criar lógica de alto nível, regras de automação, manipulação de JSON, comunicação com serviços web ou comportamento configurável pelo usuário. Em aplicações IoT, onde o dispositivo conversa com APIs, processa mensagens, recebe comandos remotos e executa regras de negócio, JavaScript pode ser uma camada conveniente acima do firmware nativo.

Outra vantagem importante é a capacidade de atualização dinâmica. Algumas engines permitem carregar ou alterar scripts sem recompilar todo o firmware. Isso é muito interessante em produtos que precisam ajustar regras de funcionamento em campo. Imagine um gateway IoT, um sensor inteligente ou um controlador de automação residencial: a camada de baixo nível continua em C, garantindo acesso seguro ao hardware, enquanto uma camada em JavaScript define comportamentos mais flexíveis. Esse modelo lembra a ideia de separar responsabilidades em camadas: o firmware nativo controla o hardware; o script expressa a lógica variável.

No entanto, essa flexibilidade tem custo. JavaScript normalmente exige uma engine de interpretação ou execução, o que consome Flash, RAM e ciclos de CPU. Mesmo engines otimizadas, como Espruino, Microvium, XS, mJS e JerryScript, precisam representar objetos, funções, strings, escopos e valores dinâmicos. Isso cria uma sobrecarga que não existiria em uma implementação puramente em C. Em microcontroladores muito pequenos, essa diferença pode inviabilizar o uso de JavaScript ou limitar fortemente o tamanho dos scripts.

Também existe o problema da previsibilidade temporal. JavaScript é uma linguagem dinâmica: tipos podem mudar em tempo de execução, objetos podem ser criados dinamicamente e algumas engines podem usar mecanismos de gerenciamento de memória. Em sistemas de tempo real, isso precisa ser analisado com muito cuidado. Um código que funciona bem em uma tarefa de configuração, telemetria ou automação pode não ser adequado para uma rotina de controle com deadline rígido, como PWM de alta precisão, leitura determinística de ADC por DMA ou controle de corrente em uma fonte chaveada.

Outro ponto crítico é a integração com o hardware. JavaScript não acessa diretamente registradores, interrupções ou periféricos da mesma forma que C. Ele depende de APIs fornecidas pela engine ou pelo firmware hospedeiro. Isso pode ser uma vantagem, porque cria uma camada mais segura e abstrata; mas também pode ser uma limitação, porque o desenvolvedor fica preso ao que a engine expõe. Em muitos projetos reais, a solução mais equilibrada é híbrida: C/C++ implementa drivers, HAL, protocolos críticos e rotinas temporais; JavaScript implementa scripts de configuração, regras de negócio, automação e lógica de aplicação.

A segurança também deve ser considerada. Permitir scripts em um dispositivo embarcado significa abrir uma superfície adicional de erro. Um script mal escrito pode consumir memória, travar uma lógica de aplicação, gerar loops indesejados ou acessar funções expostas de forma inadequada. Por isso, em produtos profissionais, a engine JavaScript deve ser usada com limites claros: controle de memória, validação de scripts, APIs restritas, watchdog, testes de integração e, quando necessário, assinatura ou autenticação do código carregado.

Portanto, usar JavaScript em microcontroladores não deve ser visto como “trocar C por JavaScript”. A visão mais madura é entender JavaScript como uma camada complementar. Ele é útil quando o projeto precisa de produtividade, atualização rápida, scripting, integração com JSON, regras configuráveis ou facilidade para desenvolvedores vindos do mundo web. Ele é menos indicado quando o projeto exige controle absoluto de tempo, uso mínimo de memória, certificação rigorosa, processamento digital pesado ou acesso intenso e direto ao hardware.

No restante do artigo, analisaremos algumas das principais engines que tornam essa abordagem possível: Espruino, Microvium, Moddable SDK com XS Engine, mJS da Cesanta e JerryScript. Cada uma adota uma estratégia diferente para resolver o mesmo desafio: como levar JavaScript para um ambiente onde cada kilobyte de RAM, cada kilobyte de Flash e cada ciclo de CPU importam.

The post JavaScript em Microcontroladores: Espruino, Microvium, Moddable XS, mJS e JerryScript first appeared on MCU & FPGA.

Em sistemas embarcados, nem todo dado pode ficar apenas em variáveis, memória RAM ou registradores. Um microcontrolador frequentemente precisa guardar configurações, logs, arquivos de calibração, certificados, imagens, modelos de IA embarcada, tabelas de parâmetros, amostras de sensores e dados coletados em campo. Quando esses dados precisam sobreviver a um reset ou à falta de energia, entramos no domínio do armazenamento não volátil.

É nesse ponto que surge a necessidade de um sistema de arquivos. Um sistema de arquivos é uma camada de software responsável por organizar dados persistentes em estruturas compreensíveis: arquivos, diretórios, nomes, metadados, posições de leitura e escrita, controle de espaço livre e, em alguns casos, mecanismos de recuperação contra falhas. Sem essa camada, o firmware teria que gravar diretamente blocos crus de memória, controlando manualmente endereços, apagamentos, alinhamento, desgaste e integridade.

No mundo dos microcontroladores, porém, o problema é mais delicado do que em um computador comum. O firmware trabalha com pouca memória RAM, tempo de execução limitado, risco de queda súbita de energia, ciclos de escrita finitos e diferentes tipos de mídia. Uma memória NOR Flash externa via SPI tem comportamento muito diferente de um cartão SD. A Flash exige apagamento por blocos, escrita com restrições físicas e controle de desgaste. Já o cartão SD possui um controlador interno que oculta boa parte da complexidade da NAND Flash usada dentro do cartão.

Por isso, comparar LittleFS e SPIFFS diretamente em um projeto com SD Card exige cuidado. O LittleFS foi projetado como um sistema de arquivos pequeno, resistente a falhas de energia, com desgaste distribuído e uso limitado de RAM/ROM para dispositivos de Flash embarcada. A própria documentação do projeto destaca recursos como dynamic wear leveling e uso de memória limitado. (GitHub) O SPIFFS, por sua vez, também foi criado para dispositivos SPI NOR Flash, com foco em alvos embarcados pequenos, pouca RAM e desgaste de blocos de Flash. (GitHub)

Isso significa que, em um projeto com STM32N6 + SD Card + FreeRTOS, o sistema de arquivos mais natural normalmente seria FATFS ou FreeRTOS+FAT, porque cartões SD são tradicionalmente formatados em FAT/FAT32/exFAT e precisam ser lidos por computadores, celulares, câmeras, gravadores e ferramentas comuns. Já LittleFS e SPIFFS fazem mais sentido quando o armazenamento é uma Flash externa ou interna acessada diretamente pelo microcontrolador, não um SD Card convencional.

O STM32N6 é uma família moderna da STMicroelectronics baseada em Arm Cortex-M55 a 800 MHz, voltada a aplicações embarcadas de alto desempenho, inclusive com recursos adequados para aplicações complexas de borda. (STMicroelectronics) Em um sistema desse tipo, usar SD Card é bastante coerente para registrar grandes volumes de dados, armazenar arquivos de configuração, gravar logs de inferência, coletar amostras de sensores ou guardar modelos e metadados de aplicação. O FreeRTOS entra apenas como camada de execução concorrente: uma tarefa pode coletar dados, outra pode gravar no cartão, outra pode transmitir pela rede, mas o sistema de arquivos precisa ser protegido contra acesso simultâneo indevido.

Portanto, neste artigo, vamos tratar o tema de forma prática: primeiro entenderemos as diferenças entre LittleFS, SPIFFS e sistemas FAT para SD Card; depois veremos quando usar cada um; em seguida construiremos exemplos em C para STM32N6 com SD Card e FreeRTOS; e, por fim, mostraremos como adaptar a ideia para LittleFS e SPIFFS, mesmo explicando por que eles não são a escolha mais natural para um cartão SD comum.

Nesta primeira parte, a ideia central é simples: sistema de arquivos em microcontrolador não é apenas “salvar um arquivo”; é escolher uma estratégia de persistência compatível com a mídia física, com a robustez desejada e com os limites do firmware.

The post Sistemas de Arquivos em Microcontroladores: LittleFS, SPIFFS e SD Card no STM32N6 first appeared on MCU & FPGA.

Quando pensamos na missão Apollo, é natural imaginar os foguetes Saturn V, os astronautas, os centros de controle da NASA e a imensa infraestrutura criada para levar seres humanos à Lua. Mas uma das partes mais decisivas dessa história cabia dentro da nave e operava com recursos que hoje pareceriam quase absurdos: o Apollo Guidance Computer, ou AGC, o computador de orientação usado no módulo de comando e no módulo lunar.

O AGC não era um computador genérico. Ele era um sistema embarcado crítico, projetado para executar funções muito específicas: navegação, orientação, controle de atitude, apoio ao pouso lunar e interação com os astronautas por meio da interface chamada DSKY, sigla para Display and Keyboard. Essa interface permitia que os astronautas enviassem comandos numéricos ao computador usando combinações de “verbos” e “substantivos”, uma forma compacta e direta de conversar com a máquina em pleno voo. (Wikipedia)

A limitação mais conhecida do AGC está na memória. O modelo usado nas missões Apollo possuía 2.048 words de memória erasable, usada como memória regravável para dados temporários, e 36.864 words de memória fixed, usada como memória permanente de programa. Essas “words” não devem ser confundidas diretamente com bytes modernos, porque a arquitetura usava palavras de 16 bits, com 15 bits úteis e 1 bit de paridade. Por isso, quando se diz de forma simplificada que o AGC tinha algo próximo de “4 KB de RAM”, estamos fazendo uma aproximação didática a partir da memória erasable. (Wikipedia)

Essa precisão é importante porque nos impede de transformar a história em mito. O AGC não era “fraco” por incompetência tecnológica. Pelo contrário: ele era uma solução extremamente sofisticada para as restrições de sua época. Peso, consumo de energia, volume, dissipação térmica, confiabilidade e previsibilidade eram fatores tão importantes quanto capacidade de processamento. Na engenharia embarcada, esse tipo de restrição continua sendo decisivo. Sistemas embarcados normalmente precisam executar funções reais, com recursos limitados e fortes exigências de desempenho, confiabilidade, robustez e segurança.

Na década de 1960, colocar um computador digital dentro de uma espaçonave era uma decisão ousada. Computadores ainda eram grandes, caros e, muitas vezes, tratados como equipamentos de apoio em solo. A NASA e o MIT Instrumentation Laboratory seguiram por outro caminho: levar a computação para dentro da missão. Isso significava confiar ao software decisões que afetariam diretamente a vida dos astronautas e o sucesso do pouso.

Essa escolha mudou a história da engenharia. O software deixou de ser apenas uma sequência de instruções auxiliares e passou a fazer parte do núcleo funcional da missão. Ele precisava responder em tempo real, lidar com sensores, interpretar comandos humanos, calcular trajetórias, preservar tarefas críticas e continuar funcionando mesmo quando o sistema fosse pressionado além do esperado.

Hoje, quando abrimos dezenas de abas no navegador, usamos frameworks pesados e tratamos memória como recurso abundante, é difícil imaginar uma equipe discutindo cada instrução como se ela tivesse peso físico. Mas no Projeto Apollo, ela tinha. Cada palavra de memória precisava ser justificada. Cada rotina precisava ter uma razão clara para existir. Cada decisão de projeto precisava equilibrar desempenho, confiabilidade e uso mínimo de recursos.

Essa escassez não destruiu a criatividade dos engenheiros. Ela a organizou. Quando tudo é limitado, o projeto precisa ser mais claro. Quando não há espaço para desperdício, a arquitetura precisa ser mais disciplinada. Quando uma falha pode comprometer uma missão inteira, o código deixa de ser apenas funcional e passa a ser uma peça de engenharia crítica.

Essa é uma lição muito atual para quem trabalha com microcontroladores, firmware, RTOS, bare metal, FPGA, IoT ou sistemas distribuídos em borda. Mais memória e mais processamento não garantem automaticamente sistemas melhores. Muitas vezes, eles apenas escondem decisões ruins por mais tempo. O Apollo Guidance Computer nos lembra que excelência técnica não nasce da abundância, mas da disciplina aplicada sob restrições reais.

A pergunta que fica para nós, desenvolvedores modernos, é simples e desconfortável: se o nosso sistema tivesse apenas alguns kilobytes disponíveis para executar uma função crítica, nosso código sobreviveria?

Na próxima seção, vamos entrar na transformação mais importante dessa história: o momento em que Margaret Hamilton e sua equipe ajudaram a mostrar que software também precisava ser tratado como engenharia.

The post Apollo Guidance Computer: o software embarcado que levou a humanidade à Lua first appeared on MCU & FPGA.

JSON, sigla para JavaScript Object Notation, é um formato textual usado para representar dados estruturados. Apesar de ter nascido no ecossistema JavaScript, hoje ele é amplamente usado em APIs web, sistemas IoT, serviços REST, comunicação entre dispositivos, arquivos de configuração e troca de mensagens entre firmware e aplicações externas.

Em microcontroladores, JSON aparece principalmente quando o dispositivo precisa conversar com algum sistema externo. Por exemplo, um ESP32 pode enviar leituras de temperatura para um servidor HTTP; um STM32 com modem 4G pode publicar dados em uma API; um RP2040 conectado a um gateway pode receber parâmetros de calibração; ou um dispositivo industrial pode gerar mensagens estruturadas para diagnóstico remoto.

A grande vantagem do JSON é a legibilidade. Uma mensagem como esta:

{
  "device": "sensor-01",
  "temperature": 27.5,
  "humidity": 61.2,
  "relay": true
}

{
  "device": "sensor-01",
  "temperature": 27.5,
  "humidity": 61.2,
  "relay": true
}

é fácil de entender tanto por humanos quanto por máquinas. Isso ajuda no desenvolvimento, no teste, no debug e na integração com sistemas web. Em vez de criar um protocolo binário próprio logo no início do projeto, muitas vezes podemos começar com JSON para acelerar a prototipagem e tornar a comunicação mais clara.

Mas existe um ponto importante: JSON não é o formato mais eficiente para microcontroladores pequenos. Ele consome mais memória que um protocolo binário, ocupa mais bytes na comunicação e exige processamento para converter texto em dados internos. Em um microcontrolador com poucos kilobytes de RAM, isso precisa ser tratado com cuidado.

Por isso, em sistemas embarcados, usamos JSON quando a clareza, a interoperabilidade e a integração com serviços externos são mais importantes do que a máxima economia de memória. Essa é uma decisão típica de projeto embarcado: escolher uma solução que facilite a comunicação, mas sem ignorar restrições de RAM, Flash, tempo de execução e robustez. Esse cuidado está alinhado com a visão clássica de desenvolvimento embarcado em C, onde restrições de memória, desempenho, confiabilidade e custo recorrente influenciam diretamente as decisões de arquitetura.

Neste tutorial, vamos usar a biblioteca cJSON, uma biblioteca em linguagem C para criar e interpretar documentos JSON. A ideia será manter tudo genérico, sem depender de ESP-IDF, STM32 HAL, Pico SDK, Zephyr ou FreeRTOS. Quando precisarmos simular comunicação com um servidor web, usaremos funções mock, ou seja, funções falsas que imitam o comportamento de uma API externa.

A arquitetura básica do nosso exemplo será esta:

+-------------------------+
|     Aplicação MCU       |
|                         |
|  Lê sensores simulados  |
|  Monta JSON com cJSON   |
|  Envia para Web Mock    |
|  Recebe resposta JSON   |
|  Interpreta resposta    |
+-----------+-------------+
            |
            v
+-------------------------+
| Serviço Web Simulado    |
|                         |
| Recebe JSON             |
| Processa dados fake     |
| Retorna JSON            |
+-------------------------+

Neste primeiro momento, podemos imaginar que o microcontrolador coleta dados de sensores e envia essas informações para um servidor. O servidor, por sua vez, responde com alguma configuração, como ligar ou desligar um relé, alterar o intervalo de amostragem ou informar se houve erro na requisição.

Um exemplo de mensagem enviada pelo microcontrolador poderia ser:

{
  "device_id": "mcu-001",
  "temperature": 28.75,
  "voltage": 3.29,
  "uptime": 15240
}

{
  "device_id": "mcu-001",
  "temperature": 28.75,
  "voltage": 3.29,
  "uptime": 15240
}

E uma resposta simulada do servidor poderia ser:

{
  "status": "ok",
  "relay": true,
  "sample_interval_ms": 5000
}

{
  "status": "ok",
  "relay": true,
  "sample_interval_ms": 5000
}

Perceba que o JSON permite representar textos, números, valores booleanos, objetos e listas. Isso é muito útil quando queremos criar mensagens flexíveis. Porém, em firmware, devemos evitar documentos JSON muito grandes, objetos muito profundos e alocações dinâmicas descontroladas.

Ao longo do tutorial, vamos trabalhar com quatro ideias principais: criar JSON, converter JSON para texto, interpretar JSON recebido e proteger o firmware contra erros de formato. A biblioteca cJSON facilita bastante esse processo, mas ela não elimina a responsabilidade do programador embarcado. Sempre será necessário verificar ponteiros, validar tipos, controlar tamanho de buffers e liberar memória corretamente.

The post Usando JSON e cJSON em Microcontroladores first appeared on MCU & FPGA.

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.

Os conversores analógico-digitais do tipo Delta-Sigma, também chamados de Sigma-Delta (ΣΔ), representam uma das arquiteturas de conversão mais importantes da eletrônica moderna, especialmente em aplicações que exigem alta resolução, excelente imunidade a ruído e grande precisão. Eles são amplamente utilizados em instrumentos de medição, sistemas de áudio digital, sensores industriais, balanças eletrônicas, sistemas biomédicos, aquisição de sinais lentos e equipamentos científicos.

Diferentemente de arquiteturas clássicas como Flash ADC, SAR (Successive Approximation Register) ou Pipeline ADC, o conversor Delta-Sigma não tenta converter instantaneamente o valor analógico em um número digital final. Em vez disso, ele utiliza uma estratégia baseada em superamostragem (oversampling), modelagem espectral de ruído (noise shaping) e filtragem digital para reconstruir o sinal com elevada precisão.

O surgimento dessa arquitetura está diretamente ligado às limitações físicas dos conversores tradicionais. Em sistemas de alta resolução, aumentar a precisão usando apenas comparadores extremamente precisos torna-se caro, complexo e energeticamente ineficiente. O Delta-Sigma contorna esse problema utilizando princípios matemáticos e temporais para deslocar o ruído de quantização para frequências mais altas, permitindo removê-lo posteriormente através de filtros digitais.

Uma das razões do enorme sucesso dos ADCs Delta-Sigma é que eles combinam:

• Alta resolução (16, 24 e até 32 bits efetivos em aplicações específicas)
• Excelente linearidade
• Forte rejeição a ruídos
• Baixo custo relativo em CMOS moderno
• Grande integração digital

Isso explica por que praticamente todo codec de áudio moderno, muitos sensores MEMS e diversos instrumentos industriais utilizam essa arquitetura.

Além disso, a evolução dos microcontroladores e FPGAs tornou o estudo dos conversores Delta-Sigma ainda mais relevante. Muitos microcontroladores modernos já possuem ADCs Sigma-Delta integrados, enquanto FPGAs frequentemente implementam moduladores Delta-Sigma em aplicações de aquisição de sinais, áudio e controle de potência.

Antes de entender profundamente o funcionamento interno do conversor Delta-Sigma, é importante compreender um conceito fundamental: o processo de amostragem e o problema do ruído de quantização.

O Problema da Quantização

Todo conversor analógico-digital precisa transformar uma grandeza contínua em um conjunto discreto de valores binários. Esse processo inevitavelmente introduz um erro chamado erro de quantização.

Imagine um sinal analógico variando continuamente entre 0V e 3,3V. Um ADC de baixa resolução possui poucos níveis possíveis para representar esse sinal. Assim, o valor real do sinal precisa ser arredondado para o nível digital mais próximo.

Por exemplo, um ADC de 3 bits possui apenas:

2^3 = 8

níveis possíveis de quantização.

Se o intervalo for de 0V até 3,3V, então cada degrau representará aproximadamente:

\[\frac{3.3V}{8} \approx 0.4125V\]

Isso significa que pequenas variações menores que aproximadamente 412 mV simplesmente desaparecem na conversão.

O erro introduzido pela diferença entre o valor analógico real e o valor digital representado é chamado ruído de quantização.

Em arquiteturas tradicionais, esse ruído está distribuído aproximadamente de forma uniforme ao longo do espectro de frequência. O grande diferencial do Delta-Sigma é justamente modificar essa distribuição espectral do ruído, empurrando-o para regiões de frequência onde ele pode ser removido digitalmente.

Em outras palavras:

• O ruído não desaparece
• O conversor reorganiza onde ele aparece no espectro

Esse conceito é chamado de Noise Shaping (Modelagem de Ruído), sendo um dos pilares matemáticos do conversor Delta-Sigma.

Superamostragem (Oversampling)

Outro conceito essencial no Delta-Sigma é a superamostragem.

Um ADC convencional normalmente amostra próximo da frequência mínima necessária definida pelo Teorema de Nyquist:

f_s \geq 2f_{max}

Já o Delta-Sigma trabalha com frequências de amostragem extremamente maiores que a banda útil do sinal.

Por exemplo:

• Áudio de 20 kHz
• ADC operando em vários MHz

Essa superamostragem traz duas vantagens fundamentais:

1. O ruído de quantização é espalhado em uma faixa espectral muito maior
2. O filtro digital posterior consegue remover boa parte desse ruído

Combinando:

• Oversampling
• Noise shaping
• Filtragem digital

o conversor Delta-Sigma consegue atingir resoluções extremamente elevadas usando hardware analógico relativamente simples.

Na próxima seção veremos a estrutura interna do modulador Delta-Sigma, incluindo:

• Integrador
• Comparador
• Realimentação (feedback)
• DAC interno
• Fluxo de bits do modulador
• Funcionamento temporal do laço Sigma-Delta
• Papel do filtro digital de decimação

Além disso, começaremos a comparar formalmente essa arquitetura com ADCs SAR, Flash e Pipeline.

The post Conversor Analógico Delta-Sigma (ΔΣ ADC) 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.

Introdução

A engenharia de software tem evoluído continuamente na tentativa de equilibrar três forças fundamentais: previsibilidade, produtividade e qualidade. Desde abordagens clássicas como o modelo em cascata, passando por frameworks estruturados como o RUP (Rational Unified Process), até metodologias ágeis modernas, o objetivo permanece o mesmo: transformar requisitos em sistemas funcionais de forma confiável e eficiente.

No entanto, uma mudança significativa vem ocorrendo com o avanço da Inteligência Artificial Generativa aplicada ao desenvolvimento de software. Modelos como OpenAI Codex, Claude Opus e sistemas especializados como SWE-agent não apenas auxiliam na escrita de código, mas passam a atuar como agentes ativos no ciclo de desenvolvimento, participando da interpretação de requisitos, análise de comportamento e validação de sistemas.

Esse novo cenário exige uma revisão das metodologias tradicionais. Enquanto modelos como o PDCA (Plan, Do, Check, Act) e processos como o RUP estruturam o desenvolvimento em ciclos iterativos, eles não foram concebidos considerando a presença de agentes inteligentes capazes de gerar, testar, analisar e corrigir código de forma autônoma e contínua. Surge então a necessidade de uma abordagem que integre explicitamente a IA como parte do processo, não apenas como ferramenta auxiliar.

É nesse contexto que se propõe a metodologia PDCL (Plan, Do, Check Logs). Inspirada nos princípios clássicos de melhoria contínua, mas adaptada à realidade da engenharia assistida por IA, essa abordagem introduz um elemento central: o uso estruturado de logs como meio de comunicação, validação e realimentação entre o sistema em execução e a inteligência artificial responsável por sua evolução.

Diferentemente das metodologias tradicionais, onde a validação depende majoritariamente de testes explícitos e inspeção humana, o PDCL estabelece um ciclo automatizado no qual a aplicação é continuamente executada, seus logs analisados, e o código refinado com base na comparação entre comportamento observado e requisitos definidos. Esse processo cria um loop fechado de desenvolvimento, onde a IA atua como agente de execução, análise e correção.

Essa proposta dialoga diretamente com conceitos consolidados da engenharia de software. Assim como os padrões de projeto são utilizados para otimizar atributos de qualidade — como desempenho, confiabilidade e manutenibilidade —, o PDCL pode ser entendido como um padrão de processo, voltado à otimização da interação entre humanos e sistemas inteligentes no ciclo de desenvolvimento.

Nos próximos tópicos, será apresentada a estrutura formal da metodologia PDCL, detalhando seus componentes, fluxo de execução e mecanismos de integração com IA generativa, seguida de um exemplo prático e uma análise crítica de suas implicações.

The post PDCL (Plan, Do, Check Logs) com GenAI: A Nova Metodologia de Engenharia de Software Orientada por Logs e Inteligência Artificial Generativa first appeared on MCU & FPGA.

Em firmware industrial e IoT de produção, o problema raramente é “como ler um sensor” ou “como reagir a uma interrupção”. O desafio real está em como transformar eventos assíncronos e imprevisíveis (interrupções de hardware, timeouts, pacotes de rede, watchdogs) em fluxos determinísticos, observáveis e recuperáveis — sem violar latência, sem bloquear ISRs, sem explodir prioridade e sem criar acoplamentos frágeis entre camadas.

O Zephyr RTOS se destaca exatamente por oferecer primitivas complementares — Interrupções, Soft Timers (k_timer) e Workqueues (k_work) — que, quando combinadas corretamente, permitem desenhar pipelines de eventos robustos, usados em produtos reais: gateways industriais, sensores remotos, equipamentos médicos, automação predial e dispositivos conectados operando por anos no campo.

Este artigo não trata essas primitivas de forma isolada. O foco é arquitetural:
como compor essas ferramentas para criar fluxos de processamento desacoplados, previsíveis e testáveis, respeitando as regras fundamentais de sistemas embarcados modernos:

• ISR mínima: interrupção apenas sinaliza, nunca processa.
• Tempo como evento: temporização explícita, não “sleep espalhado”.
• Processamento fora de ISR: trabalho pesado sempre em contexto de thread.
• Backpressure e ordenação: eventos fluem por etapas bem definidas.
• Escalabilidade: o desenho deve sobreviver ao crescimento do sistema.

Ao longo das próximas seções, vamos evoluir de um modelo mental até códigos concretos em C, mostrando:

1. O papel correto de Interrupções no Zephyr.
2. Como Soft Timers viram fontes de eventos temporais confiáveis.
3. Como Workqueues funcionam como estágios de processamento.
4. Como integrar tudo isso em pipelines de eventos industriais, com exemplos reais de firmware.

A ideia é que, ao final, você não apenas “saiba usar” essas APIs, mas consiga enxergar a arquitetura por trás de um firmware profissional — aquele que não depende de sorte, nem de atrasos mágicos, nem de lógica escondida em ISR.

The post Zephyr e Integração Avançada: Interrupções + Soft Timers + Workqueues first appeared on MCU & FPGA.

Frase-chave foco

1 – Introdução: o papel de Interrupções e Soft Timers em um RTOS moderno

Em sistemas embarcados modernos, especialmente aqueles baseados em um RTOS (Real-Time Operating System) como o Zephyr OS, a forma como lidamos com eventos assíncronos define diretamente a robustez, a previsibilidade temporal e a escalabilidade do firmware. Dois mecanismos são absolutamente centrais nesse contexto: interrupções de hardware e soft timers. Embora ambos sejam usados para reagir a eventos no tempo ou no mundo físico, eles possuem naturezas, custos e implicações arquiteturais bastante distintas.

As interrupções permitem que o hardware “interrompa” a execução normal da CPU para tratar eventos críticos e de baixa latência, como mudanças em GPIOs, chegada de dados em periféricos ou estouros de contadores. Já os soft timers do Zephyr são abstrações de alto nível baseadas no kernel, que permitem executar callbacks temporizados sem recorrer a timers de hardware dedicados ou lógica de polling. Essa separação clara entre o que é tempo crítico e o que é tempo gerenciado pelo kernel é uma das grandes virtudes do Zephyr.

Um erro comum de quem vem de arquiteturas bare-metal ou de RTOS mais simples é tentar resolver tudo com interrupções. No Zephyr, isso é um anti-padrão arquitetural. O sistema foi projetado para que interrupções sejam curtas, determinísticas e não bloqueantes, delegando o processamento mais pesado para threads, workqueues ou timers. Entender essa filosofia é essencial para escrever firmware escalável e seguro.

Ao longo deste artigo, vamos explorar:

• Como o Zephyr trata interrupções de forma portável e segura
• Como configurar e usar ISRs (Interrupt Service Routines) corretamente
• Como funcionam os Soft Timers (k_timer)
• Quando usar interrupção, timer ou thread
• Padrões e armadilhas comuns em projetos reais

Sempre com exemplos em C, comentados e aplicáveis a placas reais como STM32, nRF e RP2040.

2 – Modelo de Interrupções no Zephyr: conceitos fundamentais

Antes de escrever qualquer ISR no Zephyr, é fundamental entender que o sistema adota um modelo de interrupções abstraído, desacoplado do hardware específico, mas ainda permitindo acesso direto quando necessário. O Zephyr se apoia em três pilares principais:

1. Árvore de dispositivos (Devicetree)
2. API genérica de IRQ do kernel
3. Separação rígida entre contexto de interrupção e contexto de thread

No Zephyr, interrupções não são configuradas diretamente em registradores no código da aplicação (como em bare-metal). Em vez disso, elas são declaradas e conectadas por meio do Devicetree, que descreve o hardware de forma declarativa. Isso permite que o mesmo código rode, sem modificações, em arquiteturas distintas.

O que é uma ISR no Zephyr?

Uma ISR (Interrupt Service Routine) no Zephyr é uma função C comum, mas com restrições severas:

• Não pode bloquear
• Não pode usar k_sleep()
• Não pode alocar memória dinâmica
• Não pode chamar APIs que dependem do escalonador

Ela deve apenas:

• Reconhecer o evento
• Capturar dados mínimos
• Sinalizar uma thread, timer ou workqueue

Esse modelo força uma arquitetura mais limpa e previsível.

3 – Conectando uma interrupção no Zephyr (exemplo com GPIO)

Vamos começar com um exemplo clássico: interrupção por mudança de nível em um pino GPIO, algo extremamente comum em botões, sensores e sinais externos.

Passo 1 – Definição no Devicetree (conceito)

O Zephyr já fornece nós de GPIO prontos no Devicetree. Em geral, você não precisa criar nada manualmente, apenas referenciar o pino correto.

Exemplo conceitual (simplificado):

button0: button_0 {
    gpios = <&gpioa 0 GPIO_ACTIVE_LOW>;
};

button0: button_0 {
    gpios = <&gpioa 0 GPIO_ACTIVE_LOW>;
};

Passo 2 – Estrutura de callback de GPIO

No Zephyr, interrupções de GPIO usam a estrutura gpio_callback.

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>

/* Callback associado à interrupção */
static struct gpio_callback button_cb_data;

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>

/* Callback associado à interrupção */
static struct gpio_callback button_cb_data;

Passo 3 – Implementação da ISR

A função de callback será executada em contexto de interrupção:

void button_pressed_isr(const struct device *dev,
                        struct gpio_callback *cb,
                        uint32_t pins)
{
    ARG_UNUSED(dev);
    ARG_UNUSED(cb);
    ARG_UNUSED(pins);

    /* ISR deve ser curta e não bloqueante */
    printk("Botão pressionado!\n");
}

void button_pressed_isr(const struct device *dev,
                        struct gpio_callback *cb,
                        uint32_t pins)
{
    ARG_UNUSED(dev);
    ARG_UNUSED(cb);
    ARG_UNUSED(pins);

    /* ISR deve ser curta e não bloqueante */
    printk("Botão pressionado!\n");
}

Observação importante:
Mesmo o printk() não é ideal dentro de ISR em sistemas críticos. Ele é usado aqui apenas para fins didáticos. Em projetos reais, o correto é sinalizar uma thread.

Passo 4 – Configuração do GPIO e da interrupção

const struct device *button_dev;

button_dev = DEVICE_DT_GET(DT_NODELABEL(gpioa));

gpio_pin_configure(button_dev, 0, GPIO_INPUT | GPIO_PULL_UP);

gpio_pin_interrupt_configure(button_dev,
                              0,
                              GPIO_INT_EDGE_FALLING);

gpio_init_callback(&button_cb_data,
                   button_pressed_isr,
                   BIT(0));

gpio_add_callback(button_dev, &button_cb_data);

const struct device *button_dev;

button_dev = DEVICE_DT_GET(DT_NODELABEL(gpioa));

gpio_pin_configure(button_dev, 0, GPIO_INPUT | GPIO_PULL_UP);

gpio_pin_interrupt_configure(button_dev,
                              0,
                              GPIO_INT_EDGE_FALLING);

gpio_init_callback(&button_cb_data,
                   button_pressed_isr,
                   BIT(0));

gpio_add_callback(button_dev, &button_cb_data);

Neste ponto:

• O hardware gera a interrupção
• O driver de GPIO chama a ISR
• O kernel garante isolamento e segurança

4 – Arquitetura correta: ISR + sinalização de thread

A forma correta de usar interrupções no Zephyr é acordar ou sinalizar uma thread, e não executar lógica pesada na ISR.

Exemplo usando semaforos:

K_SEM_DEFINE(button_sem, 0, 1);

void button_pressed_isr(const struct device *dev,
                        struct gpio_callback *cb,
                        uint32_t pins)
{
    k_sem_give(&button_sem);
}

K_SEM_DEFINE(button_sem, 0, 1);

void button_pressed_isr(const struct device *dev,
                        struct gpio_callback *cb,
                        uint32_t pins)
{
    k_sem_give(&button_sem);
}

Thread associada:

void button_thread(void)
{
    while (1) {
        k_sem_take(&button_sem, K_FOREVER);
        printk("Evento tratado em thread\n");
    }
}

void button_thread(void)
{
    while (1) {
        k_sem_take(&button_sem, K_FOREVER);
        printk("Evento tratado em thread\n");
    }
}

Essa arquitetura:

• Mantém ISRs determinísticas
• Evita jitter
• Escala melhor com múltiplos eventos

The post Interrupções e Soft Timers no Zephyr OS first appeared on MCU & FPGA.