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.

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.

Durante muitos anos, a ideia de containerização esteve restrita ao universo de servidores e computação em nuvem. Tecnologias como Docker revolucionaram a forma como aplicações são distribuídas, implantadas e isoladas em ambientes Linux, permitindo que sistemas complexos fossem divididos em componentes independentes, seguros e facilmente atualizáveis. Entretanto, à medida que dispositivos IoT passaram a assumir funções críticas — desde gateways industriais até dispositivos médicos e infraestrutura conectada — surgiu uma necessidade semelhante no mundo dos sistemas embarcados: como isolar aplicações, garantir segurança e permitir atualizações modulares em microcontroladores com recursos limitados?

É nesse contexto que surge a evolução do conceito de containerização aplicada ao Zephyr, um sistema operacional de tempo real (RTOS) amplamente utilizado em dispositivos IoT e aplicações embarcadas. Diferentemente do modelo tradicional baseado em kernel Linux, hypervisors e virtualização pesada, a abordagem embarcada exige um redesenho do conceito de container para se adequar a arquiteturas com pouca memória, ausência de MMU (Memory Management Unit) e requisitos rígidos de determinismo temporal.

Este artigo explora como a containerização funciona no Zephyr OS, quais mecanismos tornam isso possível e quais são as implicações arquiteturais dessa nova abordagem para firmware moderno.

O Conceito Original de Containerização

No ambiente Linux tradicional, containerização consiste em empacotar uma aplicação juntamente com todas as suas dependências em uma unidade isolada chamada container. Diferente de uma máquina virtual, que executa um sistema operacional completo sobre um hypervisor, o container compartilha o kernel do sistema hospedeiro, isolando apenas o espaço de usuário.

Esse isolamento é obtido por meio de mecanismos como namespaces (isolamento de processos, rede e sistema de arquivos) e cgroups (controle de uso de CPU e memória). O resultado é um ambiente leve, eficiente e altamente portátil. Uma aplicação pode ser executada da mesma forma em diferentes máquinas, desde que o runtime de container esteja presente.

Contudo, esse modelo depende fortemente de características típicas de sistemas Linux completos, como suporte a virtualização, gerenciamento avançado de memória e separação robusta entre kernel e espaço de usuário. Em microcontroladores, esse cenário é completamente diferente.

O Desafio da Containerização em Microcontroladores

Em sistemas embarcados baseados em microcontroladores — como aqueles da família Cortex-M, ESP32 ou RP2040 — frequentemente não há suporte a MMU, e muitas vezes o sistema roda em modo bare-metal ou com um RTOS enxuto. A memória é limitada, e o firmware tradicionalmente é monolítico: todas as funcionalidades são compiladas juntas em uma única imagem binária.

Nesse modelo tradicional, um erro em qualquer parte do firmware pode comprometer todo o sistema. Não há isolamento real entre módulos, nem separação de privilégios. Isso se torna particularmente problemático quando o dispositivo precisa executar múltiplas aplicações, receber atualizações OTA (Over-The-Air) ou rodar código de terceiros.

O que o Zephyr propõe é uma adaptação do conceito de containerização para esse contexto restrito, utilizando os recursos disponíveis no hardware embarcado.

Como o Zephyr Implementa Containerização

A containerização no Zephyr não utiliza virtualização nem hypervisor. Em vez disso, ela se apoia em três pilares fundamentais:

1. Separação entre kernel e espaço de usuário
2. Uso de MPU (Memory Protection Unit) quando disponível
3. Definição de domínios de memória e permissões de acesso

O Zephyr permite que threads sejam executadas em modo usuário. Nessas condições, o acesso à memória e a periféricos é controlado pelo kernel. Cada aplicação pode ser associada a um domínio de memória específico, contendo apenas as regiões às quais ela tem permissão de acesso. Caso uma thread tente acessar uma região não autorizada, uma exceção é gerada.

Esse mecanismo cria uma forma de sandboxing embarcado. Embora não seja um container Linux no sentido tradicional, ele oferece isolamento suficiente para impedir que falhas em um módulo comprometam o restante do sistema.

Domínios de Memória e Isolamento

O conceito central por trás da containerização no Zephyr é o de memory domains. Um domínio de memória define um conjunto de regiões que uma aplicação pode acessar. Essas regiões podem incluir:

• Segmentos de código
• Buffers de dados
• Pilhas (stacks)
• Heaps específicos
• Áreas compartilhadas controladas

Quando a MPU está presente, o hardware impõe essas restrições fisicamente. Isso garante que uma aplicação não consiga acessar memória pertencente a outra aplicação ou ao kernel.

Essa abordagem transforma o firmware monolítico tradicional em uma arquitetura modular compartimentada. Cada módulo passa a operar como se estivesse dentro de seu próprio container lógico.

Multi-Image e Atualizações Modulares

Outra característica importante é a possibilidade de trabalhar com múltiplas imagens de firmware. Em arquiteturas mais avançadas, como aquelas com bootloaders seguros e suporte a atualização OTA, diferentes componentes podem ser atualizados independentemente.

Esse modelo se aproxima ainda mais da filosofia de containerização moderna: componentes independentes, versionáveis e substituíveis sem necessidade de reconstruir todo o sistema.

Para dispositivos IoT conectados à nuvem, essa capacidade é estratégica. Ela permite corrigir vulnerabilidades específicas sem interromper todo o sistema, além de viabilizar aplicações de terceiros com maior segurança.

Diferenças Fundamentais em Relação ao Docker

É importante enfatizar que a containerização no Zephyr não executa Docker dentro do microcontrolador. Não há suporte a namespaces Linux nem gerenciamento de imagens no formato tradicional.

O que existe é uma implementação conceitual do isolamento, baseada em recursos de hardware embarcado. A proteção depende da MPU e da arquitetura do microcontrolador. Em dispositivos sem suporte a proteção de memória, o nível de isolamento é limitado.

Portanto, trata-se de uma adaptação do paradigma, e não de uma replicação direta da tecnologia de containers usada em servidores.

Impacto Arquitetural

A introdução de containerização no contexto do Zephyr representa uma mudança significativa na forma como firmware embarcado é estruturado. Em vez de um único bloco de código com acesso irrestrito a todos os recursos, passa-se a um modelo de aplicações isoladas, com permissões explícitas e fronteiras bem definidas.

Isso aproxima sistemas embarcados do modelo cloud-native, onde aplicações são desacopladas, independentes e resilientes. Para aplicações industriais, médicas e de infraestrutura crítica, esse nível adicional de segurança e modularidade pode ser determinante.

Além disso, a abordagem fortalece a segurança cibernética em dispositivos IoT, mitigando riscos associados a execução de código malicioso ou falhas não tratadas.

Referências

Electronic Design — “You Can Now Use Containers with Zephyr OS”
https://www.electronicdesign.com/technologies/embedded/software/video/55355192/electronic-design-you-can-now-use-containers-with-zephyr-os

Vídeo explicativo sobre containers no Zephyr OS
https://www.youtube.com/watch?v=qqaKtV05NqA&t=120s

Documentação oficial do Zephyr Project
https://docs.zephyrproject.org

Documentação do Docker
https://docs.docker.com

The post Containerização em Sistemas Embarcados com Zephyr OS first appeared on MCU & FPGA.

Visão Geral dos Mecanismos de Sincronização e Comunicação

1.1 Por que o Zephyr oferece múltiplos mecanismos?

Diferente de um RTOS minimalista, o Zephyr OS foi projetado para atender desde microcontroladores simples até sistemas complexos com múltiplos cores, drivers, stacks de comunicação e middleware. Por isso, ele não impõe um único modelo de comunicação entre threads, mas oferece vários mecanismos, cada um otimizado para um tipo específico de problema.

Em termos práticos, isso significa que não existe “o melhor mecanismo”, mas sim o mecanismo correto para cada cenário. Usar k_mutex onde um k_queue seria adequado gera latência desnecessária. Usar k_poll quando um k_sem resolveria o problema aumenta complexidade sem ganho real.

De forma conceitual, os mecanismos do Zephyr podem ser classificados em três grandes grupos:

• Comunicação de dados: quando informações precisam ser transferidas entre threads
• Sincronização: quando o objetivo é coordenar execução
• Exclusão mútua: quando recursos compartilhados precisam ser protegidos

Nas próximas seções, vamos analisar como Queues, Flags, Mutexes, Notificações e Eventos se encaixam nesses grupos.

1.2 Threads no Zephyr: o pano de fundo necessário

Antes de falar de filas e eventos, é importante lembrar que o Zephyr adota um modelo de threads preemptivas, com prioridades explícitas. Threads de prioridade menor podem ser interrompidas por threads de prioridade maior a qualquer momento.

Isso cria dois desafios fundamentais:

1. Compartilhamento seguro de dados
2. Coordenação determinística entre tarefas concorrentes

Sem mecanismos adequados, surgem problemas clássicos:

• Race conditions
• Deadlocks
• Priority inversion
• Leitura de dados inconsistentes

Os objetos do kernel (k_*) existem exatamente para resolver esses problemas.

1.3 Introdução às Queues no Zephyr

As Queues no Zephyr são usadas quando dados precisam ser transferidos entre contextos, tipicamente entre threads produtoras e consumidoras. Diferente de simples variáveis globais, as queues:

• Garantem acesso thread-safe
• Permitem bloqueio automático
• São integradas ao escalonador do kernel

O Zephyr oferece múltiplos tipos de fila. A mais usada conceitualmente é a k_queue, que trabalha com ponteiros genéricos (void *), permitindo grande flexibilidade.

1.4 Estrutura básica de uma k_queue

Uma fila no Zephyr é declarada estaticamente ou dinamicamente. O caso mais comum em sistemas embarcados é a declaração estática, que evita alocação dinâmica em tempo de execução.

#include <zephyr/kernel.h>

K_QUEUE_DEFINE(minha_fila);

#include <zephyr/kernel.h>

K_QUEUE_DEFINE(minha_fila);

Essa macro cria:

• A estrutura de controle da fila
• A sincronização interna
• A integração com o escalonador

Não há necessidade de inicialização manual.

1.5 Enviando dados para a fila (Producer)

Um produtor insere elementos na fila usando k_queue_append() ou k_queue_prepend().

Exemplo simples: uma thread que produz mensagens.

struct mensagem {
    uint32_t id;
    uint32_t valor;
};

void produtor_thread(void)
{
    static struct mensagem msg;

    while (1) {
        msg.id++;
        msg.valor = k_uptime_get_32();

        k_queue_append(&minha_fila, &msg);

        k_sleep(K_MSEC(500));
    }
}

struct mensagem {
    uint32_t id;
    uint32_t valor;
};

void produtor_thread(void)
{
    static struct mensagem msg;

    while (1) {
        msg.id++;
        msg.valor = k_uptime_get_32();

        k_queue_append(&minha_fila, &msg);

        k_sleep(K_MSEC(500));
    }
}

Ponto crítico:
A fila armazena ponteiros, não cópias.
Isso significa que:

• O objeto precisa existir enquanto estiver na fila
• Variáveis automáticas de pilha não devem ser usadas

Esse detalhe é uma das principais fontes de bugs para quem vem de FreeRTOS (onde queues normalmente copiam dados).

1.6 Recebendo dados da fila (Consumer)

O consumidor usa k_queue_get(), podendo:

• Bloquear indefinidamente
• Bloquear por tempo definido
• Não bloquear

void consumidor_thread(void)
{
    struct mensagem *msg;

    while (1) {
        msg = k_queue_get(&minha_fila, K_FOREVER);

        printk("Recebido: id=%d valor=%d\n",
               msg->id, msg->valor);
    }
}

void consumidor_thread(void)
{
    struct mensagem *msg;

    while (1) {
        msg = k_queue_get(&minha_fila, K_FOREVER);

        printk("Recebido: id=%d valor=%d\n",
               msg->id, msg->valor);
    }
}

Aqui o kernel:

• Coloca a thread em estado bloqueado
• Acorda automaticamente quando um item chega
• Garante que apenas um consumidor receba cada item

1.7 Quando usar k_queue (e quando não usar)

Use Queues quando:

• Dados precisam ser transferidos entre threads
• Existe um padrão produtor–consumidor
• O volume de dados não é trivial
• A ordem de processamento importa

Evite k_queue quando:

• Apenas um flag é necessário
• Não há dados associados ao evento
• Latência mínima é crítica (flags são mais rápidas)

Nesses casos, Flags e Eventos são mais apropriados — tema da próxima seção.

1.8 Erros comuns no uso de Queues no Zephyr

Alguns erros aparecem com frequência em projetos reais:

1. Inserir ponteiros para variáveis locais
2. Reutilizar a mesma estrutura sem controle
3. Usar fila quando um simples evento resolveria
4. Esquecer que múltiplos consumidores competem pelo mesmo item

Esses erros não geram warnings de compilação, mas resultam em comportamento não determinístico, especialmente sob carga.

The post Filas, Flags, Mutexes, Notificações e Eventos no Zephyr RTOS first appeared on MCU & FPGA.

/*
 * Copyright (c) 2017 Linaro Limited
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/printk.h>
#include <zephyr/sys/__assert.h>
#include <string.h>

/* size of stack area used by each thread */
#define STACKSIZE 1024

/* scheduling priority used by each thread */
#define PRIORITY 7

#define LED0_NODE DT_ALIAS(led0)
#define LED1_NODE DT_ALIAS(led1)

#if !DT_NODE_HAS_STATUS_OKAY(LED0_NODE)
#error "Unsupported board: led0 devicetree alias is not defined"
#endif

#if !DT_NODE_HAS_STATUS_OKAY(LED1_NODE)
#error "Unsupported board: led1 devicetree alias is not defined"
#endif

struct printk_data_t {
	void *fifo_reserved; /* 1st word reserved for use by fifo */
	uint32_t led;
	uint32_t cnt;
};

K_FIFO_DEFINE(printk_fifo);

struct led {
	struct gpio_dt_spec spec;
	uint8_t num;
};

static const struct led led0 = {
	.spec = GPIO_DT_SPEC_GET_OR(LED0_NODE, gpios, {0}),
	.num = 0,
};

static const struct led led1 = {
	.spec = GPIO_DT_SPEC_GET_OR(LED1_NODE, gpios, {0}),
	.num = 1,
};

void blink(const struct led *led, uint32_t sleep_ms, uint32_t id)
{
	const struct gpio_dt_spec *spec = &led->spec;
	int cnt = 0;
	int ret;

	if (!device_is_ready(spec->port)) {
		printk("Error: %s device is not ready\n", spec->port->name);
		return;
	}

	ret = gpio_pin_configure_dt(spec, GPIO_OUTPUT);
	if (ret != 0) {
		printk("Error %d: failed to configure pin %d (LED '%d')\n",
			ret, spec->pin, led->num);
		return;
	}

	while (1) {
		gpio_pin_set(spec->port, spec->pin, cnt % 2);

		struct printk_data_t tx_data = { .led = id, .cnt = cnt };

		size_t size = sizeof(struct printk_data_t);
		char *mem_ptr = k_malloc(size);
		__ASSERT_NO_MSG(mem_ptr != 0);

		memcpy(mem_ptr, &tx_data, size);

		k_fifo_put(&printk_fifo, mem_ptr);

		k_msleep(sleep_ms);
		cnt++;
	}
}

void blink0(void)
{
	blink(&led0, 100, 0);
}

void blink1(void)
{
	blink(&led1, 1000, 1);
}

void uart_out(void)
{
	while (1) {
		struct printk_data_t *rx_data = k_fifo_get(&printk_fifo,
							   K_FOREVER);
		printk("Toggled led%d; counter=%d\n",
		       rx_data->led, rx_data->cnt);
		k_free(rx_data);
	}
}

K_THREAD_DEFINE(blink0_id, STACKSIZE, blink0, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(blink1_id, STACKSIZE, blink1, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(uart_out_id, STACKSIZE, uart_out, NULL, NULL, NULL,
		PRIORITY, 0, 0);

/*
 * Copyright (c) 2017 Linaro Limited
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/printk.h>
#include <zephyr/sys/__assert.h>
#include <string.h>

/* size of stack area used by each thread */
#define STACKSIZE 1024

/* scheduling priority used by each thread */
#define PRIORITY 7

#define LED0_NODE DT_ALIAS(led0)
#define LED1_NODE DT_ALIAS(led1)

#if !DT_NODE_HAS_STATUS_OKAY(LED0_NODE)
#error "Unsupported board: led0 devicetree alias is not defined"
#endif

#if !DT_NODE_HAS_STATUS_OKAY(LED1_NODE)
#error "Unsupported board: led1 devicetree alias is not defined"
#endif

struct printk_data_t {
	void *fifo_reserved; /* 1st word reserved for use by fifo */
	uint32_t led;
	uint32_t cnt;
};

K_FIFO_DEFINE(printk_fifo);

struct led {
	struct gpio_dt_spec spec;
	uint8_t num;
};

static const struct led led0 = {
	.spec = GPIO_DT_SPEC_GET_OR(LED0_NODE, gpios, {0}),
	.num = 0,
};

static const struct led led1 = {
	.spec = GPIO_DT_SPEC_GET_OR(LED1_NODE, gpios, {0}),
	.num = 1,
};

void blink(const struct led *led, uint32_t sleep_ms, uint32_t id)
{
	const struct gpio_dt_spec *spec = &led->spec;
	int cnt = 0;
	int ret;

	if (!device_is_ready(spec->port)) {
		printk("Error: %s device is not ready\n", spec->port->name);
		return;
	}

	ret = gpio_pin_configure_dt(spec, GPIO_OUTPUT);
	if (ret != 0) {
		printk("Error %d: failed to configure pin %d (LED '%d')\n",
			ret, spec->pin, led->num);
		return;
	}

	while (1) {
		gpio_pin_set(spec->port, spec->pin, cnt % 2);

		struct printk_data_t tx_data = { .led = id, .cnt = cnt };

		size_t size = sizeof(struct printk_data_t);
		char *mem_ptr = k_malloc(size);
		__ASSERT_NO_MSG(mem_ptr != 0);

		memcpy(mem_ptr, &tx_data, size);

		k_fifo_put(&printk_fifo, mem_ptr);

		k_msleep(sleep_ms);
		cnt++;
	}
}

void blink0(void)
{
	blink(&led0, 100, 0);
}

void blink1(void)
{
	blink(&led1, 1000, 1);
}

void uart_out(void)
{
	while (1) {
		struct printk_data_t *rx_data = k_fifo_get(&printk_fifo,
							   K_FOREVER);
		printk("Toggled led%d; counter=%d\n",
		       rx_data->led, rx_data->cnt);
		k_free(rx_data);
	}
}

K_THREAD_DEFINE(blink0_id, STACKSIZE, blink0, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(blink1_id, STACKSIZE, blink1, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(uart_out_id, STACKSIZE, uart_out, NULL, NULL, NULL,
		PRIORITY, 0, 0);

O arquivo src/main.c do exemplo (“threads”) listado acima, foi escrito para demonstrar uma ideia central do Zephyr: o seu aplicativo pode ser composto por threads declaradas estaticamente, que o kernel cria e inicia automaticamente durante o boot, sem você precisar de um “superloop” com main() controlando tudo.

Em muitos firmwares baremetal (ou mesmo com alguns RTOS), o padrão é:

• o startup do microcontrolador chama main();
• main() inicializa periféricos;
• cria tarefas/threads;
• entra em um while(1).

No Zephyr, isso pode existir (há muitos exemplos que têm void main(void)), mas não é obrigatório. Neste sample, os autores optaram por um modelo ainda mais “RTOS puro”:

1. O Zephyr sobe (boot + init do kernel).
2. O kernel inicializa infraestrutura (scheduler, heap, drivers, etc.).
3. As threads declaradas via K_THREAD_DEFINE(...) já entram no sistema como “threads do aplicativo”.
4. Cada thread roda seu próprio loop e coopera via primitivas do kernel (aqui, uma FIFO).

Ou seja: quem faz o papel de “fluxo principal” é o próprio kernel. O aplicativo é “plugado” nele por meio de definições estáticas (macros) que geram objetos e registram tudo para o boot.

Onde “entra” o seu código então?

Neste exemplo, o código entra em três pontos:

• blink0() → thread que pisca o LED0 e publica mensagens na FIFO.
• blink1() → thread que pisca o LED1 e publica mensagens na FIFO.
• uart_out() → thread que consome a FIFO e imprime via printk().

Essas três funções viram threads por causa destas três linhas no final do arquivo:

K_THREAD_DEFINE(blink0_id, STACKSIZE, blink0, NULL, NULL, NULL, PRIORITY, 0, 0);
K_THREAD_DEFINE(blink1_id, STACKSIZE, blink1, NULL, NULL, NULL, PRIORITY, 0, 0);
K_THREAD_DEFINE(uart_out_id, STACKSIZE, uart_out, NULL, NULL, NULL, PRIORITY, 0, 0);

A macro K_THREAD_DEFINE não é “só açúcar sintático”: ela efetivamente gera (em tempo de compilação) estruturas de thread, stack, metadados e a forma de o kernel iniciar essas threads no boot. Por isso dá para ter um app “100% thread-based” sem main().

Por que isso é uma boa ideia no Zephyr?

• Reprodutibilidade de boot: as threads já existem na imagem final, com stacks definidos e conhecidos.
• Menos código de “cola”: não precisa de um main() só para “criar threads”.
• Integração com o modelo do Zephyr: o kernel tem etapas de init bem definidas; seu app pode se encaixar nelas sem reinventar o fluxo.

Na próxima seção, eu faço a leitura guiada do topo do arquivo (includes + #defines), e começo a destrinchar as macros de DeviceTree (DT_ALIAS, DT_NODE_HAS_STATUS_OKAY, GPIO_DT_SPEC_GET_OR) e por que elas existem no Zephyr.

Includes, #defines e a filosofia de portabilidade do Zephyr

Vamos agora caminhar do topo do src/main.c para baixo, entendendo por que cada include e cada macro existem — e como isso se conecta ao modelo arquitetural do Zephyr.

Includes principais

Logo no início do arquivo, aparecem includes semelhantes a estes:

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/devicetree.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/printk.h>

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/devicetree.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/printk.h>

Esses headers revelam muito sobre o estilo de programação do Zephyr.

<zephyr/kernel.h>

É o coração do RTOS. Aqui estão:

• tipos básicos do kernel (k_tid_t, k_timeout_t, etc.),
• primitivas de sincronização,
• definição das macros de thread (K_THREAD_DEFINE, K_FIFO_DEFINE, etc.),
• funções como k_sleep(), k_fifo_put(), k_fifo_get().

Sem esse include, você literalmente não “fala” com o kernel.

<zephyr/device.h>

Introduz o tipo struct device, que representa instâncias concretas de hardware (GPIO, UART, I2C, SPI…).

No Zephyr:

• você não instancia drivers manualmente,
• os dispositivos são criados a partir do DeviceTree,
• o aplicativo apenas obtém uma referência para eles.

Esse detalhe é essencial para entender por que não existe GPIOA, GPIOB, ou registradores “na mão”, como em código baremetal tradicional.

<zephyr/devicetree.h>

Aqui começa uma das maiores diferenças entre Zephyr e firmwares clássicos.

O DeviceTree é um modelo declarativo de hardware, herdado do mundo Linux, mas adaptado para sistemas embarcados.

Esse header fornece macros que:

• acessam nós do DeviceTree em tempo de compilação,
• validam se um periférico existe,
• extraem pinos, portas, flags elétricas, etc.

Isso permite escrever o mesmo código C para placas completamente diferentes, sem #ifdef STM32, #ifdef NRF, etc.

<zephyr/drivers/gpio.h>

Define a API genérica de GPIO do Zephyr:

• gpio_pin_configure_dt()
• gpio_pin_toggle_dt()
• gpio_is_ready_dt()

Repare no sufixo _dt: ele indica que a função trabalha diretamente com dados vindos do DeviceTree, encapsulados em estruturas como gpio_dt_spec.

<zephyr/sys/printk.h>

Fornece printk(), que é:

• uma saída de debug simples,
• segura para uso em contexto de kernel,
• muito usada em exemplos.

Diferente de printf, printk não depende de libc completa e é mais previsível em RTOS.

Macros de configuração: STACKSIZE e PRIORITY

Logo após os includes, aparecem definições como:

#define STACKSIZE 1024
#define PRIORITY 7

#define STACKSIZE 1024
#define PRIORITY 7

Essas macros não são decorativas.

STACKSIZE

No Zephyr, cada thread tem sua própria pilha, explicitamente definida.

Isso é fundamental por dois motivos:

1. Determinismo
   Em sistemas embarcados críticos, saber exatamente quanto de stack cada thread usa é parte do projeto.
2. Proteção e debug
   O Zephyr pode aplicar stack canaries e stack overflow detection.

Aqui, cada thread criada com K_THREAD_DEFINE receberá uma pilha de 1024 bytes.

PRIORITY

No Zephyr:

• números menores → prioridade maior
• prioridades negativas são reservadas a threads do sistema
• prioridades positivas são para o aplicativo

Logo, PRIORITY 7 significa:

thread de aplicação, com prioridade relativamente baixa.

Isso é coerente com o exemplo:

• piscar LED e imprimir mensagens não são tarefas críticas.

Introdução ao DeviceTree no código

Agora chegamos a um trecho essencial:

#define LED0_NODE DT_ALIAS(led0)
#define LED1_NODE DT_ALIAS(led1)

#define LED0_NODE DT_ALIAS(led0)
#define LED1_NODE DT_ALIAS(led1)

Aqui entra um conceito que costuma confundir quem vem do baremetal.

O que é DT_ALIAS(led0)?

No arquivo .dts da placa (ou em um overlay), existe algo como:

aliases {
    led0 = &led0;
    led1 = &led1;
};

aliases {
    led0 = &led0;
    led1 = &led1;
};

O DT_ALIAS(led0):

• resolve, em tempo de compilação, o nó correspondente,
• gera um identificador interno usado pelas macros seguintes.

Isso elimina:

• números mágicos de pino,
• dependência direta da placa,
• #ifdef por fabricante.

Validação do hardware em compile time: DT_NODE_HAS_STATUS_OKAY e GPIO_DT_SPEC_GET_OR

Agora entramos em uma das partes mais importantes e menos triviais do código: o trecho que liga o DeviceTree ao código C de forma segura, portável e verificável em tempo de compilação.

O código é similar a este:

static const struct gpio_dt_spec led0 =
    GPIO_DT_SPEC_GET_OR(LED0_NODE, gpios, {0});

static const struct gpio_dt_spec led1 =
    GPIO_DT_SPEC_GET_OR(LED1_NODE, gpios, {0});

static const struct gpio_dt_spec led0 =
    GPIO_DT_SPEC_GET_OR(LED0_NODE, gpios, {0});

static const struct gpio_dt_spec led1 =
    GPIO_DT_SPEC_GET_OR(LED1_NODE, gpios, {0});

Mas antes disso, normalmente aparece um #if de proteção:

#if !DT_NODE_HAS_STATUS_OKAY(LED0_NODE)
#error "Unsupported board: led0 devicetree alias is not defined"
#endif

#if !DT_NODE_HAS_STATUS_OKAY(LED0_NODE)
#error "Unsupported board: led0 devicetree alias is not defined"
#endif

Vamos entender cada parte com profundidade.

DT_NODE_HAS_STATUS_OKAY(...)

O que essa macro realmente faz?

Essa macro pergunta ao DeviceTree:

“Existe um nó com esse identificador e ele está marcado como status = "okay"?”

No .dts, um LED típico é descrito assim:

led0: led_0 {
    gpios = <&gpioa 5 GPIO_ACTIVE_LOW>;
    label = "User LED";
    status = "okay";
};

led0: led_0 {
    gpios = <&gpioa 5 GPIO_ACTIVE_LOW>;
    label = "User LED";
    status = "okay";
};

Se:

• o alias não existir, ou
• o nó existir mas estiver desativado (status = "disabled"),

então DT_NODE_HAS_STATUS_OKAY(LED0_NODE) será falso.

Por que o Zephyr prefere falhar em compile time?

Este #error não é um capricho.

Ele garante que:

• você não gera um firmware inválido,
• o erro aparece antes de gravar no hardware,
• o mesmo código fonte denuncia automaticamente placas incompatíveis.

Em código baremetal clássico, isso só seria percebido:

• em runtime,
• ou pior, como um LED que “não pisca” sem explicação.

struct gpio_dt_spec

Agora vamos à estrutura que tudo gira em torno:

struct gpio_dt_spec {
    const struct device *port;
    gpio_pin_t pin;
    gpio_flags_t dt_flags;
};

struct gpio_dt_spec {
    const struct device *port;
    gpio_pin_t pin;
    gpio_flags_t dt_flags;
};

Ela encapsula tudo que você precisa para manipular um GPIO, sem saber:

• qual MCU é,
• qual registrador usar,
• se é STM32, nRF, ESP32, etc.

O DeviceTree preenche isso para você.

GPIO_DT_SPEC_GET_OR(...)

Essa macro é uma obra-prima de engenharia de firmware orientada a portabilidade.

GPIO_DT_SPEC_GET_OR(LED0_NODE, gpios, {0})

GPIO_DT_SPEC_GET_OR(LED0_NODE, gpios, {0})

Vamos decompor:

1. LED0_NODE

É o nó do DeviceTree resolvido pelo alias (led0).

2. gpios

É o nome da propriedade dentro do nó.

No .dts:

gpios = <&gpioa 5 GPIO_ACTIVE_LOW>;

gpios = <&gpioa 5 GPIO_ACTIVE_LOW>;

Ou seja:

• controlador GPIO,
• número do pino,
• flags elétricas.

3. {0}

Valor padrão caso a propriedade não exista.

Isso evita:

• ponteiros inválidos,
• acesso a hardware inexistente,
• falhas silenciosas.

O que essa macro gera na prática?

Ela cria uma instância constante de gpio_dt_spec, preenchida em tempo de compilação, algo conceitualmente assim:

led0.port = DEVICE_DT_GET(DT_NODELABEL(gpioa));
led0.pin = 5;
led0.dt_flags = GPIO_ACTIVE_LOW;

led0.port = DEVICE_DT_GET(DT_NODELABEL(gpioa));
led0.pin = 5;
led0.dt_flags = GPIO_ACTIVE_LOW;

Mas sem você escrever nada disso manualmente — e de forma portátil.

Checagem em runtime: gpio_is_ready_dt()

Mais adiante, dentro da thread, aparece:

if (!gpio_is_ready_dt(&led0)) {
    return;
}

if (!gpio_is_ready_dt(&led0)) {
    return;
}

Aqui há uma distinção importante:

• compile time: o nó existe e está válido
• runtime: o driver foi inicializado corretamente

Essa separação é arquiteturalmente correta:

• DeviceTree valida o hardware declarado
• gpio_is_ready_dt() valida o estado do driver

Seção 4 — Comunicação entre threads: struct msg e K_FIFO_DEFINE

Agora entramos no mecanismo central de comunicação entre as threads deste exemplo: a FIFO do Zephyr.
Aqui o código deixa claro que o objetivo do sample não é piscar LEDs, mas demonstrar concorrência e troca de dados entre threads.

A estrutura struct msg

O código define algo conceitualmente assim:

struct msg {
    void *fifo_reserved;
    uint32_t led;
    uint32_t cnt;
};

struct msg {
    void *fifo_reserved;
    uint32_t led;
    uint32_t cnt;
};

Essa estrutura tem um detalhe que costuma passar despercebido por quem vem de FreeRTOS ou CMSIS-RTOS:

void *fifo_reserved;

Esse campo não é opcional.

No Zephyr, as FIFOs (k_fifo) funcionam de maneira diferente de queues tradicionais:

• o kernel não copia dados para dentro da fila,
• ele encadeia objetos já existentes na memória,
• para isso, o primeiro campo da estrutura deve ser reservado para o kernel.

Ou seja:

• o kernel usa esse ponteiro para formar a lista encadeada interna da FIFO,
• você nunca deve tocar nesse campo manualmente.

Regra de ouro no Zephyr

Se um objeto vai para uma FIFO ou LIFO, o primeiro membro da struct deve ser um ponteiro reservado ao kernel.

Campos de dados da mensagem

uint32_t led;
uint32_t cnt;

uint32_t led;
uint32_t cnt;

Aqui temos o payload real:

• led → identifica qual thread/LED gerou a mensagem
• cnt → contador de quantas vezes aquele LED já piscou

Isso permite que uma thread produza dados e outra consuma, sem qualquer dependência direta entre elas.

Definição da FIFO: K_FIFO_DEFINE

Em seguida, aparece algo como:

K_FIFO_DEFINE(printk_fifo);

K_FIFO_DEFINE(printk_fifo);

Essa macro:

• cria uma FIFO global,
• alocada estaticamente,
• pronta para uso desde o boot.

Não há:

• malloc,
• init,
• create.

Tudo é resolvido em tempo de compilação, o que combina perfeitamente com sistemas embarcados determinísticos.

Internamente, essa macro cria:

• uma struct k_fifo,
• os objetos auxiliares necessários,
• e registra tudo para o kernel.

Produzindo mensagens: k_fifo_put()

Dentro das threads blink0() e blink1(), aparece um trecho parecido com:

struct msg msg;

msg.led = 0;
msg.cnt = cnt++;

k_fifo_put(&printk_fifo, &msg);

struct msg msg;

msg.led = 0;
msg.cnt = cnt++;

k_fifo_put(&printk_fifo, &msg);

Aqui há um ponto extremamente importante de engenharia de firmware:

Onde está alocada msg?

Se msg for:

• variável local na stack → ERRO GRAVE
• variável estática ou global → CORRETO

O exemplo real do Zephyr usa variáveis estáticas, exatamente porque:

• a FIFO guarda apenas o ponteiro,
• se a variável sair de escopo, o ponteiro ficará inválido,
• isso gera comportamento indefinido.

Esse detalhe é intencional no sample:
ele força o leitor a entender o modelo de memória do kernel.

Comparação com FreeRTOS
No FreeRTOS, xQueueSend() copia os dados.
No Zephyr, k_fifo_put() encadeia o objeto.

Consumindo mensagens: k_fifo_get()

Na thread uart_out():

struct msg *msg;

msg = k_fifo_get(&printk_fifo, K_FOREVER);

struct msg *msg;

msg = k_fifo_get(&printk_fifo, K_FOREVER);

Aqui vemos três conceitos importantes:

1. Retorno por ponteiro
   O kernel devolve o endereço do objeto original.
2. Bloqueio controlado
   K_FOREVER indica que a thread ficará bloqueada até chegar uma mensagem.
3. Eficiência extrema
   Não há cópia de dados, apenas manipulação de ponteiros.

Depois disso, o código faz:

printk("Toggled led%d; counter=%d\n", msg->led, msg->cnt);

printk("Toggled led%d; counter=%d\n", msg->led, msg->cnt);

A thread consumidora:

• não sabe quem produziu,
• não controla LEDs,
• apenas interpreta dados.

Isso é arquitetura orientada a eventos, aplicada de forma simples e elegante.

As threads blink0, blink1 e uart_out: escalonamento, k_sleep() e modelo de execução

Agora vamos analisar as funções que viram threads. Aqui está o “comportamento” real do sistema, e onde o Zephyr mostra claramente que não existe superloop — existem fluxos concorrentes cooperando sob controle do kernel.

Assinatura das funções de thread

Todas as funções têm uma assinatura semelhante a:

void blink0(void *a, void *b, void *c)

void blink0(void *a, void *b, void *c)

Isso não é arbitrário.

O Zephyr define que toda thread criada via K_THREAD_DEFINE deve aceitar três argumentos genéricos (void *), mesmo que você não os use.

Por que três parâmetros?

• Permite passar contexto para a thread
• Mantém ABI estável
• Evita múltiplas variações de protótipos

No exemplo:

• os parâmetros não são usados,
• mas a assinatura precisa ser respeitada.

Thread blink0 e blink1: produtoras de eventos

As duas threads são quase idênticas, mudando apenas:

• o LED controlado,
• o período de pisca.

Estrutura típica:

static void blink0(void *a, void *b, void *c)
{
    uint32_t cnt = 0;

    while (1) {
        gpio_pin_toggle_dt(&led0);

        struct msg msg0;
        msg0.led = 0;
        msg0.cnt = cnt++;

        k_fifo_put(&printk_fifo, &msg0);
        k_sleep(K_MSEC(1000));
    }
}

static void blink0(void *a, void *b, void *c)
{
    uint32_t cnt = 0;

    while (1) {
        gpio_pin_toggle_dt(&led0);

        struct msg msg0;
        msg0.led = 0;
        msg0.cnt = cnt++;

        k_fifo_put(&printk_fifo, &msg0);
        k_sleep(K_MSEC(1000));
    }
}

Vamos destrinchar isso em partes.

while (1) não é “superloop”

Apesar de parecer um superloop, não é.

Aqui:

• cada thread tem seu próprio loop,
• o escalonamento é feito pelo kernel,
• a thread “some” do processador quando dorme.

Isso é radicalmente diferente de:

while (1) {
    delay_ms(1000);
}

while (1) {
    delay_ms(1000);
}

em baremetal.

gpio_pin_toggle_dt(&led0)

Essa chamada:

• acessa o driver GPIO genérico,
• usa informações vindas do DeviceTree,
• não toca em registradores diretamente.

O mesmo código roda:

• em STM32,
• nRF,
• ESP32,
• QEMU (com GPIO simulado).

Criação da mensagem

struct msg msg0;
msg0.led = 0;
msg0.cnt = cnt++;

struct msg msg0;
msg0.led = 0;
msg0.cnt = cnt++;

O exemplo real usa variáveis estáticas, justamente para garantir que:

• a memória continue válida após o k_fifo_put().

Isso reforça a ideia de que:

no Zephyr, memória e tempo de vida do objeto importam.

k_fifo_put()

Quando a thread chama:

k_fifo_put(&printk_fifo, &msg0);

k_fifo_put(&printk_fifo, &msg0);

o kernel:

• não copia dados,
• apenas encadeia o objeto,
• acorda qualquer thread bloqueada em k_fifo_get().

Isso é uma sincronização implícita.

k_sleep(K_MSEC(1000))

Aqui está um ponto-chave.

k_sleep():

• coloca a thread em estado sleeping,
• libera o processador imediatamente,
• permite que outras threads rodem.

K_MSEC(1000) é uma macro que:

• converte milissegundos para k_timeout_t,
• evita erros de unidade,
• torna o código legível e portátil.

Importante
k_sleep() não é busy-wait.
Ele coopera com o scheduler.

Thread uart_out: consumidora de eventos

Agora a thread que não controla hardware crítico, apenas processa mensagens.

Estrutura típica:

static void uart_out(void *a, void *b, void *c)
{
    while (1) {
        struct msg *msg;

        msg = k_fifo_get(&printk_fifo, K_FOREVER);

        printk("Toggled led%d; counter=%d\n",
               msg->led, msg->cnt);
    }
}

static void uart_out(void *a, void *b, void *c)
{
    while (1) {
        struct msg *msg;

        msg = k_fifo_get(&printk_fifo, K_FOREVER);

        printk("Toggled led%d; counter=%d\n",
               msg->led, msg->cnt);
    }
}

k_fifo_get(..., K_FOREVER)

Esse é um exemplo clássico de thread orientada a eventos:

• se não há mensagem → thread dorme
• se chega mensagem → thread acorda

Não existe polling, não existe delay.

printk() dentro de uma thread dedicada

Essa decisão arquitetural é excelente:

• evita printk() em múltiplas threads concorrentes,
• reduz risco de interleaving de mensagens,
• centraliza I/O lento em uma única thread.

Isso é exatamente o tipo de padrão que se espera em sistemas RTOS bem projetados.

Prioridades iguais: por quê?

Todas as threads usam:

#define PRIORITY 7

#define PRIORITY 7

Isso significa:

• escalonamento round-robin entre elas,
• nenhuma é mais importante que a outra,
• comportamento previsível para um exemplo didático.

Em um sistema real:

• threads de controle teriam prioridade maior,
• logging teria prioridade menor.

K_THREAD_DEFINE: o que essa macro realmente cria e por que ela substitui o main()

Agora chegamos ao ponto mais conceitual e arquitetural do tutorial.
Entender K_THREAD_DEFINE é entender por que o Zephyr não precisa de main() neste exemplo.

Vamos partir da macro usada no código:

K_THREAD_DEFINE(blink0_id,
                STACKSIZE,
                blink0,
                NULL, NULL, NULL,
                PRIORITY,
                0,
                0);

K_THREAD_DEFINE(blink0_id,
                STACKSIZE,
                blink0,
                NULL, NULL, NULL,
                PRIORITY,
                0,
                0);

À primeira vista, parece “apenas” uma forma compacta de criar threads.
Na prática, ela define objetos globais que o kernel conhece antes mesmo de iniciar o scheduler.

Anatomia completa da macro

A assinatura conceitual é:

K_THREAD_DEFINE(
    name,
    stack_size,
    entry,
    p1, p2, p3,
    priority,
    options,
    delay
)

K_THREAD_DEFINE(
    name,
    stack_size,
    entry,
    p1, p2, p3,
    priority,
    options,
    delay
)

Vamos destrinchar item por item.

name — Identificador da thread

blink0_id

blink0_id

Esse nome:

• vira um símbolo global,
• identifica a thread no linker,
• pode ser usado para debug e tracing.

Internamente, o Zephyr cria:

• uma struct k_thread,
• uma stack associada,
• metadados de inicialização.

stack_size — Pilha dedicada

STACKSIZE

STACKSIZE

Diferente de muitos exemplos em outros RTOS, aqui:

• a pilha é obrigatória,
• é conhecida em tempo de compilação,
• não depende de heap.

Isso é essencial para:

• sistemas determinísticos,
• análise estática,
• aplicações safety-critical.

entry — Função da thread

blink0

blink0

Essa função:

• não é chamada manualmente,
• será invocada pelo kernel,
• começa a rodar quando o scheduler inicia.

É aqui que o modelo do Zephyr diverge completamente do “main() cria tudo”.

p1, p2, p3 — Parâmetros genéricos

NULL, NULL, NULL

NULL, NULL, NULL

Esses ponteiros:

• permitem passar contexto para a thread,
• evitam uso de globais,
• mantêm ABI uniforme.

No exemplo, não são usados, mas em sistemas reais:

• podem carregar ponteiros de estruturas,
• ou referências a drivers.

priority — Prioridade da thread

PRIORITY

PRIORITY

Relembrando:

• números menores → prioridade maior
• prioridades negativas → threads do sistema

Aqui todas são iguais para fins didáticos.

options — Flags de comportamento

0

0

Aqui poderiam entrar opções como:

• K_FP_REGS → thread usa FPU
• K_USER → thread em modo usuário (se MPU estiver ativa)

O exemplo mantém tudo simples.

delay — Início retardado

0

0

Indica:

• a thread inicia imediatamente no boot.

Em sistemas reais, você pode:

• atrasar threads,
• escalonar inicializações,
• reduzir pico de consumo no boot.

O que o Zephyr gera por trás da macro?

Conceitualmente, o compilador/linker acabam gerando algo equivalente a:

• uma stack alocada em .bss ou .noinit
• uma struct k_thread
• uma entrada em uma seção especial (ex: .z_thread_data)

Durante o boot:

1. O kernel percorre essas seções.
2. Inicializa todas as threads estáticas.
3. Insere as threads prontas no scheduler.
4. Inicia a execução sem jamais chamar main().

Isso é fundamental
O fluxo não é:

reset → main() → scheduler

reset → main() → scheduler

É:

reset → kernel init → threads do sistema → threads do app

reset → kernel init → threads do sistema → threads do app

Mas o Zephyr pode ter main()?

Sim. E muitos exemplos têm.

Se existir:

void main(void)
{
    ...
}

void main(void)
{
    ...
}

O Zephyr:

• cria uma thread especial chamada main,
• executa essa função como uma thread normal,
• com prioridade e stack configuráveis via Kconfig.

Neste sample, os autores optaram por não usar main(), para mostrar que:

• o kernel é o centro da aplicação,
• não existe mais “função principal” no sentido clássico.

Comparação direta com outros modelos

Baremetal

int main(void)
{
    init();
    while (1) { ... }
}

int main(void)
{
    init();
    while (1) { ... }
}

FreeRTOS clássico

int main(void)
{
    xTaskCreate(...);
    vTaskStartScheduler();
    while (1);
}

int main(void)
{
    xTaskCreate(...);
    vTaskStartScheduler();
    while (1);
}

Zephyr (este exemplo)

K_THREAD_DEFINE(...);
K_THREAD_DEFINE(...);
K_THREAD_DEFINE(...);

K_THREAD_DEFINE(...);
K_THREAD_DEFINE(...);
K_THREAD_DEFINE(...);

Nenhum fluxo explícito.
O linker + kernel fazem o trabalho.

Ciclo de vida completo do sistema, quando usar ou não main() e boas práticas reais

Para fechar o tutorial, vamos juntar todas as peças e olhar o sistema do reset até a execução contínua, e depois discutir decisões arquiteturais reais: quando esse modelo é ideal e quando o main() ainda faz sentido.

Ciclo de vida do firmware neste exemplo

O fluxo real de execução do Zephyr, neste sample, é aproximadamente o seguinte:

1. Reset do microcontrolador
   • Código de startup (CMSIS / SoC específico)
   • Inicialização mínima de stack e memória
2. Inicialização do kernel Zephyr
   • Scheduler
   • Estruturas internas
   • Heap (se habilitado)
   • Infraestrutura de drivers
3. Inicialização baseada em DeviceTree
   • Criação dos dispositivos declarados
   • Binding de drivers (GPIO, UART, etc.)
   • Verificação de status = "okay"
4. Criação das threads estáticas
   • Threads do sistema
   • Threads definidas por K_THREAD_DEFINE
   • Pilhas já alocadas e conhecidas
5. Scheduler entra em execução
   • Threads blink0, blink1 e uart_out passam a disputar CPU
   • Não existe chamada a main()
   • Não existe “loop central”
6. Sistema em regime permanente
   • Threads produtoras geram eventos
   • FIFO coordena comunicação
   • Thread consumidora bloqueia e acorda conforme necessário

Esse fluxo deixa claro que o kernel é o “programa principal”.
O seu código apenas descreve o que existe, não quando chamar.

Quando esse modelo é ideal

Esse estilo (sem main()) é excelente quando:

• o sistema é 100% orientado a eventos,
• todas as tarefas são naturalmente threads,
• o comportamento é reativo (sensores, mensagens, filas),
• você quer inicialização determinística e estática,
• o projeto cresce em complexidade e modularidade.

Exemplos típicos:

• gateways IoT,
• sistemas de logging e monitoramento,
• aplicações industriais com múltiplas tarefas independentes,
• firmware educacional focado em RTOS “puro”.

Quando main() ainda faz sentido no Zephyr

Apesar do poder desse modelo, há cenários em que usar main() é mais adequado:

• inicializações sequenciais complexas;
• criação dinâmica de threads;
• lógica de boot dependente de estado externo;
• migração gradual de firmware baremetal;
• aplicações simples, onde threads estáticas seriam “overkill”.

Nesse caso, o Zephyr trata main() assim:

void main(void)
{
    // isso roda como uma thread normal
}

void main(void)
{
    // isso roda como uma thread normal
}

Ou seja:

• main() não quebra o modelo do Zephyr,
• ela apenas vira uma thread especial,
• com prioridade e stack configuráveis via Kconfig.

Boa prática arquitetural (opinião técnica)

Em projetos reais e bem estruturados, o padrão mais saudável costuma ser:

• usar threads estáticas (K_THREAD_DEFINE) para:
  • tarefas permanentes,
  • serviços do sistema,
  • pipelines de dados;
• usar main() apenas para:
  • orquestrar inicializações,
  • criar threads dinâmicas,
  • decidir configurações em runtime.

O sample threads existe justamente para mostrar que:

você não é obrigado a pensar em firmware como “um loop principal”.

Conclusão técnica do tutorial

Este exemplo simples demonstra conceitos profundos:

• Zephyr não é “baremetal com RTOS por cima”;
• o kernel é o centro da aplicação;
• DeviceTree elimina dependência de hardware no código;
• FIFOs trabalham com objetos, não cópias;
• threads são entidades declarativas;
• main() é opcional, não fundamental.

Quem entende esse sample entende a filosofia do Zephyr.

The post Introdução ao Zephyr RTOS: Entendendo Threads, DeviceTree e a Ausência do main() first appeared on MCU & FPGA.