It's possibly easier to create a FreeRTOS task for this. Task waits for e.g. a semaphore or queue, then handles the sensors. Either your interrupt or your normal code can raise the semaphore or put something in the queue and let the task handle the thing.

Smells like something is not properly re-entrant, which causes the spurious errors. Is there a way to handle the cancel in the download task, as in, the cancelling task raises a semaphore, the download task checks that and calls esp_http_client_close() function?

That does not look like a potentiometer (potentiometer specs mention resistance, not pulses). More likely it's a rotary encoder instead.

Well, being able to toggle GPIO's in a few clock cycles is exactly what I expect from a MCU. We are aware of that, hence the addition of fast GPIO in later chips. We have 'fast GPIO' options in the -S2 and -C3 to get around this limit, but the ESP32 does not have that. These versions have only a si...

By default, ESP32C3 JTAG is routed to the internal USB-serial-JTAG controller. You can either use that to debug (simply add an USB cable) or you can burn the fuse to route it to the JTAG GPIOs.

Try setting this to the same as .des.length, rounded to the next multiple of 4.

The reason is that the driver already uses that interrupt to handle the blocking read and write calls. Also note that queue reads are not 'polled'; the RTOS suspends the reading task until something (e.g. the UART interrupt) pushes something onto it, at which point (dependent on priority) it immedia...

Nope. I want to test your code, but I need some time and concentration to get all the parts (korvo board, sdcard) together. If you could simplify your app a bit more so I can run it on a random devkit, that'd probably make life easier for me.

Looks like you're looking at the docs for the current master, not the 5.0 release (you can select the release in the dropdown box on the left). this is for the 5.0 release, and it mentions a small inline example using dac.h.