Could not find xtensa_lx6 with no_std

[Gazedo]

I'm running into the following issue:

error[E0433]: failed to resolve: could not find `xtensa_lx6` in `$crate`
   --> src/main.rs:109:9
    |
109 |         shared_bus::new_xtensa!(i2c::Master<i2c::I2C0, Gpio21<Unknown>, Gpio22<Unknown>> = i2c)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `xtensa_lx6` in `$crate`
    |
    = note: this error originates in the macro `shared_bus::new_xtensa` (in Nightly builds, run with -Z macro-backtrace for more info)

Am I missing an import or something? I've tried the following:

shared-bus = { git = "https://github.com/Rahix/shared-bus.git", features = ["xtensa"] }
shared-bus = { version = "0.2.4", default-feature = false, features = ["xtensa"] }
shared-bus = { version = "0.2.2", default-feature = false, features = ["xtensa"] }
shared-bus = { version = "0.2.0", default-feature = false, features = ["xtensa"] }

with one of the following:

xtensa-lx = { version = "0.6.0", features = ["esp32"] }
xtensa-lx-rt = { version = "0.13.0", features = ["esp32"] }
xtensa-lx6 = { version = "0.2.0" }

Thats the line that worked back when the app was std with the new_std! macro and I don't think I'm calling it incorrectly, this is the code I'm using:

let i2c = i2c::Master::new(i2c0, i2c::MasterPins { sda, scl }, config).unwrap();
let bus: &'static _ = shared_bus::new_xtensa!(i2c::Master<i2c::I2C0, Gpio21<Unknown>, Gpio22<Unknown>> = i2c).unwrap();

[Rahix]

It looks like this line is not correct:

shared-bus/src/macros.rs

Line 154 in 283dcad

let m: Option<&'static mut _> = $crate::xtensa_lx6::singleton!(

It should be

        let m: Option<&'static mut _> = $crate::xtensa_lx::singleton!(

because that's what the re-export is called here:

shared-bus/src/lib.rs

Line 137 in 283dcad

pub use xtensa_lx;

I don't have xtensa hardware on hand so I can't test this. Could you verify if this is indeed the problem and, if it works, send a PR?

[Gazedo]

Well the correction you suggested compiles however the controller resets as soon as I try to use the bus with a wdt error. I'm not sure what the issue is as these calls worked while the app was std. Do you think the issue may still be with the shared_bus library or should I just submit the pr and continue debugging in another direction?

[Rahix]

I think it must be an unrelated issue. I'm not familiar with the platform so I don't have any ideas here, unfortunately. Do you also get a watchdog reset when e.g. busy-spinning without doing anything? Do you have a way to catch CPU faults (the equivalent to a HardFault on ARM) to check whether anything of that sort is going on? Or do you know for certain whether Rust panicked or not?

[Gazedo]

Without using shared_bus there isn't any crash, something with how the bus is exposed after the new_xtensa! macro is causing a crash. Do I need to change my code at all other than replacing the macro?

I can't debug extensively as I'm not currently set up for that.

[pyaillet]

@Gazedo Are you using it with in no_std context (with esp_hal) or in std context (with esp_idf_hal and esp_idf_sys)? (Well because, I guess you're using this with an esp, but I might be wrong)

If you're doing the latter (which seems so because of the wdt), I guess there is a a bad interaction between the xtensa_lx6 mutex and the esp-idf platform, someone reported the same problem on the #esp-rs:matrix today. You could just switch to the std::sync::Mutex, that's what I'm doing nowadays.

However if you're using esp-hal I may be able to find time to look into this next week.

[pyaillet]

Anyway, if my guesses are correct, I would open a PR to complete the documentation of the xtensa implementation and direct users to use the std approach if they are using esp-idf

[Gazedo]

You are correct in that I am trying to use esp_idf_hal and esp_idf_sys with a no_std app. I basically have the app working in std so I wanted to try to convert over with minimal changes but I guess that wont work. My app requires espnow which isn't working under a full no_std app as far as I can find. I'll continue investigating for ways to make this work, I'm still newish to Rust so thanks for the help figuring out whats going on!

I'll submit that pr with the one line change. I tried updating xtensa_lx to 0.7 but that requires adding a feature flag for which esp32 you're targeting, I don't know yet how to best to do that so I'm going to leave xtensa_lx at 0.6.0 for the pr.

[Rahix]

Sorry for having to ask: With commit b78409b, the original issue here should be fixed, right? Or is there anything else remaining?

[pyaillet]

It should resolve the compilation bug on this crate.

However, I am not sure it could be put into use as esp32 crates depends on ^0.7.0 (See here ).

I'm willing to submit a PR with an upgrade to xtensa_lx-0.7.0 but would it be ok to replace the xtensa feature with a feature for each specific esp boards?
If backward compatibility is a problem, we can keep the xtensa feature and make it activate the esp32 board which seems to be a reasonable default.

[Rahix]

I guess it is not a problem to upgrade to ^0.7.0. It will require a breaking version bump of shared-bus as well, but I think that's fine.

I'm not sure I'm following your comment about board-specific features. Isn't it enough to support the correct version of the underlying architecture HAL crate? For Cortex-M based boards, we also only need the cortex-m dependency... But maybe I am missing something?