#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

#26

thanks, that line of code got lost when I switched computers, it works now again, yey!

#27

I have developed for the Blackfin before (bootloader, kernel, and app development) and used Ubuntu (Xenial), but that was for a client who provided the PC hardware to host Ubuntu. If I can get started on Aleph, I would want to host the tools on Mac.

It is possible to have a case sensitive filesystem on macOS, but you probably need a second partition so that the boot drive can be standard mac insensitive. I have an old cvs repository that I needed to host on my new mac mini, and found that it also needs a case sensitive filesystem. I simply created a spare 100 GB partition and formatted it with Mac OS Extended (Case-sensitive, Journaled). I now place projects on that drive when needed.

I realize that this thread is eighteen months old, but I just got here.

#28

File system case sensitivity was the primary (but not sole) sticking point with getting the blackfin compiler built under macOS IIRC. Ultimately I ended up just switching to developing in full linux vm.

#29

ok, maybe i’ll give it a try on my case-sensitive partition

#30

sorry to bump this old thread, but i’ve had a great deal of trouble finding the blackfin gcc binary package for OS X. does this exist anywhere known? i can definitely afford the space for a case sensitive partition for it.

#31

I was never able to locate a prebuilt copy of the blackfin gcc toolchain for macOS nor was I successful in building it from source so I personally resorted to a Linux VM (specifically a tweaked copy of the vagrant setup mentioned above; https://github.com/bensteinberg/aleph-development).

1 Like