Making firmware hacking easier


This week, I plan to fix a couple of things to make the firmware hacking of modules easier.

The first step is to provide an official build environment that can be installed with only a few commands. I settled with VirtualBox running a Linux virtual machine, the whole thing managed by vagrant. It’s still a tiny bit of work to install VirtualBox and Vagrant on OS X / Windows / Linux, but from there we can all have the same development environment.

You can find the vagrant file and virtual machine initialization script * here *.

The second step is to progressively check that the firmware of all modules are not over capacity (code size and/or CPU) when compiled with a more recent versions of gcc than the antiquated 4.5.2 originally used during the development of braids (2012 !). For this purpose, I have rewritten a significant part of Braids’ code resulting in leaner and faster code, that is not so ticklish about compiler version. A few more tweaks and I’ll be able to publish a release candidate of the Braids code by the end of the week. After that, I’ll focus on all the other STM32F1 modules (Tides, Frames, Peaks, Yarns, and Streams).


wow and USB support. Just in time for a new linux box


Hot damn! I’m excited! :slight_smile:
Thanks again for all of your work and commitment to staying opensource!


This is cool, thank you pichenettes!



Thanks a lot for making your products living and evolving gems !


Confirmed working on 64 bit win7 and win10 using bitvise as the SSH client.

I see the STlink in the USB devices, is that confirmed working? That’s one thing I’d love to get working in a linux shell


Great! Looking forward to the firmware refactorings and the compiler upgrade which was indeed much needed.

Isn’t Vagrant a bit overkill for the task though? Last time I used it, it was to install a dev env of gigabytes of Java, C and Scala shared library and complex configs of database servers and… Compare to this, you only need the cross-compilation toolchain, don’t you? Anyway, he who can do more can do less I guess.

A small remark though: in my experience, it’s never good to stick with one particular compiler version. It can result in brittle code that is hard to debug and port, because you are using particular bugs or idiosyncrasies of that version. On the contrary, code that can run on, say, 3 minor versions of GCC will be very robust and time-proof. I know, it’s a lot of work, but it will save you some in the long run.


> is that confirmed working?

No, I don’t have one. I would appreciate if someone wrote a makefile rule for sending files to the device with stlink, though. It seems to be a popular device.

> Isn’t Vagrant a bit overkill for the task though?

Any other way of publishing a linux installation “recipe”. I’m not too keen on publishing an already “frozen” VM environment - the file is too large!

> it’s never good to stick with one particular compiler version

For the older projects, the problem is the CPU use and flash storage of the generated code. For the newer projects, there might be small issues of CPU use.

The alternatives are:

  • writing very large chunks of code in assembly.
  • downgrading the performance/audio quality of some products.
  • upgrading to a bigger processor (which one??) or overclocking with risks of unexpected glitches/failures.


@pichenettes You sir are a hero.


> Any other way of publishing a linux installation “recipe”. I’m not too keen on publishing an already “frozen” VM environment – the file is too large!

What’s the problem you see with the situation now?


No idea what I am talking about but could this be usefull as platform


> What’s the problem you see with the situation now?

Currently, to build the code, you have to install a bunch of stuff, which might or might not interfere with things already present on your machine.

The goal is to provide a way of having on your machine, in as few steps as possible, a development environment “blessed” by Mutable Instruments, be 100% sure that everything is correctly configured, and be able to throw everything away without messing with your machine in case you want to move on.


> you have to install a bunch of stuff

On a mac, it basically boils down to unzipping an archive wherever you want, and setting a path in the makefile stmlib, and install Python Libserial/OpenOCD if you want FTDI/JTAG support. Wouldn’t a step-by-step tutorial be quicker? Is it more complicated on Windows?

If you want it to be simpler than that, then you’ll have to go the VM route, but in this case a standard Linux distro with the tools, compiler and couple of text editors will suffice.


Nice! Having a known-good setup is quite useful, I ended up with a similar VM until I figured out my programmer hardware was defective and not openocd/drivers/system/me.


There are extensive and detailed notes on how to set up the toolchain etc on a Mac on this forum, compiled by @flocked, but lots of people on MW fell at that hurdle, it seems. Thus a packaged build environment seems like a good idea, although I wonder that people able to fiddle with the code can’t install toolchain. But then, lots of people who program for a living seem to need a graphical IDE these days. Have a standard toolchain with a standard compiler version is the more important objective, and a Vagrant environment seems like a good way of doing this. I’ll test it with ST-Link v2 when I get home next week.


I’ve added some stuff for ST-link support, and for installing the FTDI drivers. What’s missing: rules in stmlib/ for sending the firmware to the device with STlink.


Olivier, have you looked at my OpenOCD config for the ST-link v2? I’m not using the proprietary ST-link utilities, and it’s integrated in your makefiles. With a bit of massaging one could make it parametric on the adapter. Here’s the commit:


Thanks! Let me know if this works

You have to change the PGM_INTERFACE and PGM_INTERFACE_TYPE variables in stmlib/ and that’s it!


Cool, I’ll try the tiny version later! Wouldn’t ?= allow setting without editing the makefile?


pld: done!