a2nr
/
velxio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
velxio/test/test_Raspberry_Pi_Pico_W/autosearch/00_README.md

37 lines
2.6 KiB
Markdown
Raw Normal View History

Add comprehensive tests for Cyw43Emulator functionality and lifecycle - Implemented handshake tests to validate initial bus state and register responses. - Created end-to-end tests for Pico W LED blinking using MicroPython firmware. - Added SDPCM framing tests to ensure proper encoding and decoding of control frames. - Developed IOCTL tests to verify command responses and state changes in the emulator. - Established a full lifecycle test for WiFi operations, including scanning, connecting, and packet handling. - Introduced TypeScript configuration for test files to ensure compatibility and strict type checking.
2026-04-29 10:21:26 +07:00
# Pico W WiFi (CYW43439) emulation — autosearch dossier
This folder collects the research that backs **the question raised by the
user on 2026-04-28**:
> "Velxio emulates ESP32 WiFi but not Raspberry Pi Pico W WiFi. The
> WiFi chip is a CYW43439. Has anyone written an emulator for it? Look
refactor: rename wokwi-libs/ → third-party/ The directory grew well beyond Wokwi-only contents: it now hosts lcgamboa's QEMU fork (qemu-lcgamboa), Espressif's esp32-camera, the ngspice WASM build, fritzing-parts, picowi, an alternative QEMU (qemu-esp32), the 100_Days_100_IoT_Projects examples repo, and Wokwi's own avr8js/rp2040js/wokwi-elements/wokwi-features/wokwi-boards. "wokwi-libs" was misleading — half the contents have nothing to do with Wokwi. "third-party/" is the standard convention for vendored external dependencies. Mechanical changes: Path rename: wokwi-libs/ → third-party/ update-wokwi-libs.bat → update-third-party.bat docs/WOKWI_LIBS.md → docs/THIRD_PARTY.md Submodule reconfiguration: .gitmodules — 4 path= and section names updated .git/modules/wokwi-libs/ → .git/modules/third-party/ each submodule's .git file rewired to ../../.git/modules/third-party/<name> Reference updates (~80 files): vite.config.ts aliases, Dockerfile COPY paths, GH Actions workflow steps, build_qemu_*.sh, all docs/* and test/*/autosearch/* entries that mention the path, package-lock.json file: dependencies, .gitignore patterns, sitemap.xml + index.html SEO blurbs, scripts/generate-component-*, .dockerignore, .idea/vcs.xml. Bulk replaced both `wokwi-libs/` (path) and bare `wokwi-libs` (textual mentions in docs/comments). Verified: - npx tsc -b --noEmit produces no new errors related to these paths - vite.config.ts aliases now point at ../third-party/avr8js etc. - All 4 git submodules (avr8js, rp2040js, wokwi-elements, wokwi-features) are linked under third-party/ with their worktrees re-populated and config files referencing the new path - `grep -r wokwi-libs` returns zero hits outside node_modules, .vite, frontend/dist, third-party/ (upstream submodule contents), *.pyc caches, and *.dll.pre-camera rollback binaries Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 10:58:57 +07:00
> at `third-party/rp2040js`, find out what would be needed to complete
Add comprehensive tests for Cyw43Emulator functionality and lifecycle - Implemented handshake tests to validate initial bus state and register responses. - Created end-to-end tests for Pico W LED blinking using MicroPython firmware. - Added SDPCM framing tests to ensure proper encoding and decoding of control frames. - Developed IOCTL tests to verify command responses and state changes in the emulator. - Established a full lifecycle test for WiFi operations, including scanning, connecting, and packet handling. - Introduced TypeScript configuration for test files to ensure compatibility and strict type checking.
2026-04-29 10:21:26 +07:00
> WiFi emulation."
## TL;DR
| Question | Answer |
|---|---|
| Does upstream `rp2040js` emulate the CYW43439? | **No.** Open issue [#134](https://github.com/wokwi/rp2040js/issues/134) ("Is there a way to emulate cyw43 using nodejs?") sits unanswered since it was opened. There is no PR, no branch, no design draft. |
| Does Wokwi emulate Pico W WiFi today? | **Yes**, but the CYW43 model is **closed-source** and lives server-side together with the rest of the Wokwi network stack. Only the bare RP2040 core (`rp2040js`) is open. |
| Is there any community emulator? | **No.** Every CYW43 project we found is the *opposite direction* — host-side drivers (`georgerobotics/cyw43-driver`, `embassy-rs/cyw43`, `soypat/cyw43439`, `iosoft/picowi`) that talk to *real* silicon. None is an emulator of the chip. |
| Is the protocol documented well enough to build one? | **Mostly yes.** The gSPI bus is described in the Infineon datasheet and re-implemented in three open-source drivers. The 224 KB firmware blob is *not* — it is a closed binary loaded into the chip, but for emulation purposes we don't need to run it; we only need to **answer the host driver as if it had executed**. |
| Reasonable scope for Velxio? | **Yes, in tiers** (see [04_emulation_design.md](./04_emulation_design.md)). Tier 0 (handshake-only stub) is doable in days. Tier 2 (DHCP + TCP via slirp) is comparable in size to the existing ESP32 path. |
## What's in this folder
```
00_README.md ← this file
01_velxio_current_state.md ← what Velxio actually does today on Pico W
02_rp2040js_inventory.md ← what rp2040js exposes that we'd hook into
03_cyw43_bus_protocol.md ← gSPI command word, registers, magic values
04_emulation_design.md ← layered plan from stub → full WiFi
05_existing_implementations.md ← every CYW43 codebase we found, classified
06_firmware_blob_question.md ← can we ship the 224 KB blob? legal/practical
07_open_questions.md ← decisions we cannot make from research alone
sources.md ← canonical URLs, dated 2026-04-28
```
The companion folder `../test_code/` contains runnable prototypes that
refactor: rename wokwi-libs/ → third-party/ The directory grew well beyond Wokwi-only contents: it now hosts lcgamboa's QEMU fork (qemu-lcgamboa), Espressif's esp32-camera, the ngspice WASM build, fritzing-parts, picowi, an alternative QEMU (qemu-esp32), the 100_Days_100_IoT_Projects examples repo, and Wokwi's own avr8js/rp2040js/wokwi-elements/wokwi-features/wokwi-boards. "wokwi-libs" was misleading — half the contents have nothing to do with Wokwi. "third-party/" is the standard convention for vendored external dependencies. Mechanical changes: Path rename: wokwi-libs/ → third-party/ update-wokwi-libs.bat → update-third-party.bat docs/WOKWI_LIBS.md → docs/THIRD_PARTY.md Submodule reconfiguration: .gitmodules — 4 path= and section names updated .git/modules/wokwi-libs/ → .git/modules/third-party/ each submodule's .git file rewired to ../../.git/modules/third-party/<name> Reference updates (~80 files): vite.config.ts aliases, Dockerfile COPY paths, GH Actions workflow steps, build_qemu_*.sh, all docs/* and test/*/autosearch/* entries that mention the path, package-lock.json file: dependencies, .gitignore patterns, sitemap.xml + index.html SEO blurbs, scripts/generate-component-*, .dockerignore, .idea/vcs.xml. Bulk replaced both `wokwi-libs/` (path) and bare `wokwi-libs` (textual mentions in docs/comments). Verified: - npx tsc -b --noEmit produces no new errors related to these paths - vite.config.ts aliases now point at ../third-party/avr8js etc. - All 4 git submodules (avr8js, rp2040js, wokwi-elements, wokwi-features) are linked under third-party/ with their worktrees re-populated and config files referencing the new path - `grep -r wokwi-libs` returns zero hits outside node_modules, .vite, frontend/dist, third-party/ (upstream submodule contents), *.pyc caches, and *.dll.pre-camera rollback binaries Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 10:58:57 +07:00
exercise these findings against the real `third-party/rp2040js`.