BermejaSat #15: Banco de Pruebas Paralelo — Puesta a Punto de una Raspberry Pi Pico W para Validar el BMP/BME280

Introducción

Con la integración del GPS GY-NEO6MV2 ya documentada en la entrada anterior, el siguiente componente pendiente en la lista de sensores de BermejaSat es el barómetro de precisión BMP/BME280, encargado de medir presión y temperatura durante el descenso — la misión primaria exigida por las bases del desafío CanSat de la ESA.

Antes de soldar y programar este sensor directamente sobre la Heltec V3.2 definitiva, hemos optado por un paso intermedio: montar un banco de pruebas paralelo con una Raspberry Pi Pico W que teníamos disponible en el laboratorio. La idea es sencilla y evita quemar tiempo de desarrollo en la placa final: si el sensor falla, el error se aísla mejor en un entorno mínimo (una placa, un sensor, un cable) que en el firmware completo de telemetría.

🔌 Por qué la Pico W es un banco de pruebas válido

Antes de conectar nada, conviene verificar la compatibilidad eléctrica. La Raspberry Pi Pico W (basada en el chip RP2040) trabaja con lógica de 3.3V, exactamente igual que el chip Bosch del BMP280/BME280. A diferencia de placas de 5V como un Arduino Uno clásico, aquí no hace falta ningún adaptador de nivel lógico: el sensor se alimenta directamente desde la salida de 3.3V de la Pico.

🛠️ Identificación del módulo: GY-BM/PM280

El módulo con el que hemos trabajado es un GY-BM/PM280, un breakout que puede montar dos chips distintos bajo el mismo diseño de placa: el BME280 (presión + temperatura + humedad) o el BMP280 (solo presión + temperatura, sin humedad). Para los requisitos oficiales de la misión CanSat basta con presión y temperatura, así que ambas variantes son válidas; si el chip resulta ser BME, la humedad queda como dato extra en la trama de telemetría sin coste adicional de cableado.

Este módulo trae 6 pines, y es importante no dar por sentado su función a ciegas:

Pin del módulo	Función	Conexión en la Pico W
VCC	Alimentación 3.3V	Pin 36 (3V3 OUT)
GND	Tierra	Pin 38 (GND)
SCL	Reloj I2C	Pin 2 (GPIO1)
SDA	Datos I2C	Pin 1 (GPIO0)
CSB	Chip Select (modo SPI)	Sin conectar (flotante)
SDO	Selección de dirección I2C	GND → 0x76 · VCC → 0x77

⚠️ Dos precauciones antes de dar el cableado por bueno:

1. CSB debe quedar al aire. Este chip Bosch soporta tanto I2C como SPI, y es precisamente el pin CSB el que decide el modo de arranque. Dejarlo flotante (o a nivel alto) activa el modo I2C que necesitamos; conectarlo por error a GND fuerza el modo SPI y el bus I2C deja de responder, aunque el resto del cableado esté bien hecho.
2. SDO fija la dirección I2C del sensor, y hay que conocerla de antemano para no confundir “sensor no detectado” con “sensor detectado en la dirección equivocada”.

💻 El mismo entorno para toda BermejaSat: Arduino IDE también en la Pico

Para no introducir un segundo lenguaje ni un segundo IDE en el proyecto, hemos configurado la Pico W dentro del mismo Arduino IDE que ya usamos para las placas ESP32 (LILYGO y Heltec). Esto es posible gracias al core no oficial de RP2040 mantenido por Earle F. Philhower, III, con soporte completo para la variante W (WiFi/Bluetooth incluidos, aunque en este banco de pruebas no los usemos todavía).

Pasos de instalación:

1. Archivo → Preferencias → URLs Adicionales de Gestor de Tarjetas, añadir: https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json
2. Herramientas → Placa → Gestor de placas, buscar “pico” e instalar Raspberry Pi Pico/RP2040 (Earle F. Philhower, III).
3. Herramientas → Placa → Raspberry Pi RP2040 Boards → Raspberry Pi Pico W (es importante elegir la variante W, no la Pico estándar, ya que cambia el pin del LED integrado).

⚠️ Diagnóstico de un fallo real: “No drive to deploy”

Como ya es costumbre documentar en esta serie, la primera subida de código no fue directa. Al compilar el primer sketch de prueba, la compilación terminó sin errores:

Sketch uses 312724 bytes (14%) of program storage space.
Global variables use 69584 bytes (26%) of dynamic memory.

Pero la subida falló con este mensaje:

Scanning for RP2040 devices
Failed uploading: uploading error: exit status 1
No drive to deploy.

Diagnóstico: el IDE intentó reiniciar la placa automáticamente a través del puerto serie para meterla en modo bootloader, pero ese reinicio no llegó a completarse a tiempo, por lo que nunca apareció la unidad de almacenamiento RPI-RP2 donde debía copiarse el firmware.

Solución aplicada — modo BOOTSEL manual:

1. Desconectar el cable USB de la Pico W.
2. Mantener pulsado el botón físico BOOTSEL mientras se reconecta el USB, soltándolo un par de segundos después. La placa aparece entonces como una unidad de almacenamiento RPI-RP2.
3. Pulsar “Subir” en el IDE inmediatamente, sin depender ya del reinicio automático.

Con la placa forzada a modo bootloader, la segunda subida sí se completó:

Flashing D: (RPI-RP2)
Wrote 659968 bytes to D:/NEW.UF2

El “pitido” de desconexión que suena justo después es esperable, no un error: en cuanto termina de escribir el firmware, la placa se reinicia sola, sale del modo almacenamiento USB y arranca el sketch recién cargado — por eso Windows la “pierde” como unidad de disco y la “recupera” como un nuevo puerto serie (en nuestro caso, cambió de COM22 a COM23).

✅ Prueba básica: parpadeo de LED y puerto serie

Antes de tocar el sensor, había que confirmar que la placa, el cable y el IDE funcionaban de extremo a extremo. Para ello, un sketch mínimo sin ninguna librería externa:

// BermejaSat - Prueba básica Pico W
// Objetivo: verificar que la placa se detecta, se sube el sketch
// y el puerto serie funciona, antes de conectar ningún sensor.

#define LED_PIN LED_BUILTIN  // en Pico W el LED está gestionado por el chip WiFi (CYW43)

void setup() {
  Serial.begin(115200);
  pinMode(LED_PIN, OUTPUT);
  delay(2000); // tiempo para abrir el monitor serie
  Serial.println("BermejaSat - Pico W activa y funcionando");
}

void loop() {
  digitalWrite(LED_PIN, HIGH);
  Serial.println("LED encendido");
  delay(1000);

  digitalWrite(LED_PIN, LOW);
  Serial.println("LED apagado");
  delay(1000);
}

Tras seleccionar el nuevo puerto (Herramientas → Puerto) y abrir el Monitor Serie a 115200 baudios, el resultado fue el esperado: LED parpadeando físicamente en la placa y los mensajes LED encendido / LED apagado alternándose cada segundo. Banco de pruebas operativo.

🔬 Próximo paso: escáner I2C para confirmar el sensor

Con la placa ya validada, el siguiente paso — siguiendo el mismo método de diagnóstico por descarte que se usó en la entrada #1 con la pantalla OLED — es confirmar que el GY-BM/PM280 responde en el bus I2C antes de escribir ninguna lógica de lectura de presión y temperatura:

#include <Wire.h>

#define SDA_PIN 0
#define SCL_PIN 1

void setup() {
  Serial.begin(115200);
  while (!Serial) delay(10);

  Wire.setSDA(SDA_PIN);
  Wire.setSCL(SCL_PIN);
  Wire.begin();

  Serial.println("Escaner I2C - BermejaSat (banco de pruebas Pico W)");
}

void loop() {
  byte error, address;
  int dispositivos = 0;

  Serial.println("Escaneando...");

  for (address = 1; address < 127; address++) {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0) {
      Serial.print("Dispositivo encontrado en 0x");
      if (address < 16) Serial.print("0");
      Serial.print(address, HEX);

      if (address == 0x76 || address == 0x77) {
        Serial.print("  <-- probable BMP/BME280");
      }
      Serial.println();
      dispositivos++;
    }
  }

  if (dispositivos == 0) {
    Serial.println("No se encontro ningun dispositivo I2C.");
    Serial.println("Revisa: alimentacion VCC, pin CSB al aire, y cableado SDA/SCL.");
  }

  delay(3000);
}

Una vez confirmada la dirección (0x76 o 0x77), el siguiente paso natural será añadir la librería Adafruit_BME280 (o Adafruit_BMP280) para leer presión, temperatura y, si el chip lo soporta, humedad — antes de trasladar ese mismo bloque de lectura al firmware definitivo de la Heltec V3.2.

Conclusión Pedagógica

Este banco de pruebas paralelo ilustra un principio de ingeniería que va más allá del propio CanSat: aislar variables antes de integrar. En lugar de arriesgarse a depurar simultáneamente un sensor nuevo, un chip nuevo (ESP32-S3) y un firmware complejo con OLED, LoRa y GPS, se valida primero el sensor en el entorno más simple posible. Además, el propio proceso de puesta a punto de la Pico W — con su fallo real de subida y su solución mediante el modo BOOTSEL — refuerza la importancia de leer los mensajes de error con calma en lugar de asumir que “no funciona”: casi siempre, el propio log de la herramienta contiene la pista del problema.

---