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 http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx 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: https://gist.github.com/zzsnzmn/46994b83c8a51fcb4781

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 git@gist.github.com:46994b83c8a51fcb4781.git 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 git@github.com:tehn/mod.git ./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/
make

cd ../earthsea
make

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

I could have gone that route, but I preferred making it so that I could have the same interface if I wanted to develop on windows or linux. I’ll try and get an image posted to the docker hub this evening. Barring the initial overhead of learning how docker works, it’s nice being able to use the “same” environment in multiple places.

Once I clean up the code, I’ll post the firmware hack I made. It’s basically just an implementation of fourths for the whitewhale :P.

1 Like

I tossed the docker image up onto the public docker hub: https://hub.docker.com/r/zzsnzmn/monome_mod/.

The little fourths hack is here: https://github.com/zzsnzmn/mod under the “/blank” folder. It’s pretty rough and depends on the clock being turned up high for the lights to change, but it’s nice if you want to create pad based things and play rather than sequence whitewhale. Once I get some more free time I’ll split up voltage control so each half controls a CV out, I would also like to create realtime recording/looping functionality but I need to think about how that would work first.

I think it would be nice to try and create a template of partially implemented functions so other people that want to get into modding the eurorack firmware have a lower barrier to entry. I was trying to do that with the “blank” project, but ended up getting side tracked…

3 Likes

How are you folks flashing/debugging code on the avr32?

Are you using the FTDI interface as mentioned here: http://monome.org/docs/modular/dev/

Or a Pololu USB AVR programmer as mentioned here: http://llllllll.co/t/problem-re-flashing-original-40h-kit-firmware-help-much-appreciated/1014/5

Or something else?

DFU programmer as described here: http://monome.org/docs/modular/update/

And in case you’re wondering the DFU programmer can’t overwrite the bootloader (i.e. you can’t brick the module).

Cool. Thanks for the link on how to use the DFU programmer to flash firmware updates w/o risk of overwriting the bootloader.

What about loading and debugging code during development (e.g. setting breakpoints, stepping thru code, examining registers and vars, etc)?

Does anyone use AVR JTAG programmers AVR JTAG ICE MKII or AVR-JTAG-L?

Has anyone tried using this Intellijel USB ISP? https://intellijel.com/product/usb-isp/

no JTAG is available-- breakpoints, stepping, etc.

there’s a UART header on the back of the PCB for debugging via a serial terminal.

intellijel programmer is not compatible

Excellent! Thanks for clearing that up.

UART log debugging will work.

Do you recommend sticking with DFU programming?

Is there a benefit to using a USB ISP and if so do you still recommend the Pololu USB AVR Programmer V1 or the newer Pololu USB AVR Programmer v2?

i really need to set up UART at some point. my debugging consists of having a special key combo to enable the ‘debug’ mode where 2 or 4 rows on the grid are used for binary representations of some variables i need to watch…

Oh, very cool idea. So the UART header is on the PCB… but I guess setting it up means initializing it? Is it not configured/on already?

After doing some more research on flashing the AVR, I appreciate why DFU programming is the way to go. The USB AVR programmer is for flashing everything which could kill the boot loader and make my head hurt and heart ache. And if I want to use JTAG then I could get an EVK1101 for code development and then port over but I’d rather just get another monome module :slight_smile:

I’ve been working on some stuff and doing a buncha passing around pointers stuff like:

void set_tr_defaults(tr_row *t) {
    t->loop_start = 0;
    t->loop_end = 15;
    for (int i = 0; i < 16; i++) {
        t->steps[i] = 0;
    }
    t->pos = 0;
    t->cut_pos = 0;
    t->next_pos = 1;
    t->triggered = 0 ;
    t->mute = 1;
    t->pattern = 0;
}

set_tr_defaults(&tr_row_1);

void draw_tr_row(tr_row *t) {
  ... some other stuff ...
}

draw_tr_row(&tr_row_1);

Is there any performance impact to passing around pointers to other stuff like this for embedded programming? I figure there isn’t since it’s just passing the location of tr_row_1, but I’ve all but forgotten everything I learned about C from school :X.