Rust ESP32 Community Meeting 2021-11-09

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled 9th November 2021 - 4pm CEST/GMT+2 via Google Meet. The meeting invite is automatically sent to attendees of previous meetings. If you'd like to join, please notify us at https://matrix.to/#/#esp-rs-community-meetins:matrix.org

You can find information from previous meeting at https://github.com/esp-rs/rust/discussions

[MabezDev]

esp-idf

• Increase default stack size Resolved.
  • A lot of bug reports about stack overflows on the main thread
  • I suspect stack frames in debug mode are quite large
  • Do we do this esp-idf, or do we add to sdkconfig.defaults for our example projects?
• esp32s3 build now working with STD library approach
  • native build only, pio does not have support for s3 target/toolchains.

RISCV

• atomic emulation handler now on github: https://github.com/esp-rs/riscv-atomic-emulation-trap
  • Not yet released, requires this PR: Trap handler override improvments rust-embedded/riscv-rt#81

Tooling

• probe-rs now has an open PR that uses the builtin JTAG of the esp32c3 (& s3)

Questions

• LLVM
  • Patch status, anything changed?
• Codegen GCC
  • When should we try this out? I think we just need a build of libgccjit for Xtensa, how hard is that to integrate with the current tooling pipeline?

[ivmarkov]

A few weeks ago I have added a default stack size of 7K for the main task to esp-idf-demo, and to esp-idf-template in sdkconfig.defaults.

[georgik]

Updates:

• Build issues and solutions/workarounds: https://github.com/esp-rs/rust-build/wiki/Build-failures
  • ldproxy on Windows slightly longer path is problematic
• macOS x86_64 Monterey - SIGABRT problem - related to ulimit, not present in 1.58.0
• small RGB565 demo for USB-S3-OTG showcase
• deployment and test scripts updates - https://github.com/esp-rs/rust-build/
  • scripts took longer than expected, blueprint for idf-env bootstrapping implementation
  • esp-idf-sys and embuild style of self-contained build - discussion about possible updates to deployment model in projects like idf-installer

[N3xed]

The windows issue maybe the command line length limit which was discussed here. I haven't actually tested if gcc compiled with --with-gnu-ld actually fixes this, but hopefully it does.

[ivmarkov]

The windows issue maybe the command line length limit which was discussed here. I haven't actually tested if gcc compiled with --with-gnu-ld actually fixes this, but hopefully it does.

I just tested the Windows build of this custom toolchain, and it does fix the linking issue for me. I'll open a bug at the ESP-IDF GitHub repo to request the GCC toolchain on Windows to be built with this build flag.

I don't think we need this flag enabled for other operating systems.

[ivmarkov]

One more thing. @georgik - the above issue is definitely "the too long command line on Windows" issue, and not the "too long file path on Windows" issue.

JFYI, here's how the "too long file path on Windows" issue looks like when building with `cargo build features --native":

  CMake Warning in F:/a_very_long_directory/another_very_long_directory/rust-esp32-std-demo/.embuild/espressif/esp-idf-release/v4.4/components/wifi_provisioning/CMakeLists.txt:
    The object file directory

      F:/a_very_long_directory/another_very_long_directory/rust-esp32-std-demo/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-c0e7d0213267a394/out/build/esp-idf/wifi_provisioning/CMakeFiles/__idf_wifi_provisioning.dir/./    

    has 218 characters.  The maximum full path to an object file is 250
    characters (see CMAKE_OBJECT_PATH_MAX).  Object file

      proto-c/wifi_constants.pb-c.c.obj

    cannot be safely placed under this directory.  The build may not work
    correctly.

  thread 'main' panicked at '
  command did not execute successfully, got: exit code: 1

  build script failed, must exit now', C:\Users\ivan\.cargo\registry\src\github.com-1ecc6299db9ec823\cmake-0.1.46\src\lib.rs:974:5

[ivmarkov]

ESP-IDF issue: espressif/esp-idf#7864

[ivmarkov]

• Crate rust-esp32-std-mini renamed again, this time to esp-idf-template, so that it matches the naming convention of the ESP-IDF crates in esp-rs which all start with esp-idf-:
  • Now a cargo generate project. Users can specify their project name, target chip, STD vs no_std (in case anybody wants to do no_std with the ESP-IDF (?)), and ESP-IDF version (stable = 4.3, upcoming = 4.4 and master = 5.0)
  • Supports CMake builds in addition to cargo-first builds (user can choose cargo or cmake during project generation). This subsumes the functionality of Espressif's rust-esp32-example

Question: how do we feel about moving ^^^ to the esp-rs org?

• Bugfixes to the no_std support in all esp-idf-* crates (it did not compile before)

  • A side effect from the esp-idf-template supporting no_std now
  • Again, not sure who and why would use that with ESP-IDF (I mean you link against a libc, pthread and sockets lib anyway, but decide to pass on the Rust typesafe APIs for those (=STD)?!), but nice to have it available - just in case

• (Old topic, forgot to mention it before): Created a new org - esp-rs-compat

  • Mimics the appearance of esp-rs
  • Purpose in life: host forks of upstream off-the-shelf Rust crates, which are patched for ESP-IDF compatibility. That is, until the patches are upstreamed.

• Various small bugfixes (as a result, a lot of minor releases to the esp-idf* crates)

Questions / open topics:

• Need to discuss realpath libc defined but not implemented (IDFGH-6119) espressif/esp-idf#7798
• (Related) need to discuss the future of Rust panic_abort support. Concretely, are we going to support any backtracing in Rust for the C3 chip and how.
• SPI RAM support - is it stable on versions before 5.0 (master)? I hit strange crashes when trying to alloc & use SPI RAM from an HTTPD GET handler?
• Debugging Rust with OpenOCD + GDB + VSCode: has anybody been successful at doing that? I can set/get breakpoints and run the code overall, but the "Variables" view in VScode does not show the internal state of the variables

[ivmarkov]

Question: how do we feel about moving ^^^ to the esp-rs org?

Moved to the esp-rs org.

[ivmarkov]

Programmatic backtracing for RiscV issue submitted here.

[jessebraham]

bare-metal

xtensa-lx-rt

• Update: draft PR now builds for ESP32, ESP32-C3, ESP32-S2, and ESP32-S3
  • Unify & feature gate Xtensa asm xtensa-lx-rt#27

PACs

• We now have PAC repositories for ESP32, ESP32-C3, ESP32-S2, and ESP32-S3
  • ESP32-S2/S3 yet to be published, waiting until next release of xtensa-lx-rt
  • All still contain errors, are missing peripherals, etc. but are slowly improving in quality

espflash

• ESP32-S3 support has been merged into master
• Command-line argument parsing has been refactored, cargo-espflash and espflash are now identical other than build options
• slip-codec dependency was updated, but unfortunately now prints decoding information to stderr
  • I have opened a PR upstream to fix this, waiting to be merged
• Partition tables are not actually being applied if provided, so this will need to be fixed
• Begun working on support for QEMU (merge_bin-like feature)

[ivmarkov]

Opened an issue for the ULP "mini HAL" here