36ad2bef3f
Closes the remaining gaps in cross-board I2C so any topology of supported boards (Uno↔ESP32, two ESP32s, Uno↔Uno↔Uno, ESP32-C3 connected to anything, etc.) works end-to-end with all I2C components including write-only sinks (SSD1306, PCF8574, LCD-I2C). Implementation (6 phases): 1. **BFS routing in I2CBusManager**: connectToSlave + handleExternalConnect walk the bridge graph with a visited Set so multi-hop chains (A↔B↔C with the device on C) resolve transparently. A new forwarder-device shim is installed at intermediate hops so the existing handleExternalWrite/Read/Stop machinery routes through without per-method visited tracking. 2. **Per-peer proxy ownership in Esp32BridgeShim**: replaces the global _proxiedAddrs Set with _proxiedByPeer Map so concurrent bridges to the same ESP32 (e.g. wired to both Uno and Pico) don't wipe each other's proxies on teardown. Interconnect's per-wire teardown calls clearProxiesForPeer(peerBus) instead of clearAllProxies. 3. **BFS-aware proxy sync**: syncProxyFromPeer now walks the peer bus + its transitive bridges, so an ESP32 sees devices on boards two or more hops away. _peerDeviceLookup keeps a flat addr → device map for write-forwarding and resync. 4. **Periodic resync (250 ms)**: Esp32BridgeShim runs a setInterval while any proxy is live, re-dumping each device with dumpRegisters() and pushing updateProxyI2c only when an XOR- stride hash changes. This keeps RTC time advancing visible to ESP32 firmware without flooding the WS pipe with static calibration dumps. Hash is primed during initial sync so the first tick doesn't push a redundant identical buffer. 5. **Write-forwarding ProxySlave → peer**: backend ProxySlave buffers write bytes during the transaction and emits a `proxy_i2c_complete` event on STOP / repeated-START. Frontend Esp32Bridge dispatches the event to a new onProxyI2cComplete callback; the shim replays the byte sequence on the actual peer I2CDevice via writeByte() + stop(). Makes ESP32 firmware writes to peer SSD1306 actually repaint the OLED, peer PCF8574 latch updates, peer I2CMemoryDevice register mutations propagate. 6. **ESP32-C3 routed as bridge**: Interconnect.isBrowserSim no longer claims c3/xiao-c3/c3-supermini — they were already going through Esp32Bridge per the store's ESP32_RISCV_KINDS routing, but Interconnect was treating them as browser sims which broke proxy install. isEsp32Bridge now correctly includes c3 family + ESP32-S3 + Arduino Nano ESP32. Defensive: addBoard now disposes any existing shim's proxies before overwriting simulatorMap entry so test reruns don't leak timers. Tests: - 4 BFS multi-hop tests (i2c-multi-board-slave-gap.test.ts) - 11 cross-board scenarios + per-peer + write-forward + resync (i2c-esp32-multiboard-bridge.test.ts) - 1 real-firmware E2E for write-forward via QEMU (compile + load + observe proxy_i2c_complete arriving with the byte) - New sketch fixture: esp32_i2c_write_to_peer.ino Result: 90 test files / 1295 tests pass / 0 fail. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| fixtures | ||
| scripts | ||
| sdk | ||
| sketches | ||
| src | ||
| test | ||
| .gitignore | ||
| README.md | ||
| package-lock.json | ||
| package.json | ||
| vitest.config.js | ||
README.md
test_custom_chips
Sandbox aislado para validar el sistema de custom chips de Velxio antes de integrarlo al frontend. Cero dependencia de Wokwi.
Objetivos
- Probar que se puede cargar un
.wasm(chip compilado a partir de C) y enrutarlo al simulador. - Probar que un sketch de Arduino real (
.hexcompilado conarduino-cli) puede comunicarse con el chip vía GPIO e I2C. - Mantener fidelidad 1:1 con la infraestructura de Velxio (
PinManager,I2CBusManager,AVRSimulator) para que el código que se valide acá sea trivial de portar.
Estructura
test_custom_chips/
├── package.json
├── README.md
├── vitest.config.js
├── sdk/
│ ├── include/
│ │ └── velxio-chip.h ← API que ven los chips
│ └── examples/
│ ├── inverter.c
│ ├── inverter.chip.json
│ ├── eeprom-24c01.c
│ └── eeprom-24c01.chip.json
├── scripts/
│ ├── compile-chip.sh ← clang invocation Linux/macOS
│ ├── compile-chip.ps1 ← clang invocation Windows
│ ├── compile-all.sh ← compila todos los ejemplos
│ └── setup-wasi-sdk.md ← cómo instalar wasi-sdk
├── src/ ← runtime y mirrors de Velxio
│ ├── ChipRuntime.js ← loader WASM + host imports
│ ├── WasiShim.js ← WASI mínimo (fd_write, proc_exit)
│ ├── PinManager.js ← espejo de Velxio
│ ├── I2CBus.js ← espejo del I2CBusManager
│ ├── AVRHarness.js ← avr8js wrapper Velxio-fiel
│ ├── intelHex.js ← parser
│ └── index.js
├── fixtures/ ← .wasm compilados + .hex sketches
└── test/
├── js/ ← tests que NO requieren clang
│ ├── 01_pin_manager.test.js
│ ├── 02_i2c_bus.test.js
│ ├── 03_avr_harness.test.js
│ └── 04_runtime_imports.test.js
└── e2e/ ← tests que requieren .wasm compilado
├── 05_chip_inverter.test.js
└── 06_chip_eeprom_24c01.test.js
Quickstart
# 1. Instalar deps
cd test/test_custom_chips
npm install
# 2. (Solo para tests E2E) instalar wasi-sdk siguiendo scripts/setup-wasi-sdk.md
# 3. (Solo para tests E2E) compilar los ejemplos
npm run compile:examples
# 4. Correr tests
npm test # todo
npm run test:js # solo tests JS-only (no requieren wasi-sdk)
npm run test:e2e # solo E2E con WASM
Los tests e2e/ se hacen it.skip automáticamente si el .wasm correspondiente no
está en fixtures/. Eso permite correr la suite parcialmente sin tener wasi-sdk instalado.
Por qué un sandbox separado
Igual que test_circuit/ validó el solver SPICE antes de integrarlo, este sandbox valida
el runtime de chips antes de tocar el frontend de Velxio. Cuando los tests pasen end-to-end,
los archivos de src/ se portan al frontend (con tipado TS) e integran con el editor.
Estado actual
Ver ../autosearch/04_findings.md para el log corrido de qué funciona y qué falta.