Perguntas de Entrevista sobre Sistemas Embarcados e Firmware em Zig

Sistemas embarcados são uma das portas de entrada mais promissoras para quem trabalha com Zig no Brasil — empresas de automotivo, agrícola e industrial contratam rotineiramente para posições de engenheiro de firmware e engenheiro de sistemas embarcados. Nessas entrevistas, quase não se pergunta sobre frameworks; o foco é controle de hardware, memória, tempo real e integração com código C legado.

Este guia reúne as perguntas mais frequentes com respostas práticas e código idiomático em Zig. Combine-o com a preparação de memória e comptime, os dois temas mais cobrados em vagas embarcadas, conforme detalhamos no guia de carreira embedded.

Perguntas e Respostas

1. Como acesso registradores de hardware em Zig de forma segura?

Acesso a registradores mapeados em memória exige leitura/escrita que o compilador não pode otimizar. Em Zig usamos ponteiros volatile construídos a partir de um endereço físico com @ptrFromInt:

const std = @import("std");

// Endereço do registro de saída do GPIOA (exemplo STM32)
const GPIOA_ODR: u32 = 0x48000014;

pub fn acenderLed() void {
    // Ponteiro volátil: o compilador não reordena nem poda o acesso
    const odr: *volatile u32 = @ptrFromInt(GPIOA_ODR);
    odr.* |= (1 << 5); // liga o pino 5
}

A key insight para entrevistas: toda leitura/escrita de hardware deve ser volatile. Esquecer o volatile é o bug mais comum — funciona em builds de debug e quebra em -OReleaseFast, porque o otimizador elimina o acesso achando que o valor nunca muda.

2. Como representar um bloco de registradores com uma struct?

Em vez de espalhar endereços mágicos, o idiomático é sobrepor uma extern struct ao periférico e acessá-la por um ponteiro volatile. Isso mantém o layout binário previsível (ordem dos campos = ordem dos registradores) e dá segurança de tipos:

const GPIOA = extern struct {
    moder: u32,   // offset 0x00
    otyper: u32,  // offset 0x04
    ospeedr: u32, // offset 0x08
    pupdr: u32,   // offset 0x0C
    idr: u32,     // offset 0x10
    odr: u32,     // offset 0x14
};

const gpioa: *volatile GPIOA = @ptrFromInt(0x48000000);

pub fn configurarPino() void {
    gpioa.moder &= ~@as(u32, 0b11 << 10); // limpa bits do pino 5
    gpioa.moder |= (0b01 << 10);           // modo saída
    gpioa.odr |= (1 << 5);                 // nível lógico alto
}

extern struct (e não packed struct) é a escolha certa aqui porque o layout segue a ABI C, espelhando o datasheet. Reserve packed struct para campos de bits dentro de um único registrador, onde o controle bit-a-bit importa.

3. Como configuro o Zig para cross-compilar para um ARM Cortex-M?

A cross-compilation é nativa no Zig — não há toolchain externo. No build.zig você define o target via resolveTargetQuery:

const std = @import("std");

pub fn build(b: *std.Build) void {
    const target = b.resolveTargetQuery(.{
        .cpu_arch = .thumb,       // conjunto de instruções Thumb (Cortex-M)
        .os_tag = .freestanding,  // sem sistema operacional, bare-metal
        .abi = .eabi,             // Embedded ABI
        .cpu_model = .{ .explicit = &std.Target.arm.cpu.cortex_m4 },
    });

    const exe = b.addExecutable(.{
        .name = "firmware.elf",
        .root_module = b.createModule(.{
            .root_source_file = b.path("src/main.zig"),
            .target = target,
            .optimize = .ReleaseFast,
        }),
    });
    b.installArtifact(exe);
}

Pergunta frequente de follow-up: por que freestanding? Porque firmware roda sem SO, sem libc e sem main no sentido tradicional. O ponto de entrada é o reset handler definido na tabela de vetores.

4. Como uso comptime para gerar um mapa de registradores sem custo de runtime?

Em embarcados, cada ciclo conta. Com comptime você calcula endereços, máscaras e validações em tempo de compilação — o binário final contém apenas constantes:

fn regBase(comptime port: []const u8) u32 {
    if (comptime std.mem.eql(u8, port, "A")) return 0x48000000;
    if (comptime std.mem.eql(u8, port, "B")) return 0x48000400;
    @compileError("porta inválida");
}

pub fn setPino(comptime port: []const u8, pino: u5) void {
    const base = comptime regBase(port);
    const odr: *volatile u32 = @ptrFromInt(base + 0x14);
    odr.* |= (@as(u32, 1) << pino);
}

A vantagem em entrevista: chamar setPino("X", ...) com uma porta inválida vira erro de compilação, não crash em campo. Isso elimina categorias inteiras de bugs de firmware antes do device existir.

5. Como lidar com a ausência de heap em microcontroladores?

Muitos alvos embarcados não têm alocador. Em vez de std.heap.page_allocator, use um buffer estático com FixedBufferAllocator ou simplesmente evite alocação nas rotinas de tempo real:

var buffer_heap: [4096]u8 linksection(".heap") = undefined;

pub fn initHeap() std.mem.Allocator {
    var fba = std.heap.FixedBufferAllocator.init(&buffer_heap);
    return fba.allocator();
}

Regra prática cobrada em entrevista: nunca aloque dentro de uma ISR (rotina de interrupção). Alocação pode falhar, fragmentar ou bloquear — inaceitável em tempo real. Use buffers estáticos ou pools pré-alocados.

6. Como escrevo a tabela de vetores de interrupção?

No Cortex-M, o vetor de reset fica no início da flash. Em Zig definimos uma extern struct exportada numa seção especial:

const VectorTable = extern struct {
    initial_stack_pointer: usize,
    reset: *const fn () callconv(.c) noreturn,
    nmi: *const fn () callconv(.c) void,
    hard_fault: *const fn () callconv(.c) void,
};

export const vector_table linksection(".isr_vector") = VectorTable{
    .initial_stack_pointer = 0x20008000,
    .reset = resetHandler,
    .nmi = defaultHandler,
    .hard_fault = faultHandler,
};

fn resetHandler() callconv(.c) noreturn {
    // inicializa .bss, .data, chama main, loop infinito
    while (true) {}
}

O detalhe que impressiona: por que callconv(.c)? Handlers de exceção do Cortex-M usam a AAPCS padrão — o “retorno” especial é tratado pelo hardware, não pela função.

7. Como integro Zig a um RTOS existente, como o FreeRTOS?

A maioria dos projetos embarcados mistura Zig com C legado. A integração usa @cImport para headers e o build system linka a biblioteca do RTOS:

const c = @cImport({
    @cInclude("FreeRTOS.h");
    @cInclude("task.h");
});

pub fn criarTask(entry: *const fn () callconv(.c) void) void {
    _ = c.xTaskCreate(entry, "zig_task", 128, null, 2, null);
}

No build.zig, exe.linkLibC() e exe.addObjectFile(.{ .cwd_relative = "lib/freertos.a" }) trazem o RTOS. Essa pergunta testa se você entende que Zig não reescreve o mundo — ele coexiste com a base C existente, o que é exatamente o argumento de adoção gradual que empresas como as da página de empresas valorizam.

8. Como garanto determinismo e comportamento de tempo real?

Determinismo significa tempos de execução previsíveis, independentemente da entrada. Os inimigos são: alocação dinâmica, recursão descontrolada e estruturas de dados não acotadas. Boas respostas envolvem:

• Sem alocação em hot paths e ISRs (buffers estáticos, como na pergunta 5).
• Tamanho máximo fixo para filas e buffers circulares, evitando crescimento dinâmico.
• Evitar recursão: prefira máquinas de estado explícitas.
• Medir, não adivinhar: instrumente com um timer de hardware e registre pior caso.

Zig ajuda porque o allocator é explícito — uma função que não recebe Allocator por construção não pode alocar, diferentemente de C com malloc global.

9. Como depuro firmware escrito em Zig?

As ferramentas padrão da indústria funcionam: GDB/OpenOCD sobre SWD para stepping no hardware real, e QEMU para emulação de alvos como lm3s6965evb (Cortex-M3) durante o desenvolvimento:

# Emula o firmware sem hardware físico
qemu-system-arm -M lm3s6965evb -kernel firmware.elf -nographic -S -gdb tcp::1234

Em entrevista, vale mencionar que std.debug.print funciona em freestanding desde que você conecte a saída a uma UART — útil para logging leve, mas jamais dentro de ISRs críticas.

10. O que perguntam sobre manipulação de bits e bitfields?

Manipulação de bits é onipresente em firmware. Espere perguntas sobre set/clear/toggle de um bit, leitura de um campo e uso de packed struct para bitfields:

// Toggle idiomático com XOR: nenhum read-modify-write extra
const odr: *volatile u32 = @ptrFromInt(0x48000014);
odr.* ^= (1 << 5); // inverte o pino 5

// Bitfield compacto num único byte de status
const Status = packed struct {
    erro: u1,
    pronto: u1,
    ocupado: u1,
    _reserved: u5,
};

O gotcha clássico: ao combinar volatile com packed struct, acesse o registrador inteiro de uma vez (read-modify-write atômico no nível da linguagem) para evitar condições de corrida com interrupções — ou proteja com @disableInterrupts()/reentrância cuidadosa.

Como se preparar para vagas embarcadas

1. Pratique cross-compilation real: compile um “blink” para thumb-freestando-eabi e rode no QEMU.
2. Estude o guia de carreira embedded: microcontroladores, IoT e mercado brasileiro.
3. Reforce memória: allocators e segurança de memória são o tema central.
4. Acompanhe vagas de sistemas embarcados: empresas de automotivo e agrícola publicam posições de firmware com regularidade.
5. Monte um portfólio com projetos reais de hardware para discutir em entrevista.

A combinação de controle de baixo nível, segurança em tempo de compilação e interoperabilidade com C faz do Zig uma ferramenta cada vez mais procurada em firmware. Dominar as perguntas acima — e saber explicá-las com código — é o que separa candidatos juniores de engenheiros de firmware prontos para produção.