> The ESP32-C3 is said to be the successor to the ESP-8266. And like the 8266 is limited in Programmable IO compared with the ESP-32. This USB method of In-Circuit debugging uses two processor PIO pins instead of the four pins needed for JTAG debugging–freeing up two pins for general use.
> In the processor’s low power modes, the USB interface is powered down and USB debugging is not possible. If you need to debug while in one of the two low power modes, you should use the JTAG interface.
> Visual Studio Code operates at the source code level and is able to use this method of debugging to set breakpoints, examine variables and the stack, single-step high level source code and flash the device. But VSCode has no knowledge of the processor details (e.g. CPU internal registers, memory configuration–access and format). As a result single-stepping through assembly code while examining CPU registers, flags and memory is not possible. But the detailed knowledge gained while single-stepping assembly code would be an advantage in learning the ESP32-C3’s risc-v architecture. VSCode teamed with PlatformIO could provide this capability and I have filed an issue to that purpose on PlatformIO’s github. https://github.com/platformio/platform-espressif32/issues/651
Armstrong and Aldrin did their own test. Just a moment after he became the first human being to step onto the Moon, Armstrong had scooped a bit of lunar dirt into a sample bag and put it in a pocket of his spacesuit—a contingency sample, in the event the astronauts had to leave suddenly without collecting rocks. Back inside the lunar module the duo opened the bag and spread the lunar soil on top of the ascent engine. As they repressurized the cabin, they watched to see if the dirt started to smolder. “If it did, we’d stop pressurization, open the hatch and toss it out,” Aldrin explained. “But nothing happened.”