The avr-gcc 4.7.1 is released! Update for AS6 ?

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

Hello!

The avr-gcc just released and there are quite many new features!

http://gcc.gnu.org/gcc-4.7/changes.html

When will be an avr-gcc update available for AS6 ?

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

Does anyone tried this with AS6 ?
http://www.makehackvoid.com/node/578/release

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

You might want to ask evildeece.

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

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

Quote:

You might want to ask evildeece.

Or Sprinter SB who's done a load of the work and knows whether it's ready to go to press or not.

Either yesterday or today he was already talking about faults in 4.7.1 which are now fixed in 4.7.2

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

clawson wrote:
Or Sprinter SB who's done a load of the work and knows whether it's ready to go to press or not.

Either yesterday or today he was already talking about faults in 4.7.1 which are now fixed in 4.7.2


Yes, of course.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

clawson wrote:
faults in 4.7.1 which are now fixed in 4.7.2
Just a small performance regression that might lead to some % of flash waste.

You might still be better off than with 4.6 or older compiler versions though.

avrfreaks does not support Opera. Profile inactive.

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

the good thing is that avr gcc 4.7.1+ has the new _flash feature so no need of pgm header and special functions as i understand.

well i hope at least to see it in AS 6.1 as also the data breakpoints at last implemented. Iar is too expensive and ugly for that money.

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

DieCore wrote:
the good thing is that avr gcc 4.7.1+ has the new _flash feature so no need of pgm header and special functions as i understand.
There is still need of special, non-standard functions if you locate data in flash. For example, you need
printf_P (const __flash char*, ...);

for format string in flash.

avrfreaks does not support Opera. Profile inactive.

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

Is it your release avr-gcc-5.2.1?

https://sourceforge.net/projects...

 

I have some trubles with avr-gcc-5.2.1 (the same time with avr-gcc-4.9.2 everything is fine)

 

    MCU = atmega1281

    LDFLAGS += -nodefaultlibs -lm -lgcc -lc              <<<<< i think the reason is -nodefaultlibs

 

    CFLAGS += -flto

    CFLAGS += -ffunction-sections
    CFLAGS += -fdata-sections
    CFLAGS += -mrelax

 

 

 

C:\Users\A7DDC~1.IVA\AppData\Local\Temp\ccoUMzIX.ltrans0.ltrans.o: In function `main':
<artificial>:(.text.startup.main+0x174): undefined reference to `eeprom_read_block'
<artificial>:(.text.startup.main+0x334): undefined reference to `eeprom_update_block'
<artificial>:(.text.startup.main+0x492): undefined reference to `eeprom_read_float'
<artificial>:(.text.gui_menu_item_value_write+0x34): undefined reference to `eeprom_update_block'
<artificial>:(.text.gui_menu_item_value_read+0x34): undefined reference to `eeprom_read_block'
<artificial>:(.text.pctl_program_callback+0x4e): undefined reference to `eeprom_read_dword'
...
collect2.exe: error: ld returned 1 exit status

 

Last Edited: Wed. Mar 2, 2016 - 11:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The way per device EEPROM library code is done has changed in recent issues of the compiler.

 

It used to be the case that all the various devices had their own eeprom functions in libc.a. This is the 4.5.3 compiler:

/usr/lib/avr/lib/avr4$ avr-nm libc.a | grep eewr_byte
eewr_byte_atmega48.o:
00000000 T __eewr_byte_m48
         U __eewr_byte_m48
eewr_byte_atmega48a.o:
00000000 T __eewr_byte_m48a
         U __eewr_byte_m48a
eewr_byte_atmega48p.o:
00000000 T __eewr_byte_m48p
         U __eewr_byte_m48p
eewr_byte_atmega8.o:
00000000 T __eewr_byte_m8
         U __eewr_byte_m8
eewr_byte_atmega88.o:
00000000 T __eewr_byte_m88
         U __eewr_byte_m88
eewr_byte_atmega88a.o:
00000000 T __eewr_byte_m88a
         U __eewr_byte_m88a
eewr_byte_atmega88p.o:
00000000 T __eewr_byte_m88p
         U __eewr_byte_m88p
eewr_byte_atmega88pa.o:
00000000 T __eewr_byte_m88pa
         U __eewr_byte_m88pa
eewr_byte_atmega8515.o:
00000000 T __eewr_byte_m8515
         U __eewr_byte_m8515
eewr_byte_atmega8535.o:
00000000 T __eewr_byte_m8535
         U __eewr_byte_m8535
eewr_byte_atmega8hva.o:
00000000 T __eewr_byte_m8hva
         U __eewr_byte_m8hva
eewr_byte_at90pwm1.o:
00000000 T __eewr_byte_90pwm1
         U __eewr_byte_90pwm1
eewr_byte_at90pwm2.o:
00000000 T __eewr_byte_90pwm2
         U __eewr_byte_90pwm2
eewr_byte_at90pwm2b.o:
00000000 T __eewr_byte_90pwm2b
         U __eewr_byte_90pwm2b
eewr_byte_at90pwm3.o:
00000000 T __eewr_byte_90pwm3
         U __eewr_byte_90pwm3
eewr_byte_at90pwm3b.o:
00000000 T __eewr_byte_90pwm3b
         U __eewr_byte_90pwm3b
eewr_byte_at90pwm81.o:
00000000 T __eewr_byte_90pwm81
         U __eewr_byte_90pwm81

I just picked "AVR4" there because it has few members but if you run avr-nm on any of the other libc.a you will find all the device specific routines within libc.a.

 

Now look at the same thing in a 4.9.2 version of the compiler:

avr8-gnu-toolchain-linux_x86_64/avr/lib/avr4$ avr-nm libc.a | grep eewr_byte
avr8-gnu-toolchain-linux_x86_64/avr/lib/avr4$ 

So nothing for the EEPROM in libc.a any more and instead:

avr8-gnu-toolchain-linux_x86_64/avr/lib/avr4$ grep eewr_byte *
Binary file libat90pwm1.a matches
Binary file libat90pwm2.a matches
Binary file libat90pwm2b.a matches
Binary file libat90pwm3.a matches
Binary file libat90pwm3b.a matches
Binary file libat90pwm81.a matches
Binary file libata6285.a matches
Binary file libata6286.a matches
Binary file libata6289.a matches
Binary file libata6612c.a matches
Binary file libatmega48.a matches
Binary file libatmega48a.a matches
Binary file libatmega48p.a matches
Binary file libatmega48pa.a matches
Binary file libatmega48pb.a matches
Binary file libatmega8515.a matches
Binary file libatmega8535.a matches
Binary file libatmega88.a matches
Binary file libatmega88a.a matches
Binary file libatmega88p.a matches
Binary file libatmega88pa.a matches
Binary file libatmega88pb.a matches
Binary file libatmega8.a matches
Binary file libatmega8a.a matches
Binary file libatmega8hva.a matches

and taking just one of those:

avr8-gnu-toolchain-linux_x86_64/avr/lib/avr4$ avr-nm libatmega88.a 

eerd_block.o:
00000000 T eeprom_read_block
00000004 T eeprom_read_blraw

eerd_byte.o:
00000000 T eeprom_read_byte

eerd_dword.o:
         U eeprom_read_blraw
00000000 T eeprom_read_dword
00000000 T eeprom_read_float

eerd_word.o:
         U eeprom_read_blraw
00000000 T eeprom_read_word

eeupd_block.o:
00000000 T eeprom_update_block
         U eeprom_update_r18

eeupd_byte.o:
00000000 T eeprom_update_byte
00000002 T eeprom_update_r18

eeupd_dword.o:
         U eeprom_update_byte
00000000 T eeprom_update_dword
00000000 T eeprom_update_float
         U eeprom_update_r18

eeupd_word.o:
         U eeprom_update_byte
         U eeprom_update_r18
00000000 T eeprom_update_word

eewr_block.o:
00000000 T eeprom_write_block
         U eeprom_write_r18

eewr_byte.o:
00000000 T eeprom_write_byte
00000002 T eeprom_write_r18

eewr_dword.o:
00000000 T eeprom_write_dword
00000000 T eeprom_write_float
         U eeprom_write_r18
         U eeprom_write_word

eewr_word.o:
         U eeprom_write_byte
         U eeprom_write_r18
00000000 T eeprom_write_word

So the stuff that was all grouped together in libc.a is now split into a load of lib<specific device name>.a files. This is to make it easier to install support for new models.

 

When you build code and link with "-mmcu=atmega88" then the implied link is now "-lc -lm -latmega88".

 

So either your compiler is not finding ../avr/lib/avr51/libatmega1281.a or it's not doing the implied "-latmega1281" when it links and is passed -mmcu=atmega1281

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

I find the reason: it was -nodefaultlibs linker option.

But in previous gcc version it works fine...

 

Without -nodefaultlibs previous compiler crashes when linking project.

 

Last Edited: Wed. Mar 2, 2016 - 11:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup because by using -nodefaultlibs you are saying "do not link as standard with -lc -lm -latmega1281". If you really want to continue to use -nodefaultlibs to avoid linking with libc.a and libm.a then you will need to specifically add "-latmega1281" in order to link with just the library that holds the EEPROM routines.

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

Thanx!

PS: Can anybody give link to downolad recent (5.2.3 or 6.0.0) avr-gcc compiler for windows64?

Last Edited: Wed. Mar 2, 2016 - 01:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is in those versions (for AVR) that you don't get in Atmel's current 4.9.2 builds?

 

If it were me I'd just wait for Atmel to issue a 5.x. Their version adds support for 100+ AVRs that are not supported in the mainline development tree for avr-gcc. (though Atmel are pushing support for those back to HEAD by degrees).

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

I always looking for best code-generation density (my low cost devices are based on AVR with 4,8 or 16K flash)

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

If size matter then don'y use GCC for the AVR. 

 

And ASM will have a even better density.

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

demiurg_spb wrote:
I always looking for best code-generation density (my low cost devices are based on AVR with 4,8 or 16K flash)

Rather ironically (for AVR) the code generation actually seems to be getting worse with each release of avr-gcc. (in part because the main compiler engine is optimized to generate the best ARM and i386 code).