Schematics And PCB

Embedr's hardware design workflow is built around the pcb/ workspace inside the same project. Firmware, datasheets, schematic source, board layout, and agent context stay together.

The hardware source layer

The pcb/ folder is where hardware design becomes part of the project stack.

my-project/
  embedr.yaml
  src/
    main.cpp
  pcb/
    pcb.toml
    boards/
      main.zen

The .zen file is source. It is meant to be edited, reviewed, and committed. Generated KiCad files can be produced from it.

Initialize the workspace

Open the Schematics tab. If no workspace exists, Embedr shows an empty state with a button to ask the agent to initialize schematics.

The CLI equivalent is:

embedr pcb init

This creates the PCB workspace and starter board source.

Schematic preview

When the workspace and main board file exist, the Schematics tab shows a preview. Use refresh if the preview does not update after changes.

The preview is useful for quick inspection, not as a replacement for source review. The .zen file is the source of truth.

Build and test

The PCB workflow exposes actions:

• initialize workspace,
• open board .zen,
• build,
• test,
• inspect netlist,
• evaluate schematic,
• lint .zen,
• manage placement comments,
• layout check and sync,
• auto place,
• auto layout and routing,
• open in KiCad,
• format .zen.

The CLI commands are under embedr pcb.

embedr pcb status
embedr pcb build
embedr pcb test
embedr pcb layout --check
embedr pcb fmt

Agent workflow

The agent can work from a vague request, but hardware work benefits from visible checkpoints. A good loop is:

• "Initialize the PCB workspace for this project."
• "Add a simple LED and resistor schematic in .zen source."
• "Run the PCB build and summarize errors."
• "Inspect the netlist and tell me whether power, ground, and signal nets look right."
• "Run auto placement for a first board proposal."
• "Run auto layout and routing, then summarize open nets."
• "Update the schematic to match the firmware pin definitions."

That last prompt is important. Firmware pins and schematic pins should not drift.

Firmware to schematic consistency

When firmware changes wiring assumptions, update hardware docs or schematic source in the same task.

Examples:

• LED_PIN changes from GPIO 2 to GPIO 5,
• I2C moves from default pins to custom pins,
• a sensor changes from SPI to I2C,
• a resistor value changes because current changed.

The agent can help, but ask explicitly:

Update the schematic notes to match the pin changes in src/main.cpp.

What is .zen?

In this workflow, .zen files are hardware source files. They describe schematic and board intent in text.

That matters because text hardware source can be:

• reviewed in Git,
• searched,
• edited by the agent,
• connected to firmware assumptions,
• generated into layout artifacts.

Text hardware source

Text hardware source is useful because it can carry both electrical intent and layout hints. For example, placement comments can tell the board workflow where a part should live or how a schematic symbol should be grouped.

That does not remove engineering review. It makes the review diffable.

Boundaries

Embedr keeps hardware as code close to firmware and can produce board proposals. KiCad remains the detailed PCB environment for manual review, manufacturing checks, footprint work, copper pours, and final fabrication output.