ESP-IDF vs Arduino

[oliv3r]

Currently, you seem to be using the ESP-IDF framework because of the SPI-slave?

If so, I found https://docs.arduino.cc/libraries/esp32spislave/ which seems to suggest that this might now be available in the platform.io/arduino framework. If so, it probably would be a good idea to start migrating to the arduino framework instead, which is afaik the preferred ESPHome framework, and offers us OTA via the webif, which is not possible with ESP-IDF.

This is actually important when using name_add_mac_suffix which makes it much harder to discover devices with ESPHome and thus very hard to flash them.

[hberntsen]

Hi oliv3r! I'm using the ESP-IDF framework because it is (1) my personal preference and (2) it is recommended by esphome:

This is an alternative base framework for ESP32 chips; it is recommended for variants of the ESP32 like ESP32S2, ESP32S3, ESP32C3 and single-core ESP32 chips.

-- https://esphome.io/components/esp32#esp32-espidf-framework

I see the library you link does not support DMA:

This is the simple SPI slave library and does NOT use DMA. Please use ESP32DMASPI to transfer more than 32 bytes with DMA.

Not using DMA would be a downgrade as I'm able to use that with the ESP-IDF. I'm also not fully sure what they mean with more than 32 bytes (we need to transfer 33). So it might not even work?

[oliv3r]

I know they write ESP-IDF is preferred, but almost all sketches use Arduino, because it offers more functionality. Which is ironic, because under the hood, arduino still uses esp-idf.

Besides the aforementioned OTA webif update; serial debug seems to be not ideal with ESP-IDF either ... (I just get the boot logs for example)

It's sad that this is what the state of things are :(

[hberntsen]

Part of my personal preference for the esp-idf is that the arduino abstractions add an extra layer of missing functionality and bugs for me ;). I feel like it makes it harder to do things because I need to know both what the chip itself can do and which part of that the arduino library does. Especially here, where I had to fiddle around with generating my own SPI CS signal to get the hardware to work. It was a nice experience to have the most direct access to the hardware stuff to ensure it was really needed.

Don't get me wrong, I like arduino to get going quickly and for simpler things. But when I need details, I'd rather go a layer deeper.

I can't help you with the OTA unfortunately. I'm flashing my units by hand docker run --rm -v "${PWD}":/config -v "${PWD}/.penv:/root/.platformio/penv" -it esphome/esphome:2024.12 run ac1.yaml. Which also works via WiFi.

The USB serial port logging works fine for me. Make sure that you configure the right output:

logger:
  level: INFO
  baud_rate: 115200
  hardware_uart: UART0

The ESP32-C3 boards in this project don't use the native USB interface but a USB->UART chip. So you need to configure ESPHome to use it.

Oh, and by the way. I'm not sure how wise it is to connect the USB cable to the unit while it is also connected to the AC. With the USB cable we're attaching two 5V power supplies with each other. I've cut the red wire in a USB cable to prevent that when debugging.