Ich arbeite mich gerade in den ATMEGA-Klon lgt8F328p ein. Dort werden die EE-Daten im Flash abgespeichert. Das funktioniert auch. Jetzt möchte ich EE-Prozeduren definieren, die genauso heißen wie in der avr-lib (/avr/eeprom.h), also z.B. eeprom_read_byte(). Das Übersetzen klappt, aber es gibt einen Fehler beim Linken, der besagt, daß es einen Konflikt mit libatmega328p gibt. Nun binde ich die AVR-Bibliothek (/avr/eeprom.h) gar nicht ein. Gibt es eine Möglichkeit festzulegen, daß nur meine eigene eeprom_read_byte() Prozedur verwendet wird? Übrigens verwende ich hier noch AVR-Studio 4, aber das dürfte wohl keine Rolle spielen. Harald Fehlermeldung: d:/prog/winavr/bin/../lib/gcc/avr/5.3.0/../../../../avr/lib/avr5\libatme ga328p.a(eewr_byte.o): In function `eeprom_write_byte': EEPROM_LGT.o:D:\Pes\AVR\Test_LGT\default/../EEPROM_LGT.c:22: first defined here
Harald P. schrieb: > Gibt es eine Möglichkeit festzulegen, daß nur meine eigene > eeprom_read_byte() Prozedur verwendet wird? Ich schaetze mal du musst in den Arduino-Sourcen herumwuehlen und dort die Funktionen als "weak" definieren. Alternativ kannst du auch eine eigene HW anlegen. leo
leo schrieb: > Alternativ kannst du auch eine eigene HW anlegen. Sorry, ist ja schon: https://github.com/RalphBacon/LGT8F328P-Arduino-Clone-Chip-ATMega328P Also dort die Anpassungen machen. leo
Harald P. schrieb: > Nun binde ich die AVR-Bibliothek (/avr/eeprom.h) gar nicht ein. Das ist keine "Bibliothek", das ist ein Header. leo schrieb: > Ich schaetze mal du musst in den Arduino-Sourcen herumwuehlen und dort > die Funktionen als "weak" definieren. Was hat das mit Arduino-Sourcen zu tun? Der TO spricht von "AVR-Studio 4", das hat nun mal gar nichts mit Arduino zu tun. Es geht hier um die AVR-Libc. Erst lesen, dann schreiben.
:
Bearbeitet durch Moderator
Harald P. schrieb: > Gibt es eine Möglichkeit festzulegen, daß nur meine eigene > eeprom_read_byte() Prozedur verwendet wird? Irgendwer scheint irgendwas aufzurufen, was den Linker veranlasst, überhaupt erst die entsprechenden Module der avr-libc einzubinden. Das solltest du verhindern, aber vorher musst du rausfinden, was das verursacht. (Der Linker bindet nur solche Objektmodule aus Bibliotheken ein, die eine bis zu diesem Zeitpunkt ungelöste externe Referenz auflösen helfen.) > Übrigens verwende ich hier > noch AVR-Studio 4, aber das dürfte wohl keine Rolle spielen. In gewisser Weise schon, denn es ist ja offensichtlich deine IDE, die den Aufruf des Linkers zusammenbastelt, der genau zu diesem Problem führt.
Frank M. schrieb: >> Ich schaetze mal du musst in den Arduino-Sourcen herumwuehlen und dort >> die Funktionen als "weak" definieren. > > Was hat das mit Arduino-Sourcen zu tun? Sorry, verlesen. An "weak" aendert das aber nichts. leo
leo schrieb: > An "weak" aendert das aber nichts. Doch. weak wird überschätzt. Ist hier absolut nicht nötig, da die avr-libc modular genug ist, als dass deren Module eigentlich vom Linker gar nicht erst in Betracht gezogen werden sollten. Warum sie es trotzdem werden, muss der TE allerdings schon selbst rausfinden. Sich hinter einer IDE zu verstecken, die einem die entsprechenden Compileraufrufe generiert, ist da eher suboptimal, wenn man derartiges debuggen will.
So (mein) Fehler gefunden: Ich hatte an anderer Stelle noch einige EE-Funktionen wie eeprom_read_block etc. verwendet - ohne den Header einzubinden. Der Linker scheint dann so schlau zu sein, daß er dann die Standard-EE-Routinen in Gänze einbindet. Er meckert also nicht, daß die Funktionen nicht definiert sind. Auf diese Weise gibt es dann den Konflikt. Vielen Dank für eure Hilfe! Harald
Harald P. schrieb: > Jetzt möchte ich EE-Prozeduren definieren, die genauso heißen wie > in der avr-lib (/avr/eeprom.h), also z.B. eeprom_read_byte(). > Das Übersetzen klappt, aber es gibt einen Fehler beim Linken, der besagt, > daß es einen Konflikt mit libatmega328p gibt. Linken mit -nodevicelib, wird unterstützt ab v5: http://gcc.gnu.org/gcc-5/changes.html#avr http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-nodevicelib In der lib<device>.a sind EEPROM-Routinen, ich weiß aber grad nicht ob da noch anderes Zeug drinne ist. Also in die avr-libc Quellen gucken oder Jörg fragen. Und in avr/eeprom.h sind nicht nur Prototypen, sondern auch Makros wie eeprom_busy_wait() oder eeprom_is_ready().
Johann L. schrieb: > Linken mit -nodevicelib, wird unterstützt ab v5: > > http://gcc.gnu.org/gcc-5/changes.html#avr > > http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-nodevicelib Soweit ich weiß werden Device-Libs ebenfalls erst ab v5 unterstützt, vorher waren die entsprechenden Funktionen Teil der libc.a (avr-libc configure testet die Compilerversion ab). Verfügbarkeit der Option ist also gegeben.
:
Bearbeitet durch User
Johann L. schrieb: > vorher waren die entsprechenden Funktionen Teil der libc.a Ist aber auch nicht wirklich tragisch. Wenn die Module aus der libc.a nicht referenziert werden (also nicht am Ende als "global undefined" auftauchen), weil sie halt zuvor bereits durch eigene eingebundene Routinen aufgelöst werden konnten, dann werden diese Module nicht aus der Standardbibliothek gelinkt – egal, ob libc.a oder separate device lib.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.