#1

For those developing for the Aleph which OS are you using to host the toolchain, Mac, Linux, … Windows?

I’d like to be able to develop both apps (avr32) and modules (blackfin).

Building the avr32 toolchain from source on Mac OS X 10.10 was fairly straight forward (makefile fixes) and things seems to work well (tested by rebuilding source for whitewhale and earthsea euro modules and re-flashing them). Getting the blackfin toolchain built under OS X looks to be a lot of work (it wants a case sensitive filesystem :frowning: )…

So I switched to trying Ubuntu 14.04. Getting the precompiled blackfin toolchain running was easy but it took a lot of trial and error / hacking to get the avr32 toolchian compiled as above. In the end I had to build an older version of texinfo (version 4.13) and hack one of the files generated by gperf (removing __inline__ in one place) to get things compiling.

I’m not 100% confident in my Ubuntu environment yet after trying to use a release of bees 0.6.0 I built (lot’s of hanging problems when loading scenes). I’m new to the Aleph so some of my problems with the resulting build could well just be pilot error.

What platforms are you using?

Github reorganization
#2

i use mac 10.10 for avr32 and ubuntu for the blackfin.

thanks for fixing the ftp links on the avr32 build!

re: hanging problems with the new Bees, we’re checking this out-- i suspect it’s a simple issue of filenames.

1 Like
#3

I’m using ubuntu for dev of both. If you are on a mac though, there’s a good vagrant box that one of the aleph users setup for aleph dev here: https://github.com/bensteinberg/aleph-development

1 Like
#4

Excellent! The thought using vagrant to maintain a clean development environment occurred to me this morning. Thanks for the link!

#5

Ah yes. I see the problem (the module reports its name as “aleph-waves” but the build creates just “waves”. Which way are you leaning; prefix or no prefix?

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