On OS X 10.9.1, using CrossPack-AVR-2013-12-16, following these instructions:

$ git pull origin xt
$ git submodule init (note: there is a typo in this command on the firmware instructions page)
$ git submodule update
$ make
…
/usr/local/CrossPack-AVR/bin/avr-g++ -c -mmcu=atmega644p -I. -g -Os -w -Wall -DF_CPU=20000000 -D_PROG_TYPES_COMPAT_ -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -DDISABLE_DEFAULT_UART_RX_ISR -DATMEGA644P -DSERIAL_RX_0 -mcall-prologues -fno-exceptions shruthi/oscillator.cc -o build/shruthi1/oscillator.o
In file included from ./shruthi/shruthi.h:25:0,
from ./shruthi/oscillator.h:25,
from shruthi/oscillator.cc:16:
shruthi/oscillator.cc:478:46: error: variable ‘shruthi::Oscillator::fn_table_’ must be const in order to be put into read-only section by means of 'attribute((progmem))'
Oscillator::RenderFn Oscillator::fn_table_[] PROGMEM = {
^
make: ***** [build/shruthi1/oscillator.o] Error 1

I had to use CrossPack-AVR-20100115 in order for things to work, have you tried that?

Hmmm, is there any reason to suspect that the toolchain in Crosspack-AVR isn’t backwardly compatible?

Same error with the master branch.

Yes, there is a reason to believe that the toolchain in CrossPack-AVR isn’t backwardly compatible, due to changes in avr-gcc

Will wait for advice from Lord Krishna on best way to proceed…

Just tried it with CrossPack-AVR-20100115 on a different machine, and the firmware builds without error. Looks like I’ll have to downgrade the AVR toolchain for now, but perhaps this version dependency should be noted in the documentation, and maybe addressed at some stage. I doubt there is any great advantage in using the latest toolchain, but it i good to know which version needs to be used with the source code as it currently stands.

It’s possible to have several versions of AVR installed, and configure which version should be used, although I can’t remember the command off the top of my head, I’ll have to look it up.

Yup, but it is easy to downgrade, and then upgrade again later.

I’ve fixed the error. There might be other. I don’t have access to a machine with a newer version of the toolchain at the moment.

The Shruthi and Ambika codebases are so close to the full CPU and flash memory usage that they can’t actually be compiled successfully with the newer version of gcc since the “-Os” flag generates slightly different code patterns that make the code bigger and/or slower in some places. That terribly sucks, but you’re all guilty for it with all your insane feature requests.

And of course we’ll want even more features

Just a thought: can the ATmega1284P be used as a drop-in replacement for the ATmega644P ? It seems to have the same pinout, and does 20 MHz as well.

That would give you some breathing space … but perhaps not solve the speed issues.

EDIT: ah, there seem to be issues with this particular controller

@pichenettes: OK, thanks. Will try again with the latest avr-gcc. However it sounds like it might be best to stay with the Feb 2010 version of the CrossPack toolchain for now, for routine use.

Have successfully flashed v1.0 to a standard Shruthi1, compiled with the Feb 2010 CrossPack toolchain, using an Atmel AVRISP mkII programmer. With the XT/v1.0 branch, if you have a standard Shruthi, be sure to issue “make upload_all”, not “make bake_all_xt” - the XT controller code makes for a spectacular but rather dysfunctional flashing lightshow on a standard Shruthi!

Note that you can power the Shruthi with the encoder pressed to select which programmer it’ll run with (none, frank’s, the official XT).

fcd72 has been uploaded to firmware.

only for knobs…