ESP32 Forum

This is a subtle one ... I'm studying the RMT RX input functions. I see that we can ask the RMT driver to create a ring buffer and get the handle to that ring buffer using "rmt_get_ringbuf_handler". Here comes the first part of the puzzle:

What is the "origin" on the ring buffer functions? They appear to be supplied as part of the FreeRTOS package but I haven't found any reference to their existence outside of ESP-IDF.... were they created by Espressif as FreeRTOS extensions?

Once we have a handle to the ring buffer, we might then want to be informed when new items are added to it. We can do this by calling xRingbufferReceive which polls/blocks on one ring buffer. However, if we have many sources of input (eg. multiple ring buffers or queues) then we might want to use a FreeRTOS Queue Set so that we can block on one or more potential sources becoming ready. The Ring Buffer functions seem to have a solution for this. There is a function called "xRingbufferAddToQueueSetWrite" that will add a ring buffer into a queue set. Awesome ... I can now block on the queue set and learn when the ring buffer becomes written to ...

But ... and here is the major question ...

What if I have TWO or more ring buffers? I can add each of them to the Queue Set and then block on that ... I am presuming I will be woken up when ANY of the ring buffers are written to ... however ... and here's the rub ... the "xQueueSelectFromSet" returns the handle of the object that is ready for reading ... and I am led to believe that for ring buffers, this will be an internal semaphore buried deep in the internals of the Ring Buffer. What that means to me in practical terms is that if I have two ring buffers, add both of them to a queue set and then block waiting for either ring buffer to have an item written into it, when one of them does I'll be woken up ... but form the information available to me, I won't know WHICH of the ring buffers caused me to wake.

Yes I believe ringbuf library is made by @esp_sprite

Once you receive the matching handle you can compare it to the handles you think it could be to figure out which member to operate on.

But consider: http://www.freertos.org/Pend-on-multipl ... gn_pattern which may or may not be possible without reworking/reimplementing some lower level code

I think if we look at the internals here ...

https://github.com/espressif/esp-idf/bl ... buf.c#L641

We see that what is being added to the QueueSet is an internal (to Ringbuf) semaphore. As such, if I were to wake up from a block on a Queue Set, I wouldn't get a handle to the ring buffer that triggered the wake up, rather I'd get a handle to a semaphore that is "likely" an internal attribute of the implementation of a ring buffer. Now if it is going to be the intent that we do such and the internal semaphore becomes part of the clearly defined programming interface, then I'm all good. It may very well be that the purpose of adding the Ring Buffer to the queue set is not to select between multiple Ring buffers but is instead a "mechanism" to allow us to determine if a Ring buffer is ready for reading without blocking without ACTUALLY reading ... basically it might be the ONLY way to achieve a poll on a ring buffer.

Later ... ah no ... we can poll just fine using "xRingbufferReceive" with 0 as ticks_to_wait.

Later yet .... ah no ... calling "xRingbufferReceive" with 0 as ticks will return immediate if there is something in the buffer AND also retrieve the contents. If I "JUST" want to know if there is a record that "COULD" be read, then the Queue Set might be the only way to do that.

Right I guess you could request getter functions for the semaphores or a compare function.

Good point, I'll see if I can add these.