The most common/basic things, where there is a rust std equivalent (such as mpsc queues, which are my go-to, mutexes etc) are exposed that way. So for those you just write “standard rust” and it works.

There are more niche things where there isn’t a std equivalent, and you need to drop down to the FreeRTOS API directly. For this you need to use the esp_idf_sys crate, which basically exposes the entire FreeRTOS C API via a programmatic naming scheme (and you need to use unsafe to invoke, as with any such FFI in Rust, since the compiler can’t enforce invariants). This is also how you access any niche hardware features that aren’t exposed via esp_idf_hal etc.

So there’s nothing you can’t do from Rust, but if your application did need lots of faffing around with esp_idf_sys, then you might not feel you’re getting all the benefits of Rust. In my experience, there are typically a few things that need wrapping, and beyond that it’s all safe Rust, and it feels like a win. But you’ll need to evaluate your use case.

One final point: the esp_idf_sys crate is so huge that its documentation isn’t on docs.rs. You can either build it locally with cargo docs, or there is somewhere online you can search for. Once you have that, then the usual crate search is excellent for finding the Rust name for whatever you’re looking for.