From 1e4d78fda5cb7806c4c2d139b6010a99252eaab0 Mon Sep 17 00:00:00 2001 From: David Montero Crespo Date: Fri, 15 May 2026 00:31:19 -0300 Subject: [PATCH] fix(board): raspberry-pi-pico renders a real Pico, not Nano RP2040 Connect MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 'raspberry-pi-pico' boardKind used to render — a Web Component. That's a completely different board: it has pin labels D2..D13 / A0..A7 / 5V / VIN, and a horizontal 168×68 layout. The actual Raspberry Pi Pico has GP0..GP28 / 3V3 / VBUS / VSYS and is vertical-narrow (105×264). Symptom: every wire in a Pi-Pico example that referenced a real Pico pin (GP10, GP18, 3V3, GND.5, etc.) silently fell back to (0, 0) in pinPositionCalculator — the calculator looks up `element.pinInfo` by name, doesn't find GP* on the Nano RP2040 Connect component, and returns the board's top-left corner. The Pico Doom example was the loudest casualty (cables to the corner instead of the TFT), but seven other GP-style examples (pico-7segment, pico-button-led, pico-rgb, pico-dht22, pico-doom-raycaster, plus pico-ntc/pico-joystick which use A0/A1 aliases that map to GP26/GP27) all silently routed to nowhere. Fix is a two-liner: 'raspberry-pi-pico' shares the same case as 'pi-pico-w' (both use the same Web Component because the Pico and Pico W are pin-compatible). BOARD_SIZE updated to 105×264 to match the real Pico footprint. Dropped the now-unused NanoRP2040 import. Known regression — eleven older examples (pico-blink, pico-serial-led- control, pico-i2c-scanner, pico-i2c-rtc-read, pico-i2c-eeprom-rw, pico-spi-loopback, pico-adc-read, pico-multi-protocol, pico-hcsr04, pico-pir, pico-servo) were wired against D2..D12 of the wrong board. Their wires will now land at (0,0). Those examples' sketches were written for the Pi Pico (use LED_BUILTIN = GP25, A0..A3 = GP26..GP29) so the wires were ALREADY electrically nonsense — they connected external components to pins the sketch never touched. Visible bug trades silent bug; both need a follow-up commit to rewire each one to the Pico pin its sketch actually expects. Combined with the earlier MADCTL fix (6edc715) and the SPI adapter fix (6a7b721), Pico Doom should now finally render end-to-end on velxio.dev. Build verified (vite OSS+pro, 285 SEO pages). Co-Authored-By: Claude Opus 4.7 (1M context) --- .../components/simulator/BoardOnCanvas.tsx | 21 ++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/frontend/src/components/simulator/BoardOnCanvas.tsx b/frontend/src/components/simulator/BoardOnCanvas.tsx index d9dfab39..e2aac2a5 100644 --- a/frontend/src/components/simulator/BoardOnCanvas.tsx +++ b/frontend/src/components/simulator/BoardOnCanvas.tsx @@ -3,7 +3,10 @@ import type { BoardInstance } from '../../types/board'; import { ArduinoUno } from '../velxio-components/ArduinoUno'; import { ArduinoNano } from '../velxio-components/ArduinoNano'; import { ArduinoMega } from '../velxio-components/ArduinoMega'; -import { NanoRP2040 } from '../velxio-components/NanoRP2040'; +// NanoRP2040 (wokwi-nano-rp2040-connect) used to back the 'raspberry-pi-pico' +// boardKind by mistake — kept the import out so future contributors don't +// re-wire it back in. If someone genuinely needs a Nano RP2040 Connect +// board (D2..D13 labels), add a new boardKind 'arduino-nano-rp2040'. import { RaspberryPi3 } from '../velxio-components/RaspberryPi3'; import { Esp32 } from '../velxio-components/Esp32'; import { Attiny85 } from '../velxio-components/Attiny85'; @@ -17,7 +20,14 @@ const BOARD_SIZE: Record = { 'arduino-uno': { w: 274, h: 202 }, // 72.58mm × 53.34mm 'arduino-nano': { w: 170, h: 67 }, // 44.9mm × 17.8mm 'arduino-mega': { w: 388, h: 192 }, // 102.66mm × 50.80mm - 'raspberry-pi-pico': { w: 168, h: 68 }, // wokwi-nano-rp2040-connect: 44.573mm × 17.956mm + // Pi Pico physical board is 51mm × 21mm vertical-narrow. The render + // uses velxio's , same Web Component as 'pi-pico-w' + // because the Pico and Pico W are pin-compatible. Used to render the + // wokwi-nano-rp2040-connect (168×68) — that was a completely different + // board with D2-D13 pin labels, so wires in pico examples that + // referenced GP10/GP18/etc. landed at (0,0). The render now matches + // the boardKind name. + 'raspberry-pi-pico': { w: 105, h: 264 }, 'raspberry-pi-3': { w: 250, h: 160 }, // RaspberryPi3Element: PI_WIDTH=250 PI_HEIGHT=160 esp32: { w: 141, h: 265 }, // esp32-devkit-v1: 28.2 × 53 mm 'esp32-s3': { w: 128, h: 350 }, // esp32-s3-devkitc-1: 25.5 × 70 mm @@ -76,8 +86,13 @@ export const BoardOnCanvas = ({ return ; case 'arduino-mega': return ; + // 'raspberry-pi-pico' used to render (a wokwi-nano- + // rp2040-connect element with D2-D13 pin labels). That was a + // misnaming bug — the Nano RP2040 Connect is a different board. + // Use the same Pico Web Component as 'pi-pico-w' so the pins are + // labeled GP0..GP28, 3V3, VBUS, etc. — matching the FQBN + // (rp2040:rp2040:rpipico) and every Pi-Pico sketch's #defines. case 'raspberry-pi-pico': - return ; case 'pi-pico-w': return ; case 'raspberry-pi-3':