84 lines
3.0 KiB
Markdown
84 lines
3.0 KiB
Markdown
# Decisiones pendientes
|
|
|
|
Cosas que vale la pena resolver explícitamente antes de mergear a master.
|
|
|
|
## ABI del struct `vx_i2c_config`
|
|
|
|
C struct layout depende del compilador. `clang --target=wasm32-unknown-wasi` con default
|
|
alignment usa:
|
|
|
|
- Pointers: 4 bytes
|
|
- `uint8_t`: 1 byte (con padding al siguiente alignment)
|
|
- `int32_t`: 4 bytes
|
|
- `bool`: 1 byte (en wasm32)
|
|
|
|
Layout esperado (en orden de declaración del header):
|
|
|
|
| Offset | Field | Bytes |
|
|
|---|---|---|
|
|
| 0 | `address` (uint8_t + 3 bytes padding) | 4 |
|
|
| 4 | `scl` (vx_pin = int32_t) | 4 |
|
|
| 8 | `sda` | 4 |
|
|
| 12 | `on_connect` (function pointer = i32) | 4 |
|
|
| 16 | `on_read` | 4 |
|
|
| 20 | `on_write` | 4 |
|
|
| 24 | `on_stop` | 4 |
|
|
| 28 | `user_data` (void*) | 4 |
|
|
| **32** | **total** | |
|
|
|
|
→ **Acción**: documentar este layout en el header con `_Static_assert(offsetof(...))`.
|
|
|
|
## ¿Cómo carga un chip su `chip.json` en runtime?
|
|
|
|
El `chip.json` describe pines y atributos. Pero el host ya tiene esa info al instanciar el chip
|
|
(la lee al cargar el chip). Cuando el chip llama `vx_pin_register("SDA", VX_INPUT)`, ¿el host:
|
|
|
|
a) Confía en lo que dice el WASM y crea el pin sobre la marcha?
|
|
b) Verifica que "SDA" existe en el `chip.json` y rechaza si no?
|
|
|
|
→ Propuesta: (a) en MVP, (b) como warning en consola más adelante.
|
|
|
|
## Manejo de tiempo
|
|
|
|
Cada simulador tiene su clock:
|
|
- AVR: `cpu.cycles` a 16 MHz
|
|
- RP2040: ciclos a 133 MHz
|
|
- ESP32 (QEMU): tiempo real wall clock
|
|
|
|
`vx_sim_now_nanos` debe ser:
|
|
|
|
→ Propuesta: anclar al CPU del board al que está conectado el chip vía wire. Si está conectado a un
|
|
AVR, usar `cpu.cycles / 16e6 * 1e9`. Si a un RP2040, su contador. Si a múltiples boards,
|
|
tomar el primer board encontrado (caso raro).
|
|
|
|
## Múltiples instancias del mismo chip
|
|
|
|
Si el usuario pone dos 24C01 con direcciones I2C distintas, ¿cómo se distinguen?
|
|
|
|
- Cada instancia tiene su `WebAssembly.Instance` propia. Aislamiento de memoria perfecto.
|
|
- Cada `chip_setup()` crea su propio `chip_state_t` con `malloc`.
|
|
- Pero **dos instancias del mismo `.wasm`** comparten el módulo compilado (cache).
|
|
|
|
→ Acción: validar con un test E2E que dos 24C01 con direcciones 0x50 y 0x51 funcionan en paralelo.
|
|
|
|
## printf y la "Chips Console"
|
|
|
|
`printf` desde el chip va a `fd_write` (WASI). El stub lo captura y por ahora va al stderr de Node.
|
|
|
|
→ Pendiente: decidir si en producción Velxio agrega un panel "Chips Console" separado del Serial Monitor,
|
|
o si lo intercala con un prefijo `[chip-name]:`.
|
|
|
|
## Compilación: backend o browser
|
|
|
|
Implementación del MVP: backend Docker con wasi-sdk + endpoint REST.
|
|
Alternativa futura: clang en browser (vía `clang-wasm`) para modo offline puro.
|
|
|
|
→ Decisión actual: backend. Reevaluar tamaño del bundle browser cuando esté el MVP corriendo.
|
|
|
|
## Dimensión de la memoria del WASM
|
|
|
|
`WebAssembly.Memory({ initial: 2 })` = 128 KB. Suficiente para 99% de chips.
|
|
Algunos con buffers grandes (frame buffers) pueden necesitar más.
|
|
|
|
→ Acción: hacer configurable. Default 2 páginas, máximo 16 (1 MB).
|