#include <avr/io.h>
#include <avr/eeprom.h>
void init(void);
void write_com(unsigned char com);
void write_data(unsigned char data);
int main(void)
{
unsigned char i;
eeprom_busy_wait();
eeprom_write_byte(0x00,0x01);
eeprom_busy_wait();
i = eeprom_read_byte(0x00);
while(1);
}
I really don't how to do.Link against the libraries that provide these references in the right order. Consult the AVR SDK documentation which libs these are.
U have to add the library '(WinAVR path)\avr\lib\avr5\libc.a' to the 'link libraries' under 'project->build options->linker settings' for ur code to compile. It's quite strange though that the include file doesn't link to the corresponding library.
I mean how can the programmer know which compiled library to add after including an include file. I think I'm missing something here.Harhar... sorry to say that, but it's exactly the other way round. You as developer need to know the SDK you are responsible of using it right. The documentation will tell what file to include and what lib to link against.
int my_calc(int i1, int i2)
{
int i = i1-i2;
return i;
}
int my_calc(int i1, int i2)
{
int i = i1+i2;
return i;
}
I have no oppositions to that but that's not quite the case here.I mean how can the programmer know which compiled library to add after including an include file. I think I'm missing something here.Harhar... sorry to say that, but it's exactly the other way round. You as developer need to know the SDK you are responsible of using it right. The documentation will tell what file to include and what lib to link against.
Why? Simple: Assume the following two libraries:
[LIB1:]Code[LIB2:]int my_calc(int i1, int i2)
{
int i = i1-i2;
return i;
}CodeBoth libs would provide the same function with the same interface. How on earth shall the compiler or linker know, which to link against? It's up to you and will always be up to you to setup your project right. Get used to it or you will sooner or later make serious mistakes.int my_calc(int i1, int i2)
{
int i = i1+i2;
return i;
}
U have to add the library '(WinAVR path)\avr\lib\avr5\libc.a' to the 'link libraries' under 'project->build options->linker settings' for ur code to compile. It's quite strange though that the include file doesn't link to the corresponding library.
BTW avr-gcc automatically links to libc.a if it's in the link path.Can u explain this in detail pls, how do u manage that exactly?
Running project pre-build stepsNote no "-lc" in linking. There are two!! "-lm" but it's completely different story.
avr-gcc.exe -mmcu=atmega32 -O3 -Wall -std=gnu99 -fno-strict-aliasing -DF_CPU=14745600UL -gdwarf-2 -W -Wall -std=gnu99 -I"C:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain\avr\include" -S main.c -o bin\Debug\main.s
-------------- Build: Debug in KIv05 pH ---------------
avr-gcc.exe -mmcu=atmega32 -O3 -Wall -std=gnu99 -fno-strict-aliasing -DF_CPU=14745600UL -gdwarf-2 -W -Wall -std=gnu99 -I"C:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain\avr\include" -c main.c -o obj\Debug\main.o
avr-g++.exe -o bin\Debug\KIv05_pH.elf obj\Debug\main.o -mmcu=atmega32 -Wl,-Map=bin\Debug\KIv05_pH.elf.map,--cref -lm -lm
Output size is 55,61 KB
Running project post-build steps
avr-objcopy -O ihex -R .eeprom -R .eesafe bin\Debug\KIv05_pH.elf bin\Debug\KIv05_pH.elf.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin\Debug\KIv05_pH.elf bin\Debug\KIv05_pH.elf.eep.hex
avr-size --mcu=atmega32 --format=avr bin\Debug\KIv05_pH.elf
AVR Memory Usage
----------------
Device: atmega32
Program: 9448 bytes (28.8% Full)
(.text + .data + .bootloader)
Data: 148 bytes (7.2% Full)
(.data + .bss + .noinit)
cmd /R "avr-objdump bin\Debug\KIv05_pH.elf -h -S > bin\Debug\KIv05_pH.elf.lss"
Process terminated with status 0 (0 minutes, 5 seconds)
0 errors, 0 warnings
-------------- Build: Debug in Test ---------------
avr-gcc.exe -Wall -mmcu=atmega16 -DF_CPU=16000000UL -g -W -Wall -std=gnu99 -I"C:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain\avr\include" -c main.c -o obj\Debug\main.o
avr-g++.exe -o bin\Debug\Test.elf obj\Debug\main.o -mmcu=atmega16 -Wl,-Map=bin\Debug\Test.elf.map,--cref
Output size is 5,73 KB
Running project post-build steps
avr-size --mcu=atmega16 --format=avr bin\Debug\Test.elf
AVR Memory Usage
----------------
Device: atmega16
Program: 226 bytes (1.4% Full)
(.text + .data + .bootloader)
Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)
avr-objcopy -O ihex -R .eeprom -R .eesafe bin\Debug\Test.elf bin\Debug\Test.elf.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin\Debug\Test.elf bin\Debug\Test.elf.eep.hex
cmd /c "avr-objdump -h -S bin\Debug\Test.elf > bin\Debug\Test.elf.lss"
Process terminated with status 0 (0 minutes, 3 seconds)
0 errors, 0 warnings
scarphin - Glad you found your problem's solution.
Zage2009 - No. I use WinXP SP3, C::B rev6454 or Later. I keep my old C::B configurations after reinstalling C::B. And also after reinstalling winAvr I always do manual compiler configuration in C::B, cause C::B doesn't autodetect avr-gcc (IMHO), maybe at this step I remove '$winavr/avr/lib' - can't say, cause I don't remember. Guess scarphin is right and it's some C::B's AVR-GCC compiler configuration bug, and I was lucky not to hit it :D
I reinstall the win7 in vmware Workstation and install the WinAVR,CB10.05(rev6283) in Win7.The result is that the option 'winavr/avr/lib' is still in the Linker tab of the Search directions and perhaps there still is the same problem in different operation system.scarphin - Glad you found your problem's solution.
Zage2009 - No. I use WinXP SP3, C::B rev6454 or Later. I keep my old C::B configurations after reinstalling C::B. And also after reinstalling winAvr I always do manual compiler configuration in C::B, cause C::B doesn't autodetect avr-gcc (IMHO), maybe at this step I remove '$winavr/avr/lib' - can't say, cause I don't remember. Guess scarphin is right and it's some C::B's AVR-GCC compiler configuration bug, and I was lucky not to hit it :D
Thes settings are made if you use autodetection, otherwise they stay empty.
It's sure CB adds 'avr/lib' folder automatically to the linker search path. The problem is if it should do this or not. Can someone test under linux and see if the problem also exits on linux or not pls? So the devs can remove it in the next nightly if adding 'avr/lib' to the search path generates this linker problem also under linux.