From d38ed04f855d5b1966d32a0aa1c4bbda48cc8a99 Mon Sep 17 00:00:00 2001 From: David Montero Date: Wed, 24 Jun 2026 04:48:29 +0200 Subject: [PATCH] fix(pi): drive canvas LEDs from guest GPIO (PinManager -> SPICE) The Pi bridge onPinChange was a no-op, so guest GPIO writes never reached the PinManager / SPICE solver and wired LEDs stayed dark even though user scripts printed 'LED on'. Mirror the ESP32 branch: forward to pm.triggerPinChange so GPIO drives the canvas. Interconnect still preserves and calls this before its own cross-board routing. --- frontend/src/store/useSimulatorStore.ts | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/frontend/src/store/useSimulatorStore.ts b/frontend/src/store/useSimulatorStore.ts index 55b37787..44ba15c7 100644 --- a/frontend/src/store/useSimulatorStore.ts +++ b/frontend/src/store/useSimulatorStore.ts @@ -1072,8 +1072,14 @@ export const useSimulatorStore = create((set, get) => { serialCallback(ch); // Cross-board routing now handled by Interconnect (see bind below). }; - bridge.onPinChange = (_gpioPin, _state) => { - // Cross-board routing now handled by Interconnect (see bind below). + bridge.onPinChange = (gpioPin, state) => { + // Feed the guest's GPIO writes into this board's PinManager so they + // reach wired components and the SPICE solver (the LED brightness + // path) — same as the ESP32 branch. Without this the Pi could print + // "LED on" but the canvas LEDs stayed dark. Interconnect preserves + // and calls this before its own cross-board routing. + const boardPm = pinManagerMap.get(id); + if (boardPm) boardPm.triggerPinChange(gpioPin, state, 'mcu'); }; // Guest Linux finished booting (shell prompt reached). Flip piBooted so // the workspace swaps the "Booting…" overlay for the live terminal and