Breadboard / Physical Wiring

About breadboard diagrams

A breadboard diagram shows how to physically wire components on a solderless prototyping board — the iconic visual genre of every Arduino / ESP32 / Raspberry Pi tutorial. The reader replicates what they see, hole-for-hole, on real hardware. This is complementary to the abstract circuit schematic (circuit, IEEE 315): the schematic is the engineer's reasoning view; the breadboard is the maker's replication view.

Schematex implements Fritzing-style stylized breadboard rendering. Components are drawn as recognisable bodies (resistors with color bands, LEDs as colored domes, DIPs with notches, MCU PCBs with labelled pin headers). Jumper wires are drawn as smooth cubic Bézier arcs between specific tie-points — not Manhattan right angles. The DSL addresses every part and every wire by breadboard-native coordinates (@col-row, e.g. @5e), not pixel positions, so the file is hand-authorable and version-controllable.

Note — this engine is not a circuit schematic and does not enforce electrical rules. Use it for tutorials, lab handouts, READMEs, and learning material. For nodal analysis or formal schematics, use the circuit engine instead.

1. Your first breadboard

Three sections: a one-line breadboard header, a parts block, and a wires block. Optional board: and title: lines come right after the header.

Every part is id: kind [args] @placement. Every wire is <endpoint> --color-- <endpoint>. That's the whole grammar.

2. Coordinates

Breadboards have a 2D address grid. Schematex coordinates always start with @.

Mini boards (board: mini) have no power rails — @+t… / @-b… are rejected by the parser.

3. Board sizes

breadboard
board: half          // default — 30 columns, 400 tie-points, rails (continuous)

Pitfall — on full-size boards the rails break at the middle. If your circuit uses both halves you must jumper the rails together explicitly.

4. Parts catalog

Each part is id: <kind> [args] @<placement>. The catalog covers the most common Arduino / ESP32 maker components:

Discrete components (sit on the breadboard):

Microcontroller boards (placed beside / above / below the substrate):

Sensors / displays / actuators (modules sit on the breadboard with pin row anchored at the supplied coordinate):

Resistor color bands are decorated automatically from value — 220 → red-red-brown-gold, 10000 → brown-black-orange-gold.

5. Wires

Every wire connects two endpoints. An endpoint is either a part pin (partId:pinName) or a breadboard coordinate (@…).

wires
  uno:5V  --red--    @+t1
  uno:GND --black--  @-t1
  uno:D9  --yellow-- @9c
  @9a     --green--  @+t9

Color is purely visual — the engine does not validate it against electrical role.

For visually crowded boards, via @<coord> lets you pin an intermediate hole that biases the Bézier control points:

wires
  uno:D13 --yellow-- @9a via @8c

Most wires don't need via — the layout engine produces a natural arc on its own.

6. Sensor with pull-up resistor (DHT11 motif)

The iconic Arduino tutorial pattern: a 10 kΩ pull-up between VCC and the sensor's data line.

7. ESP32 + I²C OLED

ESP32 runs at 3.3 V (not 5 V). I²C convention: green = SDA, white = SCL.

8. Limitations of v0.1

• No leader-line callouts — reference designators (R1, C2) are drawn near the part body. Off-board callout boxes are deferred.
• No .fzz import — Schematex consumes only its own DSL; Fritzing files are not parsed.
• No simulation — this is a renderer, not a Wokwi-style simulator. Component-value validation (Ohm's law, current limits) is out of scope.
• No PCB / schematic round-trip — breadboard and circuit are independent engines. Authoring two views of the same prototype currently means writing two DSLs.
• Fixed parts catalog — user-defined part types are deferred. v0.1 ships the maker-tutorial 80% catalog (resistors, LEDs, caps, DIPs, headers, four MCU families, six sensor / display / actuator modules).
• Power-rail break visual — full-size boards mark the 30/31 break with a hole-wide gap; the rail stripes still draw through the gap (cosmetic).