Embedded Rust

I want to become fluent in Rust, and I have a few things I'd like to do with embedded systems, so I figured I'd combine the two. This has got a lot easier since I first thought about it: there's a book.

The thing I specifically want to do is regularly sample the ADC, using non-blocking APIs.

This is sort of supported: There are some standardised HAL APIs, and they use nb which is a generalised non-blocking mechanism.

This does mean, however, that you end up needing a spin loop that tries everything you are waiting for. You can handle interrupts, so perhaps there's a sleep function that wakes up after an interrupt has been processed? Then I could add something like Chibios events: the interrupt would set the right event flag, and the main loop would act on each event flag that was set, each time it woke up.

I don't need to do this, because the RTFM framework does it already, and statically analyses your program for deadlocks.

RTFM lets you define 'tasks' which are functions that are invoked to process messages. You can send a message to a task from an interrupt, and the scheduler will invoke the task function with that message later.

This means everything will have to be written as a state machine: Rust doesn't have co-routines, although it may in future.

As far as I can tell, if you want to the processor to sleep when Idle, you just don't specify an idle function.

There are drivers for a couple of peripherals I have: the accelerometer and gyroscope in the stm32f3 discovery board, and the ENC28J60 ethernet adapter.

I couldn't immediately get an example to build, but then I don't know much about rust or cargo, which is obviously a handicap.
I found an example which uses rtfm with an stm32f103: rusty-clock. It uses a released version of RTFM, and the RTFM documentation refers to master, which has some API changes that affect the trivial init.rs example. Anyway, Cargo can just use git repositories, so I'm going with that.

RTFM also doesn't expect memory.x to be required - that those details are provided by the PAC crate. This doesn't seem to be the norm, and definitely isn't true of the stm32f1 create. Anyway, I just grabbed memory.x from the rusty clock project.

The result builds.

Other references:
Cortex M Quick start
Awesome embedded Rust

Popular posts from this blog

3D Printer ramblings

 I have a Prusa i3 mk2.5 in storage. I used to use it in my shed I used not to worry about it's harmful emissions: I just didn't share the space with it. I had, however, added an enclosure, and was planning to add a HEPA filter too it. Once it's in an enclosure, it's massive. Even if I had added the filter, there's no where to put it. I'd like a small printer that has an enclosure or is easy to enclose. I figure I could get by with 150x150x150 build area: I was rarely patient enough to wait for my i3 to print bigger models. 200x200x200 would probably actually replace my current printer, so that would be a bonus. Not many printers have HEPA filters, which is really a shame. It seems just to be the result of a misconception about HEPA filters, and about filtration in general. Read this . E.g. I was looking at a used Lulzbot mini, and there are ready made enclosure s for it, however . In this particular case, it's no big deal: opportunities to buy a Lulzbot min
Read more

Balance Bot V2

Image
My current balance bot sort of works, but it's surprising it does: it's centre of gravity is actually only about 60mm above the motor axis. The whole thing ways 320g. The 6 AAA batteries only weigh 70g, so despite being right at the top, the don't affect the centre of gravity much. 6 AA batteries would weigh about 180g. That would add a 34% to the overall weight, and move the centre of gravity much higher. Seems like a dramatic increase in weight: it would be nice to be a bit more incremental. More AAA batteries isn't really worth considering: they only weight 12g, vs 30g for an AA. 4 AA would deliver much less power/torque, so that's no good. There's no middle ground, in other words. I'm also going to make the whole thing a bit taller: I need more space to add more sensors in any case. Last time I made the frame, I needed an elaborate jig to get it square and it actually didn't work that well. This time, I decided to use some short bits of a
Read more

Robot arm

Image
I 3d printed this robot arm I original found on Thingiverse, but the Instructable is recommended. There's a MK2, and also a delta style arm, both of which look like good alternatives, but this will do for now. Here's a video of it moving: I've attached it to an STM32F4 Nucleo board, via a prototype shield: In the video, I'm sending commands from a python script that runs on my desktop, communicating via USB serial. I've written an implementation of canonical s-expressions in c++ that doesn't require memory allocation, as well as a python version to talk to it. It's the main reason I haven't posted for so long, and of course overkill for just controlling some servos, but should prove more generally useful. Here's the code . It uses platformio for the build, and mbed rtos.
Read more