ivmarkov

The situation has evolved since then in that `async-io` 2.0 (in `smol`) has out of the box support for ESP IDF. Also the changes to `tokio` are released in the...

TL;DR: Remove the `nb_block!` macros from the code. Long story: you are mis-interpreting the example. The example calls `transmit/receive` via the e-hal traits, and there you need `nb_block!`. You are...

> I ran into this as well and figured it out by explicitly specifying I want the trait method, thus opting into the nonblocking API. > > ```rust > nb::block!(embedded_can::nb::Can::transmit(&mut...

I think what you are saying is that this doc example does not compile out of the box, as it went out of date. Because we don't run `cargo test`...

@kyrias Do you need more than what is already exposed (and what @N3xed described above), or shall I close this?

All of the above should be unnecessary. Please use - in your `build.rs` script of the crate that depends on `esp-idf-sys` - this: ``` embuild::build::CInclArgs::try_from_env("ESP_IDF") ```

I have difficulties believing that, [as what you get via `CInclArgs`](https://github.com/esp-rs/esp-idf-sys/blob/0d13e8ed22ef6ec29c9e0922f155df9dfb2ba553/build/native/cmake_driver.rs#L35) is what **bindgen in esp-idf-sys itself** is using to [assemble the `esp-idf-sys` bindings](https://github.com/esp-rs/esp-idf-sys/blob/0d13e8ed22ef6ec29c9e0922f155df9dfb2ba553/build/native/cmake_driver.rs#L53).

(... modulo headers for custom components, but these are a separate topic altogether.)

> I guess that works, but `bindgen` only accepts either individual arguments or an iterator of them, and so we'd need to pull in a crate that can do proper...

I think what to expose and where the rough edges currently are would be easiest to pinpoint if someone **tries** to use what we already have, and then show -...