🛠 Nœud IoT de datalogging : capteurs sur le M4, stockage et transport en conteneur

Objetivos

El caso de uso de firma de la X8, documentado por el tutorial oficial datalogging-iot: los sensores se conectan del lado del MCU (el STM32H747 expone del lado de Arduino 8 entradas ADC con VREF separado, 3 SPI, 4 salidas PWM, 7 GPIO — además de los 3 ADC/2 DAC/comparadores y RNG del SoC), y el contenedor Docker del lado de Linux se encarga del almacenamiento, la cola de espera y la transmisión (MQTT/HTTP). Separación de responsabilidades: el tiempo real y lo analógico en el M4, la memoria (2 GB LPDDR4, 16 GB eMMC), la red y las librerías modernas en el A53.

Hardware

• 1 × Arduino Portenta X8 + placa base (Breakout/Max Carrier) para acceder a los pines del sensor
• 1 × sensor analógico (sonda, potenciómetro) en una entrada ADC del lado M4, o sensor digital en SPI/I²C
• Red IP activa (tutorial de red) para la transmisión
• Core «Arduino Mbed OS Portenta Boards» + adb
• Un broker MQTT de prueba (o un simple servidor HTTP) en la LAN

Código completo

// capteur_m4.ino — acquisition sur le M4, exposition RPC au conteneur
#include "SerialRPC.h"
#include "RPC.h"

const int BROCHE_CAPTEUR = A0;   // > 

// Le conteneur Linux appelle cette fonction a son rythme d'echantillonnage
int readSensor {
  long somme = 0;
  for (int i = 0; i < 16; i++) { somme += analogRead(BROCHE_CAPTEUR); }
  return (int)(somme / 16);      // moyenne de 16 lectures
}

void setup {
  Serial.begin(115200);
  RPC.bind("readSensor", readSensor);
}

void loop { delay(50); }

# Cote Linux : un conteneur de logging qui appelle readSensor via le
# broker m4-proxy (5001), journalise sur l'eMMC et publie en MQTT.
# Image de depart officielle pour le pont Python<->M4 :
docker run -d --name logger \
  --restart unless-stopped \
  -p 5002-5020:5002-5020 \
  -v /home/fio/logs:/data \
  --device /dev/ttyGS0 \
  arduino/python-rpc-serial
# > 
# (lecture RPC + file + MQTT) — reproduis-le depuis le tuto officiel.

Verificación esperada

El contenedor llama a readSensor a intervalos regulares, los valores aparecen en el registro en la eMMC (carpeta montada desde el host) y llegan al broker MQTT. La ventaja de esta configuración: el M4 no conoce ni TCP ni JSON — expone una función; todo lo demás (bufferización durante cortes de red, TLS, formatos) reside en el contenedor, reemplazable y actualizable vía OTA sin tocar el firmware.

Errores frecuentes

• Ejecutar la pila de red completa en el M4: es posible pero contraproducente en la X8 — el diseño oficial coloca la transmisión del lado de Linux; el M4 permanece como un dispositivo de E/S de tiempo real.
• readSensor que bloquea: una llamada RPC debe ser breve; si promedias sobre 10 000 muestras, la llamada Python espera y el watchdog del contenedor puede alertar.
• Pérdida de datos durante cortes: el --restart unless-stopped reinicia el contenedor, pero solo una cola de espera persistida en la eMMC (archivo, SQLite) sobrevive a los reinicios — no te conformes con un buffer en memoria.
• Confundir los ADC: la tabla de la hoja de datos de la X8 (8 entradas ADC con VREF separado del lado M4) no corresponde al pinout completo del STM32H747 — cablea según la placa base y la página de pinout, no según una ficha del SoC.
• Alimentación de los sensores: los pines de la placa son de 3,3 V, 8 mA máx. por pin — un sensor de 5 V o de alto consumo requiere una etapa de nivel/traslación, nunca conexión directa.
• >
• >