LabWired

View saved version →

---
name: labwired
description: Use when the user wants to develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or flash and debug a real board.
---

# LabWired

LabWired runs firmware on a deterministic simulation of microcontrollers (ARM Cortex-M, RISC-V and ESP32 families) wired to simulated parts. Everything here is simulation. It is not a physical board, and a passing run is not proof the circuit works on real hardware. Say so when reporting results.

Tool names are prefixed `labwired_`. Read each tool's schema instead of guessing arguments. `labwired_search` finds tools by keyword, and `labwired_context` returns suggested next steps for the session.

## Workflow

1. Discover. Use `labwired_list` and `labwired_describe` to find the board and parts. Use exact catalog component ids. `labwired_part` and `labwired_datasheet` give pin and register facts for a part; quote what they return and note its stated assurance level.
2. Compose and validate. Build a diagram `{ board, parts, wires }` and run `labwired_validate`. Fix every error before continuing. It also checks whether firmware drives the pins that were actually wired.
3. Compile. Give `labwired_compile` the source with an explicit board, language and entry path. Large projects go through `labwired_put_source` first. Use the returned `firmware_ref` in later calls. If compilation fails, show the compiler errors and fix them.
4. Run and check. `labwired_run` is observational: it reports status, serial output and diagnosis. `labwired_verify` checks the firmware against expectations the user states (serial text, pin behaviour, display). Report the verdict and the evidence returned. Do not call something verified unless the tool returned a pass. A fault on an unmodelled peripheral is a real limit of the simulation. Report it as such.
5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget. Always show the `open_url`. Omit `diagram` for a starter LED blink on a board. Pass the `firmware_ref` from step 3 to replay the exact compiled firmware, and `autorun: true` for a link that opens the board already running.

## Optional

- PCB: `labwired_pcb_create` starts a 2-layer board from a diagram, `labwired_pcb_auto` places and routes it, `labwired_pcb_inspect` reads ratsnest and DRC, and `labwired_pcb_view` shows it. `labwired_pcb_simulate` checks the copper against the diagram, and `labwired_pcb_export` returns fab files only after DRC passes. It is not a fabrication sign-off.
- Cost: `labwired_price` reads live distributor prices. Treat family matches as estimates.
- Projects: `labwired_project_create`, `labwired_project_list`, `labwired_project_get` and `labwired_project_update` save and read the user's projects. `labwired_project_verify` records the proof that `labwired_project_publish` needs. Confirm with the user before `labwired_project_delete` or `labwired_project_unpublish`.
- Debugging: `labwired_debug_start`, `labwired_debug` and `labwired_debug_stop` drive a debug session on the simulated target.
- Benches: `labwired_device_*` tools talk to a physical bench the user has docked in LabWired Studio. If none is connected, say so. Do not imply hardware was touched.

## Limits

Sign-in is required. Runs have daily allowances and time limits. Peripheral models cover what the catalog lists; unsupported hardware access fails loudly. Timing in the simulation follows the model, not measured silicon. Do not paste secrets or credentials into firmware, prompts or diagrams.

Referenced files: 1 — file references are metadata, not package contents.