AVR Freaks :: View topic - avrgcc 4.1.1, supports mega2560/2561

AVR Freaks

AVR GCC forum - avrgcc 4.1.1, supports mega2560/2561

Wang Guohui - May 30, 2006 - 08:33 AM
Post subject: avrgcc 4.1.1, supports mega2560/2561

Hello, lads,

AVRGCC tool chain (gcc-4.1.1, binutils-060523, avr-libc-1.4.4) built. It supports ATmega2560/2561.
It is available on: http://www.atmanecl.net/EnglishSite/softwareEnglish.htm

Best Regards,
Wang

abcminiuser - May 30, 2006 - 09:53 AM
Post subject: RE: avrgcc 4.1.1, supports mega2560/2561

Does this work with the latest WinAVR distribution - does it read the %path% variable correctly to find the LibC header files?

- Dean Twisted Evil

Wang Guohui - May 30, 2006 - 10:08 AM
Post subject:

Yes, It works with the default include path, and also works under Win98.

Wang

jimbotko - May 30, 2006 - 11:22 AM
Post subject:

Nice work! Does anybody have a nice Makefile template that play nice with v4.1.1? Using the template provided with the latest WinAVR distribution causes the make process to barf with various errors related to avr-objcopy, specifically when creating the load file for EEPROM and the extended listing.

abcminiuser - May 30, 2006 - 11:27 AM
Post subject:

Yep, just tried then and am seeing the same glitch, plus an ungodly amount of "warning: pointer targets in passing argument 1 of 'strcpy_P' differ in signedness". I can fix the latter with a few casts I believe, but i'm not sure how to fix the objcopy problem. As far as I can see the passed parameters are correct, so i'm unsure as to why it's just spitting out usage info rather than performing the requested operation.

Also thanks from me too. Usually non-WinAVR GCC builds have all sorts of problems as they are generally compiled with a different set of options which cause problems when put on different machines.

EDIT: Does anyone have the offical LibC 1.4.4 *binary* which I can grab? I want to reinstall the LibC to remove the Atman-specific headers.

- Dean Twisted Evil

peter.sager - May 30, 2006 - 11:56 AM
Post subject:

Hello

Are the signedness warnings a new gcc-4.1.1 issue? Out of the GCC-4.1.1 User Manual:
________________________________________________

-Wpointer-sign
Warn for pointer argument passing or assignment with different signedness.
This option is only supported for C and Objective-C. It is implied by ‘-Wall’
and by ‘-pedantic’, which can be disabled with ‘-Wno-pointer-sign’.
________________________________________________

I have added the [-Wno-pointer-sign] compiler option to suppress this warning.

Then I have no more errors or warnings in AvrStudio, but I have to say, that I don't use an EEPROM-Section

Best regards, Peter

[edit]
It seams like the [-Wpointer-sign] warning differentiates between:
unsigned char ≠ char ≠ signed char

abcminiuser - May 30, 2006 - 12:00 PM
Post subject:

Brilliant - that fixed it, and with any luck I won't see any problems using the new compiler (i've already modified my code to use the "used" attributes on my ISRs to prevent the global optimiser from removing them).

The only remaining problem is the avr-objcopy. This is the build output from PN:

Code:

Creating Extended Listing: ButtLoad.lss

avr-objdump -h -S ButtLoad.elf > ButtLoad.lss

Usage: C:\WinAVR\bin\avr-objdump.exe <option(s)> <file(s)>

 Display information from object <file(s)>.

 At least one of the following switches must be given:

  -a, --archive-headers    Display archive header information

  -f, --file-headers       Display the contents of the overall file header

  -p, --private-headers    Display object format specific file header contents

  -h, --[section-]headers  Display the contents of the section headers

  -x, --all-headers        Display the contents of all headers

  -d, --disassemble        Display assembler contents of executable sections

  -D, --disassemble-all    Display assembler contents of all sections

  -S, --source             Intermix source code with disassembly

  -s, --full-contents      Display the full contents of all sections requested

  -g, --debugging          Display debug information in object file

  -e, --debugging-tags     Display debug information using ctags style

  -G, --stabs              Display (in raw form) any STABS info in the file

  -W, --dwarf              Display DWARF info in the file

  -t, --syms               Display the contents of the symbol table(s)

  -T, --dynamic-syms       Display the contents of the dynamic symbol table

  -r, --reloc              Display the relocation entries in the file

  -R, --dynamic-reloc      Display the dynamic relocation entries in the file

  @<file>                  Read options from <file>

  -v, --version            Display this program's version number

  -i, --info               List object formats and architectures supported

  -H, --help               Display this information

make.exe: *** [ButtLoad.lss] Error 2

Looks to me that the correct parameters are being passed, it just wont accept them. Any ideas?

EDIT: Bugger, now I need it I can't find the linker option for global optimizations. Does anyone know what it is?

- Dean Twisted Evil

Wang Guohui - May 30, 2006 - 01:02 PM
Post subject:

To Dean,

Quote:

Creating Extended Listing: ButtLoad.lss
avr-objdump -h -S ButtLoad.elf > ButtLoad.lss

The problem seem not found sh.exe in any PATH envionment variable.
Suggest try to copy sh.exe to a registered PATH and try again, it should be ok.

Best regards

Wang

abcminiuser - May 30, 2006 - 01:06 PM
Post subject:

Wang,

Thanks for the suggestion, but it doesn't seem to be a problem. I did a echo %path% > C:\PathData.txt and got:

Quote:

C:\WinAVR\bin;C:\WinAVR\utils\bin;C:\WinAVR\avr\include;C:\WinAVR\avr;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI Technologies\ATI Control Panel C:\salvo\inc;C:\Program Files\Subversion\bin;C:\Program Files\QuickTime\QTSystem\

And sh.exe is located in C:\WinAVR\bin - the first directory on the list. As a test I ran sh from the command line from a different directory and it found it just fine.

Further testing. If I try to MAKE ALL without first cleaning, I get the error:

Quote:

Size before:
C:\WinAVR\bin\avr-size.exe: 'a.out': No such file

I assume this is connected with the fact that my MAKE ALL fails, thus failing to remove temp files.

Echoing a request for a WinAVR-based GCC4.1 compatible makefile, having a known-good template with which to work with would help immensly.

EDIT: Just did some more testing. The parameters are correct, but avr-objdump is not finding the elf in the current directory. Specifying the elf path explictly works. Is there an easy way to force the tool to use the current directory?

- Dean Twisted Evil

Wang Guohui - May 30, 2006 - 01:35 PM
Post subject:

I remembered that I had the same problem with .lss generation under gcc3.4.5, I solved with copy the sh.exe.

Quote:

I assume this is connected with the fact that my MAKE ALL fails, thus failing to remove temp files.

I agree with you, would you try invoke "make all" with -k option?

Code:

make -k all

Wang

peter.sager - May 30, 2006 - 11:09 PM
Post subject:

@Dean

For global optimisation: Are you thinking of:
-ffunction-sections + -gc-sections

Or maybe also:
-combine
-fwhole-program

I'm not sure if thhese options can do much. Maybe there is only a difference, if you have dead-code because you havn't tided-up your code.

Peter

Wang Guohui - May 31, 2006 - 02:52 AM
Post subject:

Hello,

avrgcc 4.1.1 tool chain fixed the problem for creating the load file for EEPROM and updated.

Regards,

Wang

jimbotko - May 31, 2006 - 04:00 AM
Post subject:

Wang Guohui wrote:

Hello,

avrgcc 4.1.1 tool chain fixed the problem for creating the load file for EEPROM and updated.

Regards,

Wang

Well I no longer get the usage error when creating the load file for the EEPROM, but I still get it for creating the extended listing. Sad

abcminiuser - May 31, 2006 - 05:22 AM
Post subject:

peter.sager wrote:

Bingo, "-fwhole-program" was what I was thinking of. I'm going to need to brush up on the new GCC4.x options Smile

.

Still getting the avr-objdump error. As i've said the software works correctly when given an explicit path, but when it is run from the makefile it errors out -- was a different compile option used? Apparently other GCC-based software which auto-generates the makefiles with explicit paths works, but not standard GCC with a makefile template.

I've recieved a few emails with things to try, will test them out when I get home from school in an hour or so and report back.

- Dean Twisted Evil

jimbotko - May 31, 2006 - 08:50 AM
Post subject:

So what are the "gotchas" with the GCC 4.x versus 3.x? Someone mentioned a "used" directive to keep ISRs from being optimized out. Are there other things to keep an eye out for that might break previously working code? Thanks!

abcminiuser - May 31, 2006 - 09:11 AM
Post subject:

Well, right now I can't really comment seeing as I can't compile Smile

.

Yes, you need to specify several new attributes, specifically "used" and "externally_visible" to prevent the new and improoved optimisations from deleting them. The new GCC system optimises the entire program, and removes dead code (no more "i'm not using function x so why is it taking up program space" questions) as well as I believe posessing multi-level macro substitutions, giving way for better LibC macros - with any luck the previously suggested macros for linking several ISRs will now compile correctly. GCC4 has also been patched along with the toolchain for the newest AVR devices.

I seem to remember a rather severe "gotcha" to do with pointers to structs - something along the lines of trying to increment the pointer deleted the local copy of the struct or something. I would assume it's been fixed by now. I'm going to go find the GCC bugzilla, and i'll report here if I find any AVR-target "gotchas".

Has anyone been sucessfull compiling a project with the new GCC4.1 under Programmers Notepad?

EDIT: AVR Bug List

- Dean Twisted Evil

abcminiuser - May 31, 2006 - 11:17 AM
Post subject:

After a lot of tests (including spaces in paths, filename case, etc) i've discovered the problem -- only I don't know how to fix it.

For some reason avr-objdump no longer likes to be piped to a file from inside PN. Take the following makefile line:

Code:

$(OBJDUMP) -h -S $< > $@

That runs the avr-objdump program, creates an extended listing from the input file ($(TARGET).elf) and pipes the output to the file $(TARGET).lss. In the command line (cmd.exe) this works fine, but within Programmer's Notepad the piping causes it to fail. The following line works:

Code:

$(OBJDUMP) -h -S $<

However having the entire listing appear in the output window is rather useless. If anyone can think of a fix, i'm all ears.

EDIT" Piping seems to be recognised (although running without a cmd window it fails to pipe) if the CON device is specified:

Quote:

Creating Extended Listing: ButtLoad.lss
avr-objdump -h -S ButtLoad.elf > CON
0 [main] sh 432 fhandler_base::dup: dup(CON) failed, handle F, Win32 error 87
/usr/bin/sh: CON: Invalid argument

Further testing shows that all the tools executed within PN fail if a pipe to a file is specified.

- Dean Twisted Evil

lfmorrison - May 31, 2006 - 12:12 PM
Post subject:

Huh?

avr-objdump is from binutils, not gcc. The latest stable release of binutils is still 2.16.1, the same as was used in recent releases of WinAVR.

It doesn't make sense that just updating gcc would break binutils programs, since binutils is built independently and prior to gcc in any given toolchain.

Probably it has more to do with the possibility that the binaries you "dropped into" your WinAVR installation are broken or some incompatiblities exist between the your computer and host on which they were built.

I have had no troubles piping my locally-built (using cygwin; I haven't ventured into MinGW peculiarities yet) copies of binutils 2.16.1, gcc 3.5.x, and gcc 4.0.x/4.1.0 through PN. Perhaps you should look into obtaining/building an alternative set of the relevant binaries.

[edit] Re-reading the initial post, I see this distribution is using a pre-release copy of binutils. Probably has to do with the necessary changes for adding ATmega256x support... [/edit]

abcminiuser - May 31, 2006 - 12:27 PM
Post subject:

Yep, just realised I got a new email from Wang telling me to remove some of the files. Seems AtmanAVR has incompatible builds of the binutils, which it places in the \bin\ directory. Since WinAVR\bin is higher in %path% than WinAVR\avr\utils\bin\, the new files were overiding the old. Still have to fix AVR-size, but everything else seems to be fine.

EDIT: Huzzah - removing the wonky files and replacing the avr-size exe with the WinAVR orginal has put me back in business. Sorry for wasting everyone's time!

- Dean Twisted Evil

Wang Guohui - May 31, 2006 - 12:40 PM
Post subject:

Hello,

This works well with WINAVR: GCC4.1-WINAVR (AVRGCC411.zip) on http://www.atmanecl.net/EnglishSite/softwareEnglish.htm

Usage: Extract all the files to the directory WINAVR.

Note: If you already updated the GCC tool chain with AVRGCC411.exe and it doesn't work with creating the extended listing, please uninstall WINAVR, and clean the hangover of files, especially the directory \WINAVR\bin. Re-install WINAVR, and extract the zip file to the installation path of WinAVR.

Wang

kenk - May 31, 2006 - 01:13 PM
Post subject:

HI Wang,

You said "avrgcc 4.1.1 tool chain fixed the problem for creating the load file for EEPROM and updated ". What exactly were your changes?

Thanks,

-Ken

abcminiuser - May 31, 2006 - 01:25 PM
Post subject:

From one of Wang's emails to me in his kind efforts to fix my problem:

Quote:

avr-objcopy.exe will return errors when copy section .eeprom but no eeprom data in deed. the problem will cause next rule can't be done.

In his email he said the problem had been fixed.

- Dean Twisted Evil

clawson - May 31, 2006 - 01:40 PM
Post subject:

Personally I think I'll just wait for Eric to put together the 4.x WinAVR Wink

Cliff

Wang Guohui - May 31, 2006 - 02:00 PM
Post subject:

Hi, Ken,

In objcopy.c file, about at 1421 line:

Code:

  if (bfd_count_sections (obfd) == 0)

    {

      non_fatal (_("there are no sections to be copied!"));

      return FALSE;

    }

change FALSE to TRUE will avoid the error.

Regards,
Wang

peter.sager - May 31, 2006 - 02:32 PM
Post subject:

Great...!

Thanks a lot for working out these problems and for providing this AVR-GCC 4.1.1 also as an WinAVR Upgrade.

Nevertheless, I want to mention that this built is an unofficial version which is containing the beta-release patches (provided by Bjoern Haase) to support the new AtMega256x devices. Everybody who is working (respectively doing experiments) with this release, has to consider that this is not an official WinAVR built.

http://lists.gnu.org/archive/html/avr-libc-dev/2006-05/msg00009.html

This is a set of patches affecting gcc, avr-libc and the binutils as well.

I think it is a good idea to make this patches available to a big community for doing tests, their feedbacks can be very valuable for working out a final solution.

Best Regards Peter

jimbotko - May 31, 2006 - 02:37 PM
Post subject:

Wang Guohui wrote:

Nice work! I compile with no errors now. My programs still working is another story... time to read up on those v4.x changes!

jimbotko - Jun 01, 2006 - 04:40 AM
Post subject:

Hmm well I've tried compling code with ISRs both with and without the used and externally_visible attributes, and it has no effect on the code size. Perhaps just having the signal or interrupt attribute has a similar effect?

jimbotko - Jun 01, 2006 - 11:22 AM
Post subject:

Well I am pleased to report that my ISRs are NOT being optimized out even with just being declared as __attribute__ ((signal)).

However the compilation appears to be barfing on some assembly macros in eeprom.h. Sad

Code:

> "make.exe" all

avr-gcc -mmcu=attiny45 -Os -mno-interrupts -funsigned-char -funsigned-bitfields -Wall -Wstrict-prototypes -ggdb -c -DF_CPU=8000000UL -Wa,-acdhlmns=main.lst main.c -o main.o

C:\DOCUME~1\marty\LOCALS~1\Temp/ccUtbaaa.s: Assembler messages:

C:\DOCUME~1\marty\LOCALS~1\Temp/ccUtbaaa.s:311: Warning: expression dangerous with linker stubs

C:\DOCUME~1\marty\LOCALS~1\Temp/ccUtbaaa.s:312: Warning: expression dangerous with linker stubs

C:\DOCUME~1\marty\LOCALS~1\Temp/ccUtbaaa.s:998: Warning: expression dangerous with linker stubs

C:\DOCUME~1\marty\LOCALS~1\Temp/ccUtbaaa.s:999: Warning: expression dangerous with linker stubs

avr-gcc -mmcu=attiny45 -Os -mno-interrupts -funsigned-char -funsigned-bitfields -Wall -Wstrict-prototypes -ggdb main.o -o nav_hack.elf -Wl,-Map=nav_hack.map --cref -lm

main.o: In function `eeprom_read_byte':

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:195: undefined reference to `__eeprom_read_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:195: undefined reference to `__eeprom_read_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:195: undefined reference to `__eeprom_read_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:195: undefined reference to `__eeprom_read_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:195: undefined reference to `__eeprom_read_byte_1C1D1E'

main.o: In function `eeprom_write_byte':

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:289: undefined reference to `__eeprom_write_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:289: undefined reference to `__eeprom_write_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:289: undefined reference to `__eeprom_write_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:289: undefined reference to `__eeprom_write_byte_1C1D1E'

c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:289: undefined reference to `__eeprom_write_byte_1C1D1E'

main.o:c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/include/avr/eeprom.h:289: more undefined references to `__eeprom_write_byte_1C1D1E' follow

make.exe: *** [nav_hack.elf] Error 1

> Process Exit Code: 2

> Time Taken: 00:01

Wang Guohui - Jun 01, 2006 - 03:40 PM
Post subject:

@jimbotko and all

Sorry, an careless mistake Embarassed

.
Please delete the file \WinAVR\lib\gcc\avr\4.1.1\libc.a, this is a temp test file but forget to remove it.

The avrgcc411.zip updated.

Wang

jimbotko - Jun 01, 2006 - 08:23 PM
Post subject:

Wang Guohui wrote:

@jimbotko and all

Sorry, an careless mistake Embarassed

.
Please delete the file \WinAVR\lib\gcc\avr\4.1.1\libc.a, this is a temp test file but forget to remove it.

The avrgcc411.zip updated.

Wang

Thanks, that fixed the EEPROM errors! However I still get the "ccUtbaaa.s:998: Warning: expression dangerous with linker stubs" warnings. Odd.

jimbotko - Jun 02, 2006 - 11:40 AM
Post subject:

C'mon, I know some of you guys are playing with this! Smile

shanuc - Jun 02, 2006 - 12:16 PM
Post subject:

the file is still in your temp directory , delete your temp files or do a make clean , may help

kscharf - Jun 02, 2006 - 03:02 PM
Post subject: Source chain for linux?

Is there a source chain available to build the mega256 aware version under linux? (the available binaries are for windows). I downloaded the source code for the GCC 4.1.1 packages mentioned but they don't appear to have the patches for the mega256 support.

How can I get a complete patched source for avr-gcc, avr-libc and avr-binutils
and how do I build this under linux? Will this work with cross-dev?

jimbotko - Jun 02, 2006 - 08:36 PM
Post subject:

shanuc wrote:

the file is still in your temp directory , delete your temp files or do a make clean , may help

Thanks for the input. I do a make clean before every build. Every time I compile, the warning file name changes. ccCIaaaa.s, then ccEZaaaa.s, then ccYZaaaa.s...

t2dave - Jun 03, 2006 - 12:45 AM
Post subject: Source code

Does anyone know where the source code for the gcc/binutils and avrlib that this beast contains - I looked on the site - and could not find it.

My understanding of the GPL is they have to give me the source if they want to distribute it. I want to compile it for linux.

dave

jimbotko - Jun 04, 2006 - 12:02 AM
Post subject:

jimbotko wrote:

shanuc wrote:

the file is still in your temp directory , delete your temp files or do a make clean , may help

Thanks for the input. I do a make clean before every build. Every time I compile, the warning file name changes. ccCIaaaa.s, then ccEZaaaa.s, then ccYZaaaa.s...

Hmm, it only seems to generate these errors when compiling my ATtiny45 project... when I compile it for an ATmega part I don't get any such warnings. Any ideas?

peter.sager - Jun 21, 2006 - 06:07 PM
Post subject:

Hello Wang

I tried to work with AvrStudio and your AVR-GCC 4.1.1 built for WinAVR, but at first it didn't work, I've got the following error:

Quote:

avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
-t --totals Display the total sizes (Berkeley only)
--target=<bfdname> Set the binary file format
@<file> Read options from <file>
-h --help Display this information
-v --version Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec tekhex binary ihex
make: *** [size] Error 1
Build succeeded with 0 Warnings...

As Dean already mentioned before, it is working when your new "avr-size.exe" is replaced by the old "avr-size.exe" of the original WinAVR distribution. Your version of avr-size does not support the Options -C (Avr) and -mcu (MCU name). Could you fix that, or add the original avr-size.exe to your WinAvr_AVR-GCC4.1.1beta.zip archive.

Best regards, Peter

peter.sager - Jun 21, 2006 - 06:10 PM
Post subject:

[deleted] because it was the same as above... ;o)

Wang Guohui - Jun 22, 2006 - 04:04 PM
Post subject:

Hello,

Quote:

Replaced avr-size.exe with WinAVR-20060421's original avr-size.exe.

Thanks to Peter and Dean,
Wang

abcminiuser - Jun 23, 2006 - 02:44 AM
Post subject:

Oh, while I'm here: is there any way to make GCC *not* look at every drive on my system when compiling? As it stands if I don't have a CD in my CDROM drive, about half the time GCC will halt until I insert any disk. This happens despite having absolutely no references to my drive D in my project.

- Dean Twisted Evil

lfmorrison - Jun 23, 2006 - 12:28 PM
Post subject:

I think that behaviour is dependant on the absolute path to the folder that was used to hold the toolset during the build process. My bet is that you're using a build of GCC that was compiled on the user's D: drive.

I remember EW talking about it a while back, and saying that it would require in-depth patching of the GCC core to change that behaviour.

I seem to remember that similar problems were encountered by WinAVR (current or previous version? I don't remember...) users who had compact flash drives mapped to M:, since EW compiled his version of avr-gcc on his M: drive. The problem didn't show up for users who didn't happen to have anything mapped to their M: drives.

clawson - Jun 23, 2006 - 12:39 PM
Post subject:

It should be possible to change the drive letter for the CD/DVD to some other letter and perhaps even use a "subst" to make a phantom D: that maps to some folder on C:

Cliff

abcminiuser - Jun 23, 2006 - 04:01 PM
Post subject:

clawson wrote:

It should be possible to change the drive letter for the CD/DVD to some other letter and perhaps even use a "subst" to make a phantom D: that maps to some folder on C:

Cliff

Oh perfectly possible, but that would be more annoying than the current problem Wink

. I'm quite happy to keep a CD in the drive at all times (which is usually the case anyway) but I wouldn't mind it if this issue would be fixed in the new WinAVR incorporating GCC4.1. Speaking of which, will the next WinAVR use GCC4.0 or GCC4.1 Eric?

- Dean Twisted Evil