Maslow Mini Merged Board

Maslow Mini — Merged Control Board

A third KiCad project that puts both existing boards on one PCB:

Scope: schematic, plus a partially-placed PCB. The mechanically-constrained parts are placed; the rest are staged off-board for manual placement. Nothing is routed yet.

The merge is in two parts: joining the two circuits, and then removing the redundancy that a single board makes pointless. 169 parts / 61 BOM lines → 156 parts / 53 BOM lines.

The design decision you asked for

Both ESP32-S3 MCUs are retained. They are wired to each other only on the BoardCom pair, which is exactly what the mated H1 2×5 headers used to carry:

Note the crossover. On the original boards both headers carried a net called BOARDCOM1 on pins 1/3 and BOARDCOM2 on pins 2/4 — but with the opposite assignment on each board, so mating them swapped the pair. That swap is preserved here.

H1 is deleted from both sections. Its remaining pins were power, so:

• pins 6/8/10 (VIN on the driver, VCC on the motor board) become one shared VIN rail
• pins 5/7/9 become one shared GND

What was consolidated

Once both circuits sit on one board, some parts are doing the same job twice.

One 3.3 V regulator

The driver board's U2 was an MP2459 — 0.5 A, feeding an ESP32-S3-WROOM-1 that peaks around 355 mA on WiFi transmit. That rail had almost no margin before the merge. The motor board's U116 is an LM2596-3.3 — 3 A. Combined 3.3 V load across both sections is roughly 530 mA typical, ~950 mA worst case, so the LM2596 carries both with ~3× headroom.

Deleted: U2, L3 (47 µH), D2 (catch), D6 (OR-ing), C80, C81, R61, R62, R63. D7 is kept and now ORs the driver USB port's VBUS into the shared VIN_BUCK, so either USB port can still power the whole board. +3V3_MC and +3V3_DRV are gone; there is one +3V3.

One reset

The motor MCU had no reset button at all — just an RC on EN. Both EN pins now share one net (RST) driven by SW2, with R28 (10 kΩ) and C134 (1 µF) as the single RC. R128 and C30 are deleted. The 1 µF is kept over the driver board's 100 nF because that is the value Espressif's design guide asks for.

One power-on LED, one Schottky part number

D101 + R115 deleted; the driver section's LED2 + R17 is kept (3.6 mA rather than 11 mA, and the LED was explicitly specified for low forward voltage on a 3.3 V rail). D102/D103 change from SS14 (40 V / 1 A) to the SS36 (60 V / 3 A) already used by D7 — one BOM line instead of two, and more margin on a 24 V rail that also carries six motor stages.

Summary

Nothing was added.

What stays separate

Each section keeps its own ESP32-S3, its own USB-C programming port and its own boot button (BOOT_MC / BOOT_DRV). Combining the two MCUs was explicitly out of scope. Combining the two USB ports would need a hub IC — a net part increase — or flashing the driver MCU through the motor MCU, which costs firmware work and makes recovery from a bad flash harder.

Also deliberately untouched: the VIN bulk capacitance. C140 (680 µF) and C72/C73 (2× 220 µF) were sized as two independent reservoirs because a header sat between them, and one of the 220 µF is probably surplus now — but that is a ripple-current question, not a schematic one. The ten 1 kΩ I2C pull-ups are also unchanged; each mux channel needs its own pair, though 1 kΩ is unusually strong (2.2–4.7 kΩ is conventional).

Two consequences of running one regulator

1. USB-only power is tighter. Each buck used to have its own port's 500 mA. Now both MCUs run from whichever single port is plugged in — fine for flashing (~230 mA from 5 V), close to the limit with both radios live (~460 mA). Plugging in both ports does not help; the diode-OR takes only the higher one.
2. Dropout on USB power. The LM2596 needs roughly Vout + 1.5–2 V. 5 V minus cable sag minus the OR-ing diode leaves ~4.3 V at high load. Fine at flashing currents, marginal at full load. This already existed on the motor board; merging just makes more depend on it.

Naming

Motor-section reference designators are the originals + 100 (U2→U102, C7→C107, CN3→CN103, …). The driver section keeps its own designators unchanged; its highest was C82, so nothing collides and you can still map any part back to its source board.

Files

Maslow Mini Merged Board.kicad_pro    project
Maslow Mini Merged Board.kicad_sch    root sheet — the two sections + the BoardCom link
Maslow Mini Merged Board.kicad_pcb    board — 70.7 x 111 mm, 20 parts placed, 136 staged, unrouted
motor_control_section.kicad_sch       page 2
driver_section.kicad_sch              page 3
MaslowMerged.kicad_sym                symbols authored for the motor-control parts
MaslowMerged.pretty/                  footprints extracted from the motor board's PCB
ProPrj_Dri-easyedapro.kicad_sym       symbols carried over from the driver board
ProPrj_Dri-easyedapro.pretty/         footprints carried over from the driver board
tools/                                the scripts that generated all of the above

PCB layout

tools/pcb_layout.py builds the board. 20 parts keep the exact position they had on their own board — every motor driver IC and every connector:

One board, both sections overlaid

The two source boards are the same mechanical envelope. Checked, not assumed:

• the driver board's outline sits inside the motor board's everywhere, to within 0.025 mm — that is rounding noise, not a different shape
• their mounting cutouts share identical centroids (the 9.2 mm² holes match to the second decimal; the 31.5 mm² slots to ~0.4 mm)
• the two boards' bottom edges are at exactly the same Y

So neither section is translated. Both sit at their own original board coordinates and overlay onto one PCB, which is what makes all six motor drivers land on the same outline. The twenty position-critical parts were checked for collisions in that arrangement: zero, and every one of them falls inside the motor outline and clear of its cutouts. Board side and rotation are preserved throughout — the driver section's ICs and connectors are on B.Cu, as they were.

Edge.Cuts is the motor board's outline used verbatim, cutouts included, since it is the larger of the two. The driver board's outline is drawn on Dwgs.User; the only place the two genuinely differ is one cutout (the motor board has a 112 mm² hole at (150, 80) that the driver board does not, and the driver board has a 290 mm² one the motor board does not).

The remaining 136 parts are staged 63 mm to the right of the board, behind a divider line on Cmts.User, in two labelled groups — one per section, sorted by reference, each keeping its original rotation and board side. tools/verify_pcb.py asserts that nothing but the twenty fixed parts touches the board area.

Staging cells are sized from each part's physical extent only — pads plus graphics and zones on copper, silk, courtyard, fab, paste and mask layers — and each part is anchored by its own top-left extent rather than its origin, so the rows line up regardless of where a given footprint puts its anchor. Text field positions and the Dwgs.User / User.* documentation and 3D-shell zones are excluded: several of these footprints park hidden fields and shell outlines a long way from the part, and measuring those blew the grid out to 1.6 m of sheet.

Footprint instances are lifted verbatim out of the two source PCBs, so pad shapes, back-side mirroring, custom padstacks and 3D model references all survive; only position, reference, net names and the schematic path are rewritten. The two exceptions are D102/D103, whose footprint changed with the SS14 → SS36 swap; those are built fresh from Diode_SMD:D_SMA.

Moving a part is not just a matter of rewriting its at. A footprint's pads and fp_* graphics are stored relative to its anchor, but two things are stored in absolute board coordinates:

• the motor board's EasyEDA import gives 77 footprints their own embedded paste/silk zone, and a footprint zone's polygon is absolute
• render_cache, the cached glyph outlines of text

An early version of pcb_layout.py moved only the anchor, which stranded those at the old location and produced footprints whose bounding box spanned 400 mm. KiCad then reported a position nowhere near what it drew, and dragging jumped. The generator now translates zone polygons with the part (in integer nanometres, so nothing drifts) and drops render_cache for KiCad to rebuild.

One unavoidable conflict: CN3 vs U103

Overlaying the two boards puts the driver board's CN3 (3-pin motor phase header, back side) on top of the motor board's U103 (DRV8876, front side). CN3's pads are through-hole, so they punch through and short to three of U103's pads — DRC reports it as shorting_items ×3, solder_mask_bridge ×3 and pth_inside_courtyard. Closest pad-to-pad distance is 1.6 mm centre-to-centre.

This is a real design conflict, not a file problem, and which of the two moves is your call, so both are left at their original coordinates and the spot is marked with a note on Cmts.User. It is the only such conflict: an exact pad-level check across all twenty fixed parts finds no other pair within 0.2 mm of touching.

Not placed, but arguably should be

IR1 and CGQ1 are the beam-break homing pair; their positions are as mechanically constrained as any connector, but they are not connectors and not motor drivers, so they went to staging. Say the word and they move to their original spots too. The indicator LEDs (LED102, LED103, LED2) are in the same category if the enclosure has light pipes.

How each section was produced

Driver section is the original schematic file, edited in place — same symbols, same placement, same graphics for everything that survives. The edits are: delete the listed symbols, convert the two surviving BoardCom labels to hierarchical pins, rename 3V3/BOOT, and retarget the instance paths at this project. Everything the deletions leave behind — labels that sat on a deleted pin, wires with nothing at one end, junctions in a wholly removed branch — is found by walking the sheet's connectivity graph rather than by hard-coded position, so the script stays correct if the source schematic moves. Two cosmetic repairs come with that: D7's reference and value text had been parked at D2's position by whoever added those diodes, and was re-seated next to D7 once D2 went; and the block captioned "3.3V Regulator / 200ma LDO / Power OR-ing with PMOS" — describing an arrangement this schematic never actually contained — is retitled "3.3 V DECOUPLING" with the stale notes removed.

Motor control section had to be reconstructed: that board exists only as a PCB. Its connectivity here is taken pin-for-pin from Four Motor Control Board M5_*.kicad_pcb, and its symbols were authored from the datasheet pinouts, each one cross-checked against how the PCB actually wires the part (e.g. the 100 nF from DRV8876 pin 12 to VM identifies pin 12 as VCP, which fixes the whole right-hand side of that package). Connectivity is drawn with a label on every pin rather than routed wires — the same style the driver board's own EasyEDA-imported schematic uses.

Verification

tools/verify_netlist.py compares the merged schematic's netlist against both source boards as a partition of pins, so net naming is irrelevant — what must match is which pins end up electrically common. Every intentional change is declared in that script and applied to the expectation, so anything else that moved would show up as a mismatch. Current result:

declared deletions: 15 parts
expected multi-pin nets: 124   actual: 124
EXACT MATCH - every remaining source net is reproduced, and nothing beyond the
declared changes was altered.

The thirteen pins the merged schematic carries that the sources do not are pads that were simply unconnected on the source PCB and are now explicit: SW101 1/3, U109 1/7 (SD NAND DAT1/DAT2, unused in SPI mode), USB102 A8/B8 (SBU), and seven spare ESP32 IOs on U110.

tools/verify_pcb.py then checks the board against the schematic: every component present exactly once with the right footprint, every pad carrying the net the schematic gives it (compared as a partition again), every footprint's schematic path pointing at the right sheet and symbol, and every part that was supposed to keep its position sitting exactly where it was to within its section's translation. Current result:

components: schematic 156, board 156
multi-pad nets: schematic 124, board 124
schematic paths: 156 unique across 156 footprints
fixed parts: 20 checked against their source-board coordinates
staged parts touching the board area: 0
uuids: 5113 total, 5113 distinct
footprint geometry identical to source: 154 of 154 checked
Edge.Cuts segments: 241
PASS

The geometry check is the important one: it compares every footprint's complete child-coordinate set against the same footprint on its source board, anchor-relative and in integer 0.1 µm units, with embedded zone polygons converted back to relative. Nothing can be left behind or drift without it failing.

The uuid and Edge.Cuts checks exist because both went wrong once. KiCad identifies every board object by its uuid, and duplicates make selection and dragging misbehave — the driver source board already ships a few (identical hidden property fields copied between parts), and an early version of pcb_layout.py multiplied them by minting outline ids from arguments that were identical for both outline copies. The generator now mints every id from one monotonic counter and re-mints any duplicate it inherits; the verifier fails if a single one survives, or if the board outline is missing.

PCB DRC reports 424 unconnected items — correct, nothing is routed — and 260 other findings, all of which are pre-existing on the source boards: the motor board's own baseline has 106 padstack, 62 text_height and 179 silk_overlap findings from its EasyEDA import, and the driver board's has 63 lib_footprint_mismatch. The merged board has fewer silkscreen violations than either source because the staged parts are spread out. No clearance, copper or hole-to-hole violations exist because there is no routing yet.

ERC over the whole project: 203 findings, all inherited from the driver board's EasyEDA import — pin_to_pin and pin_not_driven caused by that library typing its pins Unspecified, endpoint_off_grid on that sheet's original geometry, and one power_pin_not_driven on its #PWR01 ground symbol. There are no dangling labels, dangling wires, unconnected wire endpoints, unresolved symbols or missing footprint links; the driver board's own pre-merge baseline had 8 unconnected wire endpoints and 4 dangling wires, which the deletion cleanup removed. The motor-control sheet contributes zero off-grid endpoints.

Deliberate correction

The LM2596's TO-263 tab (U116 pad 6) was left with no net on the source PCB. The tab is internally GND on that package, so it is bonded to GND here. This is the one place the merged netlist intentionally differs from the source; tools/verify_netlist.py accounts for it explicitly.

Worth a look before layout

• Two 3.3 V regulators and two USB-C ports on one board is redundant. Keeping them was the conservative choice for a merge — revisit if you want to slim the BOM.
• The remaining LEDs do not agree on polarity: LED102 is wired anode-on-pin-1, LED103 anode-on-pin-2. That is reproduced from the source PCB (different footprints), but it is worth confirming against the parts you actually buy.
• 10uF / C0805 still appears as two BOM lines because both project libraries carry a C0805 footprint. Their pads differ by 0.0001 mm — they are the same EasyEDA export — so pointing all the passives at one library would collapse that line, and several others. Not done here because it touches every passive's footprint field.
• R107 (1.5 kΩ, was R7) sits directly between TRINAMICRX and TRINAMICTX — the usual half-duplex TMC UART arrangement, carried over as-is.

Regenerating

cd "Merged Control Board"
python3 tools/symlib.py MaslowMerged.kicad_sym
python3 tools/footprints.py
python3 tools/motor_sheet.py
python3 tools/driver_sheet.py
python3 tools/root_sheet.py
python3 tools/pcb_layout.py

and to re-check everything:

python3 tools/verify_netlist.py && python3 tools/verify_pcb.py

motor_sheet.py reads the analyzed motor PCB JSON and driver_sheet.py reads the original driver schematic, so both regenerate from the source boards rather than from this project.