Dando um passo um pouco maior
Na documentação do Zephyr, como acima falamos muito do kconfig, que foi herdado com menuconfig do kernel do linux, no Zephir para usar este recursos você não usa o Kconfig ou menuconfig diretamente, você chama com o comando:
west build -t menuconfig
Evite fazer mudanças agora, apenas passei pelas configurações para ver os recursos existentes.
app/src/main.c: seu primeiro “fio terra” (e como não se perder)
A documentação do Zephyr sugere colocar o código em src/ e começar com src/main.c. (Documentação Zephyr)
Para o primeiro projeto, recomendo um “Hello + heartbeat” (algo que te dá certeza de que: toolchain, console, scheduler e timing estão vivos). Exemplo:
#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>
int main(void)
{
printk("Meu primeiro projeto Zephyr (workspace app)\n");
while (1) {
printk("tick\n");
k_sleep(K_SECONDS(1));
}
}
Isso valida:
- seu console (UART/RTT/semihosting — depende da board)
- o clock/timer do kernel (
k_sleep) - a pipeline de build e flash
app/boards/: overlays para reaproveitar boards “oficiais”
O README do example-application deixa uma dica crítica: você pode usar boards do Zephyr “mainline”, desde que forneça um overlay apropriado (ele cita explicitamente app/boards). (GitHub)
Na prática, isso significa: se sua aplicação precisa, por exemplo, remapear o console UART, habilitar um LED específico ou ajustar um sensor, você cria um arquivo overlay associado à board.
O padrão mais comum é algo como:
app/boards/<board>.overlay(DeviceTree overlay)app/boards/<board>.conf(fragmento Kconfig específico da board)
Isso mantém seu prj.conf “genérico” e empurra diferenças de hardware para o lugar certo (o que evita aquele inferno de “funciona na minha placa, quebra na sua”).
