1. Introdução: por que usar Zephyr no Arduino DUE

O Zephyr Project é um sistema operacional de tempo real (RTOS – Real-Time Operating System) moderno, modular e altamente configurável, projetado para sistemas embarcados que exigem previsibilidade temporal, portabilidade e escalabilidade. Diferente do ecossistema Arduino tradicional — baseado em superloop e bibliotecas monolíticas — o Zephyr oferece um modelo arquitetural profissional, alinhado a práticas industriais, como device tree, Kconfig, CMake e um kernel preemptivo completo.

O Arduino DUE ocupa um espaço interessante nesse contexto. Baseado no microcontrolador Atmel/Microchip SAM3X8E, um ARM Cortex-M3 de 32 bits operando a 84 MHz, ele oferece recursos raros no “mundo Arduino”: barramento externo, controlador DMA (Direct Memory Access), múltiplas UARTs, SPI, TWI (I²C – Inter-Integrated Circuit), além de USB nativo (USB OTG). Esses recursos fazem do DUE uma excelente plataforma didática para aprender Zephyr em um hardware amplamente conhecido.

Neste artigo, você aprenderá passo a passo, de forma minuciosa, como criar um projeto Zephyr totalmente funcional para o Arduino DUE, utilizando todos os recursos documentados oficialmente pela fundação Zephyr para essa placa. O foco não será apenas “compilar e rodar”, mas entender a arquitetura do projeto, as decisões de configuração e o papel de cada arquivo envolvido.

2. Visão geral do suporte do Zephyr ao Arduino DUE

Antes de escrever qualquer linha de código, é fundamental entender como o Zephyr enxerga o Arduino DUE. No Zephyr, placas não são tratadas como “kits genéricos”, mas como descrições formais de hardware, compostas por:

• Board Definition: define CPU, clock, memória e periféricos básicos
• Device Tree (DTS): descreve os dispositivos de hardware de forma declarativa
• Kconfig da placa: habilita ou restringe funcionalidades do kernel
• Arquivos de build: integram a placa ao sistema CMake do Zephyr

No caso do Arduino DUE, o Zephyr fornece oficialmente:

• Arquivo de board baseado no SAM3X8E
• Mapeamento correto de pinos compatível com o layout do DUE
• Suporte a:
  • GPIO (General Purpose Input/Output)
  • UART (console serial)
  • SPI
  • I²C (TWI no SAM)
  • Temporizadores e SysTick
• Programação via porta USB de programação (a mesma usada com o bossac)

Isso significa que não é necessário criar uma placa customizada para começar: o Arduino DUE já está plenamente integrado ao ecossistema Zephyr.

3. Pré-requisitos do ambiente de desenvolvimento

Antes de criar o projeto, o ambiente Zephyr precisa estar corretamente instalado. Assumiremos aqui que você já leu os artigos anteriores da série e possui:

• Linux (Ubuntu 22.04 ou superior recomendado)
• Python 3.10+
• west (ferramenta de meta-build do Zephyr)
• Zephyr SDK instalada
• Toolchain ARM embarcada funcional

Para validar rapidamente se o ambiente está correto, execute:

west --version

west --version

E depois:

west boards | grep due

west boards | grep due

Se o ambiente estiver correto, você verá a placa arduino_due listada entre as placas suportadas. Esse comando é extremamente importante: ele confirma que o Zephyr reconhece oficialmente o Arduino DUE no seu workspace.

4. Estrutura recomendada de workspace

Um erro comum entre iniciantes é misturar código de aplicação com o repositório do Zephyr. A abordagem correta é usar um workspace limpo, com a seguinte estrutura conceitual:

zephyr-workspace/
├── zephyr/              # Código-fonte do Zephyr RTOS
├── modules/             # Módulos externos (opcional)
├── bootloader/          # Bootloaders (opcional)
└── arduino_due_app/     # SUA aplicação

zephyr-workspace/
├── zephyr/              # Código-fonte do Zephyr RTOS
├── modules/             # Módulos externos (opcional)
├── bootloader/          # Bootloaders (opcional)
└── arduino_due_app/     # SUA aplicação

Dentro da pasta arduino_due_app, ficará apenas o código da aplicação, sem dependências diretas do kernel. Essa separação é crucial para manter o projeto sustentável e escalável.

5. Criando o projeto do zero para o Arduino DUE

Agora vamos criar efetivamente o projeto.

5.1 Criando o diretório da aplicação

mkdir arduino_due_app
cd arduino_due_app

mkdir arduino_due_app
cd arduino_due_app

5.2 Estrutura mínima de um projeto Zephyr

Crie a seguinte estrutura inicial:

arduino_due_app/
├── CMakeLists.txt
├── prj.conf
└── src/
    └── main.c

arduino_due_app/
├── CMakeLists.txt
├── prj.conf
└── src/
    └── main.c

Essa é a estrutura mínima obrigatória para qualquer aplicação Zephyr.

6. Arquivo CMakeLists.txt: integração com o Zephyr

Crie o arquivo CMakeLists.txt com o conteúdo:

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(arduino_due_app)

target_sources(app PRIVATE src/main.c)

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(arduino_due_app)

target_sources(app PRIVATE src/main.c)

O que esse arquivo faz, exatamente?

• cmake_minimum_required: garante compatibilidade mínima do CMake
• find_package(Zephyr ...): importa todo o sistema de build do Zephyr
• project(...): define o nome lógico do projeto
• target_sources(...): registra os arquivos C da aplicação

Aqui ocorre algo importante: você não define compilador, flags ou linker script. Tudo isso é herdado automaticamente da definição da placa (arduino_due) e do kernel.

7. Arquivo prj.conf: configuração do kernel (Kconfig)

O prj.conf controla quais partes do kernel Zephyr serão compiladas.

Comece com o mínimo funcional:

CONFIG_PRINTK=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_PRINTK=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

Essas opções habilitam:

• printk() – saída básica de debug
• Driver de porta serial
• Console padrão via UART

No Arduino DUE, isso será mapeado automaticamente para a UART correta definida no device tree da placa.

8. Arquivo main.c: primeira aplicação

Crie src/main.c:

#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>

int main(void)
{
    printk("Zephyr rodando no Arduino DUE!\n");

    while (1) {
        printk("Tick\n");
        k_sleep(K_SECONDS(1));
    }

    return 0;
}

#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>

int main(void)
{
    printk("Zephyr rodando no Arduino DUE!\n");

    while (1) {
        printk("Tick\n");
        k_sleep(K_SECONDS(1));
    }

    return 0;
}

Conceitos importantes aqui

• #include <zephyr/kernel.h>: acesso ao kernel, threads e temporização
• printk(): saída síncrona simples (não é printf)
• k_sleep(): API de temporização do kernel
• main() existe, mas não é o ponto de entrada real — o kernel já está inicializado antes dela ser chamada

9. Compilando o projeto para o Arduino DUE

Agora vem a parte crítica: build correto para a placa certa.

Dentro da pasta arduino_due_app:

west build -b arduino_due

west build -b arduino_due

O Zephyr irá:

1. Ler a definição da placa Arduino DUE
2. Selecionar o SoC SAM3X8E
3. Configurar clocks, memória e periféricos
4. Gerar o firmware final

Se tudo estiver correto, o build terminará sem erros.

10. Gravando o firmware no Arduino DUE

O Arduino DUE utiliza o bootloader SAM-BA, compatível com a ferramenta bossac.

Com a placa conectada via porta USB de programação, execute:

west flash

west flash

O Zephyr cuidará automaticamente do processo de gravação usando o método correto definido para a placa.

Após o reset, abra um terminal serial:

minicom -D /dev/ttyACM0 -b 115200

minicom -D /dev/ttyACM0 -b 115200

Você deverá ver:

Zephyr rodando no Arduino DUE!
Tick
Tick
Tick

Zephyr rodando no Arduino DUE!
Tick
Tick
Tick

11. Próximos passos

A partir daqui, você já tem:

• Um projeto Zephyr funcional
• Build e flash corretamente configurados
• Console serial ativo
• Base sólida para evoluir

Nos próximos artigos, podemos avançar para:

• Device Tree do Arduino DUE em detalhes
• GPIO e LEDs
• UARTs adicionais
• SPI e I²C
• Timers e interrupções
• Multithreading real no Cortex-M3

The post Criando um Projeto Zephyr RTOS no Arduino DUE – Guia Completo e Didático first appeared on MCU & FPGA.

Introdução

O Git tornou-se o sistema de controle de versão mais utilizado no desenvolvimento de software moderno. Ele permite que desenvolvedores acompanhem alterações no código, trabalhem em equipe de forma organizada e mantenham histórico detalhado de todas as modificações realizadas em um projeto. No entanto, embora o Git ofereça um conjunto poderoso de ferramentas, seu uso eficaz depende muito da estratégia adotada pela equipe ou pelo desenvolvedor.

Em muitos projetos, especialmente aqueles relacionados a sistemas embarcados, firmware e aplicações críticas, como os que envolvem microcontroladores, RTOS ou arquiteturas distribuídas, a forma como o código é organizado dentro do Git pode impactar diretamente na qualidade do software, na rastreabilidade das mudanças e na capacidade de manutenção do projeto ao longo do tempo.

Uma estratégia bem definida de uso do Git permite resolver diversos problemas comuns no desenvolvimento colaborativo. Entre esses problemas estão conflitos frequentes de código, dificuldade em identificar quando uma funcionalidade foi introduzida, ausência de rastreabilidade entre commits e tarefas de desenvolvimento, e dificuldades para manter versões estáveis do software enquanto novas funcionalidades continuam sendo implementadas.

Ao longo da experiência prática em projetos individuais e também em equipes dentro de empresas, desenvolvi uma abordagem de organização baseada em branches de versões, branches de funcionalidades, uso disciplinado de tags e integração com sistemas de issues, especialmente no GitHub. Essa abordagem busca equilibrar três aspectos fundamentais do desenvolvimento moderno: estabilidade da versão em produção, evolução contínua do software e rastreabilidade completa das alterações realizadas.

Além disso, essa estratégia também considera cenários mais complexos de desenvolvimento, como ambientes onde existem dois repositórios distintos — um para desenvolvimento e outro para produção — e também a necessidade de manter simultaneamente múltiplas versões do software, algo comum em produtos embarcados que permanecem anos no mercado recebendo atualizações incrementais.

Neste artigo será apresentada, de forma didática e detalhada, uma estratégia prática de organização de projetos com Git, incluindo o uso de branches, tags, commits estruturados, integração com issues e organização arquitetural do código. Também serão apresentados os comandos fundamentais do Git necessários para implementar essa estratégia no dia a dia do desenvolvimento.

O objetivo não é apenas explicar os comandos, mas mostrar como construir um fluxo de trabalho que permita manter o projeto organizado, escalável e rastreável, mesmo em projetos grandes ou em equipes distribuídas.

Na próxima seção será apresentada a base dessa estratégia: a organização do repositório a partir do branch principal (Main) e a criação de branches para versões e funcionalidades.

The post Estratégia Profissional de Gestão de Código com Git em Projetos Individuais e em Equipe first appeared on MCU & FPGA.

Introdução: filas no FreeRTOS e o cenário de múltiplos consumidores

No FreeRTOS, Queue é um dos mecanismos centrais de comunicação e sincronização entre tarefas. Diferente de simples buffers, uma fila carrega não apenas dados, mas também semântica de sincronização, permitindo que tarefas produtoras e consumidoras operem de forma desacoplada no tempo. Em sistemas reais — especialmente em firmware para sensores, comunicação, aquisição de dados e pipelines de processamento — é muito comum termos um produtor e vários consumidores, todos interessados nos dados que chegam pela mesma fila.

O primeiro ponto importante, e frequentemente negligenciado, é que uma Queue do FreeRTOS não é um mecanismo de broadcast. Ela segue estritamente o modelo FIFO (First-In, First-Out) com remoção destrutiva do item. Isso significa que, quando múltiplas tarefas consumidoras bloqueiam na mesma fila, apenas uma delas receberá cada item enviado, e essa escolha é feita pelo escalonador com base em prioridade e estado das tarefas. Esse detalhe muda completamente a forma como o sistema deve ser arquitetado.

Esse comportamento é ideal quando os consumidores representam workers concorrentes, ou seja, tarefas equivalentes que disputam trabalho. Um exemplo clássico é um sistema em que uma interrupção de ADC empilha amostras em uma fila, e várias tarefas de processamento estatístico competem para consumir esses dados. Nesse caso, a fila atua como um work queue, balanceando carga automaticamente entre os consumidores.

Por outro lado, quando o objetivo é que todos os consumidores vejam todos os eventos, a Queue isoladamente é a escolha errada. Muitos bugs em sistemas embarcados com FreeRTOS surgem exatamente desse equívoco conceitual: o desenvolvedor assume que várias tarefas “escutando” a mesma fila receberão as mesmas mensagens, o que simplesmente não acontece. Esse erro se manifesta como perda intermitente de eventos, estados inconsistentes e falhas difíceis de reproduzir.

Para ilustrar o cenário correto de múltiplos consumidores concorrentes, considere o exemplo abaixo, onde várias tarefas processam mensagens vindas de um único produtor:

typedef struct {
    uint32_t id;
    uint16_t value;
} message_t;

QueueHandle_t xQueue;

void vProducerTask(void *pvParameters)
{
    message_t msg;
    uint32_t counter = 0;

    for (;;)
    {
        msg.id = counter++;
        msg.value = counter * 10;

        xQueueSend(xQueue, &msg, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void vConsumerTask(void *pvParameters)
{
    message_t msg;

    for (;;)
    {
        if (xQueueReceive(xQueue, &msg, portMAX_DELAY) == pdPASS)
        {
            /* Cada mensagem será processada por APENAS um consumidor */
            process_message(&msg);
        }
    }
}

typedef struct {
    uint32_t id;
    uint16_t value;
} message_t;

QueueHandle_t xQueue;

void vProducerTask(void *pvParameters)
{
    message_t msg;
    uint32_t counter = 0;

    for (;;)
    {
        msg.id = counter++;
        msg.value = counter * 10;

        xQueueSend(xQueue, &msg, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void vConsumerTask(void *pvParameters)
{
    message_t msg;

    for (;;)
    {
        if (xQueueReceive(xQueue, &msg, portMAX_DELAY) == pdPASS)
        {
            /* Cada mensagem será processada por APENAS um consumidor */
            process_message(&msg);
        }
    }
}

Nesse modelo, várias instâncias de vConsumerTask podem ser criadas, e cada mensagem enviada pelo produtor será entregue a apenas uma delas. O FreeRTOS garante exclusão mútua implícita no acesso à fila, evitando a necessidade de mutex para esse fluxo específico.

Nesta artigo, vamos aprofundar quando esse modelo é ideal, quais implicações surgem em termos de escalonamento, prioridade e starvation, como evitar armadilhas comuns, e quais alternativas arquiteturais devem ser usadas quando o requisito é difusão (fan-out) e não competição.

The post FreeRTOS: Uso Correto de Queue com Múltiplos Consumidores first appeared on MCU & FPGA.

Quando o firmware precisa ser previsível (tempo real), o desenho do filtro não é só “matemático”: você escolhe estruturas e limites para garantir custo computacional constante, estado pequeno e estabilidade numérica, principalmente se você for para ponto fixo ou tiver ADC+DMA alimentando o pipeline. (Essa preocupação de arquitetura e previsibilidade é típica de projetos de tempo real.)

1) Notch discreto: o “biquad” que apaga uma frequência

Um notch digital clássico pode ser implementado como um biquad IIR (segunda ordem) com zeros exatamente na frequência que você quer cancelar e polos próximos, controlando a largura do “buraco” via fator de qualidade (Q). Quanto maior o (Q), mais estreito é o notch (ótimo para interferência tonal estável), mas maior a sensibilidade a variação de (f_0) e a quantização dos coeficientes. Em termos práticos: para hum de rede em 60 Hz, se o sinal tiver variação de frequência (rede oscilando, ou a interferência “escorregando”), um (Q) alto demais pode deixar “vazar” parte do ruído. Para tom de comutação de um inversor ou fonte chaveada, se o clock for estável, dá para usar (Q) alto e atacar de forma cirúrgica.

O biquad notch mais comum pode ser escrito como:

\[
H(z)=\frac{1 – 2\cos(\omega_0)z^{-1} + z^{-2}}{1 – 2r\cos(\omega_0)z^{-1} + r^2 z^{-2}}
\]

onde \(\omega_0=2\pi f_0/F_s\) e (r) controla a “proximidade” dos polos aos zeros (quanto mais perto de 1, mais estreito e mais profundo). Uma ligação prática entre (r) e (Q) é aproximar a largura de banda por \(BW \approx f_0/Q\) e usar \(r \approx e^{-\pi BW/F_s}\). Isso funciona muito bem para firmware porque você calcula coeficientes uma vez (ou quando \(f_0\) muda) e o processamento por amostra fica constante.

Código em C: biquad notch (float) com inicialização por \(F_s, f_0, Q\)

#include <math.h>
#include <stdint.h>

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

typedef struct {
    // Coeficientes normalizados (a0 = 1)
    float b0, b1, b2;
    float a1, a2;

    // Estados (forma direta II transposta)
    float z1, z2;
} NotchBiquad;

/**
 * @brief Inicializa um filtro notch IIR (biquad) em forma direta II transposta.
 * @param f     Ponteiro para a estrutura do filtro.
 * @param Fs    Frequência de amostragem (Hz).
 * @param f0    Frequência central do notch (Hz).
 * @param Q     Fator de qualidade (adimensional). Ex.: 10..50 típicos.
 *
 * Observação prática:
 *  - Q maior => notch mais estreito, mais sensível a variações de f0 e quantização.
 *  - Q menor => notch mais largo, remove mais “vizinhança” de frequências.
 */
static inline void notch_init(NotchBiquad *f, float Fs, float f0, float Q)
{
    const float w0 = 2.0f * (float)M_PI * (f0 / Fs);

    // Largura de banda aproximada (Hz)
    const float BW = f0 / Q;

    // Polo raio r (aprox.) -> define a largura do notch
    const float r = expf(-(float)M_PI * (BW / Fs));

    const float c = cosf(w0);

    // Numerador (zeros no círculo unitário em ±w0)
    const float b0 = 1.0f;
    const float b1 = -2.0f * c;
    const float b2 = 1.0f;

    // Denominador (polos em raio r)
    const float a0 = 1.0f;
    const float a1 = -2.0f * r * c;
    const float a2 = r * r;

    // Normaliza por a0 (a0=1 aqui, mas mantemos o padrão)
    f->b0 = b0 / a0;
    f->b1 = b1 / a0;
    f->b2 = b2 / a0;
    f->a1 = a1 / a0;
    f->a2 = a2 / a0;

    f->z1 = 0.0f;
    f->z2 = 0.0f;
}

/**
 * @brief Processa 1 amostra pelo biquad notch (DF-II Transposta).
 * @param f Estrutura do filtro.
 * @param x Amostra de entrada.
 * @return  Amostra filtrada.
 */
static inline float notch_process(NotchBiquad *f, float x)
{
    // DF-II transposta:
    // y = b0*x + z1
    // z1 = b1*x - a1*y + z2
    // z2 = b2*x - a2*y
    const float y = (f->b0 * x) + f->z1;
    const float z1 = (f->b1 * x) - (f->a1 * y) + f->z2;
    const float z2 = (f->b2 * x) - (f->a2 * y);

    f->z1 = z1;
    f->z2 = z2;
    return y;
}

#include <math.h>
#include <stdint.h>

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

typedef struct {
    // Coeficientes normalizados (a0 = 1)
    float b0, b1, b2;
    float a1, a2;

    // Estados (forma direta II transposta)
    float z1, z2;
} NotchBiquad;

/**
 * @brief Inicializa um filtro notch IIR (biquad) em forma direta II transposta.
 * @param f     Ponteiro para a estrutura do filtro.
 * @param Fs    Frequência de amostragem (Hz).
 * @param f0    Frequência central do notch (Hz).
 * @param Q     Fator de qualidade (adimensional). Ex.: 10..50 típicos.
 *
 * Observação prática:
 *  - Q maior => notch mais estreito, mais sensível a variações de f0 e quantização.
 *  - Q menor => notch mais largo, remove mais “vizinhança” de frequências.
 */
static inline void notch_init(NotchBiquad *f, float Fs, float f0, float Q)
{
    const float w0 = 2.0f * (float)M_PI * (f0 / Fs);

    // Largura de banda aproximada (Hz)
    const float BW = f0 / Q;

    // Polo raio r (aprox.) -> define a largura do notch
    const float r = expf(-(float)M_PI * (BW / Fs));

    const float c = cosf(w0);

    // Numerador (zeros no círculo unitário em ±w0)
    const float b0 = 1.0f;
    const float b1 = -2.0f * c;
    const float b2 = 1.0f;

    // Denominador (polos em raio r)
    const float a0 = 1.0f;
    const float a1 = -2.0f * r * c;
    const float a2 = r * r;

    // Normaliza por a0 (a0=1 aqui, mas mantemos o padrão)
    f->b0 = b0 / a0;
    f->b1 = b1 / a0;
    f->b2 = b2 / a0;
    f->a1 = a1 / a0;
    f->a2 = a2 / a0;

    f->z1 = 0.0f;
    f->z2 = 0.0f;
}

/**
 * @brief Processa 1 amostra pelo biquad notch (DF-II Transposta).
 * @param f Estrutura do filtro.
 * @param x Amostra de entrada.
 * @return  Amostra filtrada.
 */
static inline float notch_process(NotchBiquad *f, float x)
{
    // DF-II transposta:
    // y = b0*x + z1
    // z1 = b1*x - a1*y + z2
    // z2 = b2*x - a2*y
    const float y = (f->b0 * x) + f->z1;
    const float z1 = (f->b1 * x) - (f->a1 * y) + f->z2;
    const float z2 = (f->b2 * x) - (f->a2 * y);

    f->z1 = z1;
    f->z2 = z2;
    return y;
}

Melhores usos do notch: quando você conhece (ou mede) a frequência indesejada e ela é estreita, relativamente estável e você quer preservar quase tudo ao redor. Em instrumentação, isso aparece em leitura de shunt/ADC contaminada por rede; em áudio, hum; em controle, ressonância mecânica estreita (desde que não destrua margem de fase indevidamente); em eletrônica de potência, uma componente tonal em corrente/tensão.

2) Média sincronizada: “soma coerente” alinhada à fase

A média sincronizada (às vezes chamada de synchronous averaging, time synchronous averaging) não é “só uma média móvel”. A sacada é que você escolhe uma janela exatamente igual a um período do fenômeno repetitivo (ou múltiplos inteiros) e reinicia/alinha essa janela usando um evento de referência: um zero-cross, um pulso de encoder, um índice, ou um marcador derivado do PWM. Se você tem (N) amostras por período e faz uma média sobre (K) períodos alinhados, o componente que se repete com a mesma fase soma e cresce proporcionalmente, enquanto ruído aleatório cai como (\sqrt{K}) no RMS. Além disso, componentes que não “encaixam” naquele período tendem a se cancelar.

Em termos de filtro, isso se comporta como um filtro tipo comb (pente) extremamente eficiente para rejeitar tudo que não é coerente com o período escolhido. A diferença para um notch é que você não está mirando uma única frequência: você está favorecendo toda a forma de onda repetitiva no domínio do tempo, desde que sincronizada.

Código em C: média sincronizada por períodos (com referência externa)

A seguir vai uma implementação simples (e bem útil) para firmware: você acumula amostras de cada posição dentro do período e, a cada período completo, você atualiza a média. Isso é perfeito quando você tem um “gatilho de início de período” (por exemplo, interrupção de índice do encoder ou zero-cross).

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

typedef struct {
    uint16_t N;          // amostras por período
    uint16_t idx;        // posição atual no período [0..N-1]
    uint32_t K;          // quantos períodos já acumulados (limite/controle externo)

    // Buffers de acumulação (use int64 se seu range for grande)
    int64_t *acc;        // soma por posição
    int32_t *avg;        // média por posição (resultado)
} SyncAvg;

/**
 * @brief Inicializa a média sincronizada.
 * @param s       Estrutura.
 * @param acc     Buffer de acumulação de tamanho N (int64_t).
 * @param avg     Buffer de saída média de tamanho N (int32_t).
 * @param N       Amostras por período.
 */
static inline void syncavg_init(SyncAvg *s, int64_t *acc, int32_t *avg, uint16_t N)
{
    s->N = N;
    s->idx = 0;
    s->K = 0;
    s->acc = acc;
    s->avg = avg;

    memset(s->acc, 0, (size_t)N * sizeof(int64_t));
    memset(s->avg, 0, (size_t)N * sizeof(int32_t));
}

/**
 * @brief Deve ser chamado quando ocorre o "marcador" de início de período (ex.: zero-cross ou índice do encoder).
 *        Isso força alinhamento de fase.
 */
static inline void syncavg_period_reset(SyncAvg *s)
{
    s->idx = 0;
}

/**
 * @brief Alimenta a média sincronizada com uma amostra do ADC já alinhada ao relógio de amostragem.
 * @param s Estrutura.
 * @param x Amostra (ex.: ADC já convertido para int32).
 *
 * Funcionamento:
 *  - A cada amostra, acumula na posição idx.
 *  - Ao completar N amostras, fecha um período e atualiza avg[].
 *  - A referência de fase vem de syncavg_period_reset() (externa).
 */
static inline void syncavg_push_sample(SyncAvg *s, int32_t x)
{
    s->acc[s->idx] += (int64_t)x;
    s->idx++;

    if (s->idx >= s->N) {
        s->idx = 0;
        s->K++;

        // Atualiza a média inteira por posição (custo O(N) por período).
        // Se N for grande e seu MCU for apertado, dá para atualizar de forma incremental.
        for (uint16_t i = 0; i < s->N; i++) {
            s->avg[i] = (int32_t)(s->acc[i] / (int64_t)s->K);
        }
    }
}

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

typedef struct {
    uint16_t N;          // amostras por período
    uint16_t idx;        // posição atual no período [0..N-1]
    uint32_t K;          // quantos períodos já acumulados (limite/controle externo)

    // Buffers de acumulação (use int64 se seu range for grande)
    int64_t *acc;        // soma por posição
    int32_t *avg;        // média por posição (resultado)
} SyncAvg;

/**
 * @brief Inicializa a média sincronizada.
 * @param s       Estrutura.
 * @param acc     Buffer de acumulação de tamanho N (int64_t).
 * @param avg     Buffer de saída média de tamanho N (int32_t).
 * @param N       Amostras por período.
 */
static inline void syncavg_init(SyncAvg *s, int64_t *acc, int32_t *avg, uint16_t N)
{
    s->N = N;
    s->idx = 0;
    s->K = 0;
    s->acc = acc;
    s->avg = avg;

    memset(s->acc, 0, (size_t)N * sizeof(int64_t));
    memset(s->avg, 0, (size_t)N * sizeof(int32_t));
}

/**
 * @brief Deve ser chamado quando ocorre o "marcador" de início de período (ex.: zero-cross ou índice do encoder).
 *        Isso força alinhamento de fase.
 */
static inline void syncavg_period_reset(SyncAvg *s)
{
    s->idx = 0;
}

/**
 * @brief Alimenta a média sincronizada com uma amostra do ADC já alinhada ao relógio de amostragem.
 * @param s Estrutura.
 * @param x Amostra (ex.: ADC já convertido para int32).
 *
 * Funcionamento:
 *  - A cada amostra, acumula na posição idx.
 *  - Ao completar N amostras, fecha um período e atualiza avg[].
 *  - A referência de fase vem de syncavg_period_reset() (externa).
 */
static inline void syncavg_push_sample(SyncAvg *s, int32_t x)
{
    s->acc[s->idx] += (int64_t)x;
    s->idx++;

    if (s->idx >= s->N) {
        s->idx = 0;
        s->K++;

        // Atualiza a média inteira por posição (custo O(N) por período).
        // Se N for grande e seu MCU for apertado, dá para atualizar de forma incremental.
        for (uint16_t i = 0; i < s->N; i++) {
            s->avg[i] = (int32_t)(s->acc[i] / (int64_t)s->K);
        }
    }
}

Melhores usos da média sincronizada: quando existe um evento/clock de referência que define o período do fenômeno e você quer extrair o comportamento repetitivo com máxima imunidade a ruído. Isso aparece em análise vibroacústica sincronizada com rotação (encoder), em medição de ripple sincronizada com PWM, em leitura de sinais biomédicos quando há marcador, e em sistemas de potência quando você quer “ver” a forma média ao longo de ciclos de rede sem ser enganado por ruído ou eventos transientes fora de fase.

3) Exemplo prático combinando os dois: remover hum e depois reforçar a forma repetitiva

Em pipeline real, é comum usar notch primeiro para derrubar uma interferência tonal forte e, em seguida, média sincronizada para aumentar SNR do que restou (principalmente se o sinal útil é repetitivo e você tem referência). A ordem pode inverter dependendo do caso: se a interferência também for coerente com o mesmo período, a média pode reforçá-la, então o notch antes costuma ser mais seguro.

Abaixo, um esqueleto de uso. Imagine ADC a 4 kHz, hum em 60 Hz, e você quer fazer média sincronizada por ciclo de 60 Hz usando zero-cross (logo \(N \approx 4000/60 \approx 66\) amostras por ciclo; na prática você ajusta para manter N inteiro e usar PLL/medição de período se a rede variar).

#include <stdio.h>

// Reaproveita NotchBiquad e SyncAvg já definidos acima.

#define FS_HZ        4000.0f
#define NOTCH_F0_HZ  60.0f
#define NOTCH_Q      25.0f

#define N_SAMPLES_PER_PERIOD  66  // exemplo (depende do seu sincronismo real)

static int64_t acc_buf[N_SAMPLES_PER_PERIOD];
static int32_t avg_buf[N_SAMPLES_PER_PERIOD];

int main(void)
{
    NotchBiquad notch;
    notch_init(&notch, FS_HZ, NOTCH_F0_HZ, NOTCH_Q);

    SyncAvg s;
    syncavg_init(&s, acc_buf, avg_buf, N_SAMPLES_PER_PERIOD);

    // Exemplo: loop de aquisição (mock)
    for (int n = 0; n < 20000; n++) {
        // Em firmware real: x_raw vem do ADC (DMA buffer), e zero-cross chama syncavg_period_reset(&s)
        int32_t x_raw = (int32_t)(1000 * sinf(2.0f * (float)M_PI * 10.0f * (n / FS_HZ))); // sinal útil 10 Hz
        x_raw += (int32_t)(300 * sinf(2.0f * (float)M_PI * 60.0f * (n / FS_HZ)));        // hum 60 Hz

        // Notch (float) -> converte de volta para int32
        float y_notch = notch_process(&notch, (float)x_raw);
        int32_t y = (int32_t)y_notch;

        // Evento externo de sincronismo: aqui é só demonstração (a cada N amostras)
        if ((n % N_SAMPLES_PER_PERIOD) == 0) {
            syncavg_period_reset(&s);
        }

        // Média sincronizada
        syncavg_push_sample(&s, y);

        // Quando s.K aumenta, avg_buf contém a forma média por período
        if (s.K > 0 && (n % (N_SAMPLES_PER_PERIOD * 20)) == 0) {
            printf("K=%lu, avg[0]=%ld, avg[10]=%ld\n",
                   (unsigned long)s.K, (long)avg_buf[0], (long)avg_buf[10]);
        }
    }

    return 0;
}

#include <stdio.h>

// Reaproveita NotchBiquad e SyncAvg já definidos acima.

#define FS_HZ        4000.0f
#define NOTCH_F0_HZ  60.0f
#define NOTCH_Q      25.0f

#define N_SAMPLES_PER_PERIOD  66  // exemplo (depende do seu sincronismo real)

static int64_t acc_buf[N_SAMPLES_PER_PERIOD];
static int32_t avg_buf[N_SAMPLES_PER_PERIOD];

int main(void)
{
    NotchBiquad notch;
    notch_init(¬ch, FS_HZ, NOTCH_F0_HZ, NOTCH_Q);

    SyncAvg s;
    syncavg_init(&s, acc_buf, avg_buf, N_SAMPLES_PER_PERIOD);

    // Exemplo: loop de aquisição (mock)
    for (int n = 0; n < 20000; n++) {
        // Em firmware real: x_raw vem do ADC (DMA buffer), e zero-cross chama syncavg_period_reset(&s)
        int32_t x_raw = (int32_t)(1000 * sinf(2.0f * (float)M_PI * 10.0f * (n / FS_HZ))); // sinal útil 10 Hz
        x_raw += (int32_t)(300 * sinf(2.0f * (float)M_PI * 60.0f * (n / FS_HZ)));        // hum 60 Hz

        // Notch (float) -> converte de volta para int32
        float y_notch = notch_process(¬ch, (float)x_raw);
        int32_t y = (int32_t)y_notch;

        // Evento externo de sincronismo: aqui é só demonstração (a cada N amostras)
        if ((n % N_SAMPLES_PER_PERIOD) == 0) {
            syncavg_period_reset(&s);
        }

        // Média sincronizada
        syncavg_push_sample(&s, y);

        // Quando s.K aumenta, avg_buf contém a forma média por período
        if (s.K > 0 && (n % (N_SAMPLES_PER_PERIOD * 20)) == 0) {
            printf("K=%lu, avg[0]=%ld, avg[10]=%ld\n",
                   (unsigned long)s.K, (long)avg_buf[0], (long)avg_buf[10]);
        }
    }

    return 0;
}

Fechando a ideia: o notch discreto e a média sincronizada resolvem problemas parecidos (melhorar a qualidade do sinal), mas por “mecanismos” bem diferentes, e isso muda totalmente quando cada um é a melhor escolha. O notch é a ferramenta certa quando você conhece uma frequência indesejada bem definida e relativamente estável e quer arrancá-la do sinal com o mínimo de impacto no restante do espectro. Em firmware, isso costuma ser “hum” de 50/60 Hz, tons de chaveamento, ou uma ressonância estreita que aparece como pico bem localizado. O ponto crítico é que o notch é tão bom quanto a precisão do seu (f_0) e a escolha de (Q): se a interferência varia de frequência, um notch muito estreito deixa passar; se você alarga demais, começa a “machucar” conteúdo útil perto de (f_0). Além disso, como é um IIR, você precisa cuidar de estabilidade numérica e do formato de implementação (a forma direta II transposta tende a ser mais robusta em ponto flutuante e também costuma ser a melhor porta de entrada para depois migrar para ponto fixo).

Já a média sincronizada não é “um filtro de frequência” no sentido clássico; ela é uma técnica de extração por coerência: tudo que está alinhado com o período de referência fica mais forte, e o que não está alinhado tende a desaparecer. Por isso ela é superior quando o sinal útil é repetitivo e você tem um marcador de fase confiável, como encoder em máquina rotativa, o próprio PWM em conversores/inversores, ou zero-cross da rede. O ganho prático é enorme porque ela aumenta SNR sem precisar “inventar” um modelo espectral do ruído, mas ela também tem uma fragilidade: se o sincronismo for ruim (jitter, período variável, marcador inconsistente) a média “borrará” a forma de onda e pode até criar artefatos que parecem sinal real. Em projetos de rede elétrica, por exemplo, se você fixa (N) como “amostras por ciclo” sem acompanhar a variação real da frequência, a média começa a perder fase ao longo dos ciclos; nesse caso, ou você mede o período e ajusta (N) dinamicamente, ou você reamostra o ciclo para um grid fixo antes de acumular.

Na prática, em pipeline embarcado, uma combinação muito comum é usar notch primeiro para remover uma interferência tonal forte e depois usar média sincronizada para revelar a forma repetitiva de interesse com ruído bem mais baixo. Isso funciona especialmente bem quando a interferência não é coerente com o período que você está usando para sincronizar; se for coerente, a média pode reforçar a interferência, e aí o notch vira praticamente obrigatório antes. Se o seu sistema estiver no limite de CPU, o notch custa um número fixo e pequeno de multiplicações por amostra, enquanto a média sincronizada pode custar pouco por amostra mas “cobra” um custo por período quando você atualiza a forma média; dá para manter determinismo atualizando médias de forma incremental, ou reduzindo taxa, ou usando buffers e processamento em tarefa de menor prioridade.

The post Filtro notch discreto (notch IIR) e média sincronizada (sync averaging) first appeared on MCU & FPGA.

Introdução

O processamento digital de sinais é um dos pilares da eletrônica moderna. Desde sistemas de áudio e comunicação sem fio até controle industrial e monitoramento de vibração, praticamente todo sistema embarcado contemporâneo precisa, em algum nível, manipular sinais digitais de forma eficiente. Entretanto, quando esse processamento se torna matematicamente intensivo — envolvendo filtragem digital, transformadas rápidas de Fourier (FFT), correlação, convolução ou controle em tempo real — microcontroladores convencionais podem não oferecer desempenho adequado ou eficiência energética suficiente.

É nesse contexto que surgem os processadores especializados em DSP, que aqui chamaremos de DCP (Digital Signal Processors / Digital Signal Processing Cores). Com base no artigo técnico publicado pela Analog Devices na revista Analog Dialogue, analisaremos de forma didática o papel desses processadores, suas arquiteturas internas e as vantagens que oferecem quando comparados a CPUs tradicionais em sistemas embarcados.

The post Processadores Especializados em DSP (DCP) em Sistemas Embarcados first appeared on MCU & FPGA.

Introdução e Motivação

Em sistemas embarcados modernos, especialmente aqueles baseados em FreeRTOS, a forma como o firmware reage ao mundo externo é tão importante quanto o código em si. Sensores, comunicação, interrupções, timers e pilhas de protocolo geram estímulos de forma assíncrona, e arquiteturas tradicionais baseadas apenas em superloop rapidamente se tornam difíceis de manter, escalar e depurar. É nesse contexto que surge a Arquitetura Orientada a Eventos (Event-Driven Architecture – EDA).

No FreeRTOS, uma arquitetura orientada a eventos não é um “modo especial” do sistema operacional, mas sim uma estratégia de organização do firmware, onde tarefas permanecem bloqueadas aguardando eventos específicos e acordam apenas quando algo relevante ocorre. Esses eventos podem ser sinais de interrupção, mensagens, flags, notificações, timers ou dados disponíveis em buffers. O resultado é um sistema reativo, determinístico e eficiente em consumo de CPU.

Do ponto de vista de engenharia, essa abordagem resolve três problemas clássicos:

1. Desperdício de CPU causado por polling constante
2. Acoplamento excessivo entre módulos
3. Dificuldade de sincronização entre múltiplas fontes de eventos

Ao adotar uma arquitetura orientada a eventos, o firmware passa a se comportar como um conjunto de agentes cooperativos, cada tarefa com responsabilidade clara, reagindo apenas aos eventos que lhe dizem respeito. Isso melhora a legibilidade do código, reduz latência média de resposta e facilita testes unitários e manutenção evolutiva.

No FreeRTOS, essa arquitetura é viabilizada por um conjunto muito poderoso de primitivas nativas: Task Notifications, Queues, Event Groups, Stream Buffers, Message Buffers e Software Timers. Cada uma delas atende a um tipo específico de evento e será explorada detalhadamente ao longo deste artigo, sempre com exemplos práticos e contextualizados.

O que vem a seguir

Na próxima seção, entraremos no modelo conceitual da Arquitetura Orientada a Eventos no FreeRTOS, explicando como eventos fluem pelo sistema, como tarefas devem ser estruturadas e como evitar armadilhas comuns, como event storms, inversão de prioridade e acoplamento indireto.

Modelo Conceitual da Arquitetura Orientada a Eventos

Em uma arquitetura orientada a eventos no FreeRTOS, o sistema deixa de ser centrado em fluxo sequencial de execução e passa a ser organizado em torno de eventos que representam fatos relevantes do sistema. Um evento pode significar “um dado chegou”, “um tempo expirou”, “um periférico terminou uma operação” ou “uma condição de estado foi satisfeita”. O papel central do RTOS é suspender tarefas até que esses eventos ocorram, garantindo previsibilidade temporal e uso eficiente do processador.

Do ponto de vista conceitual, essa arquitetura pode ser dividida em três elementos fundamentais: produtores de eventos, mecanismos de transporte de eventos e consumidores de eventos. Produtores normalmente são ISRs, timers de software, drivers ou tarefas de baixo nível. O transporte é feito pelas primitivas do FreeRTOS, enquanto os consumidores são tarefas que encapsulam lógica de negócio ou processamento de dados. Esse desacoplamento é essencial para sistemas escaláveis.

Um princípio importante é que tarefas orientadas a eventos devem permanecer bloqueadas na maior parte do tempo. Em FreeRTOS, isso significa usar chamadas bloqueantes como xQueueReceive(), xEventGroupWaitBits() ou ulTaskNotifyTake(), sempre com portMAX_DELAY ou tempos bem definidos. Dessa forma, não há polling ativo, e o escalonador pode dedicar CPU apenas às tarefas que realmente precisam executar naquele instante.

Outro ponto crítico do modelo é que eventos não devem carregar lógica, apenas sinalização e dados mínimos. A decisão do que fazer em resposta a um evento pertence à tarefa consumidora. Isso evita que ISRs fiquem complexas e garante que decisões de alto nível ocorram sempre em contexto de tarefa, onde mutexes, alocação de memória e chamadas de API são seguras.

Fluxo típico de eventos no FreeRTOS

Um fluxo clássico em arquitetura orientada a eventos segue o seguinte encadeamento lógico:

1. Um periférico gera uma interrupção (por exemplo, UART RX completa).
2. A ISR sinaliza o evento usando uma primitiva segura para interrupções.
3. O kernel do FreeRTOS desbloqueia a tarefa interessada.
4. A tarefa acorda, processa o evento e retorna ao estado bloqueado.

Esse modelo cria um sistema reativo e previsível, onde a latência entre o evento e o processamento é controlada diretamente pela prioridade da tarefa e pela duração das ISRs. Em projetos bem arquitetados, o tempo gasto dentro da interrupção é mínimo, e todo o processamento ocorre em nível de tarefa.

Exemplo conceitual simplificado

void vUartTask(void *pvParameters)
{
    uint8_t rxByte;

    for (;;)
    {
        if (xQueueReceive(uartRxQueue, &rxByte, portMAX_DELAY) == pdPASS)
        {
            processUartByte(rxByte);
        }
    }
}

void vUartTask(void *pvParameters)
{
    uint8_t rxByte;

    for (;;)
    {
        if (xQueueReceive(uartRxQueue, &rxByte, portMAX_DELAY) == pdPASS)
        {
            processUartByte(rxByte);
        }
    }
}

Neste exemplo, a tarefa vUartTask não executa continuamente. Ela permanece bloqueada até que um byte seja colocado na fila por uma ISR ou outra tarefa. Isso caracteriza perfeitamente o modelo orientado a eventos: o evento é a chegada de um dado, e a tarefa existe apenas para reagir a ele.

Implicações arquiteturais importantes

Ao adotar esse modelo, algumas decisões de projeto tornam-se fundamentais. A granularidade dos eventos deve ser cuidadosamente escolhida: eventos muito genéricos levam a tarefas complexas e difíceis de testar; eventos excessivamente específicos geram sobrecarga e fragmentação. Além disso, o uso correto de prioridades é crucial para garantir que eventos críticos sejam tratados com menor latência.

Outro aspecto frequentemente negligenciado é o tratamento de eventos concorrentes. O FreeRTOS permite que múltiplos eventos acordem a mesma tarefa, mas o firmware deve ser capaz de lidar com isso de forma determinística, normalmente utilizando estruturas de estado bem definidas ou state machines orientadas a eventos.

Na próxima seção, entraremos nos mecanismos de eventos disponíveis no FreeRTOS, começando pelo mais eficiente e subutilizado deles: Task Notifications, analisando seu funcionamento interno, vantagens, limitações e padrões de uso.

Excelente, seguimos.

Task Notifications como Mecanismo Central de Eventos

Entre todos os mecanismos oferecidos pelo FreeRTOS, as Task Notifications são, do ponto de vista arquitetural, a forma mais eficiente de implementar uma arquitetura orientada a eventos. Elas funcionam como um canal direto ponto-a-ponto entre o kernel e uma tarefa, sem a sobrecarga de filas, sem alocação dinâmica e com latência mínima.

Cada tarefa no FreeRTOS possui internamente um array de notificações (desde o FreeRTOS 10), onde cada entrada contém um valor de 32 bits e um estado. Isso transforma a task notification em algo conceitualmente próximo a um registrador de eventos privado da tarefa. Esse detalhe é fundamental para entender por que esse mecanismo é tão eficiente e, ao mesmo tempo, tão poderoso.

Diferente de filas ou event groups, uma task notification não é compartilhada. Ela pertence a uma única tarefa. Isso força uma arquitetura mais limpa, onde existe um mapeamento explícito entre quem produz e quem consome o evento. Em arquiteturas bem desenhadas, isso reduz drasticamente o acoplamento implícito e elimina ambiguidades.

Modelo mental correto para Task Notifications

É comum iniciantes tratarem task notifications como “um semáforo mais rápido”. Embora isso seja parcialmente verdadeiro, essa visão é limitada. O modelo correto é pensar nelas como:

• Um evento binário (acordar ou não acordar a task)
• Um contador (quantidade de eventos acumulados)
• Um bitmap de flags
• Um payload de 32 bits

Tudo isso usando a mesma infraestrutura, dependendo apenas da API utilizada.

Essa flexibilidade permite criar arquiteturas orientadas a eventos extremamente compactas, onde um único mecanismo substitui filas, semáforos e flags em muitos cenários.

Exemplo 1 — Evento simples (sinalização pura)

Neste primeiro exemplo, uma ISR sinaliza que um evento ocorreu, e a tarefa apenas reage.

void vEventTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

        handleEvent();
    }
}

void vEventTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

        handleEvent();
    }
}

A função ulTaskNotifyTake() bloqueia a tarefa até que uma notificação seja recebida. O parâmetro pdTRUE indica que o contador interno será limpo ao acordar, garantindo comportamento de evento simples.

A ISR responsável pelo evento:

void EXTI_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    vTaskNotifyGiveFromISR(eventTaskHandle, &xHigherPriorityTaskWoken);

    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void EXTI_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    vTaskNotifyGiveFromISR(eventTaskHandle, &xHigherPriorityTaskWoken);

    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Aqui, o evento é produzido de forma segura em contexto de interrupção, e o kernel pode realizar context switch imediato se a prioridade justificar. Esse padrão é ideal para eventos como botão pressionado, fim de conversão ADC ou término de DMA.

Exemplo 2 — Contador de eventos acumulados

Em cenários onde múltiplos eventos podem ocorrer antes da tarefa acordar, a task notification pode atuar como contador.

void vLoggerTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        events = ulTaskNotifyTake(pdFALSE, portMAX_DELAY);

        while (events--)
        {
            logEvent();
        }
    }
}

void vLoggerTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        events = ulTaskNotifyTake(pdFALSE, portMAX_DELAY);

        while (events--)
        {
            logEvent();
        }
    }
}

Ao usar pdFALSE, o contador não é automaticamente zerado. O valor retornado indica quantos eventos ocorreram desde a última leitura. Isso é extremamente útil em sistemas com bursts de eventos, como recepção de pacotes ou amostras rápidas de sensores.

Exemplo 3 — Task Notification como bitmap de eventos

Outra aplicação avançada é usar o valor de 32 bits como mapa de bits de eventos, substituindo completamente os Event Groups quando o evento é destinado a uma única tarefa.

#define EVT_RX_READY   (1 << 0)
#define EVT_TX_DONE   (1 << 1)
#define EVT_ERROR     (1 << 2)

void vCommTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        xTaskNotifyWait(0x00, 0xFFFFFFFF, &events, portMAX_DELAY);

        if (events & EVT_RX_READY)
            handleRx();

        if (events & EVT_TX_DONE)
            handleTxDone();

        if (events & EVT_ERROR)
            handleError();
    }
}

#define EVT_RX_READY   (1 << 0)
#define EVT_TX_DONE   (1 << 1)
#define EVT_ERROR     (1 << 2)

void vCommTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        xTaskNotifyWait(0x00, 0xFFFFFFFF, &events, portMAX_DELAY);

        if (events & EVT_RX_READY)
            handleRx();

        if (events & EVT_TX_DONE)
            handleTxDone();

        if (events & EVT_ERROR)
            handleError();
    }
}

Esse padrão cria uma máquina de eventos compacta, extremamente eficiente e fácil de analisar em termos de latência e consumo de recursos.

Vantagens arquiteturais das Task Notifications

Do ponto de vista de engenharia de sistemas, as task notifications oferecem:

• Menor latência entre evento e execução
• Zero uso de heap
• Menor footprint de memória
• Determinismo temporal elevado
• Código mais explícito e fácil de rastrear

Por esse motivo, em arquiteturas orientadas a eventos bem projetadas, task notifications devem ser a primeira opção, e não a última.

Na próxima seção, vamos tratar de Event Groups, explicando quando eles são necessários, como evitá-los em excesso e como integrá-los corretamente em uma arquitetura orientada a eventos sem criar dependências implícitas.

Seguimos.

The post Arquitetura Orientada a Eventos no FreeRTOS first appeared on MCU & FPGA.

Se você é apaixonado por microcontroladores, FPGAs, sistemas embarcados, eletrônica digital, IoT, AIoT, protocolos industriais, processamento de sinais ou arquitetura de hardware, este é o seu lugar.

Criamos um espaço colaborativo no WhatsApp para reunir desenvolvedores, estudantes, pesquisadores e entusiastas que desejam evoluir juntos no universo de MCU e FPGA e todo o seu ecossistema — do firmware ao hardware, do bare-metal ao RTOS, do HDL ao edge computing.

Aqui você poderá:

• Trocar experiências práticas
• Tirar dúvidas técnicas
• Compartilhar projetos e artigos
• Discutir arquiteturas e boas práticas
• Conhecer novas ferramentas e tecnologias
• Expandir sua rede profissional

Nosso objetivo é construir uma comunidade técnica forte, colaborativa e orientada ao crescimento real.

Entre agora pelo link:
https://chat.whatsapp.com/BYXrqPHsRO5FTP7ap7X5yq

Se você acredita na força do conhecimento compartilhado, convide também seus amigos, colegas de trabalho e membros de outros grupos técnicos. Quanto mais mentes engajadas, mais rico será o aprendizado de todos.

Vamos fortalecer o ecossistema de MCU & FPGA juntos.

The post Participe em nossa comunidade no Whatsapp first appeared on MCU & FPGA.

Introdução: comunicação entre tarefas no FreeRTOS

Em sistemas embarcados baseados em Real-Time Operating Systems (RTOS), a comunicação entre tarefas (tasks) e entre interrupções (ISRs – Interrupt Service Routines) é um dos pilares da arquitetura de software. No FreeRTOS, essa comunicação pode ocorrer por diversos mecanismos: queues, semaphores, event groups, task notifications e, mais recentemente, stream buffers e message buffers. Cada um desses mecanismos foi projetado para atender a padrões específicos de troca de dados, com impactos diretos em desempenho, uso de memória, latência e complexidade do código.

Historicamente, as queues foram o principal mecanismo para troca de dados entre tarefas no FreeRTOS. Elas oferecem uma semântica clara, segura e genérica, permitindo o envio de estruturas de dados completas entre produtores e consumidores. No entanto, conforme sistemas embarcados passaram a lidar com fluxos contínuos de dados — como áudio, streams de sensores, bytes vindos de UART, SPI, USB ou stacks de rede —, tornou-se evidente que o modelo tradicional de queue não era o mais eficiente para esse tipo de cenário.

É nesse contexto que surgem os Stream Buffers, introduzidos para lidar com dados orientados a fluxo, onde o mais importante não é a fronteira entre mensagens, mas sim a sequência contínua de bytes. Diferentemente das queues, que operam com itens discretos e de tamanho fixo, os stream buffers operam como um buffer circular de bytes, permitindo escrita e leitura parcial, com controle fino sobre bloqueio, timeout e sincronização entre tarefas e ISRs.

Nesta série de artigos sobre FreeRTOS, esta seção tem como objetivo introduzir formalmente o conceito de stream buffers, posicioná-los corretamente dentro do ecossistema de mecanismos de comunicação do sistema operacional e preparar o terreno para uma comparação técnica aprofundada com queues. Ao longo das próximas seções, veremos como funcionam internamente, quando usá-los, quando evitá-los e como escrever código eficiente e seguro usando esse recurso.

The post FreeRTOS: Stream Buffers, comparação com Queues e critérios de escolha first appeared on MCU & FPGA.

Introdução

A escolha de um microcontrolador é uma das decisões mais críticas no desenvolvimento de sistemas embarcados, pois impacta diretamente o custo, o consumo de energia, a complexidade do firmware, a conectividade disponível e até mesmo a viabilidade do produto final. Nos últimos anos, o mercado passou a oferecer famílias extremamente distintas, que atendem desde projetos educacionais e protótipos rápidos até aplicações industriais, IoT em larga escala e dispositivos vestíveis de ultra-baixo consumo.

Neste artigo comparativo, analisamos cinco plataformas amplamente utilizadas — ESP32, STM32, Arduino (AVR), RP2040 e nRF52 — destacando suas arquiteturas, capacidades de processamento, conectividade, consumo energético e contextos de uso. O objetivo não é eleger um “melhor” microcontrolador, mas fornecer critérios técnicos claros para que o engenheiro ou desenvolvedor escolha a solução mais adequada ao seu projeto.

The post Comparativo Técnico de Microcontroladores: ESP32, STM32, Arduino, RP2040 e nRF52 first appeared on MCU & FPGA.

Conteúdo Educacional e Técnico (Portais e Comunidades)

• Embarcados
  https://www.embarcados.com.br
  Principal portal brasileiro sobre sistemas embarcados, microcontroladores, RTOS, Linux embarcado e indústria. Excelente equilíbrio entre teoria, prática e mercado.
• MCU.TEC
  https://mcu.tec.br
  Conteúdo técnico aprofundado sobre microcontroladores, FPGA, RTOS, protocolos, eletrônica aplicada e integração com IA. Forte foco em didática e engenharia real.
• Microgenios
  https://www.microgenios.com.br
  Cursos, treinamentos e artigos focados em PIC, Arduino, ESP32 e IoT, com abordagem prática para iniciantes e intermediários.
• Instituto Newton C. Braga
  https://www.newtoncbraga.com.br
  Acervo clássico e extremamente vasto de eletrônica, incluindo microcontroladores, sensores, fontes e RF. Um verdadeiro repositório histórico-técnico.
• Vichinsky
  https://www.vichinsky.com
  Conteúdo técnico voltado a PIC (especialmente PIC18F2550), 8051 e Arduino, com exemplos diretos e foco em firmware bare-metal.
• All About Circuits
  https://www.allaboutcircuits.com
  Um dos melhores sites internacionais para eletrônica e microcontroladores, com artigos técnicos, fóruns e análises profundas.

Fabricantes e Documentação Oficial

• Microchip Technology
  https://www.microchip.com
  Documentação oficial de PIC, AVR (Atmel), SAM e ferramentas como MPLAB X. Fonte primária obrigatória para quem trabalha com PIC e AVR.
• STMicroelectronics
  https://www.st.com
  Referência absoluta para STM32, HAL, LL, CubeMX e ecossistema ARM Cortex-M e Cortex-A.
• NXP Semiconductors
  https://www.nxp.com
  Forte em microcontroladores industriais, automotivos, i.MX, LPC e segurança embarcada.
• Renesas Electronics
  https://www.renesas.com
  Destaque para famílias RA, RX e RZ, muito usadas em aplicações industriais e IoT avançado.
• Texas Instruments
  https://www.ti.com
  MSP430, Sitara, documentação exemplar e application notes de alto nível.

Lojas e Kits de Desenvolvimento (Brasil)

• AutoCore Robótica
  https://www.autocorerobotica.com.br
  Venda de microcontroladores, módulos ESP, sensores e kits educacionais.
• Baú da Eletrônica
  https://www.baudaeletronica.com.br
  Grande variedade de CIs, microcontroladores, ferramentas e componentes.
• ACEPIC Tecnologia
  https://www.acepic.com.br
  Especializada em kits, treinamentos e soluções educacionais para PIC, ESP32 e sistemas embarcados.

Plataformas de Pesquisa e Datasheets

• Octopart
  https://octopart.com
  Essencial para pesquisa de microcontroladores, comparação de preços, estoque global e acesso rápido a datasheets oficiais.
• Digi-Key
  https://www.digikey.com
  Além da loja, possui uma biblioteca técnica riquíssima (TechForum, artigos, vídeos).
• Mouser Electronics
  https://www.mouser.com
  Excelente para lançamentos recentes, application notes e kits de desenvolvimento.

The post Os Melhores Sites sobre Microcontroladores, Sistemas Embarcados e IoT em 2026 first appeared on MCU & FPGA.