Table of Contents
- Criando o “primeiro projeto” a partir do example-application (visão geral + clonagem correta)
- Anatomia do repositório (raiz) e o que você deve editar para “virar seu projeto”
- west.yml (o “manifest” do seu workspace)
- .west/ (não fica no Git, mas é o “cérebro operacional” do workspace)
- zephyr/ (pasta do repo) + “ser um módulo”
- CMakeLists.txt (na raiz)
- Kconfig (na raiz)
- Pastas raiz (o mapa do que existe e por que existe)
- Uma forma segura de “renomear para seu projeto” sem quebrar nada
- A pasta app/: onde nasce o seu firmware (arquivos essenciais + como adaptar com mudanças mínimas)
- 3.1 O que normalmente existe dentro de app/ (e por quê)
- app/CMakeLists.txt: o “roteador” do build
- app/prj.conf: o painel de liga/desliga do firmware
- Dando um passo um pouco maior
- app/src/main.c: seu primeiro “fio terra” (e como não se perder)
- app/boards/: overlays para reaproveitar boards “oficiais”
- Fluxo recomendado para “virar seu projeto” sem quebrar o template
- west.yml na prática (manifesto do workspace) + zephyr/module.yml (faz o Zephyr “enxergar” seu repo)
- west.yml: o que ele é e por que ele manda em tudo
- As edições mais comuns no west.yml ao adaptar o template para um projeto real
- zephyr/module.yml: como o build do Zephyr descobre seu código out-of-tree
- O “casamento” dos dois: como isso vira um firmware compilável
- Um alerta prático (bem comum) sobre overlays e “boards folder”
- Transformando o example-application no “seu projeto” (renomear, versionar, adicionar módulo próprio e validar no build)
- app/boards/.overlay e .conf (o jeito certo de adaptar hardware sem “quebrar” o projeto)
- Por que existe app/boards/ (e por que você vai amar isso depois)
- Exemplo prático: criar um LED “do seu jeito” e piscar por DeviceTree
- Código: pegando o LED por alias e piscando
- “Meu overlay não pegou”: checklist curto que resolve quase tudo
- Dica de ouro: overlays para console UART (quando você foge do default)
- Um “primeiro projeto” completo e idiomático no Zephyr: threads + logging + LED (com overlay) + console
- Quando “não aparece nada no terminal”: console UART vs RTT vs USB CDC + debug.conf (sem poluir o prj.conf)
- printk x LOG_*: por que um aparece e outro não
- Padrão de ouro: prj.conf “limpo” + debug.conf “agressivo”
- UART Console: o caminho mais comum (e onde dá errado)
- RTT (SEGGER): quando você não quer depender de UART/pinos
- USB CDC ACM (console via USB): bom para ESP32/boards com USB nativo
- Checklist rápido de “terminal mudo” (ordem que eu uso na vida real)
- Crescendo o projeto sem virar monolito: logs por arquivo (padrão limpo)
- Testes e CI no Zephyr usando o example-application: west twister, pasta tests/ e automação
- Encerramento do tutorial (visão de conjunto)
Criando o “primeiro projeto” a partir do example-application (visão geral + clonagem correta)
O repositório example-application foi feito exatamente para ser um “esqueleto” de aplicação Zephyr fora da árvore principal (out-of-tree), mostrando também como organizar workspace, módulos, CI, boards, bindings, drivers e bibliotecas externas. (GitHub)
A ideia central é: você não “compila o Zephyr”; você compila uma aplicação que puxa e configura o Zephyr, e o build gera um único binário final. (docs.zephyrproject.org)
Pré-requisito: trabalhar como workspace application (o “jeito Zephyr”)
O west funciona melhor quando seu app está dentro de um workspace (um diretório que contém .west/, o repositório zephyr/ e os módulos). A própria documentação descreve essa topologia e mostra que, nesse formato, o west.yml fica do lado da aplicação e “puxa” o Zephyr e módulos necessários. (docs.zephyrproject.org)
Isso é importante porque muita gente clona o repositório “solto” e tenta west build ali dentro — e aí aparece erro do tipo “unknown command build; do you need to run this inside a workspace?”. (Isso acontece porque o west não detectou o workspace.)
Criando o workspace já com o exemplo (forma recomendada)
Inicie criando um ambiente virtual do python para uso do Zephyr:
cd workspace
python -m venv venv
souce venv/bin/activate
# só na primeira vez
pip install westO README do repositório já dá o caminho mais limpo: inicializar um workspace apontando o manifest para o example-application, e depois baixar os módulos. (GitHub)
No Linux (ou WSL), faça assim:
# 1) Crie um workspace usando o example-application como manifest
west init -m https://github.com/zephyrproject-rtos/example-application --mr main my-workspace
cd my-worspaceBaixe Zephyr + módulos definidos pelo manifest
cd my-workspace
west updateExporte o pacote CMake do Zephyr, isto permite o CMake automaticamente carregar o modelo padrão requerido para construção de aplicações Zephyr
west zephyr-exportInstale as dependências usando:
cd zephir
west packages pip --installApós isso, você terá uma árvore onde existe uma pasta example-application/ (a sua aplicação) e também zephyr/ e modules/ (dependências do RTOS), seguindo o modelo de workspace. (docs.zephyrproject.org)
Primeiro build (para validar o ambiente)
O próprio README mostra o build apontando para a pasta app dentro do repositório (sim: o “app de verdade” fica em app/). (GitHub)
cd example-application
west build -b <SUA_BOARD> app
E, para rodar rápido sem placa específica, o repo menciona uma board customizada custom_plank, (útil só pra validar estrutura/fluxo). (GitHub)
Adaptando o exemplo para “seu novo projeto” (a primeira mudança certa)
Aqui é onde a maioria faz a adaptação do jeito mais seguro:
- Renomeie o repositório/pasta para o nome do seu produto (ex.:
my-control-app/). - Mantenha o
west.ymlcomo “coração” do workspace, porque ele define que versão do Zephyr e módulos você usa (e isso determina reprodutibilidade). Um doc de workspaces explica esse papel dowest.ymle doself: path:no layout. (docs.zephyrproject.org) - Só depois disso você começa a mexer em
app/(código,prj.conf, overlays, CMake etc.).