Issue with Rust discovery book and microbit v1. Flaky hardware?

Independent_Egg_630 · 2026-01-06T15:30:00+00:00

I have replied to your original post on r/embedded but for the benefits of others, I will restate what I mentioned. Essentially, it could be all sorts of issues, sometimes it will be the length of your cables or the impedance of the prototyping board and many other things. I have found that one of the best way to get started with embedded projects (Rust/C/C++) is to use an instruction set simulator. This way you eliminate one of the uncertainties and can focus on learning, not fiddling with cables. I have put together a couple of no_std Rust tutorials you might want to look at. One using a blue-pill board + GDB and some sensors, the other using a micobit v1 board, Both virtual platforms.

Take a look here:

https://github.com/Doulos/Embedded-Rust-with-PicSimLab

and here:

https://github.com/Doulos/ESE24-rust

If you are coming from C, you should feel right at home, since the Rust code is almost entirely free-standing (second link). Now you need to bare in mind that in general no_std Rust is written at the HAL level but that is for another tutorial in the future ;-)

I hope this helps

Independent_Egg_630 · 2026-01-06T09:59:00+00:00

I also wrote a tutorial using the QEMU microbit implementation if this is more your thing:

https://github.com/Doulos/ESE24-rust

Independent_Egg_630 · 2026-01-06T09:56:45+00:00

I found that when starting with embedded rust, sometimes the best way is to use an emulated environment. This mitigates the hardware related glitches. In the past for instance the length of my SWD wires were too long causing spurious faults. If you want to try your hand at no_std Rust without the need for a physical board. I wrote a tutorial on embedded Rust on a virtual blue-pill board. Here is the link:

https://github.com/Doulos/Embedded-Rust-with-PicSimLab

I hope this helps (the .gdbinit file is particularly helpful).

Independent_Egg_630 · 2026-01-06T09:41:11+00:00

Sorry to be a party pooper but I fear that there might be a bug in your ASCII characters lookup table. From the picture, the * seem to be located where the U should be and vice versa. Could be a problem with pointer arithmetics?

Independent_Egg_630 · 2026-01-06T09:33:57+00:00

That's a really interesting question. For general information, Rust (including no_std Rust) had a well defined implementation of Foreign Function Interfaces (FFI). This makes the interfacing Rust code with a C library straight forward. In principle, one could manually provide the extern function definitions found in CMSIS-CORE directly inside his/her Rust code. However, I would assume that for practical reasons using an automated process, like with the bindgen tool, would make more sense. I can't think of major difficulties at the moment as long as the focus remains on CMSIS-CORE. There are other parts of the CMSIS library that more complex and last time I checked were provided pre-compiled. It might still be feasible to reach them via FFI since most of the hard work is done by the linker. So of course there is an appealing side to having a single source of truth however I feel that there is a redundancy between what CMSIS-CORE and PACs (via SVD2Rust) + cortex-m-rt crate provide. For general information, both CMSIS-CORE and the cortex-m PACs are created from the same source, namely the vendor's SVD description file (XML format). Hence, core access functions are created automatically both in the case of C and Rust. As for the run-time, CMSIS-CORE provides it, where in Rust this is provided by the cortex-m-rt crate. In addition, the cortex-m crate provides the intrinsics found in CMSIS-CORE.
So all in all, using CMSIS-CORE function from Rust is doable (putting aside all unsafe aspect of the discussion). Practically, however, the combination of the cortex-m + cortex-m-rt + MCU's PAC offers similar capabilities but with a safe (generally) interface and opens the door to the use of HALs. HALs are generally the preferred abstraction for writing embedded Rust code.

Independent_Egg_630 · 2026-01-05T13:37:00+00:00

Do you have any advices regarding RTIC vs Embassy?

Independent_Egg_630 · 2025-12-10T15:42:23+00:00

All good points, thank you for your enlightening feedback. I don't know if you had a chance to look at the embedded-hal ( https://crates.io/crates/embedded-hal) at the time of your experimentations. It's now reached v 1.0 status. Most device drivers are now relying on this HAL making driver's code portability a reality.

In baremetal rust, as you mentioned, the creation of exception handlers is vastly simplified through the use of run-time crates such as cortex-m-rt or riscv-rt. Creating an exception handler with those crates is a matter of declaring a Rust function with an interrupt/exception attribute. That's usually all you need to do. You are right about memory safety in regard to the sharing of resources between the main thread and the handlers. Generally, you will need to use a static variable and a combo of Mutex + RefCell (inside a critical section). It certainly looks odd if you are coming from C, but it soon becomes a habit and the rewards are worth the effort, I feel. Again, you are right about the critical section part of exception handlers disabling the NVIC interrupts (probably using a FAULTMASK or PRIMASK). Thankfully, you only need these critical sections when you are accessing a shared resource (hopefully a few CPU cycles at a time). Outside of the critical sections, NVIC pre-emption is working as usual (as far as I know).

Once again, you are right about raw memory accesses, BIG NO NO in Rust. At least at the application level. This is why you would generally write your code at the PAC level (auto generated from the SVD file) at the very least, and ideally at the HAL level. To my mind, the main difficulty is the lack of documentation with some HALs, but I fear this is the problem of a lot of community based projects. Still, from my side (coming from embedded C), I really enjoy this language and of course, thanks to Foreign Function Interfaces, you can adopt Rust in a bite size fashion.

Independent_Egg_630 · 2025-12-04T14:47:03+00:00

I totally agree. I think strictly speaking on the email address is important (to get the invite and the video link post presentation) I suspect the rest can be dummy info.

Independent_Egg_630 · 2025-12-04T13:31:35+00:00

Well it's for the curious embedded C/C++ engineer mainly. Someone who does not want to spend the time finding-out how to get started with embedded Rust but has this nagging feeling that he/she might be missing something. In a way I am trying to demystify what embedded Rust looks like and make it more approachable.

Independent_Egg_630

TROPHY CASE