PIO board name capitalised - appears to break build

[squishykid]

Hello, thank you for this project!

I was trying to get the rust-esp32-std-hello example to run, but was finding that the compilation would always fail with a variation of the following error message:

error: failed to run custom build command for `esp-idf-sys v0.16.2`

Caused by:
  process didn't exit successfully: `/scratch/projects/rust-esp32-std-hello/target/debug/build/esp-idf-sys-c07b526a2fe263c2/build-script-build` (exit status: 1)
  --- stdout
  Found compatible PlatformIO Core 5.1.1 -> /home/rob/.platformio/penv/bin/platformio
  cargo:rerun-if-changed=./patches/esp32c3_atomics_emul.diff
  cargo:rerun-if-changed=./patches/pthread_destructor_fix.diff
  cargo:rerun-if-changed=./patches/master_missing_xtensa_atomics_fix.diff
  cargo:rerun-if-changed=./patches/master_restore_link_fragments_for_pio.diff
  cargo:rerun-if-changed=./patches/missing_xtensa_atomics_fix.diff
  Warning! Ignore unknown configuration option `patches` in section [env]
  Processing debug (board: ESP32CAM; platform: espressif32; framework: espidf)
  --------------------------------------------------------------------------------

  --- stderr
  Error: Unknown board ID 'ESP32CAM'
  Error: No such file or directory (os error 2)

It appears that the board name is always converted to upper case here: https://github.com/ivmarkov/cargo-pio/blob/master/src/project.rs#L235

After changing this I was able to proceed with the build.

I don't know the history of why the board name is changed to upper case, but perhaps it should not?

If it helps, I do not have a sdkconfig in my project, perhaps this makes a difference?

[squishykid]

Update, adding a sdkconfig file did not fix things

[ivmarkov]

The reason why I'm a bit hesitant to fix this immediately is because it works for me, and after the big API redesign I've lost track a bit as to whether it was always there, and if not - why.

Let me try to find some time over the weekend to figure out what is going on.

[TomHotston]

Hi everyone,

@ivmarkov I'd also like to this project shows some amazing promise!

I can confirm the same issue/symptoms, and same solution with the ESP32-C3-DEVKITM-1. For me this fix only works for generating the sdkconfig using cargo pio espidf menuconfig but the build of the rust-esp32-std-hello still fails. with the above error (different board name but all in uppercase)

[ivmarkov]

OK, I hear you. It is just that it is flaky (for me it works, for you it doesn't).

What operating systems are you on? Might be related.

[ivmarkov]

And please paste here your complete output, as @squishykid did.

If you do export RUST_LIB_BACKTRACE=1 before running cargo build - even better.

[TomHotston]

Thanks for looking into this. Although do feel free to wait until the weekend when you have a little more time!

I totally get that it is a bit funky to reproduce. I am running Gentoo, which is probably a rabbit hole. In order to make something slightly more reproducible, I since decided to use a docker container, built from the espressif/idf container (aka Ubuntu LTS 18.04.5) but with the extra instructions for the project backed in to compile rust, etc. I can attach the Dockerfile too if that is useful?

The export from RUST_LIB_BACKTRACE=1 cargo build is:

   Compiling rust-esp32-std-hello v0.14.2 (/project)
error: failed to run custom build command for `esp-idf-sys v0.16.3`

Caused by:
  process didn't exit successfully: `/project/target/debug/build/esp-idf-sys-51da309cbcdf1499/build-script-build` (exit status: 1)
  --- stdout
  Found compatible PlatformIO Core 5.1.1 -> /root/.platformio/penv/bin/platformio
  cargo:rerun-if-changed=./patches/esp32c3_atomics_emul.diff
  cargo:rerun-if-changed=./patches/master_missing_xtensa_atomics_fix.diff
  cargo:rerun-if-changed=./patches/master_restore_link_fragments_for_pio.diff
  cargo:rerun-if-changed=./patches/missing_xtensa_atomics_fix.diff
  cargo:rerun-if-changed=./patches/pthread_destructor_fix.diff
  cargo:rerun-if-changed=/project/./sdkconfig.debug
  Warning! Ignore unknown configuration option `patches` in section [env]
  Processing debug (board: ESP32-C3-DEVKITM-1; platform: espressif32; framework: espidf)
  --------------------------------------------------------------------------------

  --- stderr
  Error: Unknown board ID 'ESP32-C3-DEVKITM-1'
  Error: No such file or directory (os error 2)

  Stack backtrace:
     0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
               at /opt/cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.42/src/error.rs:519:25
     1: pio::project::SconsVariables::from_dump
               at /opt/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-pio-0.20.3/src/project.rs:80:10
     2: build_script_build::main
               at ./build.rs:56:30
     3: core::ops::function::FnOnce::call_once
               at /opt/rust/library/core/src/ops/function.rs:227:5
     4: std::sys_common::backtrace::__rust_begin_short_backtrace
               at /opt/rust/library/std/src/sys_common/backtrace.rs:125:18
     5: std::rt::lang_start::{{closure}}
               at /opt/rust/library/std/src/rt.rs:49:18
     6: std::rt::lang_start_internal
     7: std::rt::lang_start
               at /opt/rust/library/std/src/rt.rs:48:5
     8: main
     9: __libc_start_main
    10: _start

[squishykid]

I am on Ubuntu 21.04 with kernel 5.11.0-25-generic. My /scratch is on ext4, but the root- and by extension /home- is on zfs.

[ivmarkov]

OK so the capitalization of the board apparently breaks PlatformIO in some cases. Since I don't have a locally reproducible case here, and since NOT capitalizing will not break in any way the build (I've checked), I've removed it for now. I also suspect I've accidentally introduced this to the board variable, when doing some ergonomics improvements to the MCU variables elsewhere, so it should actually not be there for boards.

To test the new cargo-pio:

• cargo install cargo-pio <- for the cargo pio espidf menuconfig to use the new cargo-pio version
• cargo update <- for the esp32-std-hello build to switch to the updated cargo-pio library crate. If you've patched the cargo-pio crate dependency, obviously remove the patch first
• cargo clean
• cargo build

[TomHotston]

@ivmarkov That all works perfectly for me now. Sorry for taking a while to get back to you on this, I had to fix llvm first as I had broken the container while trying to fix it earlier.

Again thanks for your amazing work on this! It is really appreciated!

I will drop a pull request over with the Dockerfile at some point, after cleaning it up. It might make things easier to get setup for some people, especially for building the latest versions of the binaries from source. It might also help with debugging down the line 😀

[ivmarkov]

Yep. However - please make sure that you are not duplicating work with what Espressif themselves are doing (yes, we are cooperating with the Espressif folks on bringing in Rust support for the ESP-IDF). You might be willing to take a look at this (a bit out of date as still based on V1.50 if I'm not mistaken, but they'll surely update it) and this.

You might also be willing to hang around in this channel, where Rust on ESP* is being discussed (with and without the ESP-IDF framework).

[TomHotston]

Yep. However - please make sure that you are not duplicating work with what Espressif themselves are doing (yes, we are cooperating with the Espressif folks on bringing in Rust support for the ESP-IDF). You might be willing to take a look at this (a bit out of date as still based on V1.50 if I'm not mistaken, but they'll surely update it) and this.

Yeah, I was sure not to reproduce anything that was already around so I did have a quick look around at some of these. Try not to reinvent the wheel and all. I based it on the espressif example project but instead, it builds from the source repositories, to enable the use of the ESP32C3. I imagine in time this will be unnecessary but for the moment it might be useful to put it somewhere. Although I am not sure where this docker file best fits, or if it is really that applicable for use generally as it builds everything from the upstream. Let me know if it is applicable to put in the project, and I can stick a pull request up. Maybe that is worth doing regardless so you can have a look and then reject it if it is not applicable as it is already something I have written currently, so maybe it is beneficial in some way.

You might also be willing to hang around in this channel, where Rust on ESP* is being discussed (with and without the ESP-IDF framework).

I am already in the channel but have never had to post anything, I do have a read from time to time too. I have been thinking about starting a project in Embedded rust for a while now, especially with the advances made in the past few months it seems like it is ready for use. So actually starting to use it now seems like a good way to get involved and help out!