#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

#37

very late reply, but just for the record:

yeah on aleph, release builds (R=1) preprocess out the print statements entirely. but this was done with a tiny mod to the ASF, which got thrown out in libavr32.

recently refactoring aleph for libavr32, i just stuck the modified print_funcs sources in a new avr32/ folder for common avr32 code in the aleph repo. if modules want to use the same mechanism (and i recommend doing so, or something like it, because serial print functions actually take up a lot of time) then we could do things differently (use our own print funcs in libavr32 and prune them from ASF.)

#38

Figured out a hack to get my 64 working, however I’m not sure how safe it is. Determined that when I plug in the 64 the device is requesting a max of 500mA of power. I modified https://github.com/monome/libavr32/blob/7f412663eb97c6e7ac3aa4f78101215191349802/conf/conf_usb_host.h#L19 and bumped it up to 501 and it is now connecting and responds to button presses and everything correctly.

But like I said, I’m curious how safe it is to bump that value up. I’ve got a synthrotek PSU with 3A +12V, 1.3A -12V, 1.5A +5V with a decent amount of headroom for 5V, but I wasn’t sure if the 300 mA max was to protect the whitewhale or to protect PSUs. Or if the 300 mA was even for the 5V rail…