Tutorial Zephyr OS: Como Criar o Primeiro Projeto com example-application, DeviceTree e West

As edições mais comuns no west.yml ao adaptar o template para um projeto real

Quando você transforma o example-application no “seu produto”, as mudanças úteis (e seguras) no west.yml são estas:

1. Fixar revision com precisão
   Em vez de ficar apontando sempre para main, você pode apontar para uma tag (ex.: vX.Y.Z) ou um commit SHA, para garantir que o build de hoje seja o mesmo build daqui a 6 meses. O west.yml é exatamente o lugar onde isso vive. (Documentação Zephyr)
2. Adicionar seus repositórios (middleware, drivers, libs internas) como projects
   Se você tem, por exemplo, um repositório “meu-driver-can” ou “meu-middleware-crypto”, você adiciona como um novo project: no manifesto. A documentação descreve esse papel de projects e como o west usa isso para clonar/atualizar. (Documentação Zephyr)
3. Separar o que é “projeto west” do que é “módulo Zephyr”
   Nem todo project precisa ser “módulo”. Alguns projetos são ferramentas e não vão para o firmware. A doc de módulos deixa essa distinção bem clara: módulos são repositórios com zephyr/module.yml, e west projects são apenas entradas no manifesto. (Documentação Zephyr)

zephyr/module.yml: como o build do Zephyr descobre seu código out-of-tree

Um módulo no Zephyr (external project) é, essencialmente, um repositório que possui um arquivo zephyr/module.yml. Esse arquivo permite que o build system e o Kconfig do Zephyr “plugem” seu repositório (drivers, libs, etc.) quando apropriado. (Documentação Zephyr)

Em outras palavras:

• west.yml decide o que baixar (repositórios e revisões).
• zephyr/module.yml decide como integrar esse repositório ao build/Kconfig do Zephyr. (Documentação Zephyr)

O que existe dentro de module.yml (a utilidade prática)

A doc de módulos descreve que o zephyr/module.yml é o “descritor” do módulo. Ele pode apontar caminhos como:

• onde está o Kconfig do módulo (para aparecer no menu)
• onde estão scripts/build files
• como o módulo se encaixa na árvore do Zephyr (Documentação Zephyr)

No example-application, existe exatamente esse arquivo em zephyr/module.yml (mesmo que o GitHub às vezes falhe em renderizar a página, o caminho é o padrão do ecossistema). (GitHub)

O “casamento” dos dois: como isso vira um firmware compilável

O fluxo completo é:

1. Você inicializa o workspace e faz west update → baixa zephyr/ e módulos (conforme west.yml). (Documentação Zephyr)
2. Você builda a aplicação (west build -b <board> app) → o CMake do Zephyr executa e monta o build. A documentação do build system reforça que o CMake constrói sua aplicação junto com o kernel Zephyr e descreve o estágio de configuração (onde os CMakeLists.txt são processados). (Documentação Zephyr)
3. Durante esse build, os módulos com zephyr/module.yml podem ser incorporados e expor Kconfig/build hooks conforme necessário. (Documentação Zephyr)

Um alerta prático (bem comum) sobre overlays e “boards folder”

Você vai usar muito app/boards/<board>.overlay e app/boards/<board>.conf. Esse padrão é ensinado de forma bem objetiva (ex.: Nordic Academy): o overlay deve ter o nome exato do board target e terminar em .overlay. (Nordic Developer Academy)
E vale saber que existem discussões/issues no Zephyr sobre detalhes de como overlays são aplicados dependendo do layout (ex.: overlays em app/boards vs app.overlay), então quando algo “não pega”, geralmente não é “magia quebrada”, é regra de precedência/descoberta do build. (GitHub)