eeprom functions have moved in new Atmel gcc...

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

The optiboot bootloader uses "-nostdlib -nostartfiles" to supress the start files and other stuff copied into normal binaries to save space.   On versions that include EEPROM support, it has then included "-lc" at the end of the gcc command, in order to pick up the eeprom_read_byte() and eeprom_write_byte() functions from avr-libc.  This has worked well with assorted versions of avr-gcc/avr-libc up through 4.8.x or so.

 

In the latest Atmel toolchain release (avr8-3.5, which has avr-gcc 4.9.2), I get link errors because the eeprom functions are no longer IN lib/avr/lib/avrN/libc.a, but rather (apparently) in lib/avr/lib/avrN/lib<chipname>.a, and -lc doesn't seem to cause that to be searched :-(

Is this a bug?  (Should lib<chipname>.a be considered part of -lc ?)  Is there some other way I can add those per-chip libraries back to by build without having to name them explicitly? (actually, naming them explicitly doesn't seem to work, either.  Are the avrN sub-directories not normally in the library search path?  (Apparently not!  I sure don't want to have to derive THOSE in a makefile!)  Sigh.

 

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

westfw wrote:
Is this a bug?

I don't think so. Are you passing a -mmcu= to the linker? When you do that should link that eeprom lib for the device.

 

Or are you suggesting that it should not be excluded by "-nostdlib -nostartfiles"? I agree that -nostartfiles should have no effect on it being in the link but surely the very purpose of -nostdlib is to say you don't want to link with things like this?

 

Why are you using -nostdlib anyway? All that's required for a space concious bootloader is to ditch the vectors and CRT with -nostartfiles.

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

Why are you using -nostdlib anyway? All that's required for a space concious bootloader is to ditch the vectors and CRT with -nostartfiles.

-nostartfiles will prevent the CRT from being linked, but it won't prevent __do_clear_bss or __do_copy_data from being linked.  That requires -nostdlib.

 

EDIT: a quick look at the source for Optiboot shows no global or local static variables, so even without -nostdlib it should be that __do_clear_bss and __do_copy_data are excluded anyway.  However, if memory serves, this was not the case for earlier versions of the toolchain i.e. even without any global or static local variables, 'empty' __do_clear_bss and __do_copy_data loops would be linked anyway.  I'd surmise this is the reason -nostdlib was originally used in the Optiboot build.  It would seem it isn't necessary anymore, and this would probably solve the OP's issue.  A conditional check for the compiler version in the Makefile could include/exclude the flag as appropriate.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Feb 6, 2016 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you moved?

 

 

EDIT: I see that it is now at Github, but Google still returns the Google Code link as the first hit (for me, anyway).  I suppose that's not a surprise, since Google of course owns/runs Google Code :)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Feb 6, 2016 - 04:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
but it won't prevent __do_clear_bss or __do_copy_data from being linked. 

No that's changed too - they are only pulled in when required. If you don't have any .data/.bss variables then they won't be in the link. Nothing to do with -nostartfiles or -nostdlib. You just turn them off by not requiring them.

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

clawson wrote:
No that's changed too - they are only pulled in when required. If you don't have any .data/.bss variables then they won't be in the link. Nothing to do with -nostartfiles or -nostdlib. You just turn them off by not requiring them.
Uh...:

...this was not the case for earlier versions of the toolchain i.e. even without any global or static local variables, 'empty' __do_clear_bss and __do_copy_data loops would be linked anyway.  I'd surmise this is the reason -nostdlib was originally used in the Optiboot build.  It would seem it isn't necessary anymore, and this would probably solve the OP's issue.  A conditional check for the compiler version in the Makefile could include/exclude the flag as appropriate.

In previous versions of the toolchain, __do_clear_bss and __do_copy_data would appear whether or not there were any static variables.  More recent versions will not emit those bits in the absence of any static variables.  Using -nostdlib will suppress their emission >>even when<< there are static variables.

 

Optiboot predates the versions of the toolchain which handle __do_clear_bss and __do_copy_data properly, and -nostdlib was required to supress them.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Feb 6, 2016 - 08:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Exactly - I want the makefiles to work with everything from WINAVR (gcc 4.3.x) through the current Atmel tools (4.9.x)  :-(

 

Optiboot had to move because Google shut down code.google.com; I get a nice redirect page with

Since Google Code is closing

Optiboot has been moved to GitHub

https://github.com/Optiboot/optiboot

Do not make changes or submit issues here

Weird that you just got a 404 error!

 

A conditional check for the compiler version in the Makefile

Is there a standard way to do that?

 

 

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

Is there a standard way to do that?

Maybe not 'standard', but:

CC_MAJ:=$(shell $(CC) -dM -E - < /dev/null | grep __GNUC__ | cut -f3 -d\ )
CC_MIN:=$(shell $(CC) -dM -E - < /dev/null | grep __GNUC_MINOR__ | cut -f3 -d\ )
CC_PATCHLEVEL:=$(shell $(CC) -dM -E - < /dev/null | grep __GNUC_PATCHLEVEL__ | cut -f3 -d\ )
CC_VER:=$(shell echo $$(( $(CC_MAJ) * 10000 + $(CC_MIN) * 100 + $(CC_PATCHLEVEL) )))
ifeq ($(shell test $(CC_VER) -lt 40601 && echo 1),1)
CCFLAGS+=-nostdlib
endif

This would add -nostdlib to the CCFLAGS variable when the compiler version is older than version 4.6.1.  Note that I pulled this version out of thin air.  I have no idea if that's the compiler version where the new behaviour w.r.t. __do_clear_bss and __do_copy_data appeared.  You'll have to test that yourself.

 

Note also that I have no idea whether it is the compiler which is implicated.  It may very well be the linker.  A similar method could be used to extract the version number from the linker with avr-ld --version.  However, I expect that most any distribution will ship with the same compiler/avrlibc/binutils, so testing against the compiler version should be sufficient.

 

There are other ways to do the arithmetic.  Make usually uses sh for a shell, which can't do arithmetic, although Ubuntu's sh is actually dash, which can.  For other systems, you'll need:

SHELL=/bin/bash

Or you can use bc:

CC_VER:=$(shell echo "$(CC_MAJ)*10000 + $(CC_MIN)*100 + $(CC_PATCHLEVEL)" | bc)

You could also use bc for the comparison:

 ifeq ($(shell echo "$(CC_VER)<40601" | bc), 1)

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Feb 7, 2016 - 07:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.  Alas, finding a "shell" when running Make has already been a problem :-(

 

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

Thanks.  Alas, finding a "shell" when running Make has already been a problem :-(

The 'Windows conundrum'?  If so, I'm sure there are alternatives.  I just don't know what they are :( ... But I bet someone else around here does...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:
I'm sure there are alternatives.

Apart from installing MinGW/MSYS, it might be possible to use Windows PowerShell.

 

It would certainly be possible to write a small utility in any language to do most or all of the job. The thing that I cant figure out without experimenting is how to communicate back to GNU Make what the result was. (Can GNU Make examine the exit value from a program on Windows (i.e. the ERRORLEVEL)?) Have to google a bit. Apart from that a small program that executes AVR-GCC just as Joey does, captures the output and examines it just like Joeys script does, and then exits 1 if it's version is higher than a version given as a input parameter, 0 otherwise, looks quite doable.

 

Let me know if I should make a serious effort trying this out, Bill! (What would be your preferred language for this? If you have a C compiler that targets Windows then that would work best for me. I could do something in C#, although that will take some time since I presently have no .NET development environment set up. Perl might also work, if you have that available.)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

The thing that I cant figure out without experimenting is how to communicate back to GNU Make what the result was. (Can GNU Make examine the exit value from a program on Windows (i.e. the ERRORLEVEL)?)

I don't believe it has any notion of exit value, other than the normal notion which is to abort the build in the event of a non-zero exit value.

 

Note how the script I propose 'transforms' the exit value of the test command into output on stdout:

test $(CC_VER) -lt 40601 && echo 1

The output will be '1' if the test succeeds, and nothing (i.e. empty string) if the test fails.  In either case, the exit value of the shell command itself will always be that of success.

 

You can do the same thing in DOS/WIN shell:

C:\> dir /b | find -i "file" > nul: && echo 1

This will return '1' if C:\ contains any files or folders with the (case insensitive) string 'file' in their names.  It will return nothing (empty string) if there are none.  As for the behaviour of make's shell command (i.e. succeed or fail) in this context, I cannot say and cannot test.

 

Apart from installing MinGW/MSYS, it might be possible to use Windows PowerShell.

A solution which works with a stock WIN install and no additional tools (whether 3rd party or custom-made) would seem to be more practical.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Something like this might do it:

CC_MAJ:=$(shell $(CC) -dM -E - < nul: | find "__GNUC__" > %TEMP%\\cc_maj & for /f "tokens=3 delims= " %i in (%TEMP%\\cc_maj) DO ( echo %i) )
CC_MIN:=$(shell $(CC) -dM -E - < nul: | find "__GNUC_MINOR__" > %TEMP%\\cc_min & for /f "tokens=3 delims= " %i in (%TEMP%\\cc_min) DO ( echo %i) )
CC_PATCHLEVEL:=$(shell $(CC) -dM -E - < nul: | find "__GNUC_PATCHLEVEL__" > %TEMP%\\cc_patchlevel & for /f "tokens=3 delims= " %i in (%TEMP%\\cc_patchlevel) DO ( echo %i) )
CC_VER:=$(shell set /a $(CC_MAJ) * 10000 + $(CC_MIN) * 100 + $(CC_PATCHLEVEL))
ifeq ($(shell if $(CC_VER) lss 40601 echo 1),1)
CCFLAGS+=-nostdlib
endif

Not sure if I need to escape anything.  The only thing I did escape is the backslash in the temp files.  I can't test any of this since I don't have a windows machine with avr-gcc or make, only a mostly-bare win2kpro vm.  The shell commands are right (I hope?), but the make/$(shell) constructs w.r.t. DOS/WIN shell might be flawed.

 

Oh, and the gnu version or the dos/win version can be selected based on the variable OS as passed to make on the command line:

make OS=windows

... as per your omake.bat file.

 

As for which shell is used by make under windows:

https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html

 

EDIT: grammar

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Feb 10, 2016 - 06:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess the real question is "shouldn't "-lc -lgcc" cause the relevant per-chip libraries to be searched as well?   Yeah, the files are split differently, but it's still part of avr-libc, right?

 

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

westfw wrote:
I guess the real question is "shouldn't "-lc -lgcc" cause the relevant per-chip libraries to be searched as well? Yeah, the files are split differently, but it's still part of avr-libc, right?

I'm still confused (the amount of wine I drank last night probably doesn't help!) but I still believe that action of -nostdlib is to turn on/off the implied "-lc -lgcc" in the link. Surely, now that the EEPROM stuff have been broken out separately the switch is now controlling whether "-lc -lgg -latmega16" (for -Wl,-mmcu=atmega16) is used or not?

 

Off to try a quick experiment...

 

~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ cat avr.c
#include <avr/io.h>
#include <avr/eeprom.h>

int m;
int n EEMEM = 12345;

int main(void)
{
    m = eeprom_read_word(&n);
    while (1) {
    }
}

~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ ./avr-gcc -mmcu=atmega16 -Os -Wl,-Map,avr.map avr.c -o avr.elf
~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ cat avr.map
                [SNIP!]
Archive member included to satisfy reference by file (symbol)

/home/uid23021/windows/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.9.2/avr5/libgcc.a(_exit.o)
                              /home/uid23021/windows/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.9.2/../../../../avr/lib/avr5/crtatmega16.o (exit)
/home/uid23021/windows/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.9.2/avr5/libgcc.a(_clear_bss.o)
                              /tmp/cca8Tcmy.o (__do_clear_bss)
/home/uid23021/windows/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.9.2/../../../../avr/lib/avr5/libatmega16.a(eerd_word.o)
                              /tmp/cca8Tcmy.o (eeprom_read_word)
/home/uid23021/windows/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.9.2/../../../../avr/lib/avr5/libatmega16.a(eerd_block.o)
                              /home/uid23021/windows/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/4.9.2/../../../../avr/lib/avr5/libatmega16.a(eerd_word.o) (eeprom_read_blraw)
                [SNIP!]
~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ ./avr-gcc -nostdlib -mmcu=atmega16 -Os -Wl,-Map,avr.map avr.c -o avr.elf
/tmp/ccWc8Fx5.o: In function `main':
avr.c:(.text.startup+0x4): undefined reference to `eeprom_read_word'
collect2: error: ld returned 1 exit status

That seems to prove that the -latmega16 is controlled by the -nostdlb. So why are you using -nostdlib? What is it (beside the EEPROM stuff) that you are switching off by using it?

 

I still believe you would get exactly what you are looking for (no vector table, no CRT but include the EEPROM stuff) if you simply use -nostartfiles and forget -nostdlib (because you DO effectively want to use something from the stdlib!):

~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ cat avr.c
#include <avr/io.h>
#include <avr/eeprom.h>

int n EEMEM = 12345;

int main(void)
{
    volatile int m;

    m = eeprom_read_word(&n);
    while (1) {
    }
}

~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ ./avr-gcc -nostartfiles -mmcu=atmega16 -Os -Wl,-Map,avr.map avr.c -o avr.elf
~/windows/avr8-gnu-toolchain-linux_x86_64/bin$ avr-objdump -S avr.elf

avr.elf:     file format elf32-avr

Disassembly of section .text:

00000000 <main>:
   0:	cf 93       	push	r28
   2:	df 93       	push	r29
   4:	00 d0       	rcall	.+0      	; 0x6 <__zero_reg__+0x5>
   6:	cd b7       	in	r28, 0x3d	; 61
   8:	de b7       	in	r29, 0x3e	; 62
   a:	80 e0       	ldi	r24, 0x00	; 0
   c:	90 e0       	ldi	r25, 0x00	; 0
   e:	0e 94 0c 00 	call	0x18	; 0x18 <eeprom_read_word>
  12:	9a 83       	std	Y+2, r25	; 0x02
  14:	89 83       	std	Y+1, r24	; 0x01
  16:	ff cf       	rjmp	.-2      	; 0x16 <__zero_reg__+0x15>

00000018 <eeprom_read_word>:
  18:	a8 e1       	ldi	r26, 0x18	; 24
  1a:	b0 e0       	ldi	r27, 0x00	; 0
  1c:	42 e0       	ldi	r20, 0x02	; 2
  1e:	50 e0       	ldi	r21, 0x00	; 0
  20:	0c 94 14 00 	jmp	0x28	; 0x28 <eeprom_read_blraw>

00000024 <eeprom_read_block>:
  24:	dc 01       	movw	r26, r24
  26:	cb 01       	movw	r24, r22

00000028 <eeprom_read_blraw>:
  28:	fc 01       	movw	r30, r24
  2a:	e1 99       	sbic	0x1c, 1	; 28
  2c:	fe cf       	rjmp	.-4      	; 0x2a <eeprom_read_blraw+0x2>
  2e:	06 c0       	rjmp	.+12     	; 0x3c <eeprom_read_blraw+0x14>
  30:	ff bb       	out	0x1f, r31	; 31
  32:	ee bb       	out	0x1e, r30	; 30
  34:	e0 9a       	sbi	0x1c, 0	; 28
  36:	31 96       	adiw	r30, 0x01	; 1
  38:	0d b2       	in	r0, 0x1d	; 29
  3a:	0d 92       	st	X+, r0
  3c:	41 50       	subi	r20, 0x01	; 1
  3e:	50 40       	sbci	r21, 0x00	; 0
  40:	b8 f7       	brcc	.-18     	; 0x30 <eeprom_read_blraw+0x8>
  42:	08 95       	ret

(I also moved "int m" inside main() and made it volatile (just so some code was generated) as I didn't want _do_clear_bss())

Last Edited: Mon. Feb 8, 2016 - 10:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I still believe you would get exactly what you are looking for (no vector table, no CRT but include the EEPROM stuff) if you simply use -nostartfiles and forget -nostdlib

joeymorin wrote:

In previous versions of the toolchain, __do_clear_bss and __do_copy_data would appear whether or not there were any static variables.

joeymorin wrote:

Optiboot predates the versions of the toolchain which handle __do_clear_bss and __do_copy_data properly, and -nostdlib was required to supress them.

westfw wrote:

Exactly - I want the makefiles to work with everything from WINAVR (gcc 4.3.x) through the current Atmel tools (4.9.x)  :-(

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Oh right. I never understand folks that try to live with old, out-dated rubbish tools but I suppose there must be some reason?

 

(the curious thing though is that my (not particularly up to date blush) installation of Arduino is 1.6.3 and it already has a 4.8.1 compiler so why cater for anything before that? Anyone who gets the newest Optiboot source with an installation of Arduino is surely going to get a relatively up to date compiler too aren't they?)

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

@westfw:

how did you finally manage that issue for your optiboot code ?

 

I ran into the same issue with a (sub-)fork* of optiboot when using avr-gcc 4.9.2
*(-> https://github.com/MCUdude/MegaCore/tree/master/avr/bootloaders/optiboot_flash)

 

If you found a solution, one should modify this fork the same way

 

Beginner with ATTiny / ATMega
trying to learn coding in in C (AVR GNU Toolchain)
...

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

Use -nodevicelib.  And no, it's not an undocumented option; see the avr-gcc options documentation.
 

avrfreaks does not support Opera. Profile inactive.

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

In the latest Atmel toolchain release (avr8-3.5, which has avr-gcc 4.9.2), I get link errors because the eeprom functions are no longer IN lib/avr/lib/avrN/libc.a, but rather (apparently) in lib/avr/lib/avrN/lib<chipname>.a

 

in the meantime I used
-l$(MCU_TARGET) in the Makefile (instead of -lc) --> here

in this case the device-specific lib is used, I think

and the errors are gone...

 

just for my understanding:
If I would use -nodevicelib which of the libraries *.a (containing eeprom-functions) is linked in this case ?

(so there are still non-device specific libs ? even in 4.9.2 and greater)

 

 

Beginner with ATTiny / ATMega
trying to learn coding in in C (AVR GNU Toolchain)
...

Last Edited: Mon. Aug 14, 2017 - 10:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The effect of -nodevicelib is documented here:

 

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

 

All it's going to do is prevent a link against libatmega328p.a or whatever the file involved is. What that file would have been providing is:

C:\SysGCC\avr\avr\lib\avr5>avr-nm libatmega328p.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 presumably you'd need to provide another implementation of those functions. The "easy answer" is probably to go here:

http://svn.savannah.gnu.org/view...

 

Pick up the .S files for the EEPROM functions you want to use and build them into your project.

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

> lib<chipname>.a be considered part of -lc ?

 

In the old days, there was no lib<mcu>.a and libc.a contained bunch of MCU-specific functions.  This was a maintainance nightmare in avr-libc as the same multilib had to host a eeprom_xx variant for each -mmcu=<mcu>.  This was because not all devices belonging to the same multilib have the same eeprom SFR layout, so that mcu name had to be encoded in the function's name by means of hacks in eeprom.h.

 

At some point in time avr-libc chose to split these MCU-specific functions apart form libc.a resulting in hundreds of lib<mcu>.a located in avr/lib/<multidir>. (IIRC there was a transitional avr/lib/<mcu>/libdev.a which caused problems in avr-gcc driver with LTO + spaces in install path).

 

avr-libc configure tries to find out what avr-gcc supports and expects:

 

< v5: libc.a contains eeprom functions, no lib<mcu>.a

 

>= v5.2: separate lib<mcu>.a that is linked per default and can be skipped by -nodevicelib.  Both -nodefaultlibs and -nostdlib avoid libc.a, libm.a, libgcc.a and lib<mcu>.a, hence if you still want lib<mcu>.a just -l<mcu> after all objects.

 

v5.0 and v5.1: avr-gcc won't work together with avr-libc, see v5 release notes.

 

Moreover, naming of startup files changed from avr/lib/<multidir>/crtm8.o to avr/lib/<multidir>/crt<mcu>.o

 

Actually, due to the structure of avr-libc, the compiler cannot know anything about avr-libc.  avr-libc is designed in such a way that it is "external" to the compiler and cannot be configured togeter with the compiler. (and, even worse, due to its design, avr-libc cannot even query the multilib structure implemented by the compiler).  Hence anyone that cooks up a distribution must know whether the chosen version of avr-libc and avr-gcc will fit together.

 

avrfreaks does not support Opera. Profile inactive.