Among engineers building LoRaWAN gateways, plenty come from the STM32 world, and plenty come from the Espressif ESP world. When it's time to pick the host processor, the debate is almost inevitable: the STM32H7 runs at 480 MHz with a CoreMark above 2,000 — a clear win on raw performance. The ESP32-S3 looks weaker on paper, yet it has become a popular choice for IoT gateway designs in recent years — including ManThink's GD6 open-source gateway.

This article breaks the question down. The short answer: it's not a question of "which chip is more powerful," but "which chip matches the gateway's workload." In the specific case of a gateway, the ESP32-S3's architecture lands squarely on the sweet spot of the requirements, while much of the STM32's compute power goes unused — and the thing the STM32 lacks (wireless connectivity) has to be bought back with BOM cost and design complexity.

1. First, Understand: What Does a Gateway Host Actually Do?

Much of the selection debate stems from a misread of the gateway host's task profile. Open up a LoRaWAN gateway:

The LoRa physical layer is not the host's job. Demodulating SF7–SF12 signals, monitoring 8 frequency channels, processing 16 parallel demodulation channels — all of that is done by the concentrator chip (SX1301/SX1302). The concentrator hands already-demodulated packets to the host over SPI. What the host receives from the SPI bus is not RF samples; it's structured JSON/binary frames.

So the gateway host's real role is that of a "network processor," not a "real-time controller":

The profile of this workload: connection-dense, buffer-hungry, bursty throughput — but with no hard real-time deadlines. No motor control, no microsecond-level PWM precision; the most "real-time" requirement is simply "don't let the SPI queue overflow." Once this is understood, every comparison below falls into place.

2. ESP32-S3 at a Glance

Here are the key specifications (source: Espressif official datasheet):

Item Specification
CPU Xtensa 32-bit LX7 dual-core, up to 240 MHz
CoreMark 1329.92 dual-core (5.54 CoreMark/MHz)
On-chip SRAM 512 KB (plus 384 KB ROM)
Wireless 2.4 GHz Wi-Fi (802.11 b/g/n) + Bluetooth 5 LE
GPIO 45 programmable GPIOs
External memory Quad/Octal SPI flash and PSRAM, up to 32 MB mappable
Instruction extensions 128-bit SIMD vector instructions + single-precision FPU
Security RSA secure boot, AES-XTS flash encryption, HMAC, digital signature peripheral
Interfaces 3×UART, 2×I2C, 2×SPI (plus 2 general-purpose SPI), USB OTG, TWAI (CAN), SD/MMC
Deep sleep ~7 µA (RTC domain retained)

On raw CPU compute alone, it is indeed behind the STM32H7 (Cortex-M7 @480 MHz, CoreMark 2020 @400 MHz). But note three things the STM32H7 doesn't have: an on-chip Wi-Fi baseband, a high-bandwidth Octal PSRAM interface, and a free protocol-stack ecosystem built around both.

3. Five Decisive Reasons

Reason 1: Integrated Wi-Fi — with AP + STA concurrently

This carries the most weight in gateway scenarios.

No STM32 has Wi-Fi. Building a Wi-Fi-backhauled gateway on STM32 means an external Wi-Fi module — typically an AT-command or SPI module. That implies: extra BOM cost, extra firmware complexity (AT-command state machines are notoriously fragile), throughput limited by the module interface, and TLS that can only run either inside the module (losing key management control) or on the main MCU (paying the performance cost again).

The ESP32-S3's Wi-Fi is an on-chip baseband, and it supports Station + SoftAP concurrent mode. The GD6 gateway uses this capability to the fullest:

The key point of this design: the AP management channel is independent of the backhaul link. Even if Ethernet drops, the Wi-Fi STA can't connect, and the 4G SIM runs out of data, the administrator can always join the hotspot and troubleshoot locally. Replicating this on STM32 requires a separate AP-capable Wi-Fi module — with cost and complexity added back.

Reason 2: Octal PSRAM — the gateway's real bottleneck is memory, not compute

Look back at the workload profile in Section 1: TLS sessions, dual MQTT connections (data + remote configuration), concurrent web console requests, LoRa packet buffering under high channel load — these are all memory-buffer-heavy loads.

The ESP32-S3's 512 KB of on-chip SRAM is not enough to run a TLS-secured web server, but it has the Octal SPI PSRAM interface: the ESP32-S3-WROOM-1 N8R8 module used in the GD6 carries 8 MB of Octal PSRAM running at 80 MHz — enough to sustain data buffering under high load and concurrent web requests. Add the 8 MB QIO flash (holding A/B dual firmware partitions + SPIFFS + web static assets), and this memory configuration fits the gateway workload with margin.

And the STM32H7? Its maximum on-chip SRAM is 1 MB — smaller than the ESP32-S3's total usable memory. Matching the same capacity requires external SDRAM over FMC, which brings additional engineering work in bus routing, timing tuning, and power integrity. For a "network processor" workload, that high-bandwidth deterministic memory architecture is overkill.

Reason 3: Dual-core task split — protocol stack and application logic decouple naturally

A property of the ESP32-S3's dual-core LX7 that works very well for gateways: the Wi-Fi protocol stack can be pinned to Core 0 while application logic runs on Core 1. Bursty network-stack load (TLS handshakes, Wi-Fi driver events) never interrupts the application-side SPI receive loop or web services.

The dual-core STM32H7 parts (H745/H747: M7 + M4) can do a similar split, but that means two different cores, two firmware images, and inter-core communication you build yourself under an AMP architecture; ESP-IDF's SMP scheduling is "write ordinary FreeRTOS code, and the system assigns cores automatically" — a clear gap in development experience.

Reason 4: Security peripherals cover the gateway's update and authentication needs

For a device that's networked and remotely upgradable, security is not optional. The ESP32-S3's hardware security units map precisely onto this scenario:

The STM32H7 also has CRYP/HASH peripherals with equivalent capability. This one is a tie, not an ESP32-S3 advantage — but combined with the ecosystem factor below, the ESP32-S3's secure boot setup cost is lower (check boxes and burn keys in menuconfig; ST's flow requires the SFI secure firmware installation process).

Reason 5: Ecosystem and cost — which matters even more for an open-source gateway

For commercial products, the cost difference multiplies with volume; for open-source projects, the ecosystem difference decides whether the project survives at all. The GD6 needs both, and the ESP32-S3 is the natural intersection.

4. To Be Fair: Where STM32 Still Wins

This article is not "STM32 is bad." Listing the irreplaceable STM32 scenarios makes the selection framework complete:

  1. Hard real-time determinism: motor control, multi-axis motion, microsecond-level PWM — the Cortex-M7's deterministic execution (code in ITCM RAM, no cache jitter) is something the Xtensa + external PSRAM architecture cannot deliver. The ESP32-S3 fetching code from PSRAM has cache-miss latency spikes.
  2. Extreme temperatures: the STM32H7 family is -40 to 85°C, with junction temperatures up to 125°C on some parts; the ESP32-S3 standard grade is -40 to 85°C, but models with integrated Octal PSRAM are limited to 65°C (a PSRAM characteristic) — watch out for outdoor cabinets and hot production lines: choose the non-PSRAM variant or provide adequate heat dissipation.
  3. Ultra-long supply cycles: ST offers explicit 10+ year availability commitments for STM32, which industrial and automotive projects use for lifecycle guarantees. Espressif also makes long-term supply commitments (the ESP32-S3 is on Espressif's long-term supply list), but as a company from the consumer market, trust in ultra-long-cycle industrial procurement still tilts toward ST.
  4. Industrial buses: EtherCAT, CAN FD, Profinet — ST has ready-made solutions and certifications. The ESP32-S3 has TWAI (CAN 2.0) but no higher-layer industrial fieldbus stacks.
  5. Analog precision: the STM32H7's 16-bit ADCs and high-resolution timers put the ESP32-S3's SAR ADC accuracy and noise figures in a different class.

One sentence: a gateway is a "connectivity device," not a "control device." If your product controls motors, samples precision analog signals, or lives above 85°C, the STM32 is the right answer. If your product forwards data, terminates TLS, and serves web pages, paying for those unused capabilities is waste.

5. The GD6 Example: Architecture Built Around the ESP32-S3

In the GD6 (GD61x series) open-source design, several practices show this "play to strengths" thinking:

W5500 offloads Ethernet from the CPU. The GD6's Ethernet doesn't run a software stack over the ESP32-S3's SPI; it uses the W5500 hardware TCP/IP stack chip — Ethernet protocol processing completes inside the chip, consuming no host CPU. The host's compute is left for LoRa data processing and web services. It's smart design born of knowing raw compute isn't the strong suit.

Three backhaul links, each with its own role. Ethernet (W5500) > Wi-Fi STA (on-chip) > 4G (miniPCIe Cat 1 module) with automatic priority switching; even when a link fails, the management channel remains reachable through the Wi-Fi AP.

8 MB flash with A/B partitioning. Two complete firmware images + SPIFFS configuration region + web static assets, with automatic rollback on upgrade failure — a hard requirement for gateways deployed unattended at remote sites, and the reason flash capacity can't be trimmed.

Worth mentioning is the control group. ManThink's commercial gateway line (GDI51/GDO51) uses the LS1012A (Cortex-A53 @800 MHz running embedded Linux with a built-in ThinkLink Edge NS) — a "gateway-as-server" architecture where the host runs a full NS and application platform, a completely different workload. Within the same company, the lightweight open-source gateway picks the ESP32-S3 while the edge-server gateway picks a Cortex-A Linux SoC — which precisely confirms this article's theme: host selection follows the workload; there is no universal answer.

6. A Selection Framework: Three Questions

Condensing everything into three actionable questions:

Question 1: Is your device "connecting" or "controlling"? Forwarding protocol data, running web/TLS/MQTT → connectivity-type, high ESP32-S3 fit; controlling motors / sampling precision analog / microsecond real-time → control-type, choose STM32.

Question 2: Is wireless a requirement or a luxury? Need Wi-Fi backhaul or Wi-Fi provisioning → solved on-chip with ESP32-S3; pure Ethernet with no wireless needs ever → the STM32 gap narrows, but memory expansion and ecosystem costs remain.

Question 3: How long does the project live, and at what temperature? 10+ year availability commitment, -40 to 105°C → STM32 (or simply a Cortex-A Linux solution); normal commercial cycles and temperatures → the ESP32-S3 handles it with ease — just mind the 65°C limit of PSRAM-integrated variants.

If all three answers point to "connectivity," the ESP32-S3 is one of the lowest total-cost answers in today's ecosystem; if they point to "control," don't hesitate — go back to STM32.

Conclusion

Back to the opening question: what earned the ESP32-S3 its place in IoT gateways? It packs the three things a gateway needs most — wireless connectivity, large memory buffers, and a mature network stack — into a single-digit-dollar module at the lowest integration cost; and the raw compute it lacks is exactly the part a gateway doesn't use.

The wisdom of chip selection has never been picking the strongest chip, but picking the one that wastes the least.

Series Reading

Data sources: Espressif ESP32-S3 official datasheet (v2.0), ST STM32H7 official product pages, ThinkLink MCP documentation library (GD61x specification and user guide). The engineering analysis of the GD6's host selection is inference based on public specifications; ManThink's official documentation does not fully disclose internal selection decisions.