Rust starter for Daisy Seed

I got my Daisy Seed earlier this week (Tx Michael!) and put together a simple starter project for using the Daisy Seed with the Rust programming language:

Currently it just implements a basic “blinky” which flashes the Seed’s user led.

A good place to go digging for more example code is the examples directory in the stm32h7xx-hal crate.

The instructions for use go something like this:


Install arm target for Daisy

rustup target add thumbv7em-none-eabihf

Install gdb

# install via macports (TODO homebrew, linux, windows)
sudo port install arm-none-eabi-gdb

Install openocd

Install from source or get it from:

Generate project

cargo install cargo-generate

cargo generate \
    --git \
    --name your-project-name

Flash and run

  1. Plug a 2x10 mini adapter into the Daisy Seed with the red stripe facing up towards the white stripe.

  2. Connect the other end to a ST-Link or similiar programmer.

  3. Start openocd in one terminal:

     cd /path/to/your-project-name
  4. Run program in another terminal:

     cd /path/to/your-project-name
     cargo build
     # some programmers may need you to hit the reset button on the Daisy Seed at this point
     cargo run

Update 24 November 2020

I’ve started working on an Embedded Rust “Board Support Crate” which adds support for working with audio & midi.

The hello-daisy starter now makes use of the daisy_bsp crate and you can find some examples of how to use it here:


So you’re clocking it to 480Mhz, but libDaisy uses 400Mhz. I thought it has a chip from the older revision that doesn’t support this frequency. Are you overclocking on purpose or are Daisy developers too conservative?

Good question, I don’t actually know!

You’re right about the revisions though, 480 MHz has only been supported since revision V of the STM32H7 chips which came out April last year.

All my Daisy hardware has the revision V chip but I only bought a couple months ago so it’s possible some of the earlier hardware has an older revision?

I could probably add a compile-time feature to drop down to 400MHz if it ends up being a problem for anyone.

It very well may be that libDaisy code uses such settings to be compatible with older board revisions. Let’s hear what @shensley has to say about this.

The very early development daisy boards were done using the older, original revisions and so we had our clock tree set up for 400MHz since that was the max at the time.

I have an updated, ‘boosted’ clock tree pretty much ready to go, but it needs some testing to verify external memories still behave, and it may require adjusting things in some of the peripheral classes (i2c timing values come to mind). It also tightens up the SAI clocks to be well within 1% of the target sample rates, etc.

The commented out lines 116 and 132 in src/system.c can be swapped out for the lines directly above them to run at 480MHz if you need it.


For reference, this must be the branch mentioned above. I guess I’ll change clocks accordingly for OWL firmware fork. Free MCU upgrade FTW!


That is indeed the branch. Totally meant to link to it in my comment, and then got pulled away from my desk and forgot.

There were some weird things on that branch with the new clock tree, but I think most of it was the build I was using didn’t tell the HAL what frequency the HSE was (which is now in the CFLAGS). But it’d be worth running some tests on the external memories, and making sure typical things still function as expected (audio, adcs, etc.).

I’ll try to get this added into the modern libdaisy ASAP. I want to compare power consumption between 400/480 as well so we can make it optional (if it matters). Though at some point I want to add some more in-depth configuration of clock speeds to the PAI make this a bit more power-friendly for lightweight DSP that might want to run on a battery.


Definitely make clock speed programmable, or even adaptive like the Pi later on, as the H750 gets pretty warm at 480MHz. Running flat out for no purpose isn’t a good move if you don’t need the performance.

1 Like

I want to code for the Daisy in Rust, and I gave this starter a try.

At first, I struggled to see how to get it working, because the instructions use an ST-link programmer, openOCD, and GDB on a mac. Well, I don’t have a mac or a st-link, and I wanted to get something going that was simple (like the daisy web programmer).

It took a lot of googling and experimentation, but I’ve got it working! I want to report back how you can make this work from linux mint with just a USB cable.

Disclaimer: I have no idea what I’m doing with rust, or with embedded development. However, I’m pretty sure it’s actually working.

Here’s what I did. First get the rust toolchain:

rustup target add thumbv7em-none-eabihf

Then get the daisy-bsp github repo:

cargo install cargo-generate

cargo generate \
    --git \
    --name your-project-name

(so far it’s the same as the original instructions)

Make sure you have dfu-util:

sudo apt-get install dfu-util

(or equivalent for non-ubuntu systems)

Then get bin-utils for cargo:

rustup component add llvm-tools-preview

cargo install cargo-binutils

In the cloned repo, compile as usual:

cargo build --release

But then you need to take the ELF binary and dump out the compiled code in a raw binary format:

cargo objcopy --release -- -O binary hello-daisy.bin

At this point, put the daisy seed into DFU mode by holding boot and hitting reset. You should see two entries with the same ID (0483:df11) when running dfu-util --list

Then you can flash the binary-dump file with:

dfu-util -a 0 -s 0x08000000:leave -D hello-daisy.bin

That’s it!

I’ve only tested with variants on the basic blinker example in the BSP repo, but I have the toolchain going at this point so I’m pretty confident :slight_smile:

Next up is audio examples from the BSP repo (EDIT: working!), then figuring out how to access the hardware on the daisy pod.

Massive thanks to @antoine antoine for writing the BSP. I’m excited to see where this goes.


Something about :leave in dfu-util was causing issues with the daisy. I was getting audio errors until I stopped doing that and started hitting the hardware RESET button. I’m now flashing without it, which prevents the dfu-util error that usually show up when finishing flashing.

So, uh, if you’re trying this and can’t get any sound, or get weird and inconsistent errors when flashing, try resetting it with the hardware button after flashing.

1 Like

I’ve got a Daisy Pod on order and I’m using it as an excuse to learn Rust. What’s the best way to get started, assuming I know a lot of digital signal processing and have been programming in other languages for years?

1 Like

Probably taking a look at daisy_bsp and libdaisy_rust on github, and/or asking questions on the #rust channel on the daisy slack.

For general rust embedded, there’s a work-in-progress book. You should also look into embeddded_hal.

… at least that’s what I’d suggest. I’m pretty new to both rust and embedded dev.

1 Like