Default tempalte fails to build on master for esp32s3

Question

Default tempalte fails to build on master for esp32s3

xobs opened this issue a year ago · 8 comments

Bug description

The default project fails to build. i2s_pdm_rx_clk_config_t is missing the initializer bclk_div, and xTaskGetIdleTaskHandleForCPU() doesn't exist (may have been replaced with xTaskGetIdleTaskHandleForCore()?)

Would you like to work on a fix? [y/n]

To Reproduce

Steps to reproduce the behavior:

Create a brand-new project from this template
Set it to esp32s3
Use master branch
Build

Expected behavior

Default project should build.

Screenshots

Environment

OS: Windows 11
How did you install the environment: espup 0.7.0

Additional context

I'm still trying to understand how esp-rs works, and as such I'm following the step-by-step tutorial. Following the steps didn't work, so I'm not sure how to fix it.

Answer 1 · 2023-10-24T04:30:35.000Z

I'll fix that, but why are you using the ESP IDF master branch in the first place? You are not supposed to do that. There is a reason why it says UNSTABLE next to it.

Answer 2 · 2023-10-24T05:15:52.000Z

I'm looking to port Farpatch (https://github.com/farpatch/farpatch) from C to Rust. A while ago, I set up a nightly run that builds using the nightly versions of both blackmagic and esp-idf. That way, any time there is a breaking change I can incorporate it immediately rather than waiting for a big release with a lot of changes.

I thought to do the same thing in Rust land, and first I'd like to get it working. If I was doing that with this project, I believe I would have caught the issue when it first appeared.

I'm okay with occasional breakage, and fully recognize that it may be broken. I do it to ensure my projects are compatible with what's coming up.

Answer 3 · 2023-10-24T06:12:18.000Z

I'm looking to port Farpatch (https://github.com/farpatch/farpatch) from C to Rust. A while ago, I set up a nightly run that builds using the nightly versions of both blackmagic and esp-idf. That way, any time there is a breaking change I can incorporate it immediately rather than waiting for a big release with a lot of changes.

I thought to do the same thing in Rust land, and first I'd like to get it working. If I was doing that with this project, I believe I would have caught the issue when it first appeared.

I'm okay with occasional breakage, and fully recognize that it may be broken. I do it to ensure my projects are compatible with what's coming up.

Maybe you want instead the nightly versions of the esp-idf-* crates and not really of ESP IDF itself?

Answer 4 · 2023-10-24T10:10:54.000Z

Maybe I'm confused as to what master refers to.

Normally I build my C++ cmake project using master of esp-idf every night. That way, if something changes upstream, I'll get it right away.

I thought that by selecting master when using this template, I'd be using the same trunk version of esp-idf. However, I suppose what happens is that selects the master version of the esp-idf-sys crate? Which isn't necessarily using the master version of esp-idf? I'm a bit fuzzy on how it all works.

Regardless, it sounds like this issue doesn't belong here, despite the fact that I was using this template. Instead it should be on esp-idf-hal.

Is there any documentation on what the master option selects within this template?

Answer 5 · 2023-10-24T13:45:25.000Z

Normally I build my C++ cmake project using master of esp-idf every night. That way, if something changes upstream, I'll get it right away.

I thought that by selecting master when using this template, I'd be using the same trunk version of esp-idf. However, I suppose what happens is that selects the master version of the esp-idf-sys crate? Which isn't necessarily using the master version of esp-idf? I'm a bit fuzzy on how it all works.

No no - it is exactly as you thought originally - selecting master when using this template will select master for ESP-IDF.

It is just that - with having Rust in the game - you also need to worry about the versions of the esp-idf-* crates too, and I thought for them you want to stay up to date, NOT for ESP-IDF. Because, I thought you'll be consuming ESP IDF exclusively via these crates. But maybe I'm wrong since you are mentioning CMake - perhaps you have a mixed Rust/C++ project and you plan to hit ESP IDF directly - via C code - as well as indirectly - via Rust esp-idf-* crates?

Regardless, it sounds like this issue doesn't belong here, despite the fact that I was using this template. Instead it should be on esp-idf-hal.

Doesn't really matter.

Is there any documentation on what the master option selects within this template?

As per above, it selects the version of ESP IDF as you originally thought.
The versions for the esp-idf-* crates are controlled via the generated Cargo.toml, as usual.

Answer 6 · 2023-10-24T13:49:59.000Z

By the way, and if indeed you are running a mixed C++/Rust CMake project, this article might help: https://github.com/esp-rs/esp-idf-template/blob/master/README-cmake-details.md

If, however, you are running a standard cargo project, where you are consuming the ESP IDF only via the esp-idf-* crates, then I would still suggest getting away from ESP IDF master. The upstream changes to ESP IDF in that setup are only a problem for the esp-idf-* crates. Your problem would be the API changes to the Rust ESP IDF wrapper crates.

Answer 7 · 2023-10-26T22:39:09.000Z

FYI, esp-idf master is currently not even buildable itself. Hopefully it would, by tomorrow.

Answer 8 · 2023-10-28T06:22:52.000Z

Fixed now. Issue cargo update in your generated crate to get the newly-released esp-idf-sys and esp-idf-hal. It should build fine with ESP IDF master after that, but please also issue cargo clean just in case.