The -S2 (and -S3?) have native USB so you don't need a USB-UART chip on-board, and they can thus emulate other classes of USB devices. That's something I was hoping to find mentioned in this guide, but nope.
Unlike the ESP32-S ones though, that's all it does on the C, so you can use it to program and debug the thing, but you cannot make your own USB device with it.
Not much to be said, it should "just work" out of the box. You plug a board in (for example this one https://www.dfrobot.com/product-2566.html, I've seen it in a bunch of online stores in Europe), and it should give you a COM port on Windows, a `/dev/cu.usbmodem...` device on macOS, and something similar on Linux. Then all the usual tools should work as normal, at least the ones that come with ESP-IDF.
On the chip or the modules, this is pins GPIO18 and GPIO19 that just need to be directly connected to USB D- and D+. Of course the chip still needs between 3.0V and 3.6V for power, so you can't power it from USB directly. If the firmware is just rebooting all the time (sometimes the case on a fresh module), you may need to pull GPIO9 low to enter bootloader instead (https://docs.espressif.com/projects/esptool/en/latest/esp32c..., there is a button for this on some boards), but otherwise you can just flash it in normal mode too.
Oh, so this isn’t full in circuit debugging like ESP-PROG would enable, correct? These parts just have built in USB-Serial for programming and printing to the terminal without an external IC.
Edit: Never mind, it does appear to allow full in circuit debugging. I’ll have to do some more research.
As far as debugging goes, you basically need to run `idf.py openocd` to start OpenOCD, and then connect to it with the gdb that's part of the ESP-IDF SDK, by default it should be listening on port 3333. At least that's how I have it set up in CLion.
Yeah, this is great if you're making your own PCBs -- all you need is the ESP32 module, power supply and a USB connector.
There's no need for a usb-serial converter, JTAG connector (you can debug over USB), or a serial header with yet another random pinout that you have to figure out every time you want to program the thing...
Exactly! Our board at work got all our JTAG pins back for us to use for other things, and we got a more robust programming/debugging setup to boot. So nice. The S3 is phenomenal, and the LX7 on it is surprisingly powerful too.
Nice. They also tidied up the GPIOs a lot, which is such a good quality of life improvement (though I did spend a while hunting through the datasheet looking for the bit where they tell you that GPIO7 can only be used as an output during a full moon, or whatever).
I have one of the Wemos C3 pico boards which rely on the C3's native USB serial controller. The experience is pretty rough for quick iterations on a devboard on Windows.
You restart the board to programming mode by holding down the BOOT button down while pressing RESET. Wait a few seconds, then COM7 is available. You program the board, and then manually RESET the board with the button. COM7 disappears. Then you wait a few seconds, then COM6 appears. Oh, did you print some debug info on boot? Too bad, it takes a few seconds for the virtual serial port to appear in Windows so you just can't get input during that time because the reset resets the USB controller as well (the entire chip).
This is the benefit of on-board USB-UART chips: if you need to reset the chip, your USB controller doesn't need to be reset so your serial port stays open. Additionally, most ESP32 dev boards offer automatic reset by utilizing the DTR or RTS pins of the UART chip and a couple of transistors.
No button presses necessary (there are no buttons even, I have a slide switch on my PCB but almost never need to use it), everything resets automatically (except when it's in deep sleep, then I need to unplug it and plug it in again), I see log lines from the very first line in `app_main()`, etc.
I'm using a recent version of the ESP-IDF framework including all its tools (there is a VS Code extension that has a `Build, Flash and Monitor` button, I think all the operations are just run using the `idf.py` script, but not sure).
I haven't followed QMK recently, but I assume someone is working on an ESP32 port, now that some chips have USB device support. I'm not sure what I'd do with a keyboard that has WiFi, but I'm sure cool (and non-nefarious) ideas will emerge.
Unlike the ESP32-S ones though, that's all it does on the C, so you can use it to program and debug the thing, but you cannot make your own USB device with it.