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.

O Mercado Global de Softwares EDA para Projeto de PCBs

O mercado de ferramentas EDA (Electronic Design Automation) voltadas ao desenvolvimento de placas de circuito impresso é tradicionalmente analisado com base em dois parâmetros principais: receita anual e taxa de crescimento. A receita indica consolidação e presença em grandes cadeias industriais, enquanto o crescimento percentual revela expansão tecnológica, adoção em novos segmentos ou reposicionamento estratégico. Nesta primeira análise, discutimos quatro grandes players do setor: Altium, Cadence, Siemens (Mentor) e Ansys, observando posicionamento técnico, público-alvo e diferenciais competitivos.

Altium

A Altium é amplamente reconhecida como uma das ferramentas mais consolidadas no segmento de design profissional de PCBs. Sua plataforma principal, o Altium Designer, é fortemente adotada por empresas que trabalham com projetos de média e alta complexidade, incluindo aplicações industriais, médicas e automotivas.

Um dos principais diferenciais da ferramenta está na integração entre captura esquemática, layout, gerenciamento de bibliotecas e colaboração em nuvem por meio do Altium 365. Essa abordagem reduz fricções no fluxo de desenvolvimento e facilita o trabalho colaborativo entre equipes distribuídas. Em termos técnicos, a plataforma oferece suporte robusto para projetos HDI, controle de impedância, análise de integridade de sinal e gerenciamento avançado de regras de projeto.

O crescimento consistente da empresa reflete a combinação entre maturidade tecnológica e investimento contínuo em colaboração digital e integração de dados.

Site oficial:
https://www.altium.com

Cadence (OrCAD / Allegro)

A Cadence ocupa posição estratégica no mercado corporativo, especialmente em ambientes que exigem integração entre projeto de PCB e desenvolvimento de circuitos integrados. Suas soluções OrCAD e Allegro são amplamente utilizadas em empresas que demandam alto controle sobre integridade de sinal, integridade de potência e análise térmica.

O grande diferencial da Cadence está no ecossistema completo que conecta design eletrônico, simulação e verificação em nível de sistema. Em projetos de alta velocidade, como interfaces DDR, PCIe e redes de alta taxa de dados, a robustez das ferramentas de análise torna-se determinante.

O posicionamento da Cadence é fortemente corporativo, com foco em grandes organizações que trabalham com fluxos integrados de desenvolvimento eletrônico.

Site oficial:
https://www.cadence.com

Siemens (Mentor Graphics)

Após a aquisição da Mentor Graphics, a Siemens consolidou uma das plataformas mais integradas do mercado de EDA. A solução Siemens EDA é especialmente relevante em ambientes industriais onde há forte integração entre engenharia eletrônica e engenharia mecânica.

Um dos principais diferenciais é a conexão com ferramentas de PLM (Product Lifecycle Management), permitindo que o projeto eletrônico faça parte do ecossistema digital completo do produto. Isso é particularmente estratégico para setores como automotivo, aeroespacial e manufatura avançada.

A sinergia com o portfólio industrial da Siemens fortalece sua presença em aplicações que exigem rastreabilidade, integração com digital twin e controle rigoroso do ciclo de vida do produto.

Site oficial:
https://eda.sw.siemens.com

Ansys

A Ansys se posiciona de maneira diferenciada dentro do mercado EDA. Embora não seja tradicionalmente a ferramenta principal de layout de PCB, sua presença é extremamente forte na área de simulação multiphysics.

Ferramentas como Ansys HFSS e Ansys SIwave são amplamente utilizadas para análise eletromagnética, integridade de sinal, integridade de potência e comportamento térmico. Em projetos de RF, antenas, sistemas de potência e aplicações de alta frequência, a simulação torna-se elemento crítico para garantir desempenho e conformidade.

A Ansys complementa fluxos de design tradicionais, sendo integrada frequentemente a ferramentas de layout para validação avançada do projeto antes da fabricação.

Site oficial:
https://www.ansys.com

The post Panorama Completo do Mercado EDA: Principais Ferramentas para Projeto de PCB e Tendências Tecnológicas first appeared on MCU & FPGA.

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.

Em sistemas embarcados com RTOS, especialmente em aplicações industriais, automotivas e IoT crítico, o maior desafio não é apenas “fazer funcionar”, mas manter previsibilidade temporal, escalabilidade e manutenibilidade. É nesse ponto que os padrões de projeto aplicados a RTOS se tornam fundamentais.

Diferente de aplicações desktop, padrões em RTOS precisam respeitar restrições de tempo real, uso determinístico de memória, prioridades, latência de interrupções e sincronização segura entre contexto de ISR e tarefas. Muitos padrões clássicos de software são adaptados ou reinterpretados nesse contexto.

Neste artigo, começaremos pelos padrões estruturais básicos de tarefas, que formam a fundação de praticamente qualquer sistema com FreeRTOS.

1 – Padrões Fundamentais de Estruturação de Tarefas

1.1 Superloop + Tasks (Incremental RTOS Adoption)

Problema resolvido:
Projetos legados em superloop (while(1)) tornam-se difíceis de manter à medida que crescem. Migrar tudo de uma vez para RTOS é arriscado.

Ideia do padrão:
Manter o superloop como uma tarefa principal, introduzindo gradualmente novas tarefas RTOS.

Quando usar:

• Migração de firmware bare-metal para FreeRTOS
• Sistemas simples que estão crescendo
• Prototipação controlada

Estrutura típica:

void LegacySuperloopTask(void *pvParameters)
{
    for (;;)
    {
        ReadSensors();
        ProcessData();
        UpdateOutputs();

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void LegacySuperloopTask(void *pvParameters)
{
    for (;;)
    {
        ReadSensors();
        ProcessData();
        UpdateOutputs();

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

xTaskCreate(
    LegacySuperloopTask,
    "Legacy",
    1024,
    NULL,
    tskIDLE_PRIORITY + 1,
    NULL
);

xTaskCreate(
    LegacySuperloopTask,
    "Legacy",
    1024,
    NULL,
    tskIDLE_PRIORITY + 1,
    NULL
);

Vantagens:

• Baixo risco na migração
• Preserva código validado
• Facilita testes incrementais

Risco comum:
Transformar essa tarefa em um “monstro” que ignora o espírito do RTOS. Este padrão deve ser transitório, não permanente.

1.2 One Task Per Responsibility (Uma tarefa por responsabilidade)

Problema resolvido:
Tarefas que fazem “de tudo” dificultam análise temporal, debugging e escalonamento.

Ideia do padrão:
Cada tarefa possui uma única responsabilidade funcional bem definida.

Exemplo típico em FreeRTOS:

• Task de aquisição
• Task de processamento
• Task de comunicação

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        ReadADC();
        xTaskNotify(ProcessTaskHandle, 0, eNoAction);
        vTaskDelay(pdMS_TO_TICKS(5));
    }
}

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        ReadADC();
        xTaskNotify(ProcessTaskHandle, 0, eNoAction);
        vTaskDelay(pdMS_TO_TICKS(5));
    }
}

void ProcessTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        FilterData();
        ComputeResults();
    }
}

void ProcessTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        FilterData();
        ComputeResults();
    }
}

Vantagens:

• Facilita análise de prioridades
• Reduz acoplamento
• Favorece paralelismo real

Boas práticas:

• Nomear tarefas claramente
• Documentar WCET (Worst Case Execution Time)
• Evitar bloqueios longos

1.3 Cyclic Executive com RTOS

Problema resolvido:
Algumas aplicações precisam de periodicidade rígida, mesmo usando RTOS.

Ideia do padrão:
Uma tarefa de alta prioridade atua como orquestrador temporal, liberando outras tarefas de forma cíclica.

Estrutura conceitual:

• Task cíclica principal
• Subtarefas acionadas por notificações

void CyclicTask(void *pvParameters)
{
    TickType_t xLastWakeTime = xTaskGetTickCount();

    for (;;)
    {
        xTaskNotify(TaskAHandle, 0, eNoAction);
        xTaskNotify(TaskBHandle, 0, eNoAction);

        vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(10));
    }
}

void CyclicTask(void *pvParameters)
{
    TickType_t xLastWakeTime = xTaskGetTickCount();

    for (;;)
    {
        xTaskNotify(TaskAHandle, 0, eNoAction);
        xTaskNotify(TaskBHandle, 0, eNoAction);

        vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(10));
    }
}

Vantagens:

• Controle temporal explícito
• Previsibilidade elevada
• Útil em controle e automação

Limitação:
Menos flexível que arquiteturas puramente orientadas a eventos.

1.4 Idle Task como Padrão Arquitetural

Problema resolvido:
Desperdício de CPU e energia quando o sistema está ocioso.

Ideia do padrão:
Usar a Idle Task como ponto central para:

• Economia de energia
• Limpeza de recursos
• Instrumentação

void vApplicationIdleHook(void)
{
    EnterLowPowerMode();
}

void vApplicationIdleHook(void)
{
    EnterLowPowerMode();
}

Uso típico:

• __WFI() em Cortex-M
• Estatísticas de CPU
• Monitoramento de heap

Importante:
Nunca bloquear, nunca usar delays e nunca acessar recursos não protegidos.

2 – Padrões de Comunicação e Sincronização em RTOS

Em FreeRTOS, concorrência mal projetada é a principal fonte de bugs: deadlocks, starvation, jitter temporal e corrupção de dados. Os padrões desta seção existem para substituir variáveis globais, flags soltas e volatile mal utilizados por mecanismos determinísticos e auditáveis.

Aqui falamos de comunicação, não apenas de sincronização.

2.1 Event Queue (Fila de Eventos)

Problema resolvido:
Múltiplos produtores gerando eventos assíncronos para um único consumidor.

Ideia do padrão:
Eventos são encapsulados em estruturas e enviados por uma fila RTOS. O consumidor processa eventos em ordem temporal.

Quando usar:

• Interface homem-máquina
• Eventos de sensores
• Drivers desacoplados da lógica de aplicação

Estrutura típica do evento:

typedef enum {
    EVT_BUTTON,
    EVT_SENSOR,
    EVT_TIMEOUT
} EventType;

typedef struct {
    EventType type;
    uint32_t  data;
} AppEvent;

typedef enum {
    EVT_BUTTON,
    EVT_SENSOR,
    EVT_TIMEOUT
} EventType;

typedef struct {
    EventType type;
    uint32_t  data;
} AppEvent;

Fila global (criada na inicialização):

QueueHandle_t EventQueue;

EventQueue = xQueueCreate(10, sizeof(AppEvent));

QueueHandle_t EventQueue;

EventQueue = xQueueCreate(10, sizeof(AppEvent));

Produtor:

void ButtonISR(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    AppEvent evt = {
        .type = EVT_BUTTON,
        .data = 1
    };

    xQueueSendFromISR(EventQueue, &evt, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void ButtonISR(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    AppEvent evt = {
        .type = EVT_BUTTON,
        .data = 1
    };

    xQueueSendFromISR(EventQueue, &evt, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Consumidor:

void EventTask(void *pvParameters)
{
    AppEvent evt;

    for (;;)
    {
        if (xQueueReceive(EventQueue, &evt, portMAX_DELAY))
        {
            switch (evt.type)
            {
                case EVT_BUTTON:
                    HandleButton(evt.data);
                    break;

                case EVT_SENSOR:
                    HandleSensor(evt.data);
                    break;

                default:
                    break;
            }
        }
    }
}

void EventTask(void *pvParameters)
{
    AppEvent evt;

    for (;;)
    {
        if (xQueueReceive(EventQueue, &evt, portMAX_DELAY))
        {
            switch (evt.type)
            {
                case EVT_BUTTON:
                    HandleButton(evt.data);
                    break;

                case EVT_SENSOR:
                    HandleSensor(evt.data);
                    break;

                default:
                    break;
            }
        }
    }
}

Vantagens:

• Desacoplamento total
• Ordem garantida
• Fácil instrumentação

Erro comum:
Usar fila para stream contínuo de dados (para isso existem buffers).

2.2 Mailbox (Fila de Mensagem Única)

Problema resolvido:
Apenas o último valor importa, não o histórico.

Ideia do padrão:
Uma fila de tamanho 1 funciona como mailbox sobrescrevível.

QueueHandle_t Mailbox;

Mailbox = xQueueCreate(1, sizeof(uint32_t));

QueueHandle_t Mailbox;

Mailbox = xQueueCreate(1, sizeof(uint32_t));

Produtor:

uint32_t temperature = ReadTemperature();
xQueueOverwrite(Mailbox, &temperature);

uint32_t temperature = ReadTemperature();
xQueueOverwrite(Mailbox, &temperature);

Consumidor:

uint32_t temp;

if (xQueuePeek(Mailbox, &temp, 0))
{
    UseTemperature(temp);
}

uint32_t temp;

if (xQueuePeek(Mailbox, &temp, 0))
{
    UseTemperature(temp);
}

Quando usar:

• Telemetria
• Estados globais observáveis
• Última leitura válida

Vantagem-chave:
Evita backlog artificial.

2.3 Publish–Subscribe (Pub-Sub) com FreeRTOS

Problema resolvido:
Múltiplos consumidores interessados no mesmo evento.

Ideia do padrão:
Uma tarefa “dispatcher” recebe eventos e os redistribui para múltiplas filas.

Arquitetura:

ISR / Producers
      ↓
  Event Queue
      ↓
  Dispatcher Task
     ↓          ↓           ↓
 Task A Task B Task C

ISR / Producers
      ↓
  Event Queue
      ↓
  Dispatcher Task
     ↓          ↓           ↓
 Task A Task B Task C

Dispatcher:

void DispatcherTask(void *pvParameters)
{
    AppEvent evt;

    for (;;)
    {
        if (xQueueReceive(EventQueue, &evt, portMAX_DELAY))
        {
            xQueueSend(QueueA, &evt, 0);
            xQueueSend(QueueB, &evt, 0);
        }
    }
}

void DispatcherTask(void *pvParameters)
{
    AppEvent evt;

    for (;;)
    {
        if (xQueueReceive(EventQueue, &evt, portMAX_DELAY))
        {
            xQueueSend(QueueA, &evt, 0);
            xQueueSend(QueueB, &evt, 0);
        }
    }
}

Vantagens:

• Extensível
• Isola produtores de consumidores
• Facilita testes

Custo:
Mais RAM e latência — aceitável em troca de clareza.

2.4 Task Notification como Padrão de Sinalização Rápida

Problema resolvido:
Overhead de filas quando apenas sinalização simples é necessária.

Ideia do padrão:
Usar Task Notifications como semáforos ultraleves.

Produtor:

xTaskNotify(TaskHandle, 0x01, eSetBits);

xTaskNotify(TaskHandle, 0x01, eSetBits);

Consumidor:

uint32_t flags;

xTaskNotifyWait(0, 0xFFFFFFFF, &flags, portMAX_DELAY);

if (flags & 0x01)
{
    ProcessEvent();
}

uint32_t flags;

xTaskNotifyWait(0, 0xFFFFFFFF, &flags, portMAX_DELAY);

if (flags & 0x01)
{
    ProcessEvent();
}

Vantagens:

• Zero alocação dinâmica
• Extremamente rápido
• Ideal para ISR → Task

Limitação:
Apenas 32 bits por tarefa → não serve para dados complexos.

2.5 Stream Buffer e Message Buffer

Problema resolvido:
Troca eficiente de fluxos contínuos de dados.

Stream Buffer

• Dados binários contínuos
• Sem fronteira de mensagem

StreamBufferHandle_t sb;
sb = xStreamBufferCreate(128, 1);

StreamBufferHandle_t sb;
sb = xStreamBufferCreate(128, 1);

Message Buffer

• Mensagens delimitadas
• Ideal para pacotes

MessageBufferHandle_t mb;
mb = xMessageBufferCreate(128);

MessageBufferHandle_t mb;
mb = xMessageBufferCreate(128);

Uso típico:

• UART
• SPI
• Áudio
• Protocolos binários

Boa prática:
Preferir buffers a filas para dados “em volume”.

3 – Padrões de Exclusão Mútua, Proteção de Recursos e Prevenção de Deadlock

Em FreeRTOS, concorrência não controlada não falha sempre — falha quando você menos espera. Esta seção trata de padrões que evitam corrupção de dados, inversão de prioridade e deadlocks, sem sacrificar o determinismo.

3.1 Mutex com Priority Inheritance

Problema resolvido:
Duas ou mais tarefas acessam o mesmo recurso (UART, I²C, SPI, memória compartilhada).

Risco clássico:
Priority Inversion — tarefa de baixa prioridade bloqueia uma de alta.

Ideia do padrão:
Usar Mutex (não semáforo) para herança de prioridade automática.

SemaphoreHandle_t uartMutex;

uartMutex = xSemaphoreCreateMutex();

SemaphoreHandle_t uartMutex;

uartMutex = xSemaphoreCreateMutex();

Uso correto:

void UartTask(void *pvParameters)
{
    for (;;)
    {
        if (xSemaphoreTake(uartMutex, portMAX_DELAY))
        {
            UART_Write("Hello RTOS\n");
            xSemaphoreGive(uartMutex);
        }
    }
}

void UartTask(void *pvParameters)
{
    for (;;)
    {
        if (xSemaphoreTake(uartMutex, portMAX_DELAY))
        {
            UART_Write("Hello RTOS\n");
            xSemaphoreGive(uartMutex);
        }
    }
}

Por que não semáforo binário?

• Semáforos não fazem herança de prioridade
• Mutexes são projetados para exclusão mútua real

Regra de ouro:
Mutex protege recurso, não evento.

3.2 Gatekeeper Task (Padrão Fundamental em FreeRTOS)

Problema resolvido:
Múltiplas tarefas acessando um único periférico (UART, Flash, Display).

Ideia do padrão:
Apenas uma tarefa é dona do recurso. As demais pedem serviço via fila.

Este é um dos padrões mais importantes para firmware de produção.

Estrutura:

Tasks ──► Request Queue ──► Gatekeeper Task ──► Hardware

Tasks ──► Request Queue ──► Gatekeeper Task ──► Hardware

Mensagem de requisição:

typedef struct {
    char message[64];
} UartRequest;

typedef struct {
    char message[64];
} UartRequest;

Gatekeeper:

void UartGatekeeperTask(void *pvParameters)
{
    UartRequest req;

    for (;;)
    {
        if (xQueueReceive(UartQueue, &req, portMAX_DELAY))
        {
            UART_Write(req.message);
        }
    }
}

void UartGatekeeperTask(void *pvParameters)
{
    UartRequest req;

    for (;;)
    {
        if (xQueueReceive(UartQueue, &req, portMAX_DELAY))
        {
            UART_Write(req.message);
        }
    }
}

Cliente:

UartRequest req = { .message = "Log message\n" };
xQueueSend(UartQueue, &req, portMAX_DELAY);

UartRequest req = { .message = "Log message\n" };
xQueueSend(UartQueue, &req, portMAX_DELAY);

Vantagens:

• Elimina mutexes
• Elimina deadlocks
• Simplifica drivers

Trade-off:
Leve aumento de latência → ganho enorme em robustez.

3.3 Critical Section (Uso cirúrgico)

Problema resolvido:
Trechos extremamente curtos que não podem ser interrompidos.

taskENTER_CRITICAL();
sharedCounter++;
taskEXIT_CRITICAL();

taskENTER_CRITICAL();
sharedCounter++;
taskEXIT_CRITICAL();

O que acontece:

• Desabilita interrupções (localmente)
• Bloqueia escalonamento

Quando usar:

• Incrementos atômicos
• Flags simples
• Estruturas lock-free auxiliares

Quando NÃO usar:
Código longo
Acesso a drivers
Comunicação entre tarefas

Se você precisa de printf() dentro de critical section, algo está errado.

3.4 Read–Modify–Write protegido (Anti-pattern clássico)

Problema comum (ERRADO):

if (flag == 0)
{
    flag = 1;
}

if (flag == 0)
{
    flag = 1;
}

Correção com mutex:

xSemaphoreTake(flagMutex, portMAX_DELAY);
if (flag == 0)
{
    flag = 1;
}
xSemaphoreGive(flagMutex);

xSemaphoreTake(flagMutex, portMAX_DELAY);
if (flag == 0)
{
    flag = 1;
}
xSemaphoreGive(flagMutex);

Ou melhor ainda:
Substituir flag por task notification ou event group.

3.5 Event Groups como Padrão de Coordenação

Problema resolvido:
Sincronizar múltiplas tarefas com condições compostas.

EventGroupHandle_t systemEvents;

#define EVT_NET_READY   (1 << 0)
#define EVT_SENSOR_OK   (1 << 1)

EventGroupHandle_t systemEvents;

#define EVT_NET_READY   (1 << 0)
#define EVT_SENSOR_OK   (1 << 1)

Sinalização:

xEventGroupSetBits(systemEvents, EVT_NET_READY);

xEventGroupSetBits(systemEvents, EVT_NET_READY);

Aguardar múltiplas condições:

xEventGroupWaitBits(
    systemEvents,
    EVT_NET_READY | EVT_SENSOR_OK,
    pdFALSE,
    pdTRUE,
    portMAX_DELAY
);

xEventGroupWaitBits(
    systemEvents,
    EVT_NET_READY | EVT_SENSOR_OK,
    pdFALSE,
    pdTRUE,
    portMAX_DELAY
);

Uso típico:

• Startup sequencial
• Estados globais do sistema
• Dependências entre subsistemas

Vantagem:
Muito mais expressivo que flags globais.

3.6 Deadlock Avoidance (Padrões de Prevenção)

Causa clássica de deadlock:

• Ordem inconsistente de aquisição de mutexes

Padrão de prevenção:
Sempre adquirir recursos na mesma ordem

xSemaphoreTake(mutexA, portMAX_DELAY);
xSemaphoreTake(mutexB, portMAX_DELAY);

/* uso */

xSemaphoreGive(mutexB);
xSemaphoreGive(mutexA);

xSemaphoreTake(mutexA, portMAX_DELAY);
xSemaphoreTake(mutexB, portMAX_DELAY);

/* uso */

xSemaphoreGive(mutexB);
xSemaphoreGive(mutexA);

Alternativa mais segura:
Eliminar múltiplos mutexes → usar Gatekeeper.

4 – Padrões de Controle de Fluxo, Estados e Recuperação em RTOS

Em sistemas com FreeRTOS, fluxo implícito é inimigo do determinismo. if encadeado, flags globais e dependências ocultas tornam o comportamento do sistema impossível de prever sob carga, falhas ou eventos raros.

Os padrões desta seção tornam o comportamento do sistema explícito, rastreável e recuperável.

4.1 State Machine (Máquina de Estados Finita – FSM)

Problema resolvido:
Fluxo de controle espalhado por múltiplas tarefas e condicionais.

Ideia do padrão:
Representar o comportamento como estados explícitos e transições bem definidas.

Estrutura básica

typedef enum {
    STATE_INIT,
    STATE_IDLE,
    STATE_ACTIVE,
    STATE_ERROR
} SystemState;

typedef enum {
    STATE_INIT,
    STATE_IDLE,
    STATE_ACTIVE,
    STATE_ERROR
} SystemState;

static SystemState currentState = STATE_INIT;

static SystemState currentState = STATE_INIT;

Execução da máquina de estados (task dedicada)

void StateMachineTask(void *pvParameters)
{
    for (;;)
    {
        switch (currentState)
        {
            case STATE_INIT:
                InitHardware();
                currentState = STATE_IDLE;
                break;

            case STATE_IDLE:
                if (StartCondition())
                    currentState = STATE_ACTIVE;
                break;

            case STATE_ACTIVE:
                RunControlLoop();
                if (FaultDetected())
                    currentState = STATE_ERROR;
                break;

            case STATE_ERROR:
                HandleFault();
                currentState = STATE_IDLE;
                break;
        }

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void StateMachineTask(void *pvParameters)
{
    for (;;)
    {
        switch (currentState)
        {
            case STATE_INIT:
                InitHardware();
                currentState = STATE_IDLE;
                break;

            case STATE_IDLE:
                if (StartCondition())
                    currentState = STATE_ACTIVE;
                break;

            case STATE_ACTIVE:
                RunControlLoop();
                if (FaultDetected())
                    currentState = STATE_ERROR;
                break;

            case STATE_ERROR:
                HandleFault();
                currentState = STATE_IDLE;
                break;
        }

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

Vantagens:

• Fluxo claro
• Fácil depuração
• Excelente para controle e sequenciamento

Limitação:
Cresce mal quando há muitos estados e eventos → entra a HSM.

4.2 Hierarchical State Machine (HSM)

Problema resolvido:
Explosão combinatória de estados.

Ideia do padrão:
Estados possuem comportamento comum herdado de estados “pais”.

Exemplo conceitual

SYSTEM
 ├── OPERATIONAL
 │    ├── IDLE
 │    └── ACTIVE
 └── FAULT
      ├── WARNING
      └── CRITICAL

SYSTEM
 ├── OPERATIONAL
 │    ├── IDLE
 │    └── ACTIVE
 └── FAULT
      ├── WARNING
      └── CRITICAL

Implementação simplificada em C

typedef enum {
    SUPER_OPERATIONAL,
    SUPER_FAULT
} SuperState;

typedef enum {
    SUB_IDLE,
    SUB_ACTIVE,
    SUB_WARNING,
    SUB_CRITICAL
} SubState;

static SuperState superState;
static SubState   subState;

typedef enum {
    SUPER_OPERATIONAL,
    SUPER_FAULT
} SuperState;

typedef enum {
    SUB_IDLE,
    SUB_ACTIVE,
    SUB_WARNING,
    SUB_CRITICAL
} SubState;

static SuperState superState;
static SubState   subState;

void StateMachineStep(void)
{
    switch (superState)
    {
        case SUPER_OPERATIONAL:
            if (FaultDetected())
            {
                superState = SUPER_FAULT;
                subState = SUB_WARNING;
                break;
            }

            if (subState == SUB_IDLE && StartCondition())
                subState = SUB_ACTIVE;

            break;

        case SUPER_FAULT:
            HandleFaultCommon();

            if (subState == SUB_WARNING && EscalateFault())
                subState = SUB_CRITICAL;

            if (FaultCleared())
            {
                superState = SUPER_OPERATIONAL;
                subState = SUB_IDLE;
            }
            break;
    }
}

void StateMachineStep(void)
{
    switch (superState)
    {
        case SUPER_OPERATIONAL:
            if (FaultDetected())
            {
                superState = SUPER_FAULT;
                subState = SUB_WARNING;
                break;
            }

            if (subState == SUB_IDLE && StartCondition())
                subState = SUB_ACTIVE;

            break;

        case SUPER_FAULT:
            HandleFaultCommon();

            if (subState == SUB_WARNING && EscalateFault())
                subState = SUB_CRITICAL;

            if (FaultCleared())
            {
                superState = SUPER_OPERATIONAL;
                subState = SUB_IDLE;
            }
            break;
    }
}

Vantagens:

• Redução de duplicação
• Escala bem
• Muito usada em automotivo e aeroespacial

4.3 Mode Manager (Gerenciador de Modos)

Problema resolvido:
Múltiplas tarefas precisam reagir a mudanças globais de modo.

Ideia do padrão:
Uma tarefa central gerencia o modo do sistema, e os demais módulos se adaptam.

Modos típicos

typedef enum {
    MODE_STARTUP,
    MODE_NORMAL,
    MODE_LOW_POWER,
    MODE_MAINTENANCE
} SystemMode;

typedef enum {
    MODE_STARTUP,
    MODE_NORMAL,
    MODE_LOW_POWER,
    MODE_MAINTENANCE
} SystemMode;

Mode Manager

static SystemMode currentMode;

void ModeManagerTask(void *pvParameters)
{
    for (;;)
    {
        if (LowPowerRequested())
            currentMode = MODE_LOW_POWER;

        if (MaintenanceRequested())
            currentMode = MODE_MAINTENANCE;

        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

static SystemMode currentMode;

void ModeManagerTask(void *pvParameters)
{
    for (;;)
    {
        if (LowPowerRequested())
            currentMode = MODE_LOW_POWER;

        if (MaintenanceRequested())
            currentMode = MODE_MAINTENANCE;

        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

Uso pelas tarefas

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        if (currentMode == MODE_NORMAL)
            ReadSensors();

        vTaskDelay(pdMS_TO_TICKS(50));
    }
}

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        if (currentMode == MODE_NORMAL)
            ReadSensors();

        vTaskDelay(pdMS_TO_TICKS(50));
    }
}

Boa prática:
Substituir variável global por:

• Event Groups
• Message Queue
• Broadcast via Pub-Sub

4.4 Recovery Pattern (Padrão de Recuperação)

Problema resolvido:
Falhas transitórias travam o sistema.

Ideia do padrão:
Falhas são tratadas como estados, não exceções implícitas.

Exemplo de recuperação controlada

case STATE_ERROR:
    LogFault();
    ResetSubsystem();
    if (RetryAllowed())
        currentState = STATE_INIT;
    else
        EnterSafeState();
    break;

case STATE_ERROR:
    LogFault();
    ResetSubsystem();
    if (RetryAllowed())
        currentState = STATE_INIT;
    else
        EnterSafeState();
    break;

Vantagens:

• Evita reboot desnecessário
• Permite retry controlado
• Essencial para sistemas remotos

4.5 Watchdog como Padrão Arquitetural

Problema resolvido:
Deadlocks silenciosos e travamentos não detectados.

Ideia do padrão:
Cada tarefa sinaliza vida periodicamente para um supervisor.

void SupervisorTask(void *pvParameters)
{
    for (;;)
    {
        if (!AllTasksAlive())
            SystemReset();

        FeedWatchdog();
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void SupervisorTask(void *pvParameters)
{
    for (;;)
    {
        if (!AllTasksAlive())
            SystemReset();

        FeedWatchdog();
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Importante:
O watchdog não substitui arquitetura correta — ele a complementa.

Excelente. Agora avançamos para a arquitetura interna do firmware, onde decisões erradas costumam gerar acoplamento irreversível, e decisões corretas permitem portabilidade, testes e evolução por anos.

5 – Padrões de Arquitetura em Camadas, Drivers e Serviços em RTOS

Em sistemas com FreeRTOS, misturar driver, lógica de negócio e política de tempo real na mesma tarefa é um erro estrutural. Os padrões desta seção tratam de separação de responsabilidades, isolamento de hardware e execução previsível.

5.1 Layered Architecture (Arquitetura em Camadas)

Problema resolvido:
Firmware “espaguete”, onde qualquer módulo acessa diretamente registradores, RTOS e aplicação.

Ideia do padrão:
Organizar o sistema em camadas bem definidas, com dependências unidirecionais.

Camadas típicas em FreeRTOS

Exemplo de separação correta

Driver (HAL):

void UartHw_SendByte(uint8_t b);

void UartHw_SendByte(uint8_t b);

Serviço:

void UartService_Send(const uint8_t *data, size_t len);

void UartService_Send(const uint8_t *data, size_t len);

Aplicação:

UartService_Send((uint8_t*)"OK\n", 3);

UartService_Send((uint8_t*)"OK\n", 3);

Vantagens:

• Portabilidade de MCU
• Testes unitários viáveis
• Evolução controlada

Regra prática:
Camadas superiores não conhecem detalhes das inferiores.

5.2 Hardware Abstraction Layer (HAL) como Padrão

Problema resolvido:
Dependência direta de registradores ou SDK do fabricante.

Ideia do padrão:
Isolar acesso ao hardware atrás de uma API mínima e estável.

typedef struct {
    void (*init)(void);
    void (*write)(const uint8_t *buf, size_t len);
} UartDriver;

typedef struct {
    void (*init)(void);
    void (*write)(const uint8_t *buf, size_t len);
} UartDriver;

static UartDriver uart0 = {
    .init  = STM32_UartInit,
    .write = STM32_UartWrite
};

static UartDriver uart0 = {
    .init  = STM32_UartInit,
    .write = STM32_UartWrite
};

Benefício crítico:
Permite trocar STM32 → NXP → RP2040 sem reescrever aplicação.

5.3 Service Layer (Camada de Serviços)

Problema resolvido:
Drivers não devem conter lógica de negócio nem política de concorrência.

Ideia do padrão:
Serviços encapsulam:

• Sincronização
• Filas
• Retries
• Timeout
• Políticas de acesso

Exemplo: Serviço de UART com Gatekeeper

void UartService_Send(const uint8_t *data, size_t len)
{
    UartRequest req = {
        .data = data,
        .len  = len
    };

    xQueueSend(UartQueue, &req, portMAX_DELAY);
}

void UartService_Send(const uint8_t *data, size_t len)
{
    UartRequest req = {
        .data = data,
        .len  = len
    };

    xQueueSend(UartQueue, &req, portMAX_DELAY);
}

Vantagens:

• Aplicação fica limpa
• Política centralizada
• Drivers permanecem simples

5.4 Active Object Pattern

Problema resolvido:
Misturar lógica de controle com concorrência explícita.

Ideia do padrão:
Cada objeto ativo possui:

• Estado interno
• Fila própria
• Tarefa dedicada

Estrutura conceitual

Active Object
 ├── Queue
 ├── Task
 └── State Machine

Active Object
 ├── Queue
 ├── Task
 └── State Machine

Exemplo simplificado

typedef struct {
    QueueHandle_t queue;
} MotorController;

typedef struct {
    QueueHandle_t queue;
} MotorController;

void MotorTask(void *pvParameters)
{
    MotorCommand cmd;

    for (;;)
    {
        xQueueReceive(motor.queue, &cmd, portMAX_DELAY);
        ExecuteMotorCommand(&cmd);
    }
}

void MotorTask(void *pvParameters)
{
    MotorCommand cmd;

    for (;;)
    {
        xQueueReceive(motor.queue, &cmd, portMAX_DELAY);
        ExecuteMotorCommand(&cmd);
    }
}

Vantagens:

• Forte encapsulamento
• Ideal para controle, comunicação e I/O
• Elimina mutexes internos

Custo:
Uso maior de RAM (1 task + 1 fila por objeto)

5.5 Deferred Interrupt Processing

Problema resolvido:
ISR longa causa jitter e perda de deadlines.

Ideia do padrão:
ISR apenas sinaliza → processamento pesado ocorre em task.

void ADC_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xTaskNotifyFromISR(AdcTaskHandle, 0, eNoAction, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void ADC_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xTaskNotifyFromISR(AdcTaskHandle, 0, eNoAction, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void AdcTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        ProcessAdcData();
    }
}

void AdcTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        ProcessAdcData();
    }
}

Vantagens:

• ISR mínima
• Melhor escalonamento
• Sistema mais previsível

6 – Padrões de Inicialização, Startup Sequencial e Monitoramento de Saúde

Em sistemas com FreeRTOS, o boot é o momento mais frágil do sistema. Muitos firmwares falham não durante a operação normal, mas durante inicialização parcial, falhas de periféricos, ordem incorreta de dependências ou estados indefinidos.

Os padrões desta seção tornam o startup determinístico, auditável e recuperável.

6.1 Startup Task (Task de Inicialização)

Problema resolvido:
Inicialização espalhada entre main(), ISRs e tarefas diversas.

Ideia do padrão:
Criar uma tarefa exclusiva de startup, responsável por inicializar tudo em ordem controlada, antes do sistema entrar em operação normal.

Estrutura típica

int main(void)
{
    HardwareInit();

    xTaskCreate(StartupTask, "Startup", 1024, NULL, tskIDLE_PRIORITY + 3, NULL);

    vTaskStartScheduler();
}

int main(void)
{
    HardwareInit();

    xTaskCreate(StartupTask, "Startup", 1024, NULL, tskIDLE_PRIORITY + 3, NULL);

    vTaskStartScheduler();
}

void StartupTask(void *pvParameters)
{
    InitDrivers();
    InitServices();
    InitApplication();

    xTaskCreate(AppTask, "App", 1024, NULL, tskIDLE_PRIORITY + 1, NULL);

    vTaskDelete(NULL);
}

void StartupTask(void *pvParameters)
{
    InitDrivers();
    InitServices();
    InitApplication();

    xTaskCreate(AppTask, "App", 1024, NULL, tskIDLE_PRIORITY + 1, NULL);

    vTaskDelete(NULL);
}

Vantagens:

• Ordem explícita
• Inicialização rastreável
• Elimina “efeitos colaterais” no main()

Boa prática:
Startup task deve se autodestruir após cumprir sua função.

6.2 Init Sequencing (Sequenciamento de Inicialização)

Problema resolvido:
Tarefas começam a rodar antes de suas dependências estarem prontas.

Ideia do padrão:
Inicialização ocorre em fases bem definidas, com sincronização explícita.

Exemplo com Event Groups

#define EVT_DRIVERS_READY   (1 << 0)
#define EVT_SERVICES_READY  (1 << 1)

#define EVT_DRIVERS_READY   (1 << 0)
#define EVT_SERVICES_READY  (1 << 1)

void StartupTask(void *pvParameters)
{
    InitDrivers();
    xEventGroupSetBits(systemEvents, EVT_DRIVERS_READY);

    InitServices();
    xEventGroupSetBits(systemEvents, EVT_SERVICES_READY);

    vTaskDelete(NULL);
}

void StartupTask(void *pvParameters)
{
    InitDrivers();
    xEventGroupSetBits(systemEvents, EVT_DRIVERS_READY);

    InitServices();
    xEventGroupSetBits(systemEvents, EVT_SERVICES_READY);

    vTaskDelete(NULL);
}

void AppTask(void *pvParameters)
{
    xEventGroupWaitBits(
        systemEvents,
        EVT_DRIVERS_READY | EVT_SERVICES_READY,
        pdFALSE,
        pdTRUE,
        portMAX_DELAY
    );

    RunApplication();
}

void AppTask(void *pvParameters)
{
    xEventGroupWaitBits(
        systemEvents,
        EVT_DRIVERS_READY | EVT_SERVICES_READY,
        pdFALSE,
        pdTRUE,
        portMAX_DELAY
    );

    RunApplication();
}

Vantagem:
Dependências explícitas → menos bugs “fantasma”.

6.3 Dependency Ordering Pattern

Problema resolvido:
Serviços que dependem implicitamente uns dos outros.

Ideia do padrão:
Cada serviço declara o que precisa antes de operar.

Exemplo conceitual

bool Network_IsReady(void);
bool Storage_IsReady(void);

bool Network_IsReady(void);
bool Storage_IsReady(void);

void TelemetryTask(void *pvParameters)
{
    while (!Network_IsReady() || !Storage_IsReady())
    {
        vTaskDelay(pdMS_TO_TICKS(100));
    }

    StartTelemetry();
}

void TelemetryTask(void *pvParameters)
{
    while (!Network_IsReady() || !Storage_IsReady())
    {
        vTaskDelay(pdMS_TO_TICKS(100));
    }

    StartTelemetry();
}

Melhoria recomendada:
Substituir polling por eventos ou notificações.

6.4 Health Monitoring Pattern (Monitoramento de Saúde)

Problema resolvido:
Tarefas travam silenciosamente.

Ideia do padrão:
Cada tarefa reporta periodicamente seu estado para um supervisor central.

Estrutura básica

typedef struct {
    uint32_t taskId;
    TickType_t lastAlive;
} TaskHealth;

typedef struct {
    uint32_t taskId;
    TickType_t lastAlive;
} TaskHealth;

void HealthReport(uint32_t id)
{
    healthTable[id].lastAlive = xTaskGetTickCount();
}

void HealthReport(uint32_t id)
{
    healthTable[id].lastAlive = xTaskGetTickCount();
}

void SupervisorTask(void *pvParameters)
{
    for (;;)
    {
        if (TaskTimeoutDetected())
            EnterRecoveryMode();

        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void SupervisorTask(void *pvParameters)
{
    for (;;)
    {
        if (TaskTimeoutDetected())
            EnterRecoveryMode();

        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

Vantagens:

• Detecção precoce de falhas
• Integração natural com watchdog
• Essencial em sistemas remotos

6.5 Fail-Safe State Pattern

Problema resolvido:
Sistema entra em estado indefinido após falha grave.

Ideia do padrão:
Definir explicitamente um estado seguro, conhecido e controlado.

void EnterSafeState(void)
{
    DisableOutputs();
    StopMotors();
    SignalErrorLED();
}

void EnterSafeState(void)
{
    DisableOutputs();
    StopMotors();
    SignalErrorLED();
}

Importante:
Fail-safe não é reset. É sobrevivência controlada.

6.6 Warm Restart vs Cold Restart

Problema resolvido:
Reset total desnecessário causa perda de estado e latência.

Ideia do padrão:
Diferenciar:

• Cold restart → reboot completo
• Warm restart → reinicialização parcial de serviços

if (RecoverableFault())
    RestartServices();
else
    SystemReset();

if (RecoverableFault())
    RestartServices();
else
    SystemReset();

7 – Síntese Geral e Checklist Arquitetural de Padrões para FreeRTOS

Após percorrer os principais grupos de padrões aplicáveis a sistemas com RTOS, fica claro que FreeRTOS não é apenas um escalonador, mas uma plataforma arquitetural que exige decisões conscientes desde o primeiro xTaskCreate().

Esta seção final transforma o conteúdo técnico em instrumento de uso real, algo que pode ser consultado durante o desenho ou revisão de um firmware.

7.1 Mapa Conceitual dos Padrões em RTOS

Podemos organizar os padrões apresentados em camadas de decisão, do mais fundamental ao mais sistêmico:

Estrutura Básica

• Superloop + Tasks
• One Task per Responsibility
• Cyclic Executive
• Idle Task Pattern

Define como o sistema respira

Comunicação e Sincronização

• Event Queue
• Mailbox
• Publish–Subscribe
• Task Notifications
• Stream Buffer / Message Buffer

Define como a informação flui

Proteção de Recursos

• Mutex com Priority Inheritance
• Gatekeeper Task
• Critical Sections
• Event Groups
• Deadlock Avoidance

Define como o sistema se protege

Controle de Comportamento

• Finite State Machine (FSM)
• Hierarchical State Machine (HSM)
• Mode Manager
• Recovery Pattern
• Watchdog Pattern

Define como o sistema se comporta e reage

Arquitetura Interna

• Layered Architecture
• HAL
• Service Layer
• Active Object
• Deferred Interrupt Processing

Define como o sistema é construído

Inicialização e Robustez

• Startup Task
• Init Sequencing
• Dependency Ordering
• Health Monitoring
• Fail-Safe State
• Warm vs Cold Restart

Define como o sistema nasce e sobrevive

7.2 Checklist Arquitetural para Projetos com FreeRTOS

Use este checklist como ferramenta de revisão técnica:

Estrutura

• Cada tarefa tem uma responsabilidade clara?
• Existe uma política clara de prioridades?
• Tarefas críticas têm WCET conhecido?

Comunicação

• Variáveis globais foram substituídas por filas/eventos?
• ISR apenas sinalizam, nunca processam?
• Fluxos contínuos usam buffers, não filas?

Proteção

• Mutexes são usados apenas para recursos?
• Existe Gatekeeper para periféricos compartilhados?
• Ordem de aquisição de recursos é consistente?

Estados e Modos

• O comportamento está modelado em FSM ou HSM?
• Modos globais são explícitos?
• Falhas são estados, não exceções implícitas?

Arquitetura

• Aplicação não conhece registradores?
• Drivers não conhecem RTOS?
• Serviços encapsulam política e sincronização?

Inicialização e Saúde

• Startup ocorre em task dedicada?
• Dependências são explícitas?
• Existe supervisão de tarefas?
• Fail-safe é definido?

7.3 Erros Clássicos que Esses Padrões Evitam

• “Só mais um volatile resolve”
• “Vamos proteger tudo com mutex”
• “ISR rápida não precisa de cuidado”
• “Reset resolve qualquer coisa”
• “Depois a gente organiza a arquitetura”

Todos esses erros são sintomas da ausência de padrões, não de falta de RTOS.

Conclusão Geral do Artigo

A maturidade em sistemas embarcados com FreeRTOS não está em quantas tasks você cria, mas em como você estrutura comportamento, comunicação e recuperação.

RTOS sem padrões é apenas concorrência.
RTOS com padrões é engenharia.

Os padrões apresentados aqui não são teóricos: eles surgiram de sistemas industriais, médicos, automotivos e aeroespaciais, e quando aplicados corretamente, reduzem drasticamente:

• Bugs intermitentes
• Tempo de depuração
• Retrabalho arquitetural
• Risco em produção

The post Padrões de Projeto Aplicados a RTOS (FreeRTOS) 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.

O mercado de microcontroladores passou por uma transformação significativa nas últimas duas décadas. Durante muitos anos, fabricantes tradicionais como STMicroelectronics, Microchip, NXP, Renesas e Texas Instruments dominaram o setor com dispositivos voltados principalmente para aplicações industriais, automotivas e de controle embarcado. Esses microcontroladores eram projetados com foco em robustez, confiabilidade, precisão analógica e integração com periféricos industriais, características essenciais para sistemas críticos.

Entretanto, com a explosão da Internet das Coisas (IoT) e da cultura maker, um novo tipo de microcontrolador ganhou espaço: dispositivos altamente integrados que incorporam conectividade wireless diretamente no chip, reduzindo drasticamente a complexidade do hardware. Nesse cenário surgiu a Espressif Systems, empresa chinesa que revolucionou o mercado com o ESP8266 e posteriormente com a família ESP32, SoCs capazes de oferecer Wi-Fi, Bluetooth e processamento embarcado em um único dispositivo de baixo custo.

Esse movimento criou uma situação curiosa no mercado. Muitos desenvolvedores passaram a escolher microcontroladores simplesmente porque funcionam para determinado projeto, sem considerar adequadamente o contexto da aplicação, os requisitos de confiabilidade, a escalabilidade do produto ou o modelo de negócio por trás do fabricante do chip.

Este artigo propõe uma reflexão sobre essa questão. Para isso, analisaremos os modelos de negócio da STMicroelectronics e da Espressif, seus públicos-alvo, as decisões tecnológicas que moldaram seus portfólios e as possíveis evoluções futuras dessas estratégias. Também discutiremos brevemente como outros fabricantes importantes, como Microchip e NXP, se posicionam nesse mesmo mercado.

Antes de comparar diretamente essas empresas, é fundamental compreender como o modelo de negócio da STMicroelectronics foi construído ao longo de décadas no mercado de semicondutores e por que sua estratégia difere profundamente daquela adotada pela Espressif.

The post STMicroelectronics vs Espressif – Modelos de Negócio e Estratégias no Mercado de Microcontroladores first appeared on MCU & FPGA.

Introdução geral

Em sistemas embarcados com RTOS, especialmente em aplicações industriais, automotivas e IoT crítico, o maior desafio não é apenas “fazer funcionar”, mas manter previsibilidade temporal, escalabilidade e manutenibilidade. É nesse ponto que os padrões de projeto aplicados a RTOS se tornam fundamentais.

Diferente de aplicações desktop, padrões em RTOS precisam respeitar restrições de tempo real, uso determinístico de memória, prioridades, latência de interrupções e sincronização segura entre contexto de ISR e tarefas. Muitos padrões clássicos de software são adaptados ou reinterpretados nesse contexto.

Neste artigo, começaremos pelos padrões estruturais básicos de tarefas, que formam a fundação de praticamente qualquer sistema com FreeRTOS.

Padrões Fundamentais de Estruturação de Tarefas

1.1 Superloop + Tasks (Incremental RTOS Adoption)

Problema resolvido:
Projetos legados em superloop (while(1)) tornam-se difíceis de manter à medida que crescem. Migrar tudo de uma vez para RTOS é arriscado.

Ideia do padrão:
Manter o superloop como uma tarefa principal, introduzindo gradualmente novas tarefas RTOS.

Quando usar:

• Migração de firmware bare-metal para FreeRTOS
• Sistemas simples que estão crescendo
• Prototipação controlada

Estrutura típica:

void LegacySuperloopTask(void *pvParameters)
{
    for (;;)
    {
        ReadSensors();
        ProcessData();
        UpdateOutputs();

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void LegacySuperloopTask(void *pvParameters)
{
    for (;;)
    {
        ReadSensors();
        ProcessData();
        UpdateOutputs();

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

xTaskCreate(
    LegacySuperloopTask,
    "Legacy",
    1024,
    NULL,
    tskIDLE_PRIORITY + 1,
    NULL
);

xTaskCreate(
    LegacySuperloopTask,
    "Legacy",
    1024,
    NULL,
    tskIDLE_PRIORITY + 1,
    NULL
);

Vantagens:

• Baixo risco na migração
• Preserva código validado
• Facilita testes incrementais

Risco comum:
Transformar essa tarefa em um “monstro” que ignora o espírito do RTOS. Este padrão deve ser transitório, não permanente.

1.2 One Task Per Responsibility (Uma tarefa por responsabilidade)

Problema resolvido:
Tarefas que fazem “de tudo” dificultam análise temporal, debugging e escalonamento.

Ideia do padrão:
Cada tarefa possui uma única responsabilidade funcional bem definida.

Exemplo típico em FreeRTOS:

• Task de aquisição
• Task de processamento
• Task de comunicação

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        ReadADC();
        xTaskNotify(ProcessTaskHandle, 0, eNoAction);
        vTaskDelay(pdMS_TO_TICKS(5));
    }
}

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        ReadADC();
        xTaskNotify(ProcessTaskHandle, 0, eNoAction);
        vTaskDelay(pdMS_TO_TICKS(5));
    }
}

void ProcessTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        FilterData();
        ComputeResults();
    }
}

void ProcessTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        FilterData();
        ComputeResults();
    }
}

Vantagens:

• Facilita análise de prioridades
• Reduz acoplamento
• Favorece paralelismo real

Boas práticas:

• Nomear tarefas claramente
• Documentar WCET (Worst Case Execution Time)
• Evitar bloqueios longos

1.3 Cyclic Executive com RTOS

Problema resolvido:
Algumas aplicações precisam de periodicidade rígida, mesmo usando RTOS.

Ideia do padrão:
Uma tarefa de alta prioridade atua como orquestrador temporal, liberando outras tarefas de forma cíclica.

Estrutura conceitual:

• Task cíclica principal
• Subtarefas acionadas por notificações

void CyclicTask(void *pvParameters)
{
    TickType_t xLastWakeTime = xTaskGetTickCount();

    for (;;)
    {
        xTaskNotify(TaskAHandle, 0, eNoAction);
        xTaskNotify(TaskBHandle, 0, eNoAction);

        vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(10));
    }
}

void CyclicTask(void *pvParameters)
{
    TickType_t xLastWakeTime = xTaskGetTickCount();

    for (;;)
    {
        xTaskNotify(TaskAHandle, 0, eNoAction);
        xTaskNotify(TaskBHandle, 0, eNoAction);

        vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(10));
    }
}

Vantagens:

• Controle temporal explícito
• Previsibilidade elevada
• Útil em controle e automação

Limitação:
Menos flexível que arquiteturas puramente orientadas a eventos.

1.4 Idle Task como Padrão Arquitetural

Problema resolvido:
Desperdício de CPU e energia quando o sistema está ocioso.

Ideia do padrão:
Usar a Idle Task como ponto central para:

• Economia de energia
• Limpeza de recursos
• Instrumentação

void vApplicationIdleHook(void)
{
    EnterLowPowerMode();
}

void vApplicationIdleHook(void)
{
    EnterLowPowerMode();
}

Uso típico:

• __WFI() em Cortex-M
• Estatísticas de CPU
• Monitoramento de heap

Importante:
Nunca bloquear, nunca usar delays e nunca acessar recursos não protegidos.

The post Padrões de Projeto Aplicados a RTOS (FreeRTOS) first appeared on MCU & FPGA.