#17

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.

#18

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).

#19

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.

#20

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
#21

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
#22

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
#23

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?

#24

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).

#25

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/

#26

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

#27

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?

#28

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…

#29

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:

#30

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.

#31

Should be fine. On a 32-bit MCU passing a pointer is equivalent to copying a 32-bit integer. Chances are it will just get loaded in to a register. Since you’re dealing with modifying a struct, it’s unlikely any of that would get loaded in to registers… the fields would be accessed with offsets from the struct’s base address. The resulting code would probably be nearly identical whether you’re using a pointer to the struct or a struct value. You can always check the code by using avr-objdump -S foo.elf (where foo.elf is the name of the elf file) to inspect the results of the compilation and see if the generated code looks reasonable.

#32

Random question: Do the makefiles for the eurorack modules support debug builds and release builds?

IIRC the aleph makefiles are setup such that make produces a debug build while make R=1 creates a release build. I thought the modules had the same setup but it appears as if they don’t… or maybe my recollection that release builds turned off debug printing is wrong. :confused:

#33

Been working on debugging a bizarre issue with the whitewhale. When compiling the software myself, plugging in a 128 kit the whitewhale works and everything is dandy. When I plug in my m64 (2007) none of the FTDI install or MIDI uhc code runs.

When it works on the 128 usb enumeration ends up throwing the following debug statements:

usb device connection: 00000A9C , 1
... snip FTDI install stuff...
usb enumerated: 00000A9C , 00000000

When the 64 fails:

usb device connection: 00000A9C , 1
 usb enumerated: 00000A9C , 00000002

So basically something is happening that’s preventing the usb device from registering successfully. Not a super strong C programmer, but I think the code path I’m hitting is https://github.com/monome/libavr32/blob/master/conf/conf_usb_host.h#L55 for the enumeration callback and the status code enums listed here https://github.com/monome/libavr32/blob/ec718209606be5df516496c474df9ae82df179ee/asf/common/services/usb/uhc/uhc.h#L179 indicate an overcurrent.

I’m curious is this is something related to my power supply of if there’s something else I need to tweak to get it to register properly?

Using the most recent compiled firmware from the github release works fine with the 64.

#34

which version of gcc are you using for the builds that you are creating yourself?

#35

here’s the related thread

i will test with my 2007 64. overcurrent is an unexpected issue-- wondering if the old model needs a modification

#36

The biggest mystery to me is why does the 1.5 release version work fine, but not latest.

@ngwese avr32-gcc (AVR 32 bit GNU Toolchain--6711e09) 4.4.7