Technically possible to port ESPHome firmware to Silicon Labs SDK for EFR32 Mighty Gecko MCU family as a new platform?

[Hedda]

Describe your idea

Seeing how ESPHome has already or am in the process of being ported to Nordic Semiconductor NRF52 and STM32 MCUs as supported platforms, as well as having previous platform ports for Raspberry Pi RP2040, Realtek RTL87xx, and Beken BK72xx MCU chips.

Therefore wondering if it would also technically possible to port ESPHome firmware Silicon Labs SDK for EFR32 Mighty Gecko MCU family as a new platform?

• https://www.silabs.com/wireless/technology

While ESPHome currently lacks native support for Silicon Labs chips, it has successfully transitioned from being ESP328266 and ESP32-exclusive to supporting other platforms.

Specifically it would be interesting to see if it could be supported on EFR32MG (Wireless Gecko Series 2) series with EFR32MG24, EFR32MG26. EFR32MG28 and series of MCUs from Silabs which focus on low-power wireless communication (with Bluetooth, Zigbee, and Thread radios):

• https://www.silabs.com/wireless/gecko-series-2

Silabs of course also have EFR32FG, EFR32PG, and EFR32GG series too which have other focus areas.

• http://silabs.com/mcu/32-bit-microcontrollers

Why is this exciting?

Many embedded developers have experience with Silicon Labs + Silicon Labs is top supplier and leader design of low-power non-WiFi wireless SoC chips for major ecosystems so supporting so ESPHome could potentially gain more developers if it supported EFR32 Mighty Gecko series of MCUs.

Having a port of ESPHome to Silicon Labs's “EFR32 platform” is exciting prospect to ESPHome because it could attract additional developers that normally work with Silicon Labs hardware.

Anyway, I do not have the skills myself and understand that porting would require a significant time investment and engineering effort to bridge the ESPHome framework with the Silicon Labs SDK, however hopefully the challange and potential gain of broadening ESPHome userbase could sound like an interesting to volunteering developers.

Potential use cases

Could allow to run ESPHome on existing and future hardware products based on a EFR32MG24, EFR32FG25, EFR32MG26, or EFR32MG28 SoCs.

Silabs SoC often specialize in low-power design that still have many resources which could enable powerful battery-operated devices.

Anything else?

Nabu Casa (the primary backers of Home Assistant and ESPHome) have a history of collaboration with Silicon Labs for their Home Assistant branded hardware so curious if there could be a collaborative path for future open-source development with Silabs?

Other than time and skill I belöieve the primary difficulty woul lie in the proprietary and closed nature of certain radio drivers, protocol stacks, or the complexity of integrating Silicon Labs' specialized toolchains into the ESPHome build system.

[ssieb]

They don't have enough RAM and not really enough flash either.

[Hedda]

They don't have enough RAM and not really enough flash either.

Do they not?

ESPHome resource requirements vary by device and config, but what are minimum vs. average RAM / Flash Storage requirements for projects?

Yes I understand that if you have more RAM and more Flash Storage then you can make more complex projects, but to compare apples to apples it would be more fair to compare EFR32 models with EFR32-H2, ESP32-H21, and EFR32-H4 for making ultra-low-power devices.

Anyway, please note that are many different SKUs (models) with various specifications, and as an example EFR32MG26 Series 2 features up to 512kB SRAM and 3200kB Flash, which is more flash and about the same amount of RAM as ESP32-S3, ESP32-C3, and ESP32-C6.

• https://www.silabs.com/wireless/zigbee/efr32mg26-series-2-socs

Then there is also the brand new Silicon Labs Series 3 Wireless Platform which currently has SKUs with up to 4MB Flash and 512kB of RAM:

• https://www.silabs.com/wireless/series-3-wireless-platform

  • https://www.silabs.com/wireless/zigbee/simg301-series-3-socs

Even the older EFR32MG24 has SKUs that features up to 1536kB flash program memory + up to 256kB RAM data memory, and that is at least a lot more than ESP8266 which is also still supported by ESPHome.

[ssieb]

I didn't see ones with that much, so that's maybe possible. But comparing to 8266 is not helpful. That's barely supported.
But anyway, you'll either need to do it yourself or find someone to do it. It's not going to be a project priority.

[Hedda]

comparing to 8266 is not helpful. That's barely supported.

Just read ESPHome 2026.1.0 changelog which state that ESHome now have loads of related performance optimizations that greatly reduce both needed RAM and storage:

• https://esphome.io/changelog/2026.1.0/

"Months of performance optimization work culminates here: heap churn reduction plus allocator work enabled moving heap functions from IRAM to flash (saving ~6KB of IRAM on ESP32), removing object_id storage from RAM saves hundreds to thousands of bytes, zero-copy API support delivers ~42% more entities per packet, and ESP32 camera streaming improves by ~10% with lower latency. These optimizations translate directly into headroom for existing devices and reliability for years to come."

So, while ESPHome developers used to advise users not to use ESP8266, not because it was not suitable for the task, but because the runtime heap on ESP8266 routinely dropped below 10k, and devices were unreliable. Since millions of ESP8266 devices were already deployed in homes, they decided to do something about it. The project has been greatly helped thanks to increased support from the [Open Home Foundation, which allows the project to have two full-time developers and a broader base of part-time contributors, and after months of work, the available heap increased from under 10k to over 30k in realistic configurations on ESP8266. The work also involved ESP32, ESP32-C3, ESP32-S2, and ESP32-S3 SoCs, as all moved to the ESP-IDF by default (instead of Arduino), delivering up to 40% smaller binaries and 2 to 3 times faster compile times. ESP32 RAM usage is also much lower thanks to a range of optimizations, and zero-copy API enables ESP32 camera streaming with about 10% lower latency.

But anyway, you'll either need to do it yourself or find someone to do it. It's not going to be a project priority.

I know, it was just a question about technical feasibility and possible practical limitations or other showstoppers that would hinder a port.

Again, I am just asking if there are technical barriers preventing someone skilled enough to porting ESPHome to Silabs EFR32 MCUs.

Regardless, best to not say never as can not predict the future.

[clydebarrow]

I've used Gecko devices in the past and been able to stuff a lot of code into them. They have a lot of nice features.

There is no technical barrier to adopting it into ESPHome, just needs someone to spend the time on it.