discovery
discovery copied to clipboard
rust-embedded
11-usart None on Peripherals take
Hi there,
I'm trying to run an example code from 11-usart section without using external serial module;
Unfortunately, I still cannot get "x" printed in Minicom, also I've noticed that 11-usart/auxiliary/src/lib.rs:18 which is let cp = cortex_m::Peripherals::take().unwrap(); panics with None.
Could you please help me with that?
getting the same issue. updating cortex_m to 0.6.3 stops the panic, but I can't seem to create MonoTimer with the crated updated.
update - replacing f3 with stm32f3xx-hal more or less got it working, with the caveat that in main.rs setting w.tdr().bits() now needs to be wrapped in an unsafe block. Also the root of the project needed a memory.x file.
This is related to #259, I believe chapters 11 and 16 are still broken. @zhao-lang I'd love to see a PR with your code. As far as I'm concerned, I'd rather have an unsafe solution than a broken one!
I just ran into this issue and found @zhao-lang's branch. In that branch, the code works only if I start with cargo run --release. In debug mode, it simply doesn't output anything...
Could we just revert to earlier versions of the relevant dependencies? That should be a pretty easy and low-risk way to keep things working if indeed the book is planned to be rewritten for a different board (#263).
@zhao-lang 's code seems correct and runs for me in debug mode. Unsafe does need to be added to src/11-usart/src/main.rs but after that I think all is correct. We might as well keep the discovery book in a working state until there is a good replacement, and maybe for a little while after, so maybe we should merge https://github.com/rust-embedded/discovery/pull/267 (with the added unsafe) and keep discovery working.
Would it help if I ran through all the projects in the book updating the f3 dependency?
I bought one board that is produced in June 2020 but still got no output in the terminal while running both the original code and #267 code. However, I could get the loopback message if PC5 and PC4 are connected. That's strange. :(
I bought a discovery board in Dec. 2020 and with PR #267 it did work for my board (with the addition of the unsafe work-around). I'd like to second motion to keep the discovery board code up-to-date until a new version of the book is created.
It is not solved in master. I have a solution in my fork in branch fix-for-11-usart-using-pr267-and-tweaks
You can clone and check the branch out that with:
git clone https://github.com/winksaville/rust-embedded-discovery.git
cd rust-embedded-discovery
git checkout fix-for-11-usart-using-pr267-and-tweaks
You should be able to use cargo run and see the "X" in the terminal
output:
On Sun, Jan 3, 2021 at 12:35 AM JiangLiu [email protected] wrote:
I bought one board that is produced in June 2020 but still got no output in the terminal while running both the original code and #267 https://github.com/rust-embedded/discovery/pull/267 code. However, I could get the loopback message if PC5 and PC4 are connected. That's strange. :(
Has the problem been solved? I have the same problem.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rust-embedded/discovery/issues/264#issuecomment-753585284, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2CHGJHRYVCZ7SH4U7TA3SYAT3NANCNFSM4QKCCMKA .
I'm seeing the same panic on master as of April 10, 2021 using macos Mojave 10.14.6 (18G8012). My board was purchased a few days ago, but I'm not exactly sure how to date it.
I bought one board that is produced in June 2020 but still got no output in the terminal while running both the original code and #267 code. However, I could get the loopback message if PC5 and PC4 are connected. That's strange. :(
I'm having this issue as well. I've even hooked up my oscilloscope to the pins and I see no activity. The registers seem to be behaving normally (I've modified it to send the string over and over). That is, the busy bit is being cleared normally.
Hopefully this issue is (temporarily) fixed by #328, though I'll leave it open until a more long-term fix is in. Thanks @wpd!
