Rebuilding the Striso Firmware

Since there’s been an uptick in interest in what can be done with the Striso. I’ve put together this quick set of instructions for re-building it’s firmware. These aren’t complete, and don’t go into modding the Faust code. But should be enough to get started.

All commands here are going to be in the command line, unless otherwise noted.

Setting up to hack it

These instructions will work straight out for Linux, and should work with a bit of modification for a Mac. For Windows, while I’m sure there’s a ‘native’ windows solution, my suggestion would be to install WSL which will let you do Linux things on Windows.


You’ll need the following packages:

  • git
  • make
  • wget
  • binutils

In linux you can do this just with:

  • sudo apt install git make wget binutils

Next you need the ARM toolchain, I was able to install it with these steps.

  • ARM Toolchain has instructions to install it… the download part didn’t work for me, the instructions don’t play nice with site changes. You can download it at ARM Developer. The version I’m using is gcc-arm-none-eabi-10.3.
  • Rename the file you downloaded to gcc-arm-none-eabi.tar.bz2, then continue with the instructions from ARM Toolchain at the third step “Create a new directory to store toolchain files:”

Building the striso firmware:

  • Select a directory to put the repository in. (I like making a directory called repos and will call it that for ease)

  • cd repos

  • git clone --recurse-submodules -j8

    • Note, --recurse-submodules will pull in all the modules that striso needs to build. -j8 just speeds the process up.
  • cd striso-control-firmware

  • This will be in the master branch, which will include whatever Piers is doing at this very moment. (Hey @pierstitus , any chance of adding a ‘current release’ tag?) this might well be broken at any given time. To get a working branch go to the github repo

  • From here, building is easy: make

  • It will create a file at ./build/striso_control.uf2

  • The instructions to install it are on the github repo:

    • Hold down the “config”(square) button on the Striso and plug it into your computer.
    • On the USB drive that becomes available, copy your new striso_control.uf2 to it.

Yeah, but does it work?

Here’s a stupid trick to check if your build works, change the light behavior by opening the synth_control.cpp button and changing the ws2812_write_led command for any of the button presses. I like changing it for volume. Recompile with make and see if it uses your new color.


I don’t have a striso…
however, do a fair amount of cross-platform dev on my mac for embedded processors,
and its great to see help for fellow developers getting started, as it can be tricky !
thanks for that @fkberthold !

anyway, just wanted to add some pointers for macOS users/developers,
you can pretty much follow the above, by using homebrew…, which is a fantastic tool in this area…
(they support both intel and apple silicon :+1: )

easy to install

/bin/bash -c "$(curl -fsSL"

then pretty much it’ll be same commands, just use brew install instead…

brew install git make wget binutils

you can even install the arm toolchain

brew install --cask gcc-arm-embedded

btw: the website is good for seaching for packages.

to be unbiased , you can do similar with MacPorts , but I personally prefer home-brew.
note: you should NOT used both, as this can create a lot of confusion !

I really love homebrew, brings the benefits of linux command line to the Mac, quickly/simply, and without ‘disturbing’ and potentially breaking macOS.

anyway… hope this might help others get started if they are using macOS.

disclaimer: as I said, I don’t have a striso, so whilst Ive used this for other systems, it may not be entirely complete… so feel free to comment below, if something is wrong/missing. but should give you a nice starting point.


Thank you both so much for this guidance. I’m on the path!

I used HomeBrew to install the tools since I’m on a Mac and I successfully cloned v2.1.4 from git into a new folder I named striso.

I ran into a problem when trying make from striso-control-firmware though:

Creating build/striso_control.bin
/bin/sh: readelf: command not found
Traceback (most recent call last):
  File "uf2/utils/", line 353, in <module>
  File "uf2/utils/", line 296, in main
    appstartaddr = int(args.base, 0)
ValueError: invalid literal for int() with base 0: './build/striso_control.bin'
make: *** [build/striso_control.uf2] Error 1

Any ideas where I went wrong?

Hi Steve,

Second line of the error is your problem.

/bin/sh: readelf: command not found

In the list of packages you need, one was binutils, it has readelf. A quick search says that it should be available as a brew package, so:

brew install binutils

Should solve your problem. Barring that, you might have a path problem.


Thanks Frank. It looks like brew installs tools with a ‘g’ prefix. So in /usr/local/opt/binutils/bin I have greadelf instead of readelf. Still tinkering to fix it.

you’ll likely want arm-none-eabi-readelf
which Im pretty sure is installed with gcc-arm-embedded, see above.

1 Like

Thanks, you two! Somehow today it decided to work, not sure why. I knew I restarted terminal a couple times after making changes to test, but who knows, maybe I missed it after the critical test. Either way, glad it’s working now. Time to play with those tuning files!


Great instructions, I was able to get this working without any big problems on MacOS 11.6.6. Initially I had similar problems lie @mcgreave with missing readelf on the path, but didn’t see that brew install binutils outputs:

binutils is keg-only, which means it was not symlinked into /usr/local,
because Apple's CLT provides the same tools.

If you need to have binutils first in your PATH, run:
  echo 'export PATH="/usr/local/opt/binutils/bin:$PATH"' >> ~/.zshrc

For compilers to find binutils you may need to set:
  export LDFLAGS="-L/usr/local/opt/binutils/lib"
  export CPPFLAGS="-I/usr/local/opt/binutils/include"

So after putting it on my PATH everything worked great. Good tip with modifying the led colors to just see that changing the code works. Will dig a bit around now to see how things are structured, hope to hear more around Striso hacking on this forums!


yeah, a few things you might need/want to add to your path.
I tend to have various ‘setup functions’ defined in my .zshrc, each for different projects.


ssp-setup() {
export PATH=/opt/homebrew/bin:"${PATH}" 
export BUILDROOT=~/xc/arm-rockchip-linux-gnueabihf_sdk-buildroot
alias rebuild_cmake="cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../xcSSP.cmake .."

this allows me to quickly get up n’ running, but doesn’t ‘pollute’ the global environment too much.

also in my projects, I tend to use env vars for locations, so that users can use tools not installed onto the global path… and then just ‘default’ these to the global path if the var does not exist… so best of both worlds.
but many different ways to do this… so whatever works for you :slight_smile: