Open paulkernfeld opened 4 years ago
Hm, take()
is guarded by a singleton to protect multiple use. If the unwrap()
failed that would suggest that someone has taken the peripherals before.
We probably should update the depedencies anyway, so it doesn't make too much sense spending time on why it fails in the old version. Maybe you'd like to make that change throughout and PR it?
After trying to bump the version of cortex-m in throughout the repo, the build failed (only in chapters 11 and 16, actually). I think this is because the f3 crate is still using cortex-m 0.5. I tried to update the f3 crate, but didn't get too far because it's currently broken (see https://github.com/japaric/f3/issues/110). There are a couple PRs that are attempting to fix that issue, so I think as soon as one of them is merged it should be possible to update this repo to cortex-m 0.6. Does that sound right?
TBH this shouldn't be using f3
anymore, it is not being worked on and superceded by other efforts. https://github.com/rubberduck203/stm32f3-discovery could probably replace it, or we could integrate the relevant parts into the turtorial code and base it of stm32f3xx-hal
directly.
Maybe we should ping @japaric here to discuss options.
👋 Hi, I'm doing a small study group (with @mjhoy and @deffen3) and each of us encountered this issue when trying to do "debug it" in the LED roulette example:
The content of
lib.rs:17
is:We were able to apparently fix it by changing the version of the
cortex-m
dependency from 0.5.6 to 0.6.3 insrc/05-led-roulette/auxiliary/Cargo
, but perhaps there is a better way to do it.