(Outdated) Script for building AVR-GCC 4.5.1 on Linux

Go To Last Post
343 posts / 0 new

Pages

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

Quote:

There is no need for uninstalling the .deb
The deb only install files in /usr/local/avr , and as long as you don't touch anything there , you can leave it installed

Thanks for all the answers.
The key of the mystery was the path. I've supposed the /usr/local/avr/bin path will be added to my path by the script - and even worse, there was that forgotten, partly aborted version of avr toolchain.
Now as I set the path, everything is right. Thanks for the script, Bingo!
Istvan

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

dircon wrote:
Quote:

I've supposed the /usr/local/avr/bin path will be added to my path by the script
Istvan

Nope :shock:

Neither the buildscript , nor the .deb packages adds /usr/local/avr/bin to the path.

This is left for the "user" to do , and will prob never change.

/Bingo

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

Bingo,

It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH

Cliff

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

clawson wrote:
Bingo,

It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH

Cliff

Naajzzz 8)

Thanx Cliff :-)

/Bingo

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

Hi,
I'm using avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb package and I'm trying to program an avr ATXMega256A3. Compiling with avr-gcc and flashing with avrdude works great. I use an MKII Jtag ICE to upload the application on the flash and I'm trying on chip debugging. It looks like on chip debugging is working right as when I hit CTRL+C it stops running and gdb tells me the instruction where the application stopped.
However I can't watch / display variables nor set/delete breakpoints.
Xmega256A3 data is store in SRAM (0x802000 <-> 0x805FFF). when I try to print a variable, and watch avarice debug, I see something like this:

GDB: 

GDB: Read 2 bytes from 0x800001
jtagRead 
command[tries: 1, size: 10]: 
0x05 0xA0 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
recv: 0x1b
recv: 0x19
recv: 0x00
recv: 0x03
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 3 bytes
read:  82 20 00
recv: 0xde
recv: 0xea
CRC OK
Got message seqno 25 (command_sequence == 25)
response: 82 20 00 
->GDB: 0020

As you can see from the debug information, gdb asks for location (0x800000 + 1) and does not account for the data offset NOR for the fact that data is stored on the ATXMega starting from the higher addresses (0x805FFF) up to the lower ones).

I wonder if it's gdb or avarice responsibility to account for these offsets...

I'd really appreciate your help guys...

Thankx in advance
I'm be waiting for any comment help hint or scolding me..

R

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

@riccardomanfrin

Afaik there is no Xmega support in the "GNU" debugging tools , due to Atmel not releasing the neded info.

But i can see Jörg (avarice maintainer) inviting you to a dialog
http://www.avrfreaks.net/index.p...

/Bingo

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

@04-jun-2010
Updated the buildscript to build insight 6.8-1

/Bingo

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

@30-jun-2010
First release with avrlibc-1.7.0 here

http://www.avrfreaks.net/index.p...

/Bingo

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

FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.

For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.

Patch:
sudo apt-get install patch

libx11-dev:
sudo apt-get install libx11-dev

Termcap:
sudo apt-get install libncurses5-dev

expat:
sudo apt-get install expat

libbfd.a:
sudo apt-get install libbfd-dev

yacc:
sudo apt-get install bison

flex:
sudo apt-get install flex

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

zainka wrote:
FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.

For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.

Patch:
sudo apt-get install patch

libx11-dev:
sudo apt-get install libx11-dev

Termcap:
sudo apt-get install libncurses5-dev

expat:
sudo apt-get install expat

libbfd.a:
sudo apt-get install libbfd-dev

yacc:
sudo apt-get install bison

flex:
sudo apt-get install flex

@Zainka

Did you have a look in the Pre-reqs.txt , file in the package.

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

Uploaded Jörgs mfile tool mfile-ubuntu.tar.gz , adapted for ubuntu (1 line change)
http://www.wrightflyer.co.uk/avr...

See Readme.ubuntu

/Bingo

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

how about GCC 4.3.5?

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

vitaly_v_ch wrote:
how about GCC 4.3.5?

What's in 4.3.5 that you "really" need ?

/Bingo

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

Really? Mainly sport interest.

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

If you have used the above link
http://www.avrfreaks.net/index.p...

See
http://www.avrfreaks.net/index.p...
For fixing the delay bug in avr-libc-1.7.0

/Bingo

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

The scripts use a dangerous approach of assuming various directory creation and navigation commands work and then executing "rm -fr *" without ensuring that the current directory is what it should be. I had to spend a good chunk of last Sunday restoring from backup after one of the scripts wiped out a large part of my home directory.

Following the scripts and attempting to replicate the build process by hand yields a toolchain that works for tiny26 and mega32 projects, but can not find C runtime files for the xmega32A4:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: crtx32a4.o: No such file: No such file or directory

This file does exist, it's in /Users/cjh/avr/avr/lib/avrxmega2/crtx32a4.o (prefix is $HOME/avr/). Moving it into the project directory yields different errors with libmath and libc:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: skipping incompatible /Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/lib/libm.a when searching for -lm
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: cannot find -lm

Omitting -lm yields:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: skipping incompatible /Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/lib/libc.a when searching for -lc
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: cannot find -lc

The files appear to be the right type:

% avr-objdump -f crtx32a4.o 

crtx32a4.o:     file format elf32-avr
architecture: avr:103, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

And similar for the libraries, but long lists of entries of the same format and architecture "avr".

I'm using Mac OS X 10.6.5. The major differences from the scripts are that I'm using avr-libc-1.7.0, more recent versions of GMP and MPFR, and removing an instance of tree-inline.o from the GCC makefiles to fix a duplicate symbols problem. (bug in Snow Leopard's linker...won't ignore duplicate symbols from static libraries)

Any suggestions?

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

I'm sorry if the script has caused you trouble.

You dont write what buildscript-filename , shell-file and line that caused you trouble.
So i'll assume it's this buildscript http://www.avrfreaks.net/index.p... , and the buildavr-cleanup.sh script.

And there is actually a warning when using that.

In the readme it states

Quote:

Start by reading this thread http://www.avrfreaks.net/index.p...
Or at least the first post.

And in the post that the above url refers to : It states

Quote:

When building is done , you might want to free around 500MB of diskspace by removing the sources and binaries used to make avr-gcc.
To do so Run: ./buildavr-cleanup.sh

Note this little script expects the "build prefix" to be /usr/local/avr/

So if it was the cleanup script causing the trouble. The info (warning) was there , and you are the first that i know of , to have been "bitten".

The buildavr-cleanup.sh , was a quick "hack" because some users complained about the finished toolchain being 500MB+

As stated , the script are only tested on Ubuntu.
But a lot of people reports that with minor "adaptation" it also works on other *nixes.

/Bingo

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

For the problem . maybe try the toolchain from femtoos
http://www.femtoos.org/

Download
http://sourceforge.net/projects/...

Ruud's script is probably what you want (lots of checkking) , and is supposed to be functional on MAC.

/Bingo

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

That is the buildscript I used, but it was get-patches.sh that blew away part of my home directory. There's several times that it does mkdir's and cd's without checking for failure, blindly does "cd ..", and it simply experienced a couple failures and climbed up into my home directory before doing another "rm-fr *".

It would be much better to always specify full absolute paths, especially in the rm command. This alone would have prevented the issue, since it would have been trying to rm a nonexistent directory...it would not matter if it were in the wrong directory following a failure. I would also suggest simplifying it to put everything in a fully specified build directory rather than constantly creating and deleting this and that...it would be simpler, clearer, and less fragile.

As for the readme, I strongly suggest reorganizing it. There's no clear starting point for figuring out how to use the scripts, the quoted portion at first glance appearing to be an old portion of the revision history.

I will check out the femtoos scripts.

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

Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?

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

clawson wrote:
Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?

It's good you've never had them run amok, because they would have done a lot more damage if you were blindly following those directions. Running the scripts with the root or sudo privileges needed for an install to /usr/local would not have improved matters...it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there. As it was, I noticed it was misbehaving when it started hitting files it didn't have the permissions needed to delete.

And yes, aside from limiting the potential damage from misbehaving scripts, building a standalone toolchain makes it trivially easy to switch between different versions of a toolchain, and keeps all the stuff related to that toolchain in one place. I didn't install to /usr/local because I didn't want it there.

It's clear that there's a major issue with the scripts' assumptions that directory creation and navigation will always succeed, coupled with running a dangerous command without any sanity checks. That you've never had trouble does not change the fact that failures can lead to it blindly deleting everything in higher level directories. Depending on the choice of download locations and how closely the directions are followed, it can delete nearly everything on the hard drive, OS included. Is your response to this really "it always worked for me" followed by questioning my choice of install locations?

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

Quote:

it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there

Wouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.

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

Well it's always nice with some feedback , even though you are the first i have heard about that has lost control.

And people has been using the scripts for four years now.
With the above mentioned readme et all.

I hope Ruud's script lives up to your expectations.

Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.

Maybe i'll add a check for that.

/Bingo

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

clawson wrote:
Quote:

it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there

Wouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.

Well good for you! Can you at least admit that this might be something of an issue for other people?

It's simple. Potentially crawling up your directory tree and deleting everything in sight without warning is not desired behavior, okay?

Bingo600 wrote:
Well it's always nice with some feedback , even though you are the first i have heard about that has lost control.

And people has been using the scripts for four years now.
With the above mentioned readme et all.

I hope Ruud's script lives up to your expectations.

Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.

Maybe i'll add a check for that.

:shock:

Look. Running the scripts as instructed is potentially equivalent to typing "sudo rm -rf *" in any containing directory, up to and including the root directory of the filesystem. This is a major issue that needs fixing, the scripts in their current state are brittle and fail catastrophically. That you haven't had reports of issues up to now is pure luck. You have now had such a report, and a clear description of what the problem is and why.

There is no reason to clear out unneeded files by attempting to cd to a location and then deleting everything in the current working directory. Simply working out what directory the items to be deleted should be in and passing that to rm will avoid the issue...if the directory doesn't exist, the script won't fail by crawling up the directory tree deleting everything in its path. This doesn't take a huge amount of effort to implement, and doesn't make things harder to maintain or follow...if anything, it makes it clearer what the scripts are doing and easier to ensure that they do only what you want.

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

If it's so easy for you to do , why don't you submit the modified script here.
Nothing stops you from helping out.
Then maybe i'll get my first patch , along with the first

Quote:

You have now had such a report, and a clear description of what the problem is and why.

Have a nice life , and i'll consider to make it a FLASH guide in my next version.

/Bingo

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

Hi,

Sorry for the cross-posting. I am trying to make a 1-file-only build script for the last version of the avr-gcc/avr-libc tools, as mentioned here:
http://www.avrfreaks.net/index.p...

The script uses the information on Bingo's scripts but is adapted from the scripts used to install the cross-compilers for arm.

In short:

BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"

I was able to build the version 4.5.1 previously but not sure why I run into some trouble now that I try with 4.5.2. After installation, when I use avr-gcc I get this message:

avr-gcc  -mmcu=at90usb1287 -Wl,-Map=SCD.map SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o  halSCD.S SCD.S    -o SCD.elf 
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc 
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc 
collect2: ld returned 1 exit status 

(more information on the link above).

I know there are packages for ubuntu, but they are broken (again, see my unreplied post at the link above).

I am not able to attach the script file (I think there is a problem with the avrfreaks website, not sure), so here it is:
http://www.cl.cam.ac.uk/~osc22/f...

I hope some of you will find it useful (especially if I manage to fix this error).

Thanks.

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

Nice script ..
But why do you want the latest GCC ? , especially for a target like AVR.
Those patches in my buildscript is actually enabling/fixing a lot of things in the various packages.

I haven't got a good idea for your problem , but was wondering why you have/need these two options on the "configure" --program-prefix=avr- --with-gcc

/Bingo

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

The 2 parameters are a remainder from the original arm-gcc-cross-compiler building script. However both of them are correct and do not affect in a negative way the building of the tools (feel free to try).

The package for ubuntu, available here:
http://www.wrightflyer.co.uk/avr...
is broken as I have mentioned. It did not include the patch for delay.h.in in the avr-libc-1.7.0. One more reason why to have a building script functional that can be easily modified (I find more easy to modify my script than yours, no offence).

Why GCC-4.5.2? Well, I believe is better to go with the latest version, since they generally bring improvements. However, after a little Google (one of my friends suggested I need some practice on this...):
- from http://gcc.gnu.org/gcc-4.5/chang...
- new link-time-optimizer (sounds nice from description)
- automatic parallelisation pass
- optimising exception handling code (probably doesn't apply to our AVR targets, but still nice)
- just C related:
- -Wenum-compare option to warn about different enum types
- Added support for these new AVR devices:
ATmega8U2
ATmega16U2
ATmega32U2
- it is now possible to extend the compiler without having to modify its source code
- from http://gcc.gnu.org/ml/gcc-announ...
- improved loop optimization infrastructure
- GCC 4.5.0 also features improvements for a wide variety of specific
architectures, including support for recent CPUs using the ARM, AVR...
- many more ... (please read the links above).

Hope this will trigger some support.

Thanks.

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

The wisdom of the libc/avr-gcc maintainers is almost always the better place to start. It takes for fracking ever for anything to actually get released into gcc. And new processors are going to be unstable for a while. The patches that bingo uses which are from the toolchain maintainers mouths are based on the latest and most stable versions for this processor.

Period.

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

Ok, I've managed to fix the problem (thanks Bingo, gcc and avr-gcc community) - I was using a wrong parameter for make.

The last version of the building script is here:
http://www.cl.cam.ac.uk/~osc22/f...

Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"

Bingo if you (and others) find it useful, feel free to add it on the first page.

Thanks.

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

@goodhack

I suppose it was EW's hints on the avr-gcc list what brought you on track.

Congratulations in writing a very nice buildscript.

It still amazes me though :
That you chose to ignore the warnings in the last posts about using the unpatched upstream avr-gcc.
Instead of the proven 4.3.4 with the current maintainer patches applied.
These patches are created by Eric Weddington (WinAVR) , who adviced you on the "list". And Jörg Wunsch (avr-libc & FreeBSD port of avr-gcc).

And i sincerely hope your students won't be bitten , as these patches most likely haven't gone into the version of GCC that you are using.

/Bingo

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

Yes, it was EW's hints on the avr-gcc (as well as some other messages on the gcc-help list) that have helped me.

Well, it is not that I choose to ignore, I just want to provide a working script for the last version of GCC for those (like me) that want to use it.

Also, using your scripts, or the maintained 4.3.4 packages give extra work like applying missing patches.

I am sure the 4.3.4 version might be more stable, but why not trying to make it work with the current version?

Regarding the patches you refer to, I think that many patches have gone into the current (4.5.2) GCC version; at least from the Changelogs it seems that some things related to AVR have been aded.

Omar

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

@Omar
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Btw: The reason i haven't updated the .deb packages with the new delay.h is that i follow the FreeBSD source like 99.9% , and Jörg hasn't released avr-libc-1.7.1 yet.

But your post actually made me upload the correct delay.h file , and write a warning in the "readme's" on http://www.wrightflyer.co.uk/avr...

Now you don't need to patch , just replace a file

/Bingo

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

Nice to hear about the correct file.

Thanks.

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

Hi,

nice scripts, thank you. :)

However, it aborted while building avarice-2.10 with a linker error on Arch Linux (AMD64):

Quote:

g++ -g -O2 -o avarice crc16.o devdescr.o ioreg.o jtag2bp.o jtag2io.o jtag2misc.o jtag2prog.o jtag2run.o jtag2rw.o jtag2usb.o jtagbp.o jtaggeneric.o jtagio.o jtagmisc.o jtagprog.o jtagrun.o jtagrw.o main.o remote.o utils.o gnu_getopt.o gnu_getopt1.o -lusb -lbfd -liberty -lz
/usr/lib/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x3f4): undefined reference to `dlopen'
/usr/lib/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x417): undefined reference to `dlsym'
/usr/lib/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x4a3): undefined reference to `dlerror'
collect2: ld gab 1 als Ende-Status zurück

On Arch Linux AMD64, avarice needs to be linked against libld:

I added

AC_CHECK_LIB([dl], [dlopen], , [ac_found_ld=no])

to the avarice-2.10 configure.ac file.
Then run autoreconf && autoconf , build a new tarball, exchange it and it works. :)

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

Hi bofh,

I am happy to hear you can use them as well.

Regarding the bfd problem, you should install libbfd. In ubuntu this is solved by installing binutils-dev, as mentioned in the header of the scripts.

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

Bingo600 wrote:
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.

I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Bingo600 wrote:
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.

I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.

I don't have any examples , but i'm quite sure that it was Eric (EW) mentioning this on one of the mailinglists. As an answer to why patches wasn't moved upstream.

Ask Jörg or Eric.

/Bingo

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

goodhack wrote:
Ok, I've managed to fix the problem (thanks Bingo, gcc and avr-gcc community) - I was using a wrong parameter for make.

The last version of the building script is here:
http://www.cl.cam.ac.uk/~osc22/f...

Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"

Thanks.


Mega2560 has a bug in 4.5.2

http://www.avrfreaks.net/index.p...
http://gcc.gnu.org/bugzilla/show...

/Bingo

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

Thanks Bingo.

I have added a patch for the bug and I see the bug has now been fixed for GCC 4.6. Also I updated my script to use this patch.

Maybe we can make a complete list of unsolved bugs for 4.5.2 and hope they will all be fixed for release 4.6. And we could try to start converging from there.

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

Is there a _single_ location available that at least links to all the files necessary to get up-to-date mcus working?

I must have spent have a day compiling (using the script and the manual on the avr-libc site) only to find out that e.g. my newly acquired ATtiny4313 is not supported by the compiled avr-gcc version I got. Woohooo! Happy happy joy joy.

I don't mind the compiling part too much (well it basically sucks, but it is still tolerable), but finding all the patches... good god! :x

How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.

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

madworm wrote:
How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.

I have the impression that winavr is sometime more a fork than a port and that quite few things don't make it back into the gcc. maybe just due to the lack of motivation my Atmel to provide the work to make it happen. After all in winavr it works and other development platforms than Windows don't exist / are negligible (See the wonderful new Studio 5 based on Microsoft Visual Studio).

Markus

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

I think I'll have to agree with the fork vs. port part, but Atmel could at least have had the decency to use QT instead of the horrid MS stuff. It looks more and more like MS-word. Does it have ribbons as well?

And why do I need to register just for downloading a free-of-charge IDE? Is that strictly legal, having to register to get access to software that is - at least partially - licensed under the GPL?

Sheesh. Isn't it enough that I buy some of their chips already. Knowing who I am and what I do won't miraculously octuplicate their sales and blow away their competitors...

/rant

Now back to business please :D

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

I installed AVR Studio 5 yesterday - it supports Tiny4313. When it was pointed out to Atmel that they'd shot themselves in the foot by delivering (again) a Windows only package the retort was that while the IDE may be tied to Windows the toolchain was "cross platform". Now I don't know how they can make that claim without providing Linux binaries x386 for the avr-* tools in the toolchain - but maybe they are lurking in there (I haven't looked)?

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

It was Dean, who said that the underlying stuff is cross-platform and only the IDE is Windows specific. This might be correct in theory and marketing speak (gcc is cross-platform), but in practice this is clearly false. After I pointed out to him that an 500MB exe file is not cross-platform did not venture any further comment.

I respect Dean and suspect he was carried away with his remark. I don't think he works in the Studio team, so he might just defend them without knowing all the details first hand.

I don't need a single click 500MB installer for linux, the script provided here is sufficient for most of us Linux guys. But it looks like we are deliberately ignored.

Markus

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

The script is fine!

It basically does all the work. Only currently (well yesterday) it unfortunately does not produce a version of avr-gcc that supports the tiny4313.

The best I could do myself was to apply a patch to avr-devices.c to make the compiler aware of that chip. But later the linker barfed about a missing .o file - which existed.

If atmel is so stuck-up to ignore everything beside windows, they can't be helped and will pay the price once MS faces its inevitable end. I just love companies taking advantage of open source software and give back nowt.

I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.

Maybe it's time that someone shoves that message up the a*ses of the bean counters in management.

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

madworm wrote:
I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.

I doubt that this is easily possible, as Studio 5 is based on the Microsoft proprietary Visual Studio environment. However, the C/C++ compiler is already cross-platform compatible, only that Atmel, in its infinite wisdom has choose only to distribute the Windows version. Over time they will have to release all the patches they have applied to it as gcc is licensed under the GPL.

It would have been very easy for them to base their Studio environment on a cross-platform environment like Eclipse, like most of the industry is doing it right now. It might even have been less work.

Markus

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

Quote:

Over time they will have to release all the patches they have applied to it as gcc is licensed under the GPL.

This is one major niggle I have with AVR Toolchain and now AVR Studio 5. If you go back to WinAVR then you have:

C:\WinAVR-20100110\source\avr\gcc\4.3.3>dir
 Volume in drive C is ACER
 Volume Serial Number is C6B0-75D7

 Directory of C:\WinAVR-20100110\source\avr\gcc\4.3.3

21/01/2010  12:03              .
21/01/2010  12:03              ..
19/01/2010  18:08               392 20-gcc-4.3.3-libiberty-Makefile.in.patch
19/01/2010  18:08               924 21-gcc-4.3.3-disable-libssp.patch
19/01/2010  18:08               339 23-gcc-4.3.3-ada-Makefile.patch
19/01/2010  18:08               629 30-gcc-4.3.3-param-inline-call-cost.patch
19/01/2010  18:08             1,656 40-gcc-4.3.3-bug-10768-by-adacore.patch
19/01/2010  18:08            11,119 41-gcc-4.3.3-bug-11259_v3.patch
19/01/2010  18:08             1,606 42-gcc-4.3.3-bug-spill-v4.patch
19/01/2010  18:08             2,209 43-gcc-4.3.3-bug-35013.patch
19/01/2010  18:08             1,348 44-gcc-4.3.3-libgcc16.patch
19/01/2010  18:08             2,914 45-gcc-4.3.3-bug-33009.patch
19/01/2010  18:08               445 46-gcc-4.3.3-andsi3-wrong-attribute.patch
19/01/2010  18:08             7,348 47-gcc-4.3.3-bug-18145-v4.patch
19/01/2010  18:08            10,560 50-gcc-4.3.3-mega256-v2.patch
19/01/2010  18:08            33,036 51-gcc-4.3.3-xmega-v13.patch
19/01/2010  18:08            24,718 52-gcc-4.3.3-new-devices.patch
19/01/2010  18:08             7,276 60-gcc-4.3.3-osmain.patch
19/01/2010  18:08            16,365 61-gcc-4.3.3-builtins_v6.patch
19/01/2010  18:08             6,084 62-gcc-4.3.3-ada-mlib.patch
19/01/2010  18:08             3,458 63-gcc-4.3.3-ada-freestanding.patch
19/01/2010  18:08             2,645 64-gcc-4.3.3-ada-timebase.patch
19/01/2010  18:08             1,312 65-gcc-4.3.3-ada-gnat1_print_path.patch
19/01/2010  18:08             3,026 66-gcc-4.3.3-ada-optim_static_addr.patch

Whereas if you look at AS5 you have:

D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain>dir
 Volume in drive D is DATA
 Volume Serial Number is 3636-53FD

 Directory of D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR T
oolchain

01/03/2011  20:47              .
01/03/2011  20:47              ..
01/03/2011  20:47              avr
01/03/2011  20:48              avr32
01/03/2011  20:47              bin
01/03/2011  20:48              contrib
01/03/2011  20:48              doc
01/03/2011  20:47              include
01/03/2011  20:47              info
01/03/2011  20:48              lib
01/03/2011  20:48              libexec
01/03/2011  20:49              man
01/03/2011  20:49              share
               0 File(s)              0 bytes

Like "toolchain" before it they haven't bothered to include a source/*/*.patch directory.

In the past I know that people have used the *.patch that Eric included in WinAVR and have then applied them to a Linux built toolchain - as Toolchain/AS5 stands that is not possible and it does suggest Atmel is in violation of GPL as they are providing binaries for which the end user cannot easily rebuild them. At the very least they should just include a list of which patches have been applied and leave it to the builder to locate them from open FTP/HTTP sources.

============================================================================

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

So where are the lawyers when you need them?

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

In case somebody missed this post, Atmel publishes the modified GPL-based stuff here:
http://distribute.atmel.no/tools...

Pages