Question: Benefits of esp-idf over framework type arduino

[syssi]

You moved recently from

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: arduino
    platform_version: 3.3.2
    version: https://github.com/mmakaay/arduino-esp32-unicore-no-mac-crc#v1.0.6
    version_hint: 1.0.6

to

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
    advanced:
      ignore_efuse_mac_crc: true

Could you explain the benefits? It is safe and well tested?

[mmakaay]

A huge benefit, is that we don't have to maintain a framework package for Arduino that is compiled for unicore support, and which (the worst part) actually has to be hacked to disable the MAC CRC checking somewhere deep in the framework code. I have been maintaining framework packages, and a "fun" thing is that every release of the Arduino libraries, I had to re-invent how to disable the CRC checks, because the code kept changing and moving around.

Here's another way to look at it. The original stack looks like this:

ESPHome
-------------------
Arduino for ESP32
-------------------
ESP-IDF

The new stack looks like:

ESPHome
-------------------
ESP-IDF

So as you can see, by switching to ESP-IDF, a complete layer of the stack is now gone. Automatically, it's now impossible to suffer from possibly poor coding or flat out bugs in the Arduino layer. There is no dependency anymore on Espressif's implementation of the ESP32 Arduino libraries. So, is it safe and well tested? Well, we're actually removing code by dropping Arduino libraries, and not really switching to different code. The ESP-IDF code has always been underneath the Arduino libraries. With that, I dare to say that it is well tested, and probably even better than the Arduino libraries.

This is especially good, since Espressif's main focus is on ESP-IDF and they have less development capacity on Arduino. So when ESP-IDF moves forward, we don't have to wait for the Arduino libraries to follow the new developments. That is also a reason why the ESPHome project is implementing ESP-IDF, next to the existing Arduino support. If you look at the latest ESPHome release party video, you'll find similar comments in there, explaining why the move was done.

So if you ask me: when developing for ESP32 and when you have no need for Arduino library support, then ESP-IDF is the way forward in general.

I hope this gives you an idea of why I made the switch.

[syssi]

Thanks for your feedback. This helps me a lot! I will give it a try for my yeeling ceiling devices.

[reinisb]

Hey @mmakaay ! A quick follow-up question - when I add a new device to ESPHome, it still automatically adds framework type arduino to the yaml config. I'm wondering why is that the case and if it is safe to remove those lines? Thanks!

esphome:
  name: new-device

esp32:
  board: esp32thing
  framework:
    type: arduino

# Enable logging
logger:

....

[mmakaay]

ESPHome uses Arduino as the default framework, simply because it supports more of the devices for now. When creating a new device config, you can go for either Arduino or ESP-IDF, depending on your needs. If you remove the framework: section, you'll still get Arduino, since that's the default.

[reinisb]

Gotcha, thanks for the context!

[andreas-bulling]

Well - but one big disadvantage seems to be that esp-idf doesn't support the captive portal. That is, in case of a connection problem one has to pull the esphome device (Shellys in my case) out of the wall to reprogram. With arduino and the captive portal it's possible to access them remotely.. right?

[boussouira]

Recently esphome added captive portal support for esp-idf

[andreas-bulling]

indeed - this (to me) only remaining disadvantage has been fixed