a2nr
/
velxio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
velxio/test/test-esp32-p4/autosearch/06_recommendations.md

3.8 KiB
Raw Blame History

06 — Recomendaciones / plan accionable

Decisión propuesta

No agregar ESP32-P4 como board emulable hoy. Sumarlo en estado "compilable, no emulable" tiene un valor marginal (el usuario ve el ELF generado, pero al pulsar Run no pasa nada útil) y crea expectativa que no se puede cumplir.

Sin embargo, toda la plomería de toolchain se puede dejar lista hoy con muy poco esfuerzo, de modo que el día que espressif/qemu mergee la máquina P4, sumar el board sea cuestión de un PR de ~50 líneas.

Plan en 3 fases

Fase A — Hoy (preparación, sin exponer al usuario)

Esfuerzo: ~2 h. Riesgo: bajo. No agrega un board nuevo en el frontend.

  1. Refactor mínimo en arduino_cli.py: renombrar _is_esp32c3_board → _is_esp32_riscv_board y extender la lista a esp32c3, esp32c6, esp32h2, esp32p4. Misma lógica de bootloader_offset = 0x0000. ~10 líneas.
  2. Subscribirse al issue #127 de espressif/qemu para enterarse cuando aterrice la máquina P4.
  3. Mantener este folder test/test-esp32-p4/ como referencia viva — actualizar 01_findings.md cada vez que haya un release de espressif/qemu.

Fase B — Cuando QEMU soporte ESP32-P4

Esfuerzo: ~1-2 días. Riesgo: medio (depende de qué peripherals emule realmente la máquina).

  1. Backend (esp_qemu_manager.py):
    • Agregar 'esp32-p4': (QEMU_RISCV32, 'esp32p4') al _MACHINE dict.
    • Forzar wifi_enabled = False para P4 (chip sin radio nativa) — devolver warning explícito si el usuario lo activa.
  2. Frontend (types/board.ts):
    • Agregar 'esp32-p4' a BoardKind.
    • Agregar a BOARD_KIND_LABELS con label "ESP32-P4 Dev Module".
    • Agregar a BOARD_SUPPORTS_MICROPYTHON (MicroPython tiene puerto P4 desde mediados 2025).
  3. Pin mapping (utils/boardPinMapping.ts):
    • Mapear los 55 GPIOs según pinout del Dev Module Espressif. Patrón idéntico al ESP32-S3.
  4. Componente visual:
    • SVG nuevo en components-wokwi/ (no hay element open en wokwi-elements). Alternativa de bajo esfuerzo: reutilizar el SVG del ESP32-S3 con renombrado de pines, hasta tener un dibujo propio.
  5. Smoke test: test/test-esp32-p4/scripts/smoke.sh que (a) compila blink, (b) lanza qemu-system-riscv32 -M esp32p4 -drive ..., (c) verifica que aparece "ESP32-P4 blink starting" en el TCP serial.
  6. Tests backend: agregar caso ESP32-P4 a test/esp32/test_esp32_integration.py.

Fase C — Wi-Fi mock (opcional, cuando haya demanda real)

Cuando un usuario reporte que quiere usar WiFi.h con ESP32-P4, implementar mock por parsing del UART (mismo patrón que wifi_status_parser.py ya usa para C3). El bus SDIO al C6 emulado real es prohibitivo y se puede ignorar.

Lo que NO hacer

  • ❌ No empezar a portar rp2040js a "esp32p4js". Es un proyecto de años y duplica esfuerzo de Wokwi/Espressif.
  • ❌ No mergear el board en producción sin el QEMU operacional. Da una mala primera impresión.
  • ❌ No comprometerse con Wi-Fi/BLE para este chip. La radio externa C6 es una bestia distinta.
  • ❌ No usar QEMU-WASM para P4 mientras el backend QEMU funcione bien para los otros ESP32. Costo (~40 MB WASM extra) > beneficio.

Métrica de éxito

Cuando se ejecute Fase B, el criterio de aceptación es:

  • arduino-cli compile --fqbn esp32:esp32:esp32p4 blink produce ELF (ya OK).
  • En Velxio, seleccionar board "ESP32-P4 Dev Module" + Run reproduce el LED parpadeando + Serial Monitor muestra "HIGH/LOW" cada 500 ms.
  • Smoke test CI verde.

Cómo monitorear el bloqueante

Cuando aparezca hw/riscv/esp32p4.c en esp-develop, activar Fase B.