Thoughts on FreeRTOS queue/semaphore wrappers? about esp-idf-hal HOT 5 CLOSED

As always, PRs greatly appreciated!

But also - some justification as to why you would use native FreeRTOS queues and semaphores over Rust STD queues, mutexes and condvars and their Posix equivalents?

from esp-idf-hal.

My main concern is to ensure that when blocking waiting to send/recv on a queue/semaphore, the calling task is put into the FreeRTOS blocked state... otherwise things like tickless idling won't work, correct? Is this possible outside of native FreeRTOS queues?

from esp-idf-hal.

Things like Rust Mutex and RWLock as well as Rust queues then on top are implemented in terms of OS sync primitives. In our case - semaphores. So yes, your task will be put into a blocked state even when using the higher level constructs of Rust from above, as well as any Rust IO API from STD.

IMO native FreeRTOS queues, events, event sets and semaphores are only having an edge over their Rust wrappers when you are trying to signal such a primitive from an ISR, which is not supported with the Rust wrappers. But I've yet to see folks coming with such advanced use cases.

I'll close rhat now. Feel free to reopen in case you have counter arguments or you have in mind the ISR advanced use case. However for the latter, we already support typesafe bindings to FreeRTOS task notifications, which are the most efficient way for an ISR to awake a FreeRTOS task and pass some limited data anyway.

from esp-idf-hal.

Thanks Ivan, that's a super helpful explanation, I really appreciate it.

I almost always use task notifications from within ISRs, as you correctly recommend, so that's not an issue.

Also, off-topic, but is there a place of discussion for esp-rs? Like a discord or IRC?

Anything on this?

from esp-idf-hal.

Also, off-topic, but is there a place of discussion for esp-rs? Like a discord or IRC?

Anything on this?

Sorry I've missed that and yes, sure - we have a Matrix room.

from esp-idf-hal.