62 lines
3.4 KiB
Markdown
62 lines
3.4 KiB
Markdown
|
# 05 — Vía frontend (browser): por qué no es viable hoy
|
|||
|
|
|
|||
|
|
El otro patrón de Velxio es ejecutar el emulador **en el browser** (sin backend, sin WebSocket): así corren AVR (`avr8js`) y RP2040 (`rp2040js`). Para ESP32-P4 esta vía está cerrada por falta de un emulador open-source.
|
|||
|
|
|
|||
|
|
## Opciones evaluadas
|
|||
|
|
|
|||
|
|
### 1. Emulador JS dedicado (estilo `avr8js` / `rp2040js`)
|
|||
|
|
|
|||
|
|
**No existe.** Wokwi mantiene `avr8js` y `rp2040js` open-source en GitHub bajo MIT, pero su engine ESP32 (incluido el P4) es **cerrado** y forma parte del producto Wokwi Cloud / Wokwi VS Code. Verificado:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
$ # listado de repos públicos org wokwi en github
|
|||
|
|
avr8js # open
|
|||
|
|
rp2040js # open
|
|||
|
|
esp32p4-hello-world # solo sketch ejemplo, NO engine
|
|||
|
|
esp32p4-mipi-dsi-panel-demo # solo sketch ejemplo
|
|||
|
|
esp32-roms # ROMs reverse-engineered
|
|||
|
|
esp32-test-binaries # firmware de prueba
|
|||
|
|
# NO HAY: esp32js, esp32p4js, esp32-emulator, etc.
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Construir un emulador RV32IMAFC + 55 GPIOs + I²C/SPI/UART/I²S/USB/MIPI-DSI desde cero es **trabajo de años** para una sola persona. Out of scope para este proyecto.
|
|||
|
|
|
|||
|
|
### 2. Emuladores RISC-V genéricos (rvemu, riscv-rust, TinyEMU)
|
|||
|
|
|
|||
|
|
| Proyecto | Lenguaje | ISA | ¿Sirve para ESP32-P4? |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| `d0iasm/rvemu` | Rust + WASM | RV64GC, Sv39, UART/PLIC/CLINT | ❌ apunta a Linux/xv6, no a ESP32 SoC. |
|
|||
|
|
| `takahirox/riscv-rust` | Rust + WASM | RV64IMAFD, Sv39 | ❌ idem. |
|
|||
|
|
| `TinyEMU` (F. Bellard) | C → wasm | RV32IMA, RV64GC | ❌ idem; emula virtio, no ESP32 mem-map. |
|
|||
|
|
|
|||
|
|
El problema no es el CPU — RV32IMAFC es estándar y cualquiera de estos lo ejecuta — el problema son **los periféricos chip-específicos**: GPIO matrix, IO MUX, RTC, SYSCON, INTERRUPT_CORE, USB OTG, etc. **Sin esos, el firmware se cuelga en el bootloader** intentando configurar reloj y memoria.
|
|||
|
|
|
|||
|
|
### 3. QEMU compilado a WASM
|
|||
|
|
|
|||
|
|
Patrón explorado en `test/esp32-emulator/qemu-wasm/Dockerfile` para Xtensa (vía Emscripten). Aplicaría igual al P4 **si `espressif/qemu` tuviera la máquina**, pero como no la tiene, este path está bloqueado por la misma razón que el backend.
|
|||
|
|
|
|||
|
|
Trade-off: aún cuando esté listo, QEMU-WASM:
|
|||
|
|
- pesa ~30-40 MB (chunk lazy-loaded).
|
|||
|
|
- es ~5-10× más lento que QEMU nativo en backend.
|
|||
|
|
- no tiene WebSocket overhead.
|
|||
|
|
|
|||
|
|
Conclusión: **prefiere backend QEMU** sobre QEMU-WASM para ESP32 boards en general. Coincide con la decisión que ya tomó Velxio para C3/S3.
|
|||
|
|
|
|||
|
|
### 4. Espressif IDF Component Manager + QEMU oficial reutilizado en cliente
|
|||
|
|
|
|||
|
|
Imposible: el QEMU oficial es ELF/EXE para Linux/Mac/Windows, no WASM. Habría que recompilarlo (vuelve a opción 3).
|
|||
|
|
|
|||
|
|
## Por qué AVR y RP2040 sí están en frontend
|
|||
|
|
|
|||
|
|
- **AVR**: ISA chiquita (~131 instrucciones, 8-bit). avr8js son ~5 K líneas TS.
|
|||
|
|
- **RP2040**: ARM Cortex-M0+ con set reducido. rp2040js son ~10 K líneas TS y aprovecha que el RP2040 es bien documentado y open silicon.
|
|||
|
|
- **ESP32-P4**: SoC de **última generación** con dual-core, FPU, AI extensions, MMU, cache, MIPI… al menos un orden de magnitud más complejo. Sin la documentación interna (que Espressif solo da parcialmente), el reverse-engineering completo es prohibitivo.
|
|||
|
|
|
|||
|
|
## Veredicto
|
|||
|
|
|
|||
|
|
La vía frontend para ESP32-P4 está **descartada** salvo dos eventos improbables a corto plazo:
|
|||
|
|
- Wokwi libera su engine ESP32 (no hay señales de eso).
|
|||
|
|
- Espressif publica un emulador WASM oficial.
|
|||
|
|
|
|||
|
|
La única vía realista es **backend QEMU cuando exista la máquina** — ver [`04_qemu_backend_path.md`](04_qemu_backend_path.md).
|