Tema L1 · Laboratorio · ESP32 emulado y Bluetooth

En este laboratorio tu app Android conversa con un ESP32 que no existe físicamente. El firmware que compilas con PlatformIO corre en un emulador de ESP32-C3 dentro de tu ordenador y se comunica con la app por Bluetooth clásico (SPP), exactamente igual que lo haría con un módulo HC-05 real.

El comportamiento es sencillo a propósito:

• Cada 5 segundos el firmware manda un tick con los segundos que lleva en marcha.
• Cuando le escribes algo desde la app, contesta con un eco numerado.

Esto es lo que verás en la app (emulador Pixel 8, conectada a ESP32-EMU-SPP):

<< tick 370 s
<< tick 375 s
>> hola desde la app
<< eco #4: hola desde la app

Las flechas << marcan lo que llega del ESP32 y >> lo que envías tú.

¿Por qué es interesante para esta asignatura?

Hasta ahora casi todos tus eventos venían del dedo: onClick, onCheckedChanged... Aquí aparecen dos fuentes nuevas:

La práctica se monta con cuatro piezas. Solo esp-emu y Bumble son nuevas; el resto ya lo tienes del laboratorio anterior.

Esta regla te ahorra mucho tiempo: si algo falla en medio, casi nunca es «tu código», sino el orden de arranque o una dirección. Lo veremos en el diagnóstico.

Parece que sobra una pieza: si el emulador ejecuta un ESP32, ¿por qué no habla Bluetooth directamente? Tres razones:

1. esp-emu solo emula chips RISC-V: ESP32-C3, C6, H2 y P4. Ninguno tiene Bluetooth clásico: todos son BLE only. El ESP32 «clásico», que sí lo tiene, no se puede emular.
2. La app usa SPP, el perfil de Bluetooth clásico de los módulos HC-05/HC-06 de Arduino: un socket con un flujo de bytes en cada sentido.
3. Bumble hace de HC-05. El firmware habla por su UART1; Bumble publica el servicio SPP en la radio virtual y reenvía cada byte a esa UART. Tu código no cambia.

Compara las dos topologías:

La línea recta es un cable (o su equivalente, un socket TCP) y la ondulada es radio Bluetooth. La topología es la misma: solo cambia quién pone la radio.

Esta es la cadena de extremo a extremo:

Direcciones y sentido de la conexión

• La UART1 del firmware se sirve en 127.0.0.1:5556. Escribe siempre la IP, nunca «localhost»: localhost puede resolver a la dirección IPv6 (::1) y entonces no encuentra a esp-emu.
• El puente RFCOMM se conecta a esp-emu, no al revés. esp-emu es el servidor TCP; Bumble es el cliente.

El orden de arranque

Como el puente necesita encontrar a esp-emu escuchando, el orden importa:

Los pasos 2 y 3 los hace ./run.sh spp, que ya arranca esp-emu primero y luego Bumble.

Recibes dos ZIP del profesor e instalas dos herramientas nuevas.

ZIP demo-esp32

ZIP pde-plantilla-sdk36

La plantilla de la asignatura (Compose + vistas clásicas). Sus versiones están fijadas: no toques gradle/. Aquí añadirás BluetoothActivity, su layout y los permisos en el manifest. El emulador Pixel 8 API 36 se crea desde Device Manager.

Lo que instalas tú

• esp-emu: binario oficial de Espressif (instalador o release de GitHub). Hito: esp-emu --help responde.
• Bumble: paquete Python en un entorno virtual, con Python 3.10 o superior:

# desde la carpeta que CONTIENE demo-esp32 (los scripts esperan ../.venv)
python3 -m venv .venv
source .venv/bin/activate
pip install "bumble[all]"

Ya tienes del laboratorio anterior VS Code + PlatformIO y Android Studio.

Las comillas en "bumble[all]" no son decorativas: en zsh los corchetes se interpretan como patrón de ficheros y sin comillas el comando puede fallar.

Los pasos 1 a 3 se hacen una sola vez; del 4 al 7 son el ciclo de trabajo de la práctica.

¿Por qué tanta insistencia? Porque en una cadena de cinco piezas, un fallo en la fila 2 se manifiesta como «la app no conecta» en la fila 7, y entonces no sabes dónde mirar. Avanzar hito a hito es aislar el fallo antes de que se esconda.

Proyecto demo-esp32, entorno esp32c3-spp, placa esp32-c3-devkitm-1, framework Arduino, sin librerías extra.

Qué tocar: src/spp/main.cpp

El firmware usa dos puertos serie con papeles distintos:

El firmware lee líneas de Serial1, responde con eco y manda un tick cada 5 s. Un boceto orientativo (la configuración exacta de Serial1 es la de la plantilla):

uint32_t ultimoTick = 0;
uint32_t ecos = 0;
String linea;

void setup() {
  Serial.begin(115200);                       // logs → consola de esp-emu
  // Serial1.begin(...): baudios y pines 4/5 como vienen en la plantilla
  Serial.println("[APP] firmware SPP listo");
}

void loop() {
  if (millis() - ultimoTick >= 5000) {        // evento temporal: tick
    ultimoTick = millis();
    Serial1.printf("tick %lu s\n", (unsigned long) (millis() / 1000));
  }
  while (Serial1.available()) {               // evento externo: bytes
    char c = Serial1.read();
    if (c == '\n') {
      Serial.printf("[UART1] recibido: %s\n", linea.c_str());
      Serial1.printf("eco #%lu: %s\n", (unsigned long) ++ecos, linea.c_str());
      linea = "";
    } else if (c != '\r') {
      linea += c;
    }
  }
}

Cómo compilar

./build.sh esp32c3-spp

El script hace pio run y después esptool merge_bin. esp-emu quiere la imagen unificada merged_flash.bin, no firmware.bin: necesita toda la flash montada (no solo tu aplicación), como si fuera el chip real recién grabado.

En el ciclo de trabajo (pasos 4 a 7) vas a cambiar cosas a ambos lados constantemente. Saber qué relanzar según qué has tocado te ahorra muchos minutos.

Piensa en la cadena como piezas independientes que se hablan por «tuberías» (TCP, Bluetooth). Cambiar una pieza solo obliga a reiniciar esa pieza y, como mucho, las que dependen de ella para conectarse.