Atmel AS toolchain buildscript for linux

Last post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quick hack for compiling the Atmel AS toolchain (afaik this isn't the one used in AS5).
But i cant seem to find those patches ...

See - http://distribute.atmel.no/tools/opensource/avr-gcc/

It uses avr-gcc-4.4.3 , but avr-libc-1.7.1.
And a newer gmp & mpfr ... (dont think gmp/mpfr versions makes much difference in the avr code).

You can skip get-patches.sh (they are already in the patches dir) , and just run getfiles.sh

Im skipping avr-libc support for the xmega32x1 & xmega128b1
I cant get the Atmel patches to work (build)

I also had to make a patch for binutils Makefile.in -
56-binutils-2.20.1-avrtiny10-makefile-in.patch

Wonder if "Atmel" ever tested the sources that is in the above url (on a build) ????

#
# Drop avr-libc patching for now , i cant get the Atmel sources to work
# We are skipping support for the xmega32x1 & xmega128b1
# See - avrlibc : http://distribute.atmel.no/tools/opensource/avr-gcc/
#

As usual there is no warranties , and i can not be held responsible for any damage caused by the use of this script , ot what it creates.

Quote:
There might be a slight error with delay.h complaining (See below).

And I just had a "hint" that the solution is to include from within

/Bingo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Eric / Atmel
This isn't to "pollute" the Crosstool talk on the acr-gcc list.

It was mostly to try the patches , and to see some tiny10 support.

btw: Thanx for the patches , i suppose the new patchset for the AS5 toolchain will popup in the near future.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your Sir are a god! :D :D :D

It worked ;-) Now I can finally program my ATtiny4313...

I suggest to add these two things:

a) patch for avrdude.conf for ATtiny4313 as found here.

b) at least a note mentioning udev-rules

THANK YOU !

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One issue I've had so far is this:

Everything I compile using my makefile works. It uses avr-gcc, no C++ stuff involved.

Now as I am on linux, I tried to fire up the Arduino IDE and compile some code there as well. It compiles, except the last few steps that involve avr-g++ for compiling C++ code.

It chokes on including , which seems to want to use functions 'ceil()' and 'fabs()', which are defined in 'math.h', which doesn't get included in 'delay.h'.

 avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega168 -DF_CPU=8000000L -DARDUINO=22 -I/xxx/arduino-0022/hardware/arduino/cores/arduino /xxx/arduino-0022/hardware/arduino/cores/arduino/HardwareSerial.cpp -o/tmp/build5414833210231722667.tmp/HardwareSerial.cpp.o 
In file included from /usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/avr/delay.h:37,
                 from /xxx/arduino-0022/hardware/arduino/cores/arduino/wiring_private.h:30,
                 from /xxx/arduino-0022/hardware/arduino/cores/arduino/HardwareSerial.cpp:28:
/usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h: In function 'void _delay_ms(double)':
/usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h:149: error: 'fabs' was not declared in this scope
/usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h:149: error: 'ceil' was not declared in this scope
/usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h: In function 'void _delay_us(double)':
/usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h:226: error: 'fabs' was not declared in this scope
/usr/local/avr/lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h:226: error: 'ceil' was not declared in this scope

I can force this error to show up as well, when trying to compile my code (which compiles with avr-gcc) with avr-g++.

Then I inserted math.h into delay.h and it got a bit further, but was then complaining about missing stuff in math.h line 426.

Maybe something is not quite ok.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm.

It seems that with this version, I need to explicitly include 'math.h' before including 'util/delay.h' - in every file of code (using avr-g++). Very odd. But now I know about it ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ooooooo.
Well, I've been very active lately with and contributed to the latest version.
The latest version has some rounding capabilities and thats where those functions come in.
Normally, they are builtins for the compiler.
I'll have to go back and have a look (and a think) about how to deal with the additional
needs for the functions when using C++ in particular to see if it is a C++ thing or
just the Arduino IDE.
--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Bill

I use the new avr-libc-1.7.1 , could that be it ?

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

madworm wrote:

I suggest to add these two things:

a) patch for avrdude.conf for ATtiny4313 as found here.

b) at least a note mentioning udev-rules

You will have to apply those patches your self.

I'm only using "General releases" , as in "plain" avrdude 5.10.

The "specialities" you have to add 8)

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fair enough.

How about adding a note in the readme file? Only to prevent localized outbreaks of rage and destroyed keyboards.

My favourite: http://www.youtube.com/watch?v=ddkBMWafLSQ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@madworm

But they have to get to this thread to download the script , and they'll see your comments :-)

I will (hopefully soon) use my time updating the .deb packages on cliff's site , with new packages containing avr-libc-1.7.1.

Provided that Bill/Jörg can verify that the above math.h problem , isn't a problem ....

Edit: Just had a "hint" that the solution is to include from within

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Almost.

Adding 'math.h' to the deprecated doesn't solve the issue. It must be added to directly - at least on my system. Then it works ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@madworm

I think i corrected my prev. post from to while you were writing the above.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So it seems 8)

BTW, as I've filed the lack of ATtiny4313 support as a bug on openSUSE, people over there are quite interested in getting this thing up and running again as well.

Avrdude has been updated in the 'CrossToolchain:/avr' repositories already ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:
@Bill

I use the new avr-libc-1.7.1 , could that be it ?

/Bingo

Yes, I believe that the new delay code (which is actually much better BTW) is in 1.7.1

I haven't had time to look at this or test it yet
to see what the real issue is.

My assumption is that there is some missing C++ wrapper foo to get the compiler to recognize the builtin functions fabs() and ceil().

An interim solution is to disable the newer delay code and
revert back to the old delay code that used the delay loops.
To do that, turn on the define:
__DELAY_BACKWARD_COMPATIBLE__

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I've built this on an OpenSuse x86_64 machine and I'm getting this error:

Quote:
In file included from globals.h:28,
from lcd.c:15:
/opt/avr/bin/../lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h: In function 'vfnInitLcd':
/opt/avr/bin/../lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h:229: error: __builtin_avr_delay_cycles expects an integer constant.

I've thought problems with delay.h should be fixed in this release or am I missing something?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you building with optimization enabled?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I'm using "-O2". To get rid of the warning I have to "#define __HAS_DELAY_CYCLES 0", which seems to use the old code. See delay.h:

#elif !__HAS_DELAY_CYCLES || (__HAS_DELAY_CYCLES && !defined(__OPTIMIZE__)) || defined (__DELAY_BACKWARD_COMPATIBLE__)
...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For programming a T4313 with avrdude 5.10 , you need to add this "text definition"
http://savannah.nongnu.org/file/4313.txt?file_id=22038

Just add it to avrdude.conf after the ATtiny2313 block. I assume you’re using version 5.10.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

salixer wrote:
I'm getting this error:
Quote:
In file included from globals.h:28,
from lcd.c:15:
/opt/avr/bin/../lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h: In function 'vfnInitLcd':
/opt/avr/bin/../lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h:229: error: __builtin_avr_delay_cycles expects an integer constant.
I've thought problems with delay.h should be fixed in this release or am I missing something?

The error says that there is a problem in your code: You are using a function from delay.h (we don't see which as your code is secret) with a delay that is not a constant.

Note that by hacking around this by using older delay routines you might avoid the error but get completely unusable delay times and probably drag in float arithmetic.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, as you are saying this I've found the problem. In this function I'm using:

_delay_us(LCDSPI_DATA_DELAY);

while LCDSPI_DATA_DELAY in lcd.h is defined as:

#define LCDSPI_DATA_DELAY ((64 / (F_CPU / 1e6)) * 9)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

while LCDSPI_DATA_DELAY in lcd.h is defined as:

But that looks like a compile time constant?!?

(unless F_CPU is defined in terms of some variable?)