#6

I’ll clean these up in the next couple of days along with some other minor fixes. We were using the ‘aleph-’ prefix, but realized it was totally unnecessary seeing as the DSP only lives in the one device and just takes up space on the screen. Hence removing the name from the string.

#7

anybody tried setting up the toolchain on windows?

when trying to build bees ran into some issues initially, applied quick fixes found on google, now it looks like it’s failing while executing \avr32_lib\asf-3.7.3\avr32\utils\make\Makefile.avr32.in, and looking at it i see this:

# aleph always linux
os_type         := Linux
os              := Linux

which makes me think there might be more required than just installing the Atmel toolchain for Windows… i can build the eurorack firmware no problem.

#8

i suspect you should be able to change these lines to match the modular’s makefile and all should be well.

#9

thanks @tehn, that worked!

copied the 3 files from the firmware folder \xdk-asf-3.17.0\avr32\utils\make\ to the aleph folder \avr32_lib\asf-3.7.3\avr32\utils\make\ and I can successfully build now.

#10

@ngwese,

@Yann_Coppier and I are trying to compile a version of bees that we added an operator to, but are stuck at the compilation step. We have 10.9.5 and 10.10.4, and installed your pre-compiled version of the avr32 toolchain (from here: https://services.droparea.de/blog/avr32-toolchain-for-mac-os-x). This doesn’t seem to work though. Can you direct us to what we are missing, please?

Regards
Søren

#11

I’d need more information like what command(s) you were trying to run and what the error messages are before I can point you in any meaningful direction.

For what it is worth I never ended up using the pre-built avr32-toolchain binaries on the droparea site. Instead I built the avr32-toolchain from source; I’ve forked to original droparea repository and made some minor changes to allow it to compile per the instructions under Max OS X 10.10 (should work on 10.9 as well).

At the moment I’m using a slightly modified version of vagrant vm mentioned above to do all the avr32 and blackfin compiling…

Aleph: route16 lag (solved)
#12

Hey @ngwese thanks for your reply - we got it working in the meantime though :slight_smile:

I think we were missing the mpfr, gmp, libmpc and texinfo at the point of writing that comment.

Our new operator (a route16) is working just fine, except the whole machine is extremely laggy…

#13

Did you make a debug build (with make) or a release build (with make R=1)?

…if you are monitoring the debug printing via a serial connection and using the debug build then things can get really slow or even fail if the amount of output is too high.

Commenting out the calls to print_dbg(...) in net.c can help reduce the output by quite a lot.

#14

Hey thanks again for your swift reply mate!

we only did “sudo make” (no R=1)… and we got 2 .hex files: one “dbg.hex” and one just “.hex”.
We then only moved (and installed) the .hex file.

So, is this .hex file actually a debug build? I thought that was only the dbg.hex… Well if so, that certainly does clarify things a bit.

cheers

#15

If you don’t use make R=1 both hex files will be the debug build. That should explain the issues you’re having!

#16

ok I’ll try it now, will let you know in a moment - thanks !

#17

It works perfectly - thank you so much for your fine and fast answers, and thank you Søren as well, that was a big step ahead for me !!

#18

…it sounds like you have things working now. I did want to mention that I don’t believe you need to run make using sudo (i.e. you shouldn’t need to be root while building). The fact that you have files named just dbg.hex and .hex also sounds like something is partly broken. Building bees should result in:

  • aleph-bees-0.6.2.hex and aleph-bees.hex for release builds
  • aleph-bees-0.6.2-dbg.hex and aleph-bees.hex for debug builds
#19

Sorry, I was not being totally clear. They do have those names, I was just only referring to the end of files.

@Galapagoose thanks trent for clearing that up!

#20

you should also run ‘make clean’ when switching between debug and release… the differences are in the preprocessor so make won’t know to rebuild all the object files.

“make” - produces aleph-bees.hex and copies to aleph-bees-x.x.x-dbg.hex
“make clean” - wipes out compiled objects and aleph-bees.hex
“make R=1” produces aleph-bees.hex and copies to aleph-bees-x.x.x.hex

would probably be better to default to a release build. i’d be fine with changing it now while there aren’t too many people who would be confused by the switch.

#21

I don’t personally have a strong preference one way or the other. The current setup for debug versus release and the need to run make clean is documented in the development guide:

http://archive.monome.org/docs/aleph:development

…it might make sense to change it in concert with the greater documentation migration.

#22

thanks for clearing that out ezra! Ah it’s hidden on the archive, I probably should’ve known this somehow - thanks @ngwese

#23

just done setting up the avr32 toolchain again (building from source) now on OS X 10.10, it seems to work but there where a whole bunch of warnings during the final make of gcc/toolchain, much more than I recall from last time on an earlier os version, anyone else having the same experience?

#24

did something happen to the baud rate again for debugging? this worked on my old laptop:
screen /dev/tty.usbmodemNN 57600
tried some other rates but no success, on a mac mini now, hoping to continue using the screen command, just calling out to see if anyone is doing that too.

#25

it’s in the config.mk file, currently looks like 115200