diff --git a/PIANO-LED-CIRCLE-PLAN.md b/PIANO-LED-CIRCLE-PLAN.md index f7f86e0..fc3d05d 100644 --- a/PIANO-LED-CIRCLE-PLAN.md +++ b/PIANO-LED-CIRCLE-PLAN.md @@ -84,8 +84,11 @@ close off "plug the piano into the Pi" as a fallback. **Casio WU-BT10** - Bluetooth 5.0. Profiles: **A2DP (audio)** and **GATT (MIDI over BLE)**. Codec SBC. - USB bus powered, 0.25W, no separate supply. -- Not used in this build's MIDI path. Freed up for streaming audio from the PC to the - piano's own speakers over A2DP, if wanted. +- **This is the project's Bluetooth MIDI path**, and it terminates at the PC, not the + Pi. Piano -> WU-BT10 -> PC over BLE GATT, then PC -> Pi over USB as usual. See + section 3a for why it cannot terminate at the Pi. +- A2DP is also available for streaming audio from the PC to the piano's own speakers, + if wanted. - Source: https://support.casio.com/en/support/answer.php?cid=008006001002&qid=104463&num=1 **Reference build** (https://yanniznik.com/building-a-led-piano-visualizer/) @@ -95,6 +98,53 @@ close off "plug the piano into the Pi" as a fallback. - ~$75-100 total. Includes a $30 iConnectivity mio MIDI interface **we do not need**, because the PX-S7000 has USB-B. +## 3a. Bluetooth and WiFi on Circle + +Checked against the pinned Circle tree (Step51) on 2026-08-27, after the question was +raised of supporting Bluetooth and WiFi on the Pi alongside USB. + +**Bluetooth: not possible on Circle. Two independent blockers.** + +VERIFIED: Circle's CHANGELOG states *"As announced the Bluetooth support has been +removed for legal reasons."* What remains, `lib/usb/usbbluetooth.cpp`, is a bare HCI +transport for a USB dongle with no stack above it. There is no BLE and no GATT +anywhere in the tree, and the removed stack was classic Bluetooth in any case. MIDI +over BLE *is* GATT, so even the deleted code would not have served. + +VERIFIED: that transport would need a dongle in USB **host** mode, and Circle is +host-or-gadget and never both (see section 2). The Pi is a gadget here. + +The consequence is not a loss. The WU-BT10 already does GATT MIDI to the PC, and the +PC is the hub, so Bluetooth MIDI is available today with no firmware change at all. +It simply terminates one hop earlier than the question assumed. + +**WiFi: possible, but it is a project, not a flag.** + +VERIFIED: `addon/wlan` is a Plan 9 derived BCM4343 driver (under its own Plan 9 +license), usable with Circle's TCP/IP stack and a bundled WPA supplicant. + +Four costs, all VERIFIED unless marked: + +1. Circle's README lists the Raspberry Pi Zero 2 W as *"WLAN unknown for new + revision"*. The Zero W is Tested. That is the opposite way round from the BOM's + preference in section 5. +2. Circle ships mDNS advertisement for `_apple-midi._udp` but **not** the RTP-MIDI + protocol itself. The session layer would have to be written, or ported from + MiniDexed, which implements exactly this on Circle. +3. WLAN loads firmware blobs from `RPi-Distro/firmware-nonfree` off the SD card at + boot, which reintroduces filesystem reads and weakens the power-cycle-safe + property that section 2 was built around. +4. ASSUMED: that WLAN coexists with USB gadget mode. WLAN is SDIO and so it probably + does, but both `addon/wlan` samples pair it with USB *host*, so this is unproven + and would need a spike before anything is committed to. + +And it reintroduces exactly the LAN attack surface that section 2 names as the +deciding factor for this architecture. + +**Decision (2026-08-27): USB first.** Bluetooth is taken on the PC side via the +WU-BT10, at no cost. WiFi is deferred, not rejected; if it is revisited, cost 4 above +is the first thing to settle, because it may close the option outright. + ## 4. Assumptions to verify before spending money 1. **PX-S7000 is class-compliant USB MIDI.** Almost certainly true for a 2022 @@ -193,7 +243,10 @@ Throw all of this away afterwards. It never gets mounted, never gets a hostname, never sits on the LAN permanently. 1. Piano to PC over USB-B. Confirm it appears in `aconnect -l`. -2. Pi Zero on Raspberry Pi OS, `rpi_ws281x`, Python REPL. +2. Pi Zero on Raspberry Pi OS, `rpi_ws281x`, Python REPL. **Configure it for SPI, so + the data line is GPIO10 (physical pin 19).** The stock `rpi_ws281x` examples drive + the strip from GPIO18 over PWM, but the Circle firmware uses SPI on GPIO10. Bench + on the default pin and the wiring you prove is not the wiring you keep. 3. Confirm: pixel 0 is at the end you think it is; `(note-21)*2` lights the right key; the far end holds voltage under load; the colors look right *through the diffuser*, which is not the same as how they look bare. @@ -203,7 +256,17 @@ never sits on the LAN permanently. Exit criteria: you know the hardware is good and you know exactly what you want the firmware to do. -### Phase 1 - Circle firmware +### Phase 1 - Circle firmware [DONE 2026-08-27, unverified on hardware] + +Written and building; see `firmware/` and README.md. Both kernel images build clean +against Circle Step51. Steps 2 and 3 were resolved by reading the Circle sources +rather than by trial: the WS28XX driver clocks the strip over SPI, putting data on +MOSI = GPIO10 = physical pin 19, and the gadget lifecycle follows +`sample/29-miniorgan`, which already carries a `USB_GADGET_MODE` path. + +Nothing here has touched a real LED or enumerated on a real PC. The riskiest untested +part is USB enumeration, and it is blocked by section 10 along with all of Phase 0. + 1. Clone Circle, pin the release, build a stock sample for the Zero to confirm the toolchain and the boot path.