Component Library

Firmware libraries and hardware components are different things.

A firmware library gives your code an API. A hardware component is a physical part with pins, packages, electrical limits, datasheets, footprints, symbols, and sometimes 3D models. Embedr keeps those ideas separate so the project can reason about both software and hardware.

What a component record can contain

A component record can describe:

• part name and aliases,
• category and tags,
• manufacturer and part number,
• mounting style,
• package,
• pin names,
• protocols such as I2C, SPI, UART, PWM, or analog,
• datasheet links or extracted datasheet context,
• KiCad symbols,
• KiCad footprints,
• 3D models,
• .zen snippets or generated hardware source.

The agent can search the component library before choosing parts or writing hardware source. This helps ground the design in known components instead of inventing pin names or footprints.

When to use it

Use the component library when you need to:

• choose between similar sensors or modules,
• find a part with a known footprint,
• create schematic source for a real part,
• check pin names before wiring firmware,
• fetch a datasheet or hardware asset,
• keep examples consistent across a class or team.

For a simple blink sketch, you may not need a component record. For a board with sensors, regulators, connectors, and modules, it becomes useful quickly.

Component assets

Assets are files or structured data attached to a component record. Common assets include:

• datasheet PDF,
• datasheet markdown,
• KiCad symbol,
• KiCad footprint,
• 3D model,
• .zen documentation or snippet,
• validation notes.

Assets matter because a component name alone is not enough to build a board. A "DHT22" record is useful only if the project can also understand pins, electrical limits, and package shape.

Components in embedr.yaml

The manifest can store project-level components and connections:

components:
  - id: dht22-sensor
    version: latest
    instance: room_sensor

connections:
  - from:
      component: room_sensor
      pin: data
    to:
      component: esp32
      pin: GPIO4
    wire_color: yellow

This does not replace schematic source. It gives the project a readable hardware map that can help the app, CLI, and agent reason about the design.

Connections are intent

A connection says "these two pins should be electrically related." It is not the same as a copper trace, a breadboard jumper, or a full schematic symbol.

Use connections for:

• wiring tables,
• student lab documentation,
• early hardware planning,
• agent context before a full PCB workflow exists.

Use .zen source and KiCad files when you need formal schematic and board generation.

Agent workflow

Good requests:

Search the component library for a DHT22-style temperature sensor with a usable footprint, then explain the pins I need for ESP32 firmware.

Use the component library before editing pcb/boards/main.zen. I want a status LED, current-limiting resistor, and JST power connector with real footprints.

The important instruction is not the exact phrasing. It is that the agent should ground hardware choices in component records before writing board source.