ESP32 Forum

Hi,

There is something I do not get in all the above examples. You either have a while (1) loop to wait for an event to occur or a for (;;) which is for me the same.
The whole point of the interrupt is precisely to not have such types of infinite loops that do eat cpu time.

After looking all over internet it seems that the only way to get a true interrupt mechanism, firing an interrupt handler to recover the bytes from the uart needs to be written from scratch right? In the isr handler beside clearing the interrupts we also need to give a semaphore to the actual uart_data_process task.

The queue management waiting for an event to happen does not look to me any better than just waiting for bytes to appear at the uart with the proper flags being raised…..

Am I right or I miss something fundamental ?

Thanks

You're missing the fact that you're running on a RTOS, and functions like uart_read_bytes are so-called blocking functions (recognizable by the fact that they tend to have a timeout argument). What happens is that the UART driver sets up an interrupt when installed, and when you call uart_read_bytes, it will tell the RTOS to suspend the task until that interrupt wakes it again. A suspended task simply gets zero CPU time (it's not executed), so while uart_read_bytes is waiting for data, it uses zero CPU. When the interrupt happens, the RTOS starts executing the task again, uart_read_bytes returns, and you can read your data.

Thank you!!!

It indeed now makes a lot more sense!

Gosh a few simple things like that are not trivial to catch.

Now I fully get it .

Thanks again

In the isr handler beside clearing the interrupts we also need to give a semaphore to the actual uart_data_process task.

That's actually how the UART driver works. (The ISR puts data into a ringbuffer, and the ringbuffer gives a semaphore when it has data available to be read.)

Ok!

Then it means I have a bad parameter in the uart driver installation then because the esp keeps looping at hi frequency on the below.

NoBytesRead = uart_read_bytes(UART_NUM_2, serBufIn, NoBytesRead, 200 / portTICK_PERIOD_MS)

With what you explained above I will check for my mistake and revert

Thanks

Code: Select all

... uart_read_bytes(UART_NUM_2, serBufIn, NoBytesRead, 200 / portTICK_PERIOD_MS)

The NoBytesRead argument is not what you need there. In its place, you pass in the maximum number of bytes you want the driver to put into your buffer. If this argument is 0, uart_read_bytes() will not wait/block for any data but return straight away.

Gosh,

I made so many checks and so many tries for such a stupid mistake

Thanks a lot!