Since there's no central registry for applications on your Linux box, whatever you do for one version of the IDF you can do with another version in a different directory. When selecting a version of the IDF to use, just use the one in the directory that corresponds with your choice.

I have $HOME ...

I know exactly what the problem is. Dev boards include a little usb to uart chip that drives the boot and EN pins using its RTS and CTS outputs. This configuration is known as "default_reset" in the toolchain, and as the name suggests, all the command lines generated by the toolchain include ...

My thoughts are that the HW timers should be used when dealing with either very short repeat cycles or when dealing with specific hardware peripherals. Things like "update the cloud every so often" don't need to resolution available with the HW timers (the latency with the network will throw off the ...

If you have a point where you know by external means which board it is, you can set a fuse with that ID and then refer to it later. Perhaps a device unique factory app and then you update to a common app via OTA.

mdns has moved to be a separate component now.

Run 'idf.py add-dependency espressif/mdns==1.0.3' in your project and then build. You'll end up with a 'dependencies.lock' file that you should add to your version control.

An extension of my previous answer -- USB C host ports will generally default to providing NO power. Adding pulldowns for CC1 and CC2 will indicate to the host what level of power should be provided. It won't matter if you're connecting to a Type A port (using Type-A to USB-C cable), since there's ...

It's my understanding that you do need the CC pulldown's for the USB-JTAG connector as well, if you're using the USB connector as a possible power source (which your schematic indicates you are).

But I'm curious as to why you will be using 2 USB C connections for this. You _can_ use the USB-JTAG ...

Using the master branch of esp-idf (specifically, v5.0-dev-2483-g3aeb80acb6), I can't show the fuse table for the example code in examples/system/efuse when I'm building for esp32-s3. From a clean unmodified checked out tree, I run the following:


$ idf.py set-target esp32s3
....
$ idf.py show ...

The system/console_usb example is using USB managed by the main CPU and not the new-to-the-ESP32-{C3,S3} USB/JTAG controller. It is also hardcoded to the ESP32-S2 (see the sdkconfig.defaults file). Removing that entry and attempting to build for the ESP32-S3 results in this:


/Users/zoo/esp32/esp ...

I would very much like to see the USB/JTAG controller serial interface be a full replacement for a UART interface, allowing me to remove the CP2102 from my design and simplifying the BOM.

When I try to use this interface the way that I use the UART interface, it seems like the USB serial is a ...