F3: a crate to play with the STM32F3DISCOVERY


#1

The STM32F3DISCOVERY is a development board that has a Cortex-M4 microcontroller (72 MHz, 256 KiB Flash, 40+8 KiB RAM), MEMS sensors (accelerometer, gyroscope and magnetometer), a built-in programmer/debugger, user LEDs and other bells and whistles.

Hello, fellow Rustaceans!

Today, I’m here to announce the version 0.1.0 of my f3 crate (crates.io). As the title suggests this crate provides a high level, Arduino like API to program the microcontroller in the STM32F3DISCOVERY. Check out the documentation! It has instructions on how to get started and plenty of example programs!

Here’s the list of features as of version 0.1.0

  • Zero C code/dependencies (yay, one less build step that can go wrong)

  • High-level, Arduino-like API over LEDs, sensors, timers, etc. (But there’s only two high-level modules right now: led and delay. More to come soon!)

  • An iprint! family of macros to send print!-formatted messages to the host over the ITM (Instrumentation Trace Macrocell). IOW, you can send messages to your laptop over the same USB cable that you are using to debug your program.

  • By default, panic!s also send their messages (cause + filename + line number) to the host over the ITM.

  • The default exception handler (the function that runs when you crash your system) tells you (over the ITM) where your code crashed and under GDB it also gives access to the stack frame that triggered the crash so you can inspect the state of your program (CPU registers) at the moment of the crash.

  • By default, everything (LEDs, sensors, etc) is initialized before the user entry point, main. So everything Just Works inside main.

  • The default behavior of panic!, the default exception handler and the default pre-main initialization code can all be overridden.

The documentation of this crate does not have information about how to actually “flash” Rust programs into the microcontroller or how to debug those programs using GDB. But the Copper book does! So check that out as well.

Off-topic: I wish Cargo had some feature to build and include the documentation of a crate examples (examples/*.rs) in the main cargo doc output. I had to hack a shell script to implement that feature; the examples module was generated using that script.


#2

Hi,

This sounds great, I’ve had a couple of STM32F4DISCOVERY boards sitting in a draw for maybe 3 years now, they were on offer at the time, life got busy and I had a son but hopefully I can find time to play with them some time in the next few months. This looks like potentially a nice ‘in’ to the platform, while I’ve dabbled with C I’m not fluent and the build / toolchain and C’s warts were enough of a barrier to entry to put me off, it’s possibly also a good intro to Rust (in that there’s some smallish projects I’d like to dabble with as motivation).

I wonder how different the F4 may be from the F3, looks like different sensor chips and number of LED from a high-level.

http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/stm32f4discovery.html

They’re so cheap though it’s probably just easier to buy the exact same board initially until I gain more experience.

Anyway, just want to say thanks, this looks cool, hope I can find some time to play with it.

Cheers,
Paul


#3

Good job ! I was was waiting for some template for working with Cortex-M chips with Rust. Definitely something worth looking and I hope you will not stop there :slight_smile:


#5

I have a very similar project called primer, which is for the Stellaris (aka Tiva-C) Launchpad from TI. This uses a Cortex-M4F. I was about to add support to the Leaf Labs Maple Mini (an STM32F103) but it sounds like maybe what I need to do is smoosh these two projects together?

Or is there a danger we’d just make another zinc? Because I’ll be honest, I don’t want that - I wrote my own because I wanted something simple. But I particularly like your ITM support.

xargo ftw, btw.

Edit: wrong account


#6

Supporting more boards is something I want to do / work on / think about but what I don’t want to do is create a single repository that supports a bunch of boards because it’s a lot to work to maintain. Instead the way I want to make this work is to have a bunch of small crates and tools that make bootstraping support for a board easy. In that regard, I have already created the following crates/tools:

  • cortex-m. A crate to work with Cortex-M processors. It provides an API to access core peripherals like NVIC and SCB, also provides functions to access CPU registers like LR, PC and PSR, functions that wrap assembly instructions like bkpt and wfi and common data structures like the vector table and a stack frame.

  • r0. Startup code in Rust. zero_bss and init_data. Simple.

  • svd2rust. A tool to generate an API to access peripheral registers from SVD files. Most vendors release SVD files for their micros so you can use those files and this tool to save yourself the trouble of writing all the memory maps yourself (which is a lot of work!). If you don’t like the API this tool generates, there’s an alternative: svd-mmap. If you don’t like that API either, it should be simple to create your own using those tools as examples.

Then I want a bunch of different people to use these common crates/tools to start hacking different boards and come up with their own high level API (higher level than direct register manipulation). Then we can all sit down and discuss how our APIs are similar/different and, hopefully, come up with interfaces (traits!) that we can all agree on so we can provide a consistent API / user experience. (Yeah, I know I’m a dreamer, but I’m not the only one)

xargo ftw, btw.

:heart:

@thejpster we are discussing issues like these in this repository if you feel like sharing your opinion. We are also on the #rust-embedded channel (Mozillla’s IRC network) if you want to talk about Rust on embedded systems.