The schematic with every connection drawn through¶

A source

This page is a source of edakit – a concept, a prompt or the rules of a session –, shown as it is in the repository. Read it as such; the guides say what edakit does.

Status 2026-10-31: decided (the table at the end, in a decision round the same day) and built – W.1 to W.5 merged into main the same day, the concept done. Asked for by the owner – "a different way of drawing the schematics: today we have these excerpts with named nets, which is what people who do this often use; the maker scene, for smaller circuits, prefers a drawing as Fritzing draws it; it will reach its limits soon, let us see how far we get". Written against main at 6139c4c, the jukebox of anTONIEa at 63aa3b7 and the Christmas bell at 021f2ae, with a prototype that draws every project at hand this way and measures what it costs (prototypes/wired-schematic); checked the same day against main at b15a3ac – L.1 to L.8 of circuit-language-plan built since (pins by name or role, the pin map from the parts entry, the graph as TOML), the drawing code unchanged, the measures the same. Built so far: W.1, the frame of the SVG optional, which the owner asked for on the side – merged into main the same day; W.5, the board's print per pin (print in the parts entry, PD2 (D2) in the drawing), the same day; W.2, the wired style, merged into main the same day on the owner's word; W.4, the interview's question on the drawing (new-project writes style, project-surveyor reports it), built the same day; W.3, placement for wires, after W.2 – merged into main the same day on the owner's word (the measures of each build below the table of what to build).

The short answer¶

The drawing the owner means is Fritzing's schematic view: one sheet, every connection a wire from pin to pin, no net labels, no power symbols, a colour per wire, the module with all its pins as the board shows them. edakit's drawing is the other school: blocks with titles and notes, trees of parts on the pins of the modules, a labelled stub where a net leaves the block, flags for ground and the supplies. The difference is not the parts or the arrangement – the prototype keeps edakit's arrangement and only replaces the stubs and the flags by wires – but what a reader does: in the wired drawing the eye follows the wire, in the labelled one it reads the name twice.

How far it goes was measured, not guessed. Drawn through, the bell (19 parts, 52 pin connections) has 5 crossings on 0.8 m of wire; the guitar boost pedal (19 parts) 1; the LED bar (17 parts, 61 connections) 12; the logic level converter (14 parts, 40 connections, dense) 16 – all readable, each in under two seconds. The ESP32 DevKitC (33 parts, 157 connections, a module whose pins go to two 19-pin headers) is a mesh of 261 crossings, the Corne keyboard half (73 parts, a key matrix) 221. The limit is not the number of parts: the Tubescreamer/Rat pedal with 86 parts routes with 44 crossings. It is the structure – headers that mirror a module, buses, a matrix. A mixed style that keeps the labels for those nets and wires everything else brings the DevKitC to 28 crossings and leaves the matrix unreadable (155). Decided: a third style of edakit schematic draw beside the two – wires through for the maker-size circuit, the mixed style with labels for the pass-throughs and buses, today's drawing for the rest –, chosen per board by the key style of the schematic file, labels without it; the project interview of new-project asks for it. The SVG alone: EasyEDA's board schematic and the KiCad schematic keep their labels. Fritzing was the example of the drawing, nothing more – no breadboard view, no export.

Everything stays text in the repository: the style is a key of the schematic file, the drawing is generated from the graph and regenerated on every change, nothing lives in a drawing tool.

What the owner means¶

Two drawings of the owner's, both made by hand in Fritzing:

The jukebox (anTONIEa, hardware/circuits/tinyjukebox.fzz, its picture tinyjukebox_circuit.png): a Raspberry Pi Zero as a box of 40 pins, each named "BCM 17", "Ground", "3V3 Power"; an RFID reader, an amplifier with its speaker, four buttons with their pull-ups, an RGB LED with a transistor, a power bank with a switch. 22 parts, 124 wire pieces in the schematic view (every bend is a piece of its own in Fritzing's file), ten wire colours, values at the resistors, no net name anywhere, 3V3 and 5V drawn as wires like everything else.
The bell's original (docs/old/weihnachtsglocke_Schaltplan.png of the bell's repository, before edakit): the Nano as a box with every pin named as the board prints it – D2 … D13/SCK, A0 … A7, 5V, 3V3, GND –, five LED steps, two buttons, the servo as a three-pin header named gnd/Vcc/pulse, the LEDs with colour and wavelength. 5V and GND run as long wires around the drawing.

What the two have in common, against edakit's drawing of the bell (handbook 6.5, 20 wires, 19 flags, two blocks and a notes block on 254 x 272 mm):

	Fritzing's schematic view	edakit's drawing
a net	one wire, from pin to pin, with bends and junction dots	a wire inside a block; a labelled stub to another block; a flag for a power net
ground, supply	wires like any other, often a long one around the sheet	ground symbols and supply flags at every pin
the module	every pin, as the board shows them, the unused ones too	the connected pins only, as on a DIP package
pin names	the board's print (D2, BCM 17)	the symbol's (PD2 – the Nano's library symbol names the ATmega ports; handbook 6.2: names follow the symbol)
colours	a colour per wire, chosen by hand	one colour for every wire
structure	none: one sheet	blocks with titles and notes, a GPIO table
who draws	a person, with the mouse	the graph, in a second

The first three rows are what the owner calls the Fritzing style. The fourth is a data question of its own (the parts entry has no print name per pin; decision 6 of circuit-language.md kept aliases out of the graph's form – the drawing is another matter). The last row is the one edakit must keep: a drawing nobody draws by hand.

Where it would be used¶

edakit schematic draw, the drawing without EasyEDA (6.5): the skills circuit-design and hardware-change show it to the user after every change ("the circuit as a drawing for the user to look at"), new-project names it as the end of a project without a PCB, the walkthrough embeds it in the README (17.8), and the catalog draws every reference circuit and every block with it (docs/catalog/build.py) – all of them maker-size.
A hand-wired board (wired = true, 4.5): panel parts, jacks, pots, a strip on a cable. edakit refuses to draw it today ("has no schematic", 6.5) – though it is the one board whose only build document is a drawing of what goes to what. The guitar pedals' wiring boards are the case: 4 and 7 parts, 14 and 26 connections.
Not the board schematic in EasyEDA (schematic layout, 6.3) and not the KiCad schematic (16.3), by decision 1: both are drawn from the same plan as the SVG (schematic_layout.Layout, schematic_draw.drawing), so the style could reach them – the owner keeps them labelled; the PCB hangs on the board schematic, and a crossing there would need a probe in EasyEDA first.
Not the template schematic (schematic create: stubs with net labels, "exact, ugly", rebuilt on every run) and not the reference project with 123 parts: that one is what labels are for.

What exists¶

In edakit. The plan (schematic_layout.py): blocks from [layout] rows of the schematic file or, without it, one block per module, IC, connector, relay and battery holder, power inputs first; inside a block, parts attach to the pins of the block's start part by breadth-first search over the signal nets, every child turned so that its pin points at the parent's, stacked and spread without overlaps; a pin whose net goes on elsewhere ends in a stub of the net's name, a power net in a flag. The drawing (schematic_draw.py): the symbols from the parts database, the page, the title block, the check that no wire touches another net or a foreign pin and that every connected pin ends in a wire or a flag. EasyEDA's SCH_PrimitiveWire.create refuses a crossing with four branches (6.3), and the geometry check takes two nets' wires touching for a short – a crossing without a junction, which the wired style lives on, is not told apart from a T today.

Fritzing is the example of the drawing, nothing more (decision 6): its schematic view is where the owner's two drawings come from. Read for the measures only: a .fzz is a zip with one XML file, parts with a position per view and wires as instances of their own, one per straight piece, with a colour – that is where the jukebox's 124 pieces come from.

The other school. EasyEDA and KiCad draw either way: a wire is a wire, a label joins what has the same name, a junction dot says that crossing wires connect. The labelled drawing is what edakit generates today; the wired one is the same editors' other mode.

The prototype¶

prototypes/wired-schematic/wired.py takes edakit's plan and draws it through. It changes nothing in edakit:

a pin without a child gets a lead of one grid cell instead of a labelled stub, a power net no flag; the blocks stand twice as far apart – the gaps are the channels – and lose their frames;
a module shows every pin, as on the board, the unused ones grey;
a router on the schematic grid (10 mil x 10, 2.54 mm cells) joins every net: the ground along a rail below the drawing, the supplies along rails above, the rest by the cheapest path – a step 1, a bend 4, a crossing of another net 12, running beside one 1; never through a part, never along another net's wire, never through its ends, bends or pin tips. A rail that gathers fewer than two drops is taken away again;
every net gets a colour – ground black, supplies red – chosen so that nets that cross or run side by side differ where ten colours allow it;
the mixed style (--mixed): a net stays a labelled stub when nothing but modules, ICs and connectors hang on it – a pin passed through to a header, a bus line – or when it has six pins or more – a key matrix, a shared line;
it measures: wire length, crossings, bends, pieces it could not join, colour clashes, page size, time.

The measures of every project at hand, both styles, are the table of its README. The short of it:

board	parts	pin connections	crossings, wires through	crossings, mixed (nets labelled)	wire m	page mm
coin-cell-led	4	8	0	0 (0)	0.0	122 x 95
the bell	19	52	5	2 (1)	0.8	221 x 213
boost pedal, main	19	32	1	1 (0)	1.0	355 x 283
boost pedal, hand-wired	4	14	1	1 (0)	0.5	203 x 179
logic level converter	14	40	16	11 (1)	1.3	188 x 245
LED bar	17	61	12	7 (3)	2.2	185 x 343
ESP32 DevKitC	33	157	261, 4 unrouted	28 (31)	10.4 / 4.4	409 x 431
Corne v3, left half	73	219	221	155 (33)	19.8 / 10.8	655 x 739
Corne, left half	84	301	227	73 (36)	25.3 / 11.6	719 x 982
TS/Rat pedal, main	86	181	44	44 (2)	11.1	856 x 586

What the drawings show (the README has them; the bell three ways – Fritzing's, edakit's, the prototype's):

Maker-size circuits come out readable, unaided. The bell's drawing is the owner's old one with the rails outside: LED steps on the Nano's left, the buttons with their pull-downs below, the servo and its capacitor on 5V. Nothing was tuned per project – the same code draws the pedal, the LED bar and the coin cell.
The limit is the structure, not the count. A hub with chains of passives on its pins routes at 86 parts; a module with headers that mirror its pins, or a matrix, does not route at 33. The measure that says so is the number of crossings against the number of nets: below one per net the drawing reads, at five per net it is a mesh. The DevKitC's four unrouted pieces are the same thing: no channel was left.
The mixed style is the natural middle. Labels for the nets that are nothing but pass-throughs and buses, wires for the circuit around the module: 31 of the DevKitC's 48 nets are labelled and the rest draws through. A key matrix stays a mesh either way – it wants a drawing of its own kind (rows and columns as buses), which is the labelled style.
Placement decides the rest. The prototype keeps edakit's arrangement – blocks in rows – so every wire between blocks goes around; a module in the middle with its neighbours by connection would shorten the long loops of the LED bar and the level converter. The numbers of the table are an upper bound.
The page does not grow. The wired bell is 221 x 213 mm against edakit's 254 x 272 (the notes block is gone), the DevKitC 409 x 431 against 404 x 389. Wire length is the cost: 0.8 m for the bell, 10 m for the DevKitC.
A hand-wired board draws like any other – the prototype does not go through the board filter that refuses it.

What it does not do: the pin names (the symbol's), the notes and the pin table of the schematic file, the check of the drawing, speed (half a minute for a keyboard half in plain Python).

What to build¶

Three styles of edakit schematic draw, chosen per board by a key of the schematic file – data, as the add-feature skill asks –, labels without the key; the interview of new-project asks for it. The SVG alone (decision 1).

step	what	where	size (estimate)
W.1	The frame optional. `--no-frame`, or `frame = false` in the schematic file: no sheet border, no title block, the page the drawing and its margin – for a drawing embedded in a document.	`schematic_draw` (`fit`, `render`), `config.SCHEMATIC_KEYS`, `cli`, a test, handbook 6.5 and 10.3	built, merged into main 2026-10-31
W.2	The wired style. `style = "labels" \\| "wires" \\| "mixed"` in `hardware/schematic.toml`, labels without it; the leads, rails, router and colours of the prototype in `schematic_draw`; the geometry check learns to tell a crossing from a T; the output line reports crossings and wire length, the title block names the style. A hand-wired board is drawn (the `made=True` filter of `schematic draw` goes; decision 4). Tests on led-bar and the bell's graph; the catalog's reference circuits keep labels unless their schematic file says otherwise.	`schematic_draw.py` (the plan's leads and rails in `schematic_layout.py` behind the style, the EasyEDA path unchanged), `config.py`, `cli.py`, `tests/test_schematic_draw.py`, handbook 6.5, 10.3	~500 lines with tests, one session
W.3	Placement for wires. The module in the middle, the other blocks around it by the nets they share, channels as wide as the wires that must pass; the prototype's table as the test – fewer crossings, less wire, no bigger page.	`schematic_draw.py`	~200 lines, one session
W.4	The interview asks. new-project asks which style the board's drawing takes – labels (the default, for a board of any size), wires through (a maker-size circuit, a hand-wired board), mixed (a module with headers) – and writes `style` into the schematic file; project-surveyor reports it for a project that moves to edakit.	`skills/new-project/SKILL.md`, `agents/project-surveyor.md`, handbook 10.3	half a session
W.5	Pin names as the board prints them. A key per pin of a module's parts entry – `"print": "D2"` – that the drawing writes beside the symbol's name, nowhere else; the Nano's and the Pico's entries get them from their pinout pages; `edakit part lint` holds the key to the schema.	`catalog/kinds.toml`, `schematic_draw.box`, the entries, handbook 4.1	50 lines plus the data

Order: W.1 is done; W.2 and W.3 together give the owner the drawing, W.4 follows them; W.5 is independent and small.

W.2 as built (2026-10-31). style in the schematic file, one word or a table by board; the leads, the frames, titles and notes left out and the doubled gaps in schematic_layout.Layout behind its set wired; the router in schematic_draw on flat arrays, joining a piece in the middle of a jog trimmed back so that no lead hangs loose; a net it cannot join, or one with a single pin on the board, named at its pieces; schematic draw --board draws a hand-wired board, a bought one stays refused. After the owner's first look at the bell: a button's pins joined inside it show once per side (no loop from pin to pin), no wire runs along a part's outline, and the two cells in front of an open lead cost another net 12, so that the ground routed first does not wall in a lead of the 5 V routed after it. Measured with the build, every board without a conflict (crossings wires through / mixed, seconds wires through): the bell 6 / 3, 0.2 s; the LED bar 13 / 8, 0.5 s; the logic level converter 12 / 9; the boost pedal 3, its hand-wired board 1; the ESP32 DevKitC 373 / 33, 5 s (1 net it cannot join, named); the Corne v3 237 / 142, 12 s; the Corne 226 / 90, 18 s; the TS/Rat pedal 51 / 63, 7 s. The pages are smaller than the labelled ones (the bell 201 x 187 mm against 254 x 272). Left for W.3: the bell's last crossings – the ground between the pull-downs and the 5 V of the buttons cross because of where the blocks stand –; a rail stays only where two pieces of its net end on it, and the router joins the smallest piece to the nearest first – the TS/Rat pedal keeps all three rails, the DevKitC three of four, the bell, the LED bar and the level converter run their ground as wires between the parts; the blocks' notes and the pin table are not drawn wired through.

W.3 as built (2026-10-31). around in schematic_draw: the blocks of the rows – or one per module, IC and connector – no longer in rows but around the hub, the block with the module or else the one with the most nets to the others; each next block, the one with the most nets to those placed, tried on all four sides, as it is and turned by 180°, its pins of the shared signal nets level with theirs and moved out of the placed ones' way by the least distance – a channel of four cells and one more per shared net; of the eight the one whose wires cost least in the router's own costs, drawn from a cell out of each of its pins to a cell out of the nearest of theirs, straight with one bend: a step, a crossing of a placed or of its own wire, and the way round a part's body or along its outline there and back with two bends – a capacitor a jog, a module a long way. A power net pulls a fifth – it goes to its rail –; a block with no wire to the placed ones goes where the drawing grows least. Measured against W.2 at 27a6bd1 on every board at hand (crossings wires through / mixed, wire through): the bell 6 / 3 → 4 / 2, 1.4 → 1.2 m, its servo line from PB0 straight down to J1 below the Nano; the logic level converter 12 / 9 → 11 / 7; the boost pedal 3 / 3 → 2 / 2, 1.2 → 0.5 m; the TS/Rat pedal 51 / 63 → 36 / 39, 14.6 → 6.9 m; the Corne 226 / 90 → 218 / 74, 28.0 → 19.3 m; the ESP32 DevKitC 373 / 33 → 183 / 30, 12.0 → 8.7 m; the hand-wired boards the same. Every board has less wire, every page but the DevKitC's wired one (4 % more) is smaller in area. Worse: the LED bar wired through 13 → 18 (mixed 8 → 7) – the TLC5916's inputs come in another order than the Pico's pins, which no placement mends –, the Corne v3 mixed 142 → 171 (wired through 237 → 196), and the DevKitC leaves 5 nets unjoined instead of 1 (named, as before). A block turned by 180° keeps its texts upright.

Costs and risks¶

A crossing taken for a connection. The convention – a dot connects, a crossing does not – is every editor's, and the wired style multiplies crossings. The router keeps crossings away from ends, bends and pin tips, the drawing dots every junction; the geometry check of W.2 refuses a crossing at a junction. Likelihood of a misread by a reader: low with the dots; cost: a wrong assumption while hand-wiring, caught by edakit check only if the wrong wire is also in the graph – it never is, the graph is the source.
A drawing nobody can improve by hand. As today: whoever wants a different arrangement changes the schematic file (rows, near, style), not the drawing. For the wired style the file gets no new way to pin a wire's route – a route by hand would be the one thing outside the generator.
Time. The prototype's router is plain Python: a second for the bell, a minute for a keyboard half. W.2 keeps the grid but drops the per-cell dicts for arrays; the router runs only for a board whose key asks for wires.
Taste. Which style a reader prefers is theirs; the key decides per board, asked once at the project's setup, labels when nobody asked. The catalog's reference circuits stay as they are.

Decisions¶

Taken by the owner on 2026-10-31, in a decision round in Claude Code's form; "accepted" is the owner's yes to the recommendation.

#	Question	Decision	Status
1	Build the wired style as a third style of the one plan, reaching SVG, EasyEDA and KiCad alike?	For the SVG only: a style of `edakit schematic draw`; EasyEDA's board schematic and the KiCad schematic keep their labels	the owner's choice; the plan for all three was recommended and not taken
2	How is the style chosen?	`style` in the schematic file, labels without it; the question belongs to the project interview – new-project asks it (W.4) – and no measure chooses	the owner's choice: "labels is the default – but it counts among the questions that must be asked when setting up a project"; the default by the measure was recommended and not taken
3	Pin names as the board prints them (W.5)?	A `print` key per pin in the parts entry, drawn beside the symbol's name, used nowhere else; decision 6 of circuit-language.md stays	accepted
4	A hand-wired board gets the drawing?	Yes, in W.2	accepted
5	A breadboard or perfboard view?	No – "the schematic as Fritzing draws it, not the playful breadboard view"; the step is struck	the owner's choice; "later, when a project asks" was recommended
6	An export to Fritzing?	No – Fritzing was the example of how the schematics are drawn, "and that is where it all ends again"; never a question	the owner's word
7	Merge the branch of W.1 into main?	Yes – merged and the branch deleted the same day	accepted

Sources¶

edakit at 6139c4c, checked at b15a3ac: schematic_draw.py, schematic_layout.py (Layout, Drawing, check_geometry, apply), toolchain/kicad/schematic.py (write, the global labels from net_labels and the flags), config.py (SCHEMATIC_KEYS, Config.board(made=True)), docs/catalog/build.py, handbook 6 (6.2 names follow the symbol, 6.3 SCH_PrimitiveWire.create and four-branch crossings, 6.5), 4.5 (hand-wired boards), 10.3, 16.3, 17.8, skills circuit-design, hardware-change, new-project, .claude/skills/add-feature ("prefer data over options"); the open designs and fixtures under tests/ as the measured projects.
The prototype and its measures: prototypes/wired-schematic.
anTONIEa at 63aa3b7: hardware/circuits/tinyjukebox.fzz (read as XML: 22 parts, 124 wire pieces in the schematic view, ten colours, the mystery parts), tinyjukebox_circuit.png, hardware/README.md.
The Christmas bell at 021f2ae: docs/old/weihnachtsglocke_Schaltplan.png and weihnachtsglocke.fzz, hardware/graph.json (19 parts, 15 nets, 52 pin connections), hardware/schematic.toml; converted to the current form of the graph in a scratch copy for the prototype (edakit convert --write), the repository untouched.
Fritzing: the READMEs of github.com/fritzing/fritzing-app and fritzing-parts and the latter's LICENSE.txt, read through the session's proxy on 2026-10-31; fritzing.org did not resolve from the session.