Open Gazedo opened 1 year ago
It looks like this line is not correct:
https://github.com/Rahix/shared-bus/blob/283dcadb6c292ffd7c84b6a95466915889a9cb9e/src/macros.rs#L154
It should be
let m: Option<&'static mut _> = $crate::xtensa_lx::singleton!(
because that's what the re-export is called here:
https://github.com/Rahix/shared-bus/blob/283dcadb6c292ffd7c84b6a95466915889a9cb9e/src/lib.rs#L137
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?
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?
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?
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.
@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.
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
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.
Sorry for having to ask: With commit b78409b326fcdfb2f26d6a721737c6842615d630, the original issue here should be fixed, right? Or is there anything else remaining?
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.
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?
I'm running into the following issue:
Am I missing an import or something? I've tried the following:
with one of the following:
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: