Eurorack firmware modding

starting a thread on eurorack firmware modding/hacking.

the official framework and firmware:

i’ll post a template for arc development next week, basically just bare bones with some comments to make it easier to get started. in any case i found the framework very easy to use, it’s pretty self explanatory. take a look at skeleton\monome.h to get an idea of how to interact with grids/arcs.

in the meantime i’ve got a git/hub related question:
i’ve forked the official repo and added my orca code to my fork. i’ll move it into a separate repo at some point, but want to keep the fork in case i need to make any changes to the framework itself so that they can be pulled back into the original repo.

now i’ve made some commits to my fork, and there is a separate commit for the framework change. my question - is there a way via the github web UI to create a pull request for that specific commit only? or do i need to use the command line? tried poking around but could not find a way, if i try to create a pull request it seems to include all the commits to my fork.

excellent, and thanks again

i was going to request someone add more comments to the code, so this sounds like a great start

my hope is i can get the build process running in xcode, as its my tool of choice these days. anyone who gets that happening wins an internet awesome point from me

I’m on windows (dont remember now but pretty sure I used the Atmel AVR toolchain), so not sure about Mac but a quick google search returned this:

I need to install a proper IDE at some point too…

1 Like

thanks for that, exactly what i was looking for

will make an initial attempt at getting this building in Xcode this week, and will report in

You can make a new branch in your fork, and then cherry pick the framework commit. Then send out a pull request for that branch.

So you’ll need to do something like this:

# go back to an older commit upon which you'll base your branch
git checkout <commit before you started making changes>
# create and check out the new branch
git checkout -b framework-patch
# cherry-pick the commit with the framework changes
git cherry-pick <commit hash of framework change>

Then push your branch up to github, switch to in the UI and initiate a pull request, there should be a link for this when you visit your repo page after uploading the branch.

Hope that helps :slight_smile:

1 Like

@kisielk - thanks! so I need to create a branch - thats the part I missed. just thought maybe there was a way to cherry pick using the web UI. will give this a try!

ok. i’ve made a template for arc white whale firmware, hopefully should make it easier to get started.

i’ve added a bunch of comments throughout the code so should be pretty self explanatory but if something’s not clear / not working as expected let me know, i’ll be glad to help.

you can find it here:
there is a readme file with instructions, follow those to get your template set up.
the template firmware simply lights LEDs as you turn the encoders, and the first 2 encoders control values which get output on CV A and CV B.


Hey @ether, any luck getting Xcode setup to build? EDIT: It seems X-AVR depends on avrdude, which I think only handles 8-bit MC’s? (at least CrossPack only does) so I’m not sure an X-code build is an option, at least with X-AVR (still a nice resource for 8-bit MC’s I guess). Does that mean I’m using gcc at a command line to build? I have some path(?) issues with gcc finding header files, might have to build my own avr32 tools instead of using the packaged installer. I’m learning a lot as I go here, feel like a bumbling moron, please forgive my ignorance. Any guidance is welcome.

@scanner_darkly, what did you use on windows? Decided to try installing and running Atmel Studio using Parallels, was able to get a project for the right at32uc3b0256 MCU, copied my code into main.c, and it builds. So now I guess I’m waiting for the MP to get here to see if that all actually worked. I’d still like to get it working in OSX.

I still haven’t gotten any feedback on the concept of adding an output matrix to MP’s functionality, which has me thinking the idea may be meritless. Still, I want to see through this little project (described in more detail) for the learning experience, and get a chance to actually play with the idea in action before I completely dismiss it.

don’t remember exactly but i think it was the standard Atmel AVR toolchain for Windows. i also had the Studio installed at some point.

i think if it builds you’re good to go.

@sphiralstudios - haven’t had a chance yet. i have a t shirt somewhere that says “very busy” on the front, and “very lazy” on the back. that’s me to a t :wink:

i’d still like to explore this, but i’m probably going to have to watch from the sidelines for a while due to other commitments.

if I do make any progress i’ll stick my hand up. inspiration may strike.

i notice there is some usb midi infrastructure in the mod repository for the euro modules.

is this code from the aleph? i wonder how hard it would be to work alternative controllers into the eurorack module code.

1 Like

yes. i haven’t tested it. conceivably it should work.

1 Like

I’ve been trying to build the firmware on a linux machine. The only way I can get them to compile is if I copy the avr32 headers into the folder I’m running make from. Is there something I need to do to ensure that these headers are sourced properly?

The error in question:
../xdk-asf-3.17.0/avr32/utils/compiler.h:62:22: error: avr32/io.h: No such file or directory

Copying the headers from allows it to compile fine.

(edit, sorry for the unrelated response - that is what I get for trying to respond from my phone)

Regarding compilation problems - I don’t recall needing to do anything special.

It sounds like the compiler is not getting the right include paths set, questions which come to mind:

  • did you build the avr32-gcc toolchain yourself or install pre-built binaries?
  • how are you invoking make? Is it from one of the module specific subdirectories (like earthesea)?

If you run make clean then run make -n what does the invocation of avr32-gcc look like? In my dev tree the include paths are getting setup like so:

avr32-gcc  -march=ucr1 -mpart=uc3b0256  -g3 -MD -MP -MQ ../earthsea/main.o -Os -D BOARD=USER_BOARD -D UHD_ENABLE -D __earthsea__ -I../xdk-asf-3.17.0/../earthsea -I../xdk-asf-3.17.0/../skeleton -I../xdk-asf-3.17.0/../skeleton/conf -I../xdk-asf-3.17.0/../skeleton/usb -I../xdk-asf-3.17.0/../skeleton/usb/ftdi -I../xdk-asf-3.17.0/../skeleton/usb/hid -I../xdk-asf-3.17.0/../skeleton/usb/midi -I../xdk-asf-3.17.0/../teletype -I../xdk-asf-3.17.0/avr32/boards -I../xdk-asf-3.17.0/avr32/drivers/cpu/cycle_counter -I../xdk-asf-3.17.0/avr32/drivers/flashc -I../xdk-asf-3.17.0/avr32/drivers/gpio -I../xdk-asf-3.17.0/avr32/drivers/intc -I../xdk-asf-3.17.0/avr32/drivers/pm -I../xdk-asf-3.17.0/avr32/drivers/spi -I../xdk-asf-3.17.0/avr32/drivers/tc -I../xdk-asf-3.17.0/avr32/drivers/twi -I../xdk-asf-3.17.0/avr32/drivers/usart -I../xdk-asf-3.17.0/avr32/drivers/usbb -I../xdk-asf-3.17.0/avr32/utils -I../xdk-asf-3.17.0/avr32/utils/debug -I../xdk-asf-3.17.0/avr32/utils/preprocessor -I../xdk-asf-3.17.0/common/boards -I../xdk-asf-3.17.0/common/boards/user_board -I../xdk-asf-3.17.0/common/services/storage/ctrl_access -I../xdk-asf-3.17.0/common/services/clock -I../xdk-asf-3.17.0/common/services/delay -I../xdk-asf-3.17.0/common/services/usb/ -I../xdk-asf-3.17.0/common/services/usb/uhc -I../xdk-asf-3.17.0/common/services/usb/class/hid -I../xdk-asf-3.17.0/common/services/spi/uc3_spi -I../xdk-asf-3.17.0/common/utils  -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror-implicit-function-declaration -Wpointer-arith -mrelax -mno-cond-exec-before-reload  -std=gnu99 -funsigned-char -fno-strict-aliasing -ffunction-sections -fdata-sections -c ../earthsea/main.c -o ../earthsea/main.o

Figured it out!

“It sounds like the compiler is not getting the right include paths set” was absolutely right. I copied the headers from avr32 into <AVR_TOOLCHAIN_LOCATION>/avr32/include and it works without the duplicated directory.

I made a Dockerfile that you can use to build the firmware if you’re running OS X as well:

this is intriguing. can you explain the rationalization for running this inside of docker? i’m looking for a more basic how-and-why i guess.

I’m probably guessing a simple way of standardisation - compiler config and paths can be a nightmare for the uninitiated. Olivier over at Mutable now supplies an entire dev environment - toolchain, compilers, configuration - as a Vagrantfile; it basically means you can guarantee anyone developing the code has exactly the same config as each other.

I love Vagrant, it’s a great way to make complex environments easily replicable.

I’m not sure Docker is really appropriate for most dev environments. Docker is designed to make immutable server instances. Dev environments are by nature mutable. It is possible to bend/twist Docker to work in a Vagrant-ish way for dev environments (and you can even use Docker with Vagrant), but when writing code I’d prefer to do without containers and just use Vagrant unless my goal is produce production server environments that need high availability, or to make it easy to reproduce very complex environments (say you wanted to create reproducible tests for a complex network topology or something).

It was easier to get docker running since I couldn’t find a precompiled version of the tool chain for OS X. What I’ve been doing is running ubuntu in a docker container that’s mounted to a workspace directory and use my standard dev environment with vim outside of the container. The same could be accomplished with Vagrant and sharing a directory with the host system.

You will need to install virtualbox and docker-machine.

Steps to run the file locally:

# initialize the host virtualbox image
docker-machine create avr -d virtualbox

# Set the DOCKER_HOST and DOCKER_MACHINE environmental variables
docker-machine env avr
eval $(docker-machine env avr)

# clone the example gist
git clone docker_mod_env
cd docker_mod_env

# build the docker container
docker build -t docker_mod_env .

# make workspace directory and clone mod repository
mkdir workspace
git clone ./workspace/mod

# run the docker container
docker run --volume $PWD/workspace:/root/workspace -it docker_mod_env /bin/bash

# build some things
cd mod/whitewhale/

cd ../earthsea

Normally I’ll edit outside of docker and then switch to a window running bash inside of the container to compile and then run dfu-programmer on my host. I’m glossing over many of the details, I’ll try and get some better resources together if anyone is interested, though the docker website is pretty good.

Getting the avr32 tool chain running natively under Mac OS X isn’t actually that bad, @sam and I have been keeping this avr32-toolchain repo functioning.

Assuming you have Xcode, the command line developer tools, and homebrew installed building the complete toolchain from source using the instructions in that repository is two commands and a bit of time (while things compile).

1 Like