Entre los ingenieros que construyen pasarelas LoRaWAN, muchos provienen del mundo STM32 y muchos del mundo ESP de Espressif. A la hora de elegir el procesador anfitrión, el debate es casi inevitable: el STM32H7 funciona a 480 MHz con un CoreMark superior a 2,000, una clara ventaja en rendimiento bruto. El ESP32-S3 parece más débil sobre el papel, pero en los últimos años se ha convertido en una opción popular para diseños de pasarelas IoT, incluida la pasarela de código abierto GD6 de ManThink.

Este artículo desglosa la cuestión. La respuesta breve: no se trata de "qué chip es más potente", sino de "qué chip encaja con la carga de trabajo de la pasarela". En el caso concreto de una pasarela, la arquitectura del ESP32-S3 cae justo en el punto óptimo de los requisitos, mientras que gran parte de la potencia de cómputo del STM32 queda sin usar, y lo que le falta al STM32 (conectividad inalámbrica) hay que recuperarlo con coste de BOM y complejidad de diseño.

1. Primero, entender: ¿qué hace realmente el anfitrión de una pasarela?

Gran parte del debate de selección surge de una lectura errónea del perfil de tareas del anfitrión de la pasarela. Abramos una pasarela LoRaWAN:

La capa física LoRa no es tarea del anfitrión. Demodular señales SF7–SF12, monitorizar canales de frecuencia 8, procesar canales de demodulación paralelos 16: todo eso lo hace el chip concentrador (SX1301/SX1302). El concentrador entrega al anfitrión paquetes ya demodulados por SPI. Lo que el anfitrión recibe del bus SPI no son muestras de RF, sino tramas JSON/binarias estructuradas.

Así que el papel real del anfitrión de la pasarela es el de un "procesador de red", no el de un "controlador en tiempo real":

• Reenvío de protocolos: encapsular paquetes LoRa en tramas Semtech UDP, MQTT Bridge o Basic Station hacia el servidor de red, y la ruta inversa
• Comunicación TLS: una conexión Basic Station wss:// y MQTT sobre TLS requieren ambos handshakes TLS completos y cifrado/descifrado
• Consola web: una pasarela moderna (como el sistema gwTool6 del GD6) ejecuta un servidor HTTP que sirve páginas de configuración, vistas de estado y gestión de firmware
• Gestión de configuración: mantener el sistema de archivos SPIFFS con persistencia segura ante cortes de alimentación
• Actualizaciones OTA: verificación y conmutación de firmware con particiones A/B
• Gestión de enlaces: conmutación por prioridad entre enlaces de backhaul Ethernet, Wi-Fi y 4G

El perfil de esta carga de trabajo: densa en conexiones, ávida de búferes, con rendimiento a ráfagas, pero sin plazos estrictos de tiempo real. Sin control de motores, sin precisión PWM a nivel de microsegundos; el requisito más "de tiempo real" es simplemente "no dejar que la cola SPI se desborde". Una vez entendido esto, todas las comparaciones siguientes encajan.

2. ESP32-S3 de un vistazo

Estas son las especificaciones clave (fuente: hoja de datos oficial de Espressif):

Solo en cómputo bruto de CPU, ciertamente está por detrás del STM32H7 (Cortex-M7 @480 MHz, CoreMark 2020 @400 MHz). Pero fíjate en tres cosas que el STM32H7 no tiene: una banda base Wi-Fi integrada, una interfaz PSRAM Octal de alto ancho de banda y un ecosistema gratuito de pilas de protocolos construido en torno a ambas.

3. Cinco razones decisivas

Razón 1: Wi-Fi integrado, con AP + STA simultáneos

Esto es lo que más pesa en escenarios de pasarela.

Ningún STM32 tiene Wi-Fi. Construir una pasarela con backhaul Wi-Fi sobre STM32 implica un módulo Wi-Fi externo, normalmente un módulo de comandos AT o SPI. Eso implica: coste de BOM adicional, complejidad de firmware adicional (las máquinas de estados de comandos AT son notoriamente frágiles), rendimiento limitado por la interfaz del módulo y TLS que solo puede ejecutarse o bien dentro del módulo (perdiendo el control de la gestión de claves) o bien en el MCU principal (pagando de nuevo el coste de rendimiento).

El Wi-Fi del ESP32-S3 es una banda base integrada y admite modo concurrente Station + SoftAP. La pasarela GD6 aprovecha esta capacidad al máximo:

• Modo STA se conecta al Wi-Fi del sitio como uno de los enlaces de backhaul
• Modo AP emite simultáneamente el GD6-<Gateway EUI> punto de acceso (contraseña por defecto lgw12345678); un administrador se conecta a él y accede a la consola web en 192.168.4.1

El punto clave de este diseño: el canal de gestión AP es independiente del enlace de backhaul. Aunque Ethernet caiga, el Wi-Fi STA no pueda conectar y la SIM 4G se quede sin datos, el administrador siempre puede unirse al punto de acceso y diagnosticar localmente. Replicar esto en STM32 requiere un módulo Wi-Fi independiente con capacidad AP, con el coste y la complejidad añadidos de nuevo.

Razón 2: PSRAM Octal: el verdadero cuello de botella de la pasarela es la memoria, no el cómputo

Vuelve al perfil de carga de trabajo de la sección 1: sesiones TLS, conexiones MQTT duales (datos + configuración remota), solicitudes concurrentes de la consola web, almacenamiento en búfer de paquetes LoRa bajo alta carga de canal: todas son cargas intensivas en búferes de memoria .

Los 512 KB de SRAM integrada del ESP32-S3 no bastan para ejecutar un servidor web con seguridad TLS, pero tiene la interfaz PSRAM SPI Octal: el módulo ESP32-S3-WROOM-1 N8R8 usado en el GD6 lleva 8 MB de PSRAM Octal funcionando a 80 MHz — suficiente para sostener el almacenamiento en búfer de datos bajo alta carga y solicitudes web concurrentes. Añada la flash QIO de 8 MB (que aloja particiones de firmware dual A/B + SPIFFS + recursos estáticos web), y esta configuración de memoria se ajusta a la carga de trabajo de la puerta de enlace con margen.

¿Y el STM32H7? Su SRAM máxima en chip es de 1 MB — menor que la memoria total utilizable del ESP32-S3. Igualar la misma capacidad requiere SDRAM externa sobre FMC, lo que conlleva trabajo de ingeniería adicional en enrutamiento de bus, ajuste de temporización e integridad de potencia. Para una carga de trabajo de "procesador de red", esa arquitectura de memoria determinista de alto ancho de banda es excesiva.

Razón 3: división de tareas en doble núcleo — la pila de protocolos y la lógica de aplicación se desacoplan de forma natural

Una propiedad del ESP32-S3 de doble núcleo LX7 que funciona muy bien para puertas de enlace: la pila de protocolos Wi-Fi puede fijarse al núcleo 0 mientras la lógica de aplicación se ejecuta en el núcleo 1. La carga a ráfagas de la pila de red (negociaciones TLS, eventos del controlador Wi-Fi) nunca interrumpe el bucle de recepción SPI del lado de la aplicación ni los servicios web.

Las partes STM32H7 de doble núcleo (H745/H747: M7 + M4) pueden hacer una división similar, pero eso implica dos núcleos diferentes, dos imágenes de firmware y una comunicación entre núcleos que usted mismo construye bajo una arquitectura AMP; la planificación SMP de ESP-IDF es "escriba código FreeRTOS normal y el sistema asigna los núcleos automáticamente" — una brecha clara en la experiencia de desarrollo.

Razón 4: los periféricos de seguridad cubren las necesidades de actualización y autenticación de la puerta de enlace

Para un dispositivo que está en red y es actualizable de forma remota, la seguridad no es opcional. Las unidades de seguridad por hardware del ESP32-S3 se ajustan con precisión a este escenario:

• Arranque seguro RSA: el peor fallo de una OTA A/B es flashear firmware manipulado; el arranque seguro garantiza que solo se ejecute firmware firmado
• Cifrado de flash AES-XTS: las direcciones de servidor, los certificados y los tokens en la configuración de la puerta de enlace se almacenan cifrados
• Periféricos HMAC / firma digital: los escenarios de certificado de cliente en TLS mutuo de Basic Station obtienen protección de claves a nivel de hardware

El STM32H7 también tiene periféricos CRYP/HASH con capacidad equivalente. Este punto es un empate, no una ventaja de ESP32-S3 — pero combinado con el factor de ecosistema a continuación, el coste de configuración del arranque seguro del ESP32-S3 es menor (marque casillas y grabe claves en menuconfig; el flujo de ST requiere el proceso de instalación de firmware seguro SFI).

Razón 5: ecosistema y coste — que importan aún más para una puerta de enlace de código abierto

• ESP-IDF es gratuito y completo: controlador Wi-Fi, lwIP, mbedTLS, esp_http_server, componentes OTA listos para usar. Compárese con STM32: CubeMX + FreeRTOS + lwIP + mbedTLS + un controlador de módulo Wi-Fi externo — cada capa ensamblada a mano
• Soporte de PlatformIO / Arduino: el repositorio de código abierto del GD6 está dirigido a desarrolladores de la comunidad; cuanto menor sea la barrera, más contribuyentes
• Coste del módulo: el ESP32-S3-WROOM-1 N8R8 es un módulo completo con certificación FCC/CE con RF preajustada, con un precio en el rango de un solo dígito en dólares; un chip desnudo STM32H7 + PHY Ethernet + módulo Wi-Fi juntos cuestan varias veces más — y además usted mismo tiene que pasar la certificación RF
• Tamaño de la comunidad: la comunidad global de ESP32 y el volumen de documentación son decisivos para el arranque en frío de un proyecto de código abierto

Para productos comerciales, la diferencia de coste se multiplica con el volumen; para proyectos de código abierto, la diferencia de ecosistema decide si el proyecto sobrevive siquiera. El GD6 necesita ambas cosas, y el ESP32-S3 es la intersección natural.

4. Para ser justos: dónde sigue ganando STM32

Este artículo no dice "STM32 es malo". Enumerar los escenarios irremplazables de STM32 completa el marco de selección:

1. Determinismo de tiempo real estricto: control de motores, movimiento multieje, PWM a nivel de microsegundos — la ejecución determinista del Cortex-M7 (código en RAM ITCM, sin fluctuación de caché) es algo que la arquitectura Xtensa + PSRAM externa no puede ofrecer. El ESP32-S3 que obtiene código de la PSRAM tiene picos de latencia por fallos de caché.
2. Temperaturas extremas: la familia STM32H7 es de -40 a 85 °C, con temperaturas de unión de hasta 125 °C en algunas partes; el grado estándar ESP32-S3 es de -40 a 85 °C, pero los modelos con PSRAM Octal integrada están limitados a 65 °C (una característica de la PSRAM) — atención a los armarios exteriores y a las líneas de producción calientes: elija la variante sin PSRAM o proporcione una disipación de calor adecuada.
3. Ciclos de suministro ultralargos: ST ofrece compromisos explícitos de disponibilidad de 10+ años para STM32, que los proyectos industriales y automotrices utilizan para garantías de ciclo de vida. Espressif también asume compromisos de suministro a largo plazo (el ESP32-S3 está en la lista de suministro a largo plazo de Espressif), pero como empresa procedente del mercado de consumo, la confianza en la adquisición industrial de ciclo ultralargo todavía se inclina hacia ST.
4. Buses industriales: EtherCAT, CAN FD, Profinet — ST tiene soluciones y certificaciones listas. El ESP32-S3 tiene TWAI (CAN 2.0) pero no pilas de bus de campo industrial de capas superiores.
5. Precisión analógica: los ADC de 16 bits y los temporizadores de alta resolución del STM32H7 sitúan la precisión y las cifras de ruido del ADC SAR del ESP32-S3 en otra clase.

En una frase: una puerta de enlace es un "dispositivo de conectividad", no un "dispositivo de control". Si su producto controla motores, muestrea señales analógicas de precisión o funciona por encima de 85 °C, el STM32 es la respuesta correcta. Si su producto reenvía datos, termina TLS y sirve páginas web, pagar por esas capacidades no utilizadas es un desperdicio.

5. El ejemplo GD6: arquitectura construida en torno al ESP32-S3

En el diseño de código abierto GD6 (serie GD61x), varias prácticas muestran este pensamiento de "jugar con las fortalezas":

W5500 descarga Ethernet de la CPU. El Ethernet del GD6 no ejecuta una pila de software sobre el SPI del ESP32-S3; utiliza el chip de pila TCP/IP por hardware W5500: el procesamiento del protocolo Ethernet se completa dentro del chip, sin consumir CPU del host. La capacidad de cómputo del host queda para el procesamiento de datos LoRa y los servicios web. Es un diseño inteligente, nacido de saber que el cómputo bruto no es su punto fuerte.

Tres enlaces de backhaul, cada uno con su propia función. Ethernet (W5500) > Wi-Fi STA (en el chip) > 4G (módulo miniPCIe Cat 1) con conmutación automática de prioridad; incluso cuando un enlace falla, el canal de gestión sigue siendo accesible a través del AP Wi-Fi.

8 MB de flash con particionado A/B. Dos imágenes de firmware completas + región de configuración SPIFFS + recursos estáticos web, con reversión automática en caso de fallo de actualización: un requisito imprescindible para gateways desplegados sin supervisión en sitios remotos, y la razón por la que no se puede recortar la capacidad de flash.

Merece la pena mencionar el grupo de control. La línea de gateways comerciales de ManThink (GDI51/GDO51) utiliza el LS1012A (Cortex-A53 @800 MHz ejecutando Linux embebido con un ThinkLink Edge NS integrado), una arquitectura de "gateway como servidor" en la que el host ejecuta un NS completo y una plataforma de aplicaciones, una carga de trabajo completamente distinta. Dentro de la misma empresa, el gateway ligero de código abierto elige el ESP32-S3 mientras que el gateway de servidor de borde elige un SoC Linux Cortex-A, lo que confirma precisamente el tema de este artículo: la selección del host sigue a la carga de trabajo; no hay una respuesta universal.

6. Un marco de selección: tres preguntas

Condensando todo en tres preguntas prácticas:

Pregunta 1: ¿Tu dispositivo "conecta" o "controla"? Reenviar datos de protocolo, ejecutar web/TLS/MQTT → tipo conectividad, alta idoneidad de ESP32-S3; controlar motores / muestrear analógico de precisión / tiempo real de microsegundos → tipo control, elegir STM32.

Pregunta 2: ¿Es la inalámbrica un requisito o un lujo? Necesitas backhaul Wi-Fi o aprovisionamiento por Wi-Fi → resuelto en el chip con ESP32-S3; Ethernet puro sin necesidades inalámbricas nunca → la brecha con STM32 se reduce, pero los costes de expansión de memoria y de ecosistema permanecen.

Pregunta 3: ¿Cuánto dura el proyecto y a qué temperatura? Compromiso de disponibilidad de 10+ años, -40 a 105 °C → STM32 (o simplemente una solución Linux Cortex-A); ciclos y temperaturas comerciales normales → el ESP32-S3 lo maneja con facilidad, solo hay que tener en cuenta el límite de 65 °C de las variantes con PSRAM integrada.

Si las tres respuestas apuntan a "conectividad", el ESP32-S3 es una de las respuestas de menor coste total en el ecosistema actual; si apuntan a "control", no lo dudes: vuelve a STM32.

Conclusión

Volviendo a la pregunta inicial: ¿qué le ganó al ESP32-S3 su lugar en los gateways IoT? Reúne las tres cosas que más necesita un gateway —conectividad inalámbrica, grandes búferes de memoria y una pila de red madura— en un módulo de un solo dígito de dólares al menor coste de integración; y el cómputo bruto que le falta es exactamente la parte que un gateway no utiliza.

La sabiduría de la selección de chips nunca ha sido elegir el chip más potente, sino elegir el que desperdicia menos.

Lecturas de la serie

• Número 1: Activación LoRaWAN explicada: OTAA vs ABP — Cómo elegir
• Número 2: ADR de LoRaWAN explicado: Quién controla la tasa de datos
• Número 3: Parámetros regionales de LoRaWAN: Por qué CN470 y EU868 difieren en el número de canales
• Número 4: Parámetros de la capa física de LoRa: Cómo SF, BW y CR determinan el alcance y el rendimiento
• Número 5: Clases de dispositivo LoRaWAN (A/B/C) comparadas: Casos de uso
• Número 6: Semtech SX1301 vs SX1302 vs SX1303: Evolución de los chips concentradores
• Serie GD6: Descripción general del producto / Diseño de hardware / Inicio rápido de código abierto / Despliegue en la práctica / Casos de uso y selección

Fuentes de datos: hoja de datos oficial de Espressif ESP32-S3 (v2.0), páginas de producto oficiales de ST STM32H7, biblioteca de documentación ThinkLink MCP (especificación y guía de usuario GD61x). El análisis de ingeniería de la selección del host del GD6 es una inferencia basada en especificaciones públicas; la documentación oficial de ManThink no revela por completo las decisiones internas de selección.