AVR-Libc 1.8.1

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

Just received notice that AVR-Libc version 1.8.1 has been released. The home page has not yet been updated, but it is available to download from http://savannah.nongnu.org/proje...

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

Something is broken with the download from Savannah. I get

Quote:
The requested URL /avr-libc/avr-libc-1.8.1.tar.bz2 was not found on this server.

The 2.5 y.o. 1.8.0 download seems to work OK, so it is not a "generic" problem.

Anyone else?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Well, I could download it from http://ftp.igh.cnrs.fr/pub/nongn... (a mirror of savannah : maybe they are not fed at the same time?)

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

Well, it's been more than 2.5 years since the previous release.
Many people contributed to avr-libc lately, so even though I
didn't have the time for a thorough sweep over the bug
database, I decided to finally roll a new release.

Here's the contents of the NEWS file:

*** Changes in avr-libc-1.8.1:

* Bugs fixed:

  [#31267] misleading header iom128rfa1.h
  [#35197] sleep.h _BV defined as __BV in AT90S8515 section
  [#35226] Online-documentation broken - [...]
  [#35398] assert doesn't work unless stdlib.h is also included
  [#35498] misspelled in 
  [#35539] stdlib.h does not provide EXIT_SUCCESS et al.
  [#35948] iom32u4.h for ATmega32U4 incorrectly defines Timer 2
  [#35971] attiny4313 (2313a) pin-change interrupts PCINT[0...2] vect etc
  [#36053] Declaration of the register USIBR missing for ATtiny2313a/4313
  [#36410] avr/boot.h: poisoned SPMCR for ATmega128
  [#36454] string.h: Error for long long in C90
  [#36581] avr-libc: pgmspace.h is not ANSI compliant
  [#37103] ATtiny5/9/10/20/40 watchdog can't be enabled
  [#37778] _MemoryBarrier() in cpufunc.h error on compile
  [#38135] Install a dummy stdfix-avrlibc.h
  [#38516] Missing TWI and UCSR1D definitions for ATmega16/32 U4
  [#39049] Clock prescaler set and get are missing for TINY architecture
  [#39783] CRC missing definitions and incorrect power macros for xmega D3
  [#40003] Integer type promotion leads to inefficent code in wdt.h
  [#40206] incorrect SP init in startup code for xmegas
  [#40567] Invalid names in iotn13a.h (EEPE/EEMPE/BODS/BODSE)
  [#40569] sleep_bod_disable does not work in attiny13a
  [#40595] iotn2313a.h: wrong fuses definitions for High Fuse Byte
  [#41006] iom328p.h: wrong fuse defaults
  [#41519] wrong SPM_PAGESIZE definition in iotn[48]8.h
  [#42024] build break regarding avrtiny10
  [#42084] wrong LFUSE_DEFAULT in iotn84a.h
  [#42085] HFUSE_DEFAULT not defined for iotn84.h
  [#39779] PCIE0 and PCIE1 defined incorrectly for mega165a and mega165pa devices
  [#38614] dtostrf - wrong behavior or wrong documentation
  [#42957] missing SPMCSR defines in iom328p.h#
  [#41690] Bit definitions for SPMCSR
  [no-id]  XXX_vect_num not consistent io90pwmx.h, iousbxx6_7.h
  [no-id]  Specialize clock_prescale_set/get for mega hvb devices
  [no-id]  Update register and bit definitions for tiny 13a/24a/44a/84a,
           tiny167 and mega328p

* New devices supported:

  - ATmega256RFR2, ATmega2564RFR2, ATmega128RFR2, ATmega1284RFR2,
    ATmega64RFR2, ATmega644RFR2, AT90pwm161, ATA5272, ATA5505, ATA5790,
    ATA5795, ATA6285, ATA6286, ATmega1284, ATmega128A, ATmega164PA,
    ATmega165PA, ATmega168PA, ATmega3250PA, ATmega325PA, ATmega3290PA,
    ATmega32A, ATmega48PA, ATmega64A, ATmega8A, ATtiny1634, ATtiny828,
    ATxmega128A3U, ATxmega128A4U, ATxmega128B1, ATxmega128B3, ATxmega128C3,
    ATxmega128D4, ATxmega16A4U, ATxmega16C4, ATxmega192A3U, ATxmega192C3,
    ATxmega256A3BU, ATxmega256A3U, ATxmega256C3, ATxmega32A4U, ATxmega32C4,
    ATxmega384C3, ATxmega384D3, ATxmega64A3U, ATxmega64A4U, ATxmega64B1,
    ATxmega64B3, ATxmega64C3, ATxmega64D4

* Contributed Patches:

  [#3729] Printf for integers speed up
  [#7212] Add pgm_read_ptr() macros to pgmspace.h
  [#7220] Add UBRR overload functionality to 
  [#7260] Addition to power.h
  [#7485] CRC8-CCITT
  [#7654] include/delay.h: delay_us >255us without decreasing resolution
  [#7826] Add ATMega32u4 support to the led-blinking demo
  [#7909] Adding __volatile__ to __asm__ within pgmspace header
  [#7910] Add missing PCINT2_vect to iotn40.h and update all the
          following vector numbers
  [no-id] correction in xmega wdt_enable and wdt_disable added for xmega
  [#8499] Device ata6289 should be of avr4 architecture
  [no-id] Add RAMSTART, fix RAMSIZE, RAMEND and FLASHEND in device headers
  [#8512] Rename tiny arch to avrtiny to sync with binutils

* Other changes:

  - New macro _PROTECTED_WRITE(): write to Xmega IO registers that are
    protected through the CCP mechanism

  - Add support for scanf() conversion macros for 8-bit data types to
    : SCNd8, SCNdLEAST8, SCNdFAST8, SCNi8, SCNiLEAST8,
    SCNiFAST8, SCNo8, SCNoLEAST8, SCNoFAST8, SCNu8, SCNuLEAST8,
    SCNuFAST8, SCNx8, SCNxLEAST8, SCNxFAST8

  - Add time.h package, C standard functions such as mktime() and localtime,
    along with 'ephemera' such as solar declination, time of sun rise and set.

  - Introduce new configure option --with-debug-info=INFO, where INFO
    can be either stabs, dwarf-2, or dwarf-4.  By default, no debug
    information will be generated.

  - Add IO register debug symbols to crt*.o, so debuggers can see the
    per-device defined IO registers (and __eeprom).

  - A number of changes have been applied to make avr-libc more C++
    aware.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Downloads and bunzip2's fine on my machine.

I'll merge this thread with Joerg's announcement thread in GCC forum.

BTW I'm never clear - can you just use this as a "plug in" replacement for the avr-libc files you have or does it need to match the compiler that's using it?

The stuff is awfully tempting!

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

Oops! One consequence of the AVR-LibC release is that the online documentation just changed. Take a look at this page for example:

http://www.nongnu.org/avr-libc/u...

Something has gone seriously wrong there! First the #define's at the top are suddenly all double spaced but I guess that doesn't matter but what does matter is the "API Usage Example". What on earth had happened to the indentation?!?

Has a new version of Doxygen been used to generate these files or something? Or has the Doxygen config changed? Whatever it is, it seems to have garbled everything :-(

EDIT: just picked some other pages at random (, , etc) and everything is screwed in the same way :-( :-(

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

ugh... Will be fun to se what happens when the doc is fed through our tranform system for webdoc/studio doc...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

> Something is broken with the download from Savannah.

The various mirrors probably take some time until they update from the master.

> BTW I'm never clear - can you just use this as a "plug in" replacement for the
> avr-libc files you have or does it need to match the compiler that's using it?

As long as there's no change in the ABI, it should be possible to replace it.

> Has a new version of Doxygen been used to generate these files or something?

Yes, it's a new version of Doxygen, which is not a big surprise given the previous
releases was many years ago. I also noticed that certain helper files have been
generated which used to be present years ago but then vanished. Since the
Savannah Web tree is still maintained with CVS, reappearing files are always much
fun on a vendor branch. :/

I can perhaps try to upgrade the doxygen.conf file we are using to the new Doxygen
version. Alas, I won't be able to do this before September though. If someone
wants to beat me on this, go ahead and file the new doxygen file as a patch tracker.
If it's a real improvement over the current garbled state, I can update the
online docs independent of a new release, by re-generating them from the released
source/header files.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

To assist whoever investigates this here is July19th page:

http://web.archive.org/web/20140...

that says it was (successfully!) generated by Doxygen 1.7.6.1

And this is the page now:

http://www.nongnu.org/avr-libc/u...

Generated by Doxygen 1.8.7.

So it's some change from 1.7.6.1 to 1.8.7 that has done the damage

You'd have thought they'd do regression testing so one would assume this is some hugely fundamental change not just a "tweak". History is on this page:

http://www.stack.nl/~dimitri/dox...

It lists everything between 1.7.6.1 and 1.8.7

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

Nice work Jörg

I just made a test build of avrgcc-4.5.1 w. avrlibc-1.8.1 , no build problems :-)

/Bingo

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

Quote:

no build problems

What version of Doxygen were you using?

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

clawson wrote:
Quote:

no build problems

What version of Doxygen were you using?

I dropped making the doc's , as my MINT 17 has a newer version of texinfo that makes binutils fail.

Quote:

sed -i -e 's/@colophon/@@colophon/' \
-e 's/doc@cygnus.com/doc@@cygnus.com/' bfd/doc/bfd.texinfo

t43-se binutils-2.20.1 # sed -i -e 's/@colophon/@@colophon/' \
> -e 's/doc@cygnus.com/doc@@cygnus.com/' bfd/doc/bfd.texinfo
t43-se binutils-2.20.1 # pwd
/usr/local/avr/source/binutils-2.20.1
t43-se binutils-2.20.1 #

For those having problems building binutils without texinfo installed, run the configure step as normal. When that finishes, do this:
echo "MAKEINFO = :" >> Makefile
That command overrides the MAKEINFO variable in the Makefile, setting it to something that does not exist. This causes make to skip attempting to build (and subsequently install) the documentation. --quok 06:20, 26 August 2008 (UTC)

I just did this in the buildscript :oops:

--- /home/bingo/1-Avr/1-BuildAvr/build-avr-gcc-4.5.1-binutils-2.20.1-libc-1.8.0-gdb-7.6.1-dude-6.1-avarice-2.12-aw/make-avr-gcc/buildavr-toolchain.sh
+++ /home/bingo/1-Avr/1-BuildAvr/build-avr-gcc-4.5.1-binutils-2.20.1-libc-1.8.0-gdb-7.6.1-dude-6.1-avarice-2.12-aw/make-avr-gcc/buildavr-toolchain-nodoc.sh
@@ -174,6 +174,9 @@
    ../../source/${binutilsbase}/configure -v --target=${target} \
       --prefix=$prefix --with-gnu-ld --with-gnu-as --quiet --enable-install-libbfd --with-dwarf2 --disable-werror CFLAGS="-Wno-format-security "
    cerror "binutils configuration failed"
+
+#  Hack to prevent docs to be build , it will fail if texinfo is v5.xx (as in Mint 17)
+   echo "MAKEINFO = :" >> Makefile 
 
    echo "($0) building binutils"
    make -j${Cores} all 
@@ -272,6 +275,9 @@
       --with-gmp-include=$prefix/source/${gccbase}/gmp
    cerror "GCC configuration failed"
 
+#  Hack to prevent docs to be build , it will fail if texinfo is v5.xx (as in Mint 17)
+   echo "MAKEINFO = :" >> Makefile 
+
    echo "($0) building GCC"
 #   make all install clean LANGUAGES="c obj-c++"
    make -j${Cores} all LANGUAGES="c c++"

And rely on Jorg's 1.8.1 pdf :wink:

See the sticky if you wanna play

/Bingo

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

Quote:

See the sticky if you wanna play

But is it still a 4.5.1? I'm too used to things like __flash to leave them behind now so will just use the 4.8.1 that Atmel build for Linux.

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

clawson wrote:
Quote:

See the sticky if you wanna play

But is it still a 4.5.1? I'm too used to things like __flash to leave them behind now so will just use the 4.8.1 that Atmel build for Linux.

I know ....

I have build atmels 4.4.3

 $ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/atmel-4.4.3/bin/../libexec/gcc/avr/4.8.1/lto-wrapper
Target: avr
Configured with: /home/bingo/tmp/builddir/src/gcc/configure LDFLAGS=-L/usr/local/avr/lib CPPFLAGS= --target=avr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr/local/avr --libdir=/usr/local/avr/lib --enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-avrlibc=yes --with-mpfr=/usr/local/avr --with-gmp=/usr/local/avr --with-mpc=/usr/local/avr --enable-fixed-point --with-pkgversion=AVR_8_bit_GNU_Toolchain_3.4.4-Bingo-_201407191715 --with-bugurl=http://www.atmel.com
Thread model: single
gcc version 4.8.1 (AVR_8_bit_GNU_Toolchain_3.4.4-Bingo-_201407191715) 

But i suspect they use a heavily patched avrlibc-1.8.0 , and didn't give it a try.
Atmel in their infinite wisdom didn't release patches , but already patched sourcefiles.

Btw: Jörg mentioned that Atmels TC was broken as in "would not build a "stock avrlibc".

besides Atmel seems to replace the avrlibc headers with their own , witch can make the use of a "stock 1.8.1" a challenge , of one even dare to use it.

function replace_avr_headers()
{
    avr_headers_dir=$1
    avr_libc_srcdir=$2
    for i in ${avr_headers_dir}/avr/io[0-9a-zA-Z]*.h
    do
      # Copy the avr-headers generated header files but do not replace legacy headers
      # header_name=`basename $i`
      # if ! test -a ${avr_libc_srcdir}/include/avr/$header_name; then
        cp -v -f $i ${avr_libc_srcdir}/include/avr/ || task_error "Replacing avr-libc headers with avr-headers"
      # else
      #  echo "skipping: $header_name"
      # fi
    done
} 

I could try to build it with avrlibc-1.8.1 but don't know what state it would end up in ... :? :?

/Bingo

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

Well i tried to build avrlibc-1.8.1 with the avr-4.4.3 toolchain.

I had to remove atmega16hvbrevb and atmega32hvbrevb from the avr/lib/avr5 makefile , both complained about undefined (io.h) and some "illegal .if" in the crt0.S file.

The i encountered this one :

Quote:

avr-gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../common -I../../../include -I../../../include -Wall -W -Wstrict-prototypes -mmcu=avrtiny -D__COMPILING_AVR_LIBC__ -mcall-prologues -Os -MT asctime_r.o -MD -MP -MF .deps/asctime_r.Tpo -c -o asctime_r.o ../../../libc/time/asctime_r.c
/tmp/cc5HKYKF.s: Assembler messages:
/tmp/cc5HKYKF.s:73: Error: illegal opcode elpm for mcu avrtiny
/tmp/cc5HKYKF.s:75: Error: register not supported
/tmp/cc5HKYKF.s:76: Error: register not supported
/tmp/cc5HKYKF.s:87: Error: illegal opcode elpm for mcu avrtiny
/tmp/cc5HKYKF.s:89: Error: register not supported
/tmp/cc5HKYKF.s:90: Error: register not supported
make[5]: *** [asctime_r.o] Error 1
make[5]: Leaving directory `/home/cfo/tmp/builddir/lc181/avr-libc-1.8.1/avr/lib/avrtiny'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/cfo/tmp/builddir/lc181/avr-libc-1.8.1/avr/lib/avrtiny'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/cfo/tmp/builddir/lc181/avr-libc-1.8.1/avr/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cfo/tmp/builddir/lc181/avr-libc-1.8.1/avr'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cfo/tmp/builddir/lc181/avr-libc-1.8.1'
make: *** [all] Error 2

And decided to stop here.

It might be as Jörg says , that the Atmel TC can't build "stock avrlibc" anymore ?

But the avr-gcc-4.5.1 only builds a small subset of the avr's known by Atmels TC , as avrlibc only makes the libs for the mcu-types known to the compiler.

Maybe i'll give the new "Gnu" avr-gcc 4.9.0 a try or the 4.8.3 , i'll have to see what Johann recommends.

/Bingo

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

Cliff

Your wish is my command :-)

avr-gcc 4.9.1 w. avrlibc-1.8.1
https://www.avrfreaks.net/index.p...

/Bingo

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

Oh cool! Now that is worth having a crack at. I'm going to have to dig out a VM because the two Linux machines I use regularly both have reasons why I cannot pull the dependency packages I need to build it.

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

I didn't make a .deb , as i'm on Mint 17 x64 (ubunty 14.04) , and didn't know your target machine

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
(./buildavr-toolchain.sh) 
(./buildavr-toolchain.sh) installation of avr GNU tools complete
(./buildavr-toolchain.sh) add /usr/local/avr/bin to your path to use the avr GNU tools
(./buildavr-toolchain.sh) you might want to run the following to save disk space:
(./buildavr-toolchain.sh) 
(./buildavr-toolchain.sh) rm -rf /usr/local/avr/source /usr/local/avr/build

:-)

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

Nice .....

Looking forward to see some comparisons against the Atmel TC

/Bingo

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

clawson wrote:
Downloads and bunzip2's fine on my machine.

I'll merge this thread with Joerg's announcement thread in GCC forum.

BTW I'm never clear - can you just use this as a "plug in" replacement for the avr-libc files you have or does it need to match the compiler that's using it?

The stuff is awfully tempting!

Yeah, Mike did a lot of work there. It's the first time code for 8-bit AVR I've found that handles DST. I checked it out about a month ago, and wrote a 1s tick ISR to work with it.

I noticed some of the code is pretty heavy; almost 1KB for using just set_dst() and localtime(). I was able to shave off almost 100 bytes by re-arranging the localtime_r code:
lt = *timer + __utc_offset;
gmtime_r(&lt, timeptr);

if (__dst_ptr) {
dst = __dst_ptr(timeptr);

/* add dst offset & regenerate struct tm */
lt += dst;
gmtime_r(&lt, timeptr);
timeptr->tm_isdst = dst;
}

I sent the above code to Mike in early July, but it wasn't incorporated into the release.

I think there's also room for improvement in gmtime_r(). My first try actually made the code larger (it's hard to predict how avr-gcc's optimizer works sometimes). My next idea is to reduce the leap year calculation to divisible by four. The library already leaves out the divisible by 400 exception, which I'm guessing means the library wouldn't properly handle old timestamps from 2000. Going with just divisible by four would work for all timestamps from 1970 to February 28, 2100, and giving up correctness from 2100 to 2016 is not a big deal IMHO.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Bingo600 wrote:
Well i tried to build avrlibc-1.8.1 with the avr-4.4.3 toolchain.

I had to remove atmega16hvbrevb and atmega32hvbrevb from the avr/lib/avr5 makefile , both complained about undefined (io.h) and some "illegal .if" in the crt0.S file.

:-) See my thread from last month about upper vs lowercase in avr-libc MCU defines.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Bingo600 wrote:
Cliff

Your wish is my command :-)

avr-gcc 4.9.1 w. avrlibc-1.8.1
https://www.avrfreaks.net/index.p...

/Bingo

Cool. Does LTO work well?

http://nerdralph.blogspot.ca/201...

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Quote:

Looking forward to see some comparisons against the Atmel

Well one of the the key things is this:

$ diff -y io81.txt io91.txt | grep \<
ioa5790n.h						      <
ioa5831.h						      <
ioa6612c.h						      <
ioa6613c.h						      <
ioa6614q.h						      <
ioa6616c.h						      <
ioa6617c.h						      <
ioa664251.h						      <
iom164a.h						      <
iom164p.h						      <
iom168a.h						      <
iom169a.h						      <
iom17.h							      <
iom324p.h						      <
iom3250a.h						      <
iom3250p.h						      <
iom325a.h						      <
iom325p.h						      <
iom328.h						      <
iom3290a.h						      <
iom329a.h						      <
iom329pa.h						      <
iom329p.h						      <
iom48a.h						      <
iom644a.h						      <
iom6450a.h						      <
iom6450p.h						      <
iom645a.h						      <
iom645p.h						      <
iom6490a.h						      <
iom6490p.h						      <
iom649a.h						      <
iom64hve2.h						      <
iom88a.h						      <
iotn441.h						      <
iotn841.h						      <
iox16e5.h						      <
iox32c3.h						      <
iox32d3.h						      <
iox32e5.h						      <
iox8e5.h						      <

That's comparing a list of the io*.h in Atmel's 4.8.1 with this 4.9.1. The list here is effectively what Atmel have and the rest of the world don't.

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

I have a pdf manual which goes into more a bit more depth than the AVR-Libc documentation of the time functions. I was going to post the manual as a 'Freaks Project', but that function seems to be unavailable at the moment.

It is available at http://swfltek.com/avr/Swfltek_T...

Reading the docs, and this manual, may answer some of the issues raised earlier in this thread.

This is a rather big change and I recognize there will be a lot of questions, so I am allocating some time specifically to answer any related questions.

As with any project of this scope, I can respond most readily to questions or complaints which include specifics... mcu type, clock rate, compiler version, & etc. In other words, a specific question will elicit a specific answer, while a vague question will elicit, at best, a vague answer.

Edit: The manual has been successfully posted as a project.

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

I suppose -flto is usable with 4.9.1. - Thanx Johann :D (et all)

I just toyed with usbasp , and made it wo. and with -flto on 3 different compilers.

COMPILE = avr-gcc -Wall -O2 -Iusbdrv -I. -flto -mmcu=$(TARGET) # -DDEBUG_LEVEL=2

4.5.1

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6374	      2	    202	   6578	   19b2	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6374	      2	    202	   6578	   19b2	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 
atmel 4.4.3 (4.8.1)


avr-objcopy -j .text -j .data -O ihex main.bin main.hex
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6576	      2	    202	   6780	   1a7c	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6580	      2	    202	   6784	   1a80	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 


4.9.1

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6598	      2	    202	   6802	   1a92	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $


bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   5970	      2	    202	   6174	   181e	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 

/Bingo

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

Bingo600 wrote:

4.5.1

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6374	      2	    202	   6578	   19b2	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6374	      2	    202	   6578	   19b2	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 

...



4.9.1

bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   6598	      2	    202	   6802	   1a92	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $


bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ avr-size main.bin
   text	   data	    bss	    dec	    hex	filename
   5970	      2	    202	   6174	   181e	main.bin
bingo@T500-1 ~/tmp/usbasp.2011-05-28/firmware $ 

/Bingo

Excellent. Looks like the first time in many releases (back to 4.3 or 4.4) that avr-gcc can generate smaller code now.

Looking forward to a new Atmel toolchain release with 4.9.1!

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

I've downloaded and upgraded from avr-libc-1.8.0 to avr-libc-1.8.1 in order to gain support for atmega256rfr2 devices but avr-gcc does not recognise the -mmcu=atmega256rfr2.

 

I'm currently on GCC 4.8.1.  Will and upgrade to 4.9.1 fix this? 

 

The documentation for GCC does not list the atmega256rfr2 in v 4.9.1

https://gcc.gnu.org/onlinedocs/g...

 

although i see that it seems to be included in version 5

https://gcc.gnu.org/onlinedocs/g...

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

I'm currently on GCC 4.8.1.  Will and upgrade to 4.9.1 fix this? 

A lot of new device support is held privately by Atmel and not pushed back up to the mainstream GCC. So you may have to wait either for (a) a new toolchain release form Atmel or (b) them to push their changes back. As you found, a new device is not as simple as just replacing AVR-LibC.

 

EDIT: the HEAD of the GCC dev tree is here:

 

https://github.com/gcc-mirror/gc...

 

See line 272 ;-), so, no, you won't be waiting for Atmel.

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

Any idea when the next formal release of gcc will be for gcc 5?  I'd really like to do the dev on linux instead of having to dual boot into windows in order to develop for the atmega256rfr2.

 

Or is it safe to download a snapshot of 5 and begin with that until a formal release is made available?

 

Thanks again.

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

There's a tree diagram at the bottom of this page:

 

https://gcc.gnu.org/develop.html

 

But while it mentions 5 it only gives times for up to 4.9.1.

 

In the link I gave above there's a drop list where you can view other branches - if you look at the 4_9 branch it had the 64rfr2 but not the 256rfr2. Would it be possible to use 4.9.1 for now and 64rfr2 then trade up when the later compiler is released?

 

PS this news: http://www.phoronix.com/scan.php... suggests "2015" for GCC 5.

Last Edited: Thu. Oct 9, 2014 - 10:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm developing on an ATMega256RFR2-Xplained board at the moment which runs a 256rfr2, so I wont be able to use a 64rfr2, unfortunately.  I'll try a snapshot of GCC 5 but failing that I'll just keep going on Atmel Studio until GCC 5 is released.

 

Thanks for all the info.

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

Supporting "unsupported" Devices

...

2. Use appropriate command line options to compile for your favorite device.

...

https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices

"Dare to be naïve." - Buckminster Fuller