AVR-GCC 9.1 + AVR-LIBC with xmega3 device support

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

As I am sure a lot of people already know, Zak Kemble distributes Windows and Linux binaries for avr-gcc with the latest released versions (GCC 9.1, Binutils 2.32), you can get his stuff here: http://blog.zakkemble.net/avr-gcc-builds/

 

The only problem is, it also ships avr-libc V2.  Which is the latest release, but is in both dog years, and internet time, ANCIENT.   There are patches to support the xmega3 devices, like : ATtiny212, ATtiny214, ATtiny412, ATtiny414, ATtiny416, ATtiny417, ATtiny814, ATtiny816, ATtiny817, ATtiny1614, ATtiny1616, ATtiny1617, ATtiny3214, ATtiny3216, ATtiny3217 for avr-libc but they have sat for a while, and given patches for that project are waiting on some action since 2006, I wouldn't hold any breath hoping there will be a avr-libc V2.1 that includes that support.

 

SO, i decided to rectify that.  https://github.com/stevenj/avr-gcc-build-script is a modified version of Zaks script, which will build avr-libc from the latest SVN source, not the last release back in 2016.  And applies the xmega3 patches.  This creates a toolchain which has full xmega3 support without messing around copying files from "packs" or microchip archives, to coble together something approaching xmega3 support.  It will still create windows and linux binaries, but i have only tested on linux.

 

 

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

strontiumdog wrote:
without messing around copying files from "packs"
That could be a mistake - Atmel keep issuing pack updates with fixes in the support of many recent devices - if you don't adapt to working with packs you are going to miss out on all that.

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

I think it's a good idea. However I just copy a few files anyway, the headers can be included directly from Atmel packs.

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

clawson wrote:

strontiumdog wrote:
without messing around copying files from "packs"
That could be a mistake - Atmel keep issuing pack updates with fixes in the support of many recent devices - if you don't adapt to working with packs you are going to miss out on all that.

 

Well, it could only be a mistake if it prevented one from using the packs.  It does not.  So it's no more or less of a mistake than using unpatched avr-libc.

IF the "packs" have something you need you can still use them.

 

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

Just had a glance at  the script...

 

Does the avr-libc build use the freshly built / installed compiler?

 

You'll have to have at least one of the following:

 

1) Same prefixes (or)

2) avr-gcc in PATH (or)

3) avr-libc make CC=... where CC points to INSTALL/avr-gcc or BUILD/gcc/xgcc.

 

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:

Does the avr-libc build use the freshly built / installed compiler?

 

Yes it does, see line 103:

PATH="$PATH":"$PREFIX_LINUX"/bin
export PATH

As i said, this script started out as one from Zak Kemble,  I didn't write the whole thing, though I have modified it.

 

It "Just Worked" for me, so i didn't look deeper at the path.  However on inspection that line will probably cause an issue if avr-gcc is already in your path because the newly built avr-gcc is appended, so won't be found first.

I will be changing it to:

PATH="$PREFIX_LINUX"/bin:"$PATH"
export PATH

to correct this issue.

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

I made a few changes to the script.

It now detects the number of CPU's instead of it being hard coded.  It also is easier to build incrementally, the destination is only cleaned up when building binutils.  I added a couple of wrapper scripts which can build the components separately.

 

Test release binaries can be downloaded from:

https://github.com/stevenj/avr-gcc-build-script/releases/tag/20190728

 

Win32, Win64 and Linux x86-64 versions are all there.  I only test the linux version because i don't use windows, but it "should" work.

 

Note, these are all built with avr-libc3 and not official avr-libc