Extra data in hex file??

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

Whilst chasing an elusive bootloader bug I ended up looking at the hex file produced by winAvr. The code stops at 0x271b according to the lss file but the hex file continues well past that.

00002718 <_exit>:
    2718:	f8 94       	cli

0000271a <__stop_program>:
    271a:	ff cf       	rjmp	.-2      	; 0x271a <__stop_program>

Hex file

:0C2710000FBECDBFED010895F894FFCF7F
:10271C002A72696E672A0A0025640A0025640A0A6F
:10272C00000A253564090025362E31660900253648
:10273C006C64090000000003000000004C016801FB
:10274C00000025632E2563202A202A202A200A0A2D
:10275C00002E2564202564200000000000000000ED
:10276C000000010202030303030404040404040430
:10277C0004050505050505050505050505050505FE
:10278C0005060606060606060606060606060606DE
:10279C0006060606060606060606060606060606CD
:1027AC0006070707070707070707070707070707AE
:1027BC00070707070707070707070707070707079D
:1027CC00070707070707070707070707070707078D
:1027DC00070707070707070707070707070707077D
:1027EC00070808080808080808080808080808085E
:1027FC00080808080808080808080808080808084D
:10280C00080808080808080808080808080808083C
:10281C00080808080808080808080808080808082C
:10282C00080808080808080808080808080808081C
:10283C00080808080808080808080808080808080C
:10284C0008080808080808080808080808080808FC
:10285C0008080808080808080808080808080808EC
:02286C00080062
:00000001FF

You can see ff cf at 271a but then there seems to be a lot of spurious stuff. Any enlightnment please?

edit just to be clear this is not the bootloader code but the application code the bootloader was trying to load up. It works but at times the bootloader seesm to go wonky and I need to reinstall it...just like windows. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
You can see ff cf at 271a but then there seems to be a lot of spurious stuff. Any enlightnment please?
Most likely it is the .data section. So have a look at the application source to see where it comes from.

Stefan Ernst

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

Not sure what you mean, the bits after the code (starting at 0x271C) does get programmed into the chip. I did a read back and it was all there, I thought at first that the bootloader was corrupting the data.

Some of it seems like printable chars but most seems nonsense.

Obviously I need to learn a LOT more about winAvr. :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
Whilst chasing an elusive bootloader bug I ended up looking at the hex file produced by winAvr. The code stops at 0x271b according to the lss file but the hex file continues well past that.
Quote:
Not sure what you mean, the bits after the code (starting at 0x271C) does get programmed into the chip. I did a read back and it was all there, I thought at first that the bootloader was corrupting the data.
So is the data part of the WinAVR generated hex file? Or is it only in the "read back" hex file?

If "yes" to the first question:
It is the .data section. From that part of the flash the initialized variables get their initial values. In the source you will find something similar to this:

uint8_t Array2[] = {2,2};
uint8_t Array3[] = {3,3,3,3};
uint8_t Array4[] = {4,4,4,4,4,4,4,4};

Stefan Ernst

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

Hm, looks like you application is bigger than the application area and your bootloader does not recognize this?! So it tries to program the "additional" data in the bootloader section. And therfore you have to reprogram the bootloader from time to time?

What I do in this case is to block the bootloader area in my applications to get a WinAVR error while compiling/linking the application.

I.e. I put this

uint8_t __attribute__((section(".bootloader")))    fl_BOOTLOADER[1024];	// allocate bootloader area

into my application for a 1k bootloader

and an additional

	LDFLAGS += -Wl,--section-start=.bootloader=0x3c00	#  e.g. ATmega162

linker option in the makefile to detect memory overflow.

So the application code should never touch the bootloader area. Works fine for me.

Just an idea...
HTH Alexander

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

Alexander,
why not simply setting the boot lock bits accordingly?
Or doing some address checking in the boot loader?
Both are far better than relying on the size of the application.

Your suggestion should only be a nice extra to get an error during the compilation.

Stefan Ernst

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

Hi Stefan,

sternst wrote:
Alexander,
why not simply setting the boot lock bits accordingly?

Because I want to know, how many remaining space I have while coding the application :wink: I don't care about the bootlader anymore at a certain point of development. That's one way to go...

I agree that setting the lock bit's is the first to do when detecting trouble like this the TO had. But this code snippets would already provide some information about proper memory layout.

Alexander

[edit] BTW: I remove the complete .bootloader section when creating the hex/bin file

	$(OBJCOPY) -O binary -R .eeprom -R .bootloader $< $(TRG).bin

to get the application only...

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

Just rebuild your project. Or read the map file.

But you seem to have a bootloader at a very strange load address. Remember that avr-gcc chooses to work in bytes when the AVR has word size instructions and a word aligned (and valued) location counter.

David.

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

david.prentice wrote:
But you seem to have a bootloader at a very strange load address.
???
Referred to Alexander or John?
Alexanders address is right. And John hasn't given any information about the address the bootloader is located.

Stefan Ernst

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

Oops. He did say it was the application code.

Even so. The map file should explain where the object file comes from. avr-size should show sizes. And simulating the application in Studio could show what gets loaded into memory.

And the bootloader lock bits should prevent trashing the bootloader.

David.

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

Looks like (weird) .data (notice the last 00 at the end of all the 08's, which looks like a linker alignment that happens at the end of .data/.text).

edit- also notice the last .text line is not a 'full' record, and the .data starts a new record at the next address. Sure looks like .data (and it would be strange not to have any .data in a 10k app).

Look for __data_load_start/__data_load_end in the linker map. Or view the disassembled output in the debugger to 'see' past the end of the lss listing.

We would like to see how you produce that 01-08 sequence :)

Last Edited: Tue. Oct 6, 2009 - 01:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is the initialized data section, right?

It has the data for all the variables, arrays and other data you initialize to non-zero. The startup code copies the data from flash to sram, so variables are initialized before main() runs.

All uninitialized variables and variables initialized to zero can be left out, as the startup code fills the sram to zero.

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

I am of the opinion that there is a bug in the newer GCC and/or AVR Studio in the handling of .elf and .hex files if there is a bootloader section. Debugging info in the .elf file is carried over to the .hex file and is unnecessarily programmed, and programming the .elf directly writes the bootloader at the wrong address.

Various freaks posts have indicated using the latest versions will fix that, but it didn't when I built the contiki jackdaw code two months ago on a fresh W7 install.

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

Quote:

I am of the opinion that there is a bug in the newer GCC and/or AVR Studio in the handling of .elf and .hex files if there is a bootloader section. Debugging info in the .elf file is carried over to the .hex file and is unnecessarily programmed, and programming the .elf directly writes the bootloader at the wrong address.

4.16 did have a bootloader programming bug that was fixed in SP1 and remains fixed in 4.17. Are you using 4.16?

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

The bug has/had nothing to do with the hex file generation. It is/was an AVR-Studio bug that fails to program the chip when the start address is not 0. Since the bootloader is already on the chip here this bug is unrelated to the topic in this thread.

Stefan Ernst

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

Jepael wrote:
All uninitialized variables and variables initialized to zero can be left out, as the startup code fills the sram to zero.
Not quite right. Only the bss section (where these variables are in) is zeroed, not the entire RAM.

Stefan Ernst

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

WrightFlyer wrote:

4.16 did have a bootloader programming bug that was fixed in SP1 and remains fixed in 4.17. Are you using 4.16?

My .elf test was with 4.16 with and without SP1. I'll give 4.17 a try next time.

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

Jepael wrote:
That is the initialized data section, right?

Unless JS has hacked the linker script, I am of the opinion that this is not the .data seciton.

The initialized data section goes near the beginning of the application, immediately after the interrupt vectors and immediately before the start of any executable code.

The jibberish John is reporting, is appearing at the end of the application, after the last word of executable code - the linker scripts would not place .data there by default.

- Luke

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

lfmorrison wrote:
The initialized data section goes near the beginning of the application, immediately after the interrupt vectors and immediately before the start of any executable code.
No, that is the progmem section, which is something different.

Quote:
The jibberish John is reporting, is appearing at the end of the application, after the last word of executable code - the linker scripts would not place .data there by default.
Any evidence for this statement?

Edit: I just did a small test to be sure, .data is right after .text.

Stefan Ernst

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

Quote:

Edit: I just did a small test to be sure, .data is right after .text.

Just to back that up - .data initialisers are generally the last thing in the binary as a result of:

  .data	  : AT (ADDR (.text) + SIZEOF (.text))

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

WOW just woke up :shock: and will start answering questions.

Quote:
So is the data part of the WinAVR generated hex file?
Yes and the read back is the same.

Getting some coffee...I'll be back.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I'm using Smiley's bootloader as I needed something quick for just 2 boards (1 for the client and one with me) so I don't have to run back and forwards as they do small changes.
It compiles at just over 1K (1166 bytes) for the M164p used here (just under 1K for M32 and about 1.8K for M644p!) Don't pretend to know what's going on there but that can be another thread later on. (I think I just found a possible bug with the BL)

So the bootloader sits at 0x1C00 (0x3800). AVROSPII reports flash contents being programmed from 0x0000 to 0x286D which is consistent with the hex file content past the end of the running code. (I have almost 4K from the end of the code to the BL)

11 variables where being initialised to 0 (just removed, see what happens), all strings in flash, some printf printing variables, no arrays, some short string may still not be just in flash, I'll check.

The point of the post being that I'm used to see the last byte of the code in the list file as "the last byte of the code" and was getting suspicious, not knowing better, about the "extra" bits thinking that perhaps the compiler, which hates me for some reason... :? was being deliberately annoying or more annoying than usual. :)

Back after the compulsory 15 minutes server back up break.
Just run the code in the simulator to see the memory and it looks like there is at least 1 string which is part of the "standard" UART.c code but still don't know what all the numbers from 0x0152 to 0x250 are.

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
but still don't know what all the numbers from 0x0152 to 0x250 are.
If you want a more profound answer, please post the source code. Or at least the map file if posting the source is not possible.

Stefan Ernst

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

Looking at the map file shows

.data           0x00800100      0x152 load address 0x0000271c
                0x00800100                PROVIDE (__data_start, .)

then

                0x0000271c                __data_load_start = LOADADDR (.data)
                0x0000286e                __data_load_end = (__data_load_start + SIZEOF (.data))

and

.text           0x00000000     0x271c
 *(.vectors)
 .vectors       0x00000000       0x7c c:/winavr-20081205/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/crtm164p.o
                0x00000000                __vectors
                0x00000000                __vector_default

so it is obviously required just that I did not know about it.

On to see why the BL goes wonky at times. Can't even ask for my money back as the disclaimer says

Quote:
// And to further cover my ass, let me add that if you use this software
// it will destroy whatever machine you use it on and kill anyone in a one
// kilometer radius. So don't even consider using it for any reason whatsoever!
:wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Argh, why you don't simply post the entire map file? Do the variable, function, and file names in it contain any secret information? I doubt that your snippets cover all the relevant information about that strange numbers.

Oh wait, there is already an interesting information in the snippets. The size of the .data section is 0x152, so the numbers are not part of it. Is there any section in the map file with size 0x175 (or 0xff)? How does the hex file generation part of the makefile look like? Any "external" data added to the hex file there?

Stefan Ernst

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

Stefan,

Sadly the .map file isn't much use here. If I compile:

char global_data[] = { "hello world" };

int main(void) {
	while(1);
}

the .map file shows beyond .text:

... (other .fini sections)
 *(.fini1)
 *(.fini0)
 .fini0         0x00000098        0x4 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_exit.o)
 *(.fini0)
                0x0000009c                _etext = .

.data           0x00800100        0xc load address 0x0000009c
                0x00800100                PROVIDE (__data_start, .)
 *(.data)
 .data          0x00800100        0x0 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/crtm328p.o
 .data          0x00800100        0xc test.o
                0x00800100                global_data
 .data          0x0080010c        0x0 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_exit.o)
 .data          0x0080010c        0x0 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_copy_data.o)
 *(.data*)
 *(.rodata)
 *(.rodata*)
 *(.gnu.linkonce.d*)
                0x0080010c                . = ALIGN (0x2)
                0x0080010c                _edata = .
                0x0080010c                PROVIDE (__data_end, .)

.bss            0x0080010c        0x0
                0x0080010c                PROVIDE (__bss_start, .)

So this does not admit to the copy of "Hello World" that will be located just beyond 0x009C. Yet the .hex file has:

...
:0C0090004C000C940000FFCFF894FFCF50
:0C009C0068656C6C6F20776F726C6400FC
:00000001FF

Where the last data record is positioned at 009C and contains the data 68 65 6C 6C 6F 20 77 6F 72 6C 64 00 = "hello world",0

I guess the one thing of use in the .map file is the:

0xc load address 0x0000009c

saying there are twelve bytes at 0x009c in the .hex

In John's file the equivalent is 0x152 at 0x271C so one would expect the .hex file to finish with 0x152 bytes of data at that address.

Cliff

EDIT: Actually converting John's data to displayable text we get:

=====================================================================================
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   2A 72 69 6E 67 2A 0A 00  25 64 0A 00 25 64 0A 0A   *ring*..#d..#d..
00000010   00 0A 25 35 64 09 00 25  36 2E 31 66 09 00 25 36   ..#5d..#6.1f..#6
00000020   6C 64 09 00 00 00 00 03  00 00 00 00 4C 01 68 01   ld..........L.h.
00000030   00 00 25 63 2E 25 63 20  2A 20 2A 20 2A 20 0A 0A   ..#c.#c * * * ..
00000040   00 2E 25 64 20 25 64 20  00 00 00 00 00 00 00 00   ..#d #d ........
00000050   00 00 01 02 02 03 03 03  03 04 04 04 04 04 04 04   ................
00000060   04 05 05 05 05 05 05 05  05 05 05 05 05 05 05 05   ................
00000070   05 06 06 06 06 06 06 06  06 06 06 06 06 06 06 06   ................
00000080   06 06 06 06 06 06 06 06  06 06 06 06 06 06 06 06   ................
00000090   06 07 07 07 07 07 07 07  07 07 07 07 07 07 07 07   ................
000000A0   07 07 07 07 07 07 07 07  07 07 07 07 07 07 07 07   ................
000000B0   07 07 07 07 07 07 07 07  07 07 07 07 07 07 07 07   ................
000000C0   07 07 07 07 07 07 07 07  07 07 07 07 07 07 07 07   ................
000000D0   07 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
000000E0   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
000000F0   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
00000100   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
00000110   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
00000120   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
00000130   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
00000140   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08   ................
00000150   08 00                                              ..

(I had to change some of the percent's to # in that)

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

clawson wrote:
So this does not admit to the copy of "Hello World" that will be located just beyond 0x009C. Yet the .hex file has:

...
:0C0090004C000C940000FFCFF894FFCF50
:0C009C0068656C6C6F20776F726C6400FC
:00000001FF

Where the last data record is positioned at 009C and contains the data 68 65 6C 6C 6F 20 77 6F 72 6C 64 00 = "hello world",0

I guess the one thing of use in the .map file is the:

0xc load address 0x0000009c

saying there are twelve bytes at 0x009c in the .hex

Yes, but the .data section in Flash is a direct mirror of the .data section in RAM. So if you are interested in where the data is coming from, you only have to inspect the lines after that:

                0x00800100                PROVIDE (__data_start, .)
 *(.data)
 .data          0x00800100        0x0 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/crtm328p.o
 .data          0x00800100        0xc test.o
                0x00800100                global_data
 .data          0x0080010c        0x0 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_exit.o)
 .data          0x0080010c        0x0 c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_copy_data.o) 

There you see that all 12 bytes come from test.o and that global_data is part of these 12 bytes. Of course there is still an information gap, because you can't see whether global_data consumes all 12 bytes, or whether there are additional symbols with local scope.

Quote:
In John's file the equivalent is 0x152 at 0x271C so one would expect the .hex file to finish with 0x152 bytes of data at that address.
My guess is that there is another section (user defined) added after .data, perhaps filled with external binary data, or something like that. John announced to mail me the map file (and I also asked for the makefile). I think that could enlighten it.

Stefan Ernst

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

sternst wrote:
John announced to mail me the map file (and I also asked for the makefile).
I think that could enlighten it.
Et voilà:

 .data          0x00800151      0x100 c:/winavr-20081205/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_clz.o)
                0x00800151                __clz_tab
 .data          0x00800251

The numbers pattern is a lookup table that comes from the generic math code in the gcc lib.

John,
please add libm.a to the project:

Project -> Configuration Options -> Libraries -> libm.a -> Add Library

The strange numbers pattern will disappear then (and also the size of the code will lower significantly).

Stefan Ernst

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

js wrote:
Can't even ask for my money back as the disclaimer says
Quote:
// And to further cover my ass, let me add that if you use this software
// it will destroy whatever machine you use it on and kill anyone in a one
// kilometer radius. So don't even consider using it for any reason whatsoever!
:wink:

And, did it destroy stuff and kill people as promised?

(sorry, just couldn't resist)

JW

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

I apologize for the misinformation, I'd never noticed that before. I guess it's not very surprising, considering I generally don't use very many (if any at all) non-zero initialized global variables...

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

Getting to know the ld scripts/startup code can be useful to see where the puzzle pieces come from.

Here's an ld script with some comments-
http://www.mtcnet.net/~henryvm/a...

Here's some (alternative) startup code-
http://www.mtcnet.net/~henryvm/a...

The above startup code just to show how the linker symbols are used. With this info, it should show how these things fit together. If you want to get the 'real' picture on the startup code, get gcrt1.S from libc source, and libgcc.S from gcc source.

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

This is nuts! By just adding libm.a the code shrinks by 2,576 bytes and ram usage by 265 bytes.
Of course I don't know if everything still works :( I'll try it all out later on this morning.

I had added libprintf_flt.a already to the library because I'm printing floating point number with the Cliff' help.

Now the tail of the hex file looks like this

:041E1000F894FFCF74 end of code

:101E14002A72696E672A0A0025640A0025640A0A80
:101E2400000A253564090025362E31660900253659
:101E34006C64090000000003000000004C0168010C
:101E4400000025632E2563202A202A202A200A0A3E
:0A1E5400002E256420256420000004
:00000001FF

I just knew should have stuck to ASM.. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

This is nuts! By just adding libm.a the code shrinks by 2,576 bytes and ram usage by 265 bytes.

No this is the avr-gcc/avrlibc toolchain, and you are not even close to being the first to fall in this trap. (Do a search for libm here to see that you are but one in a loooong line).

If you don't add libm.a then the toolchain will default to use a math library that is not tweaked to the AVR, and you get unfavourable memory performance. Adding libm.a is "standard procedure" if you need math functionality in your app.

Quote:
I just knew should have stuck to ASM..

No-one deleted the AVR Assembler from the face of the Earth. It's not too late to turn back.. :wink:

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

Quote:
Adding libm.a is "standard procedure"
So should this be the default setting in the Studio generated Makefile?

I'm ASS-U-MEing that by math you mean anything even as simple as addition or subtraction that everybody is likely to use??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
So should this be the default setting in the Studio generated Makefile?
Adding it if not really needed doesn't hurt, so definitely yes, it really should be in the makefile by default.

Stefan Ernst

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

Quote:

So should this be the default setting in the Studio generated Makefile?

Seems reasonable. Talk to Atmel about that.

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

I just get confused (easily done) as to why "generic" libraries are supplied at all when AVR twicked libraries exist. It is after all winAvr.

It must be some secret GCC user's way of confusing the non true believer. True GCC believer are required to go around .naked and offer chicken's blood to the GNU god at their meetings. :lol:

Does this then mean that, "if I were a rich man", and could afford CV, ICC or, if very rich IAR, would not have such issues?

And by the way thanks to Stefan and all that helped.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

John,

It's the way it works. By default, to make things "just work" on most new port targets, the compiler contains a generic set of routines for math work - like powers, floating point manipulations, etc. so that once the core compiler is ported to a platform, normal programs can be compiled.

However, that doesn't mean the code is optimal, far from it. Since the internal routines are all done in "high level C", the assembly they produce are not optimal for most platforms, but they do work. The compiler guys expect that for each particular platform, there'll be someone who will code up the needed routines in hand-crafted assembly to take advantage of the specific platform. That's the avr-libc math library. When you link against it, it's optimised routines override the internal implementations.

It's a smart system, since it means that the compiler can be used at least non-optimally on any platform, before someone comes along to improve the efficiency.

Linking against libraries doesn't "cost" anything unless a library function is referenced, so you should *always* link against the hand-crafted AVR math library.

In the WinAVR template, this is done for you. Score one for WinAVR, minus one for the horrible AVRStudio internal template.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

John,

I know it's not nice, but let me remind you:

js wrote:
Quote:
don't say I am not prejudiced against that floating plague...
Hey my client just got 3 times the ammount of code for no extra cost by just using float. :lol:

Value for money I say. Anyway the chip is only half full (or empty) so I will leave it for now.


So, your client just gets some more data bundled with the code, and what. You've been warned... ;-)

Welcome to the wonderful GNU world.

Notice for example how many "code bloats with new version of avr-gcc" complaints are around; and note how many magic switch settings are recommended to alleviate it. Although these switches (which are not that much documented, if at all) do different things thus there's no magic combination which yields shortest code for all possible programs, it appears that using any of them will reduce most programs as compared to the default setting. So, it might sense to have some of them enabled by default, but nobody appears to be bothered.

You can file a feature or enhancement request, for sure. Just chose one of the many places where you can do so. And you will get immediately rejected, as the principal developers don't want to be bothered by feature requests without an accompanying patch, but both you and them might then start feeling better.

Jan Waclawek

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

Quote:
minus one for the horrible AVRStudio internal template.
At least my complaints may lead to some improvements if someone who can do something about it reads this thread. :)

Studio\winAvr has come a long way for people like me to make it easier to use. That's a big plus.

I doubt it that I would have been trying to use GCC the old way with PN, makefile etc...that's for geeks. :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

JohanEkdahl wrote:
Quote:

So should this be the default setting in the Studio generated Makefile?

Seems reasonable. Talk to Atmel about that.

I reported this as a "bug" in Studio's avr-gcc plugin two to three years ago. The other thing I moaned about (having -O0 not -Os as the default optimisation) was eventually changed but their reply about the libm.a thing was that it was not so easy to achieve and would be done later.

Still waiting....

Cliff

(but I guess it must still be in their bug-tracker somewhere?)

PS As for making WinAVR more specific to the AVR I think Eric will confirm that the plan is to get the AVR specific code in libm.a moved "upstream" so it becomes part of the generic libc and will be used when building for AVR. But the thing is that getting changes made to the core of GCC is like trying to do a handbrake turn in a super-tanker. It's much easier to do things "locally" that don't impact the main GCC trunk.

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

Quote:

that's for geeks.

As is assembler.. :wink:

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]