New RasPI toolchain based on atmel 3.4.3

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have build the Atmel 3.4.3 toolchain from here
http://distribute.atmel.no/tools...

On my RasPi , running raspbian not the "foundation kernel"

uname -a Linux raspi3 3.6-trunk-rpi #1 Debian 3.6.9-1~experimental.1+rpi7 armv6l GNU/Linux

The package is on Cliff's server (Thanx Cliff)
http://www.wrightflyer.co.uk/avr...

atmel-3.4.3-avr-gcc-4.8.1-2014-04-30-raspbian.armhf.deb
atmel-3.4.3-avr-gcc-4.8.1-2014-04-30-raspbian.armhf.txt

I have only compiled a single project , but it was succesfull.

Well a Kazillion warnings , seems like gcc 4.8.1 is more picky than my old 4.5.1.

Try it out if you like , and remember to get/read the .txt file also on the server.

Remember to remove the old 4.5.1 toolchain if you have that one installed.

Ohh btw: It took 18h50m to build the atmel-gcc , then came avrdude 6.1 , avarice 2.12 and avr-gdb 7.7 , but that was just 1h or so.

/Bingo

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

Ohh you can thank Sparrow2 for this release.

He is getting me some new attyny841 :-) , and those weren't supported in the old 4.5.1 toolchain buildscript.

So i decided to spend the time to get the Atmel buildscript to build on my Linux Mint & my RasPi.

It wasn't an easy job , as Atmel decided to make their binutil source depend on autoconf2.64
And an autoreconf wasn't enough.

/Bingo

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

Bingo600 wrote:

It wasn't an easy job , as Atmel decided to make their binutil source depend on autoconf2.64

Not us - that check in override/config.m4 is from upstream.

Bingo600 wrote:

And an autoreconf wasn't enough.

That, we are guilty as charged - some of the patches do not include the generated files. However, we've pushed most of our binutils patches upstream (tiny arch support is the one big item pending), so future releases should do much better on this front.

Regards

Senthil

 

blog | website

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

Hi Sentil

Thanx for the ansver.

1:
Does Atmel have any timeframe of when the last patches will arrive upstream to Binutils & GCC ?

2:
Earlier Atmel did release the individual patches , not just a big "BLOB" of a patched sourcefile.
I could diff it and generate a giant patchfile , but the indivivually patches would be much more elegant.

Thank you for your (Atmels) work on the TC.

Rgds
Bingo

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

1. I'm afraid I can't promise any timelines. Like I said, except for tiny support and maybe new part support, binutils upstream already has our changes. For GCC, all new work is done on mainline, so all current and future work should show up there. For the existing patches, we will push them upstream one by one in the coming weeks is all I can say.

2. Yes, we realize it is painful for people who just don't build but actually see/use the patches. We'll soon setup a public git repo for this - that way, both kinds of users will be happy.

Regards

Senthil

 

blog | website

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

Has anyone tried this package ?
Or is the interest/need not there ?

/Bingo

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

saaadhu wrote:
Like I said, except for tiny support and maybe new part support, binutils upstream already has our changes.
For new devices, GCC no more needs that device being supported by Binutils because the compiler driver no more passes -mmcu down to gas.

Rationale is to make compiler and Binutils more independent.

-mmcu option support in gas will only be needed for assembler programmers that call avr-as directly, which is not recommended. The recommended way to run the assembler is by means of the compiler driver, i.e. calling avr-gcc with an assembler source file (.S or .sx) or -x assembler-with-cpp. Thus -mmcu support in gas is dead code today.

Therefore, all that's needed for a new device is a device header in AVR-Libc and a 1-liner in the compiler. But you can also get along without changing the compiler sources as explained in the GCC wiki:

Supporting "unsupported" Devices

avrfreaks does not support Opera. Profile inactive.

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

Thanx Johann

So i guess it isn't worth it , to make the packages anymore.

/Bingo