Hallo,
Ich möchte in einem Projekt Daten im internen EEPROM eines Atmega32
ablegen.
Dazu gibt es ja die Funktionen der avr/eeprom.h.
Zu testzwecken habe ich einfach dies einfache Programm erstellt:
1
#include<avr/io.h>
2
#include<avr/eeprom.h>
3
4
intmain(void)
5
{
6
7
8
eeprom_write_byte((uint8_t*)22,46);
9
uint8_tData;
10
Data=eeprom_read_byte((uint8_t*)22);
11
12
while(1)
13
;
14
15
return0;
16
}
Macht zwar nicht viel aber sollte ja Funktionieren.
Allerdings bekomme ich von Codeblocks immer diese Fehlermeldung zu den
Funktionen:
undefined reference to `__eewr_byte_m32'
undefined reference to `__eerd_byte_m32'
Hab mir schon die Finger blutig gegoogelt aber nichts zu diesen Fehlern
gefunden, vielleicht hat ja hier jemand eine Idee.
Vielen Dank schon mal
Ja Codeblocks weiß was für ein Controller es ist und auch den Takt, ob
ein Makefile erstellt wird kann ich nicht genau sagen da bin ich noch
nie so ganz durchgeblickt was es damit auf sich hat.
Hallo,
ich kenne das Problem eigentlich nur bei einem Wechsel zwischen altem
und neuem Compiler/avr-libc.
Ich vermute, dass du eine neuere libc-Version verwendest, die keinen
inline-Assembler mehr nutzt, sondern Funktionen deklariert, die vom
Linker hinzugefügt werden müssen.
Deshalb meine Gegenfrage: hast du mal versucht, das gesamt Projekt
(mindestens jedes Source-File, das EEPROM-Funktionen nutzt) neu zu
kompilieren?
Wenn das alles passt, dann poste bitte mal deinen Compiler-Aufruf und
die Versionen von GCC/avr-libc.
Mit freundlichen Grüßen,
N.G.
Timo T. schrieb:> Dazu gibt es ja die Funktionen der avr/eeprom.h.
Das ist eine Headerdatei. Darin sind die Deklarationen der Funktionen,
die Du verwenden willst.
Der zugehörige Code (die Definition) der Funktionen aber ist entweder in
einem Sourcefile, das Du eigens zu Deinem Projekt hinzufügen musst, oder
in einer Library, deren Verwendung Du Deinem Linker mitteilen musst.
Nein, anders als in der "Arduino"-Welt ist eine Library kein Quelltext,
sondern compilierter Code, üblicherweise in der Form einer Datei namens
lib*.a (oder *.lib, je nach Toolchain).
Timo T. schrieb:> undefined reference to `__eewr_byte_m32'> undefined reference to `__eerd_byte_m32'
Dann wird nichtz gegen die richtigen Libraries gelinkt.
Häufiger Fehler ist, avr-ld zum Linken zu verwenden anstatt avr-gcc,
dito für andere Targets.
Wie sehen die Tool-Aufrufe aus, d.h. was ist die Ausgabe, wenn -v zu den
jeweiligen Kommandozeilen-Argumenten hinzugefügt wird?
Den hat Codeblocks so ausgegeben. Wenn ich ihn manuell ausführe kommt
die selbe fehlermeldung, Logischerweise.
Führe ich ihn mit der Option -v aus kommt diese Ausgabe:
Ohne das Ist der Fehler weg, ob es läuft kann ich gerade leider nicht
testen. Der Befehl kommt so wie er ist von Codeblocks warum er diese
Option mit rein nimmt kann ich nicht sagen.
Timo T. schrieb:> Der Befehl kommt so wie er ist von Codeblocks
Falsch ist die Option trotzdem. Beim Link-Aurfuf, den der
Compiler-Treiber "avr-g++" zusammenbastelt, kommt dieses -L vor denen,
die der Treiber korrekt an den Linker übergibt. Dies führt dazu, dass
die falsche Library libc.a (und auch libm.a, sofern benötigt) verwendet
wird.
Bei deinem Beispiel führt das zu einem Linkerfehler, weil die
EEPROM-Unterstützung für's jeweilige Device nur in der entsprechenden
Multilib-Variante der libc vorhanden ist.
Ohne eeprom-Routinen gäbe es zwar kein Linkerfehler, aber du würdest
z.B. auch Code linken, der anstatt MUL die arschlahmen Routinen für
Devices ohne MUL verwendet, sowie Code, der anstatt einem MOVW zwei
MOV verwendet, solchen, der zu kurze Sprünge nutzt, was zu einem
"relocation truncated to fit" Fehler führen könnte, etc.
> warum er diese Option mit rein nimmt kann ich nicht sagen.
Evtl. von einem Projekt übernommen oder eine Voreinstelling in C::B. In
letzerem Fall wäre ein Bug-Report gegen C::B fällig.
So hatte jetzt endlich zeit zum Testen und es funktioniert!
Vilen dank euch schonmal.
Ich habe mir jetzt auch nochmal die Einstellungen zum Compiler in
Codeblocks angeschaut und da das eingestellte Verzeichnis für den Linker
geändert jetzt funktioniert auch wieder das compilieren aus Coderblocks.
Kuran schrieb:> in C::B Settings > Search directories > Linker settings:> C:\Program Files (x86)\WinAVR-20100110\avr32\lib>> statt> C:\Program Files (x86)\WinAVR-20100110\avr\lib> je nachdem - wo Deine libs sind...> ---> gelöst! :-)
Das ist komisch, den der ATmega32 (lass dich nicht vom Namen täuschen)
ist ein 8-Biter, demnach wäre WinAVR-20100110\avr\lib richtig
das WinAVR-20100110\avr32\lib ist für die 32-Biter AVRs. Die Heißen
aber auch AVR32 und nicht ATmega/ATtiny/ATxmega
Eine eigene Frage?
Dieser Thread ist über 8 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
