Der Neuling :)
Hier nochmal meine Fehlermeldung:(Nibo2)Tutorial 6-9
>floor.c:(.text.floor_writePersistent+0xc): undefined reference to
`__eewr_block_m128'
C:\Programme\Nibolib\lib\libnibo2.a(floor.o): In function
`floor_readPersistent':
>floor.c:(.text.floor_readPersistent+0xc): undefined reference to
`__eerd_block_m128'
>C:\Winavr-20100110\avr\lib\libc.a(vfprintf_std.o): In function `vfprintf':
(.text.avr-libc+0xd4): undefined reference to `__mulhi3'
>C:\Winavr-20100110\avr\lib\libc.a(vfprintf_std.o): In function `vfprintf':
(.text.avr-libc+0xe4): undefined reference to `__mulhi3'
make: *** [LinienBoden.elf] Error 1
Build failed with 4 errors and 0 warnings...
Einige hatten ja dazu schon geantwortet.Danke soweit!
Ich versuche es mal ganauer zu beschreiben:
An das geschriebene Programm kann das nicht liegen.Bei
Nibo2(Roboter)gibt es verschiedene Bibliotheken,aus dem sich das
Programm alle Header-Datein raussucht.Vorab muss ich dem Programm
sagen,woraus er die Header-Dateien beziehen soll und wohin er Sie
transferiert(ablegt).
Bibliotheken zu verlinken sind: > libnibo2.a ;> lib.m ;>libprintf_flt.a
Zudem kommt noch eine Compilation link :> "-Wl,-u,vfprintf "
Dies ganze soll von: Winavr-20100110\bin\avr-gcc.exe zu
Winavr-20100110\utils\bin\make.exe umgewandelt
werden(sozusagen).
Und da liegt die Lücke im Verständnis.In der Fehlermeldung steht was von
"lib.c" (kein Plan warum).
Der Herr Wunsch könnte damit schon Recht haben mit dem Zitat:
[Ja, da fällt mir nur ein: es ist ein known problem, dass das
WinAVR-Makefile-Template nicht 1:1 für C++ tauglich ist. Du musst da
wohl CFLAGS durch CXXFLAGS ersetzen etc. pp. Pass bitte auch auf mit
den substitutions, da werden irgendwie die .o-Dateien aus den Namen
der .c-Dateien abgeleitet, und ${OBJS} wird im `make clean' gelöscht.
Wenn Deine Eingabedateien aber nicht auf .c enden, erfolgt kein Ersatz
des .{irgendwas} durch .o, sodass Deine Eingabedateien gelöscht
werden...]
Mit den CFLAGS durch CXXFLAGS ersetzten kann ich noch verstehen(Editor),
den Rest nicht....Sorry! :)
Vielleicht noch zur Info: Die vorherigen Programm-tutorial 1-5 (ohne
lib.m ;libprintf_flt.a und ohne "-Wl,-u,vfprintf")liefen hervorragend.
Von Nibo gibt es ja eine Vorgangsbeschreibung.An die habe ich mich
gehalten + eigenen Gehirnschmalz :), dennoch klappt das nicht.
Danke erstmal!
Mit welchen Optionen wird denn Compilier bzw. Linker aufgerufen?
Wie geschrieben gibt es für ATmega128 keine __mulhi3. Wenn sie dennoch
verwendet wird, hast du was mit den Optionen durcheinander.
Wie meinst du das mit den "Option"?
Bei AVR studio 4 : Include File search Path: >...Nibolib\include\
Libary Search Path:>...Nibolib\lib\
>...Winavr-20100110\avr\lib\
Henry schrieb:> Wie meinst du das mit den "Option"?
Poste doch mal die kompletten Kommandozeilen für den Aufruf. In
irgendeinem Logbildschirm wirst du die doch hoffentlich finden.
Henry schrieb:> Hoffe das ist besser :)>> avr-gcc -mmcu=atmega128 -Wl,-Map=Linienboden.map Linienboden.o> -L"C:\Winavr-20100110\avr\lib" -L"C:\Nibolib\lib" -lnibo2 -lm> -lprintf_flt -o Linienboden.elf
Ja. Und jetzt schaust du in das Mapfile, welches Modul/Lib dafür
zustaändig ist, die __mulhi3 reinzuziehen und postest die Optionen wie
dieses Modul erzeugt wurde :-)
äh... und wieso eigentlich -L"C:\Winavr-20100110\avr\lib" was soll das?
Um die richtige Multilibauswahl kümmert sich der Compiler!
Lass das weg!
Danke!!!!!!!!!!!!
hat funktioniert!
Die Sache ist nur,um "lib.m und vfprinf_flt.a aufzurufen und als
Link-Bibiblothek einzufügen,musste man den Ordner aufrufen:
Winnavr-20100110\avr\lib\
Hab diesen entfernt und funktioniert jetzt.
Danke Jungs!!!!!!!!!!!!! :)
Henry schrieb:> Die Sache ist nur, um "lib.m und vfprinf_flt.a aufzurufen und als> Link-Bibiblothek einzufügen, musste man den Ordner aufrufen:> Winnavr-20100110\avr\lib\
Nö. Dazu genügt es, beim Linken -lprintf_flt -lm mitzugeben.
Wenn die Libs nicht gefunden werden stimmt was mit der Installation
nicht.
Hm,
habe soeben diesen Thread entdeckt da ich mich seit 3 Tagen mit dem
gleichen Problem rumschlage (als ich zum ersten Mal gegooglt habe
existierte der noch gar nicht)und langsam die Faxen dicke habe ...
Eigentlich habe ich alles versucht was hier in den Beiträgen beschrieben
wird:
-Das ominöse "-lprintf_flt -lm" in die Linker Options,
-Explizites Einbinden von "libprintf_flt.a", "libc.a", "libm.a" in die
Linker settings (Diese Dateien existieren - überprüft !),
und "C:\WinAVR-20100110\avr\lib" in die Search directories .
In der Toolchain:
-Directory: C:\WinAVR-20100110
-Compiler: GNU AVR GCC Compiler (avr-gcc.exe)
- Das Ganze ist unter Code::Blocks und Windows 7 (Französisch)
"Post Build Steps":
avr-size --mcu=atmega324p --format=avr $(TARGET_OUTPUT_FILE)
avr-objcopy -O ihex -R .eeprom -R .eesafe $(TARGET_OUTPUT_FILE)
$(TARGET_OUTPUT_FILE).hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma
.eeprom=0 -O ihex $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).eep.hex
cmd /c "avr-objdump -h -S $(TARGET_OUTPUT_FILE) >
$(TARGET_OUTPUT_FILE).lss"
Scheitern tut's wenn ich ein schäbiges: "snprintf" verwende (kein
Problem unter AVR Studio), ohne geht die Kompilierung
Nun bin ich was makefiles angeht eine glatte Null, tu' mich also schwer
die Sache sauber zu analysieren. Allerdings weiss ich dass die
notwendigen Libraries funktionieren müssen. Unter AVR-Studio 4 (selber
Compiler) funzt's beim gleichen Programm wie's soll.
Wäre prima wenn jemand noch 'ne zündende Idee hätte da ich kurz vor dem
Aufgeben (mit Code blocks) stehe!
Danke: Hermann
Hermann E. schrieb:> Hm,> habe soeben diesen Thread entdeckt da ich mich seit 3 Tagen mit dem> gleichen Problem rumschlage (als ich zum ersten Mal gegooglt habe> existierte der noch gar nicht)und langsam die Faxen dicke habe ...>> Eigentlich habe ich alles versucht was hier in den Beiträgen beschrieben> wird:>> -Das ominöse "-lprintf_flt -lm" in die Linker Options,>> -Explizites Einbinden von "libprintf_flt.a", "libc.a", "libm.a" in die> Linker settings (Diese Dateien existieren - überprüft !)
Wozu denn??? Der Compiler wird die richtige .a einbinden von den zig *.a
Versionen, die die Toolchain bitbringt!
Ohne eine Idee, welches die richtige Version der jeweiligen .a ist,
wirst du zielich sicher daneben greifen.
> und "C:\WinAVR-20100110\avr\lib" in die Search directories .
Ditto. Lass da die Finger weg!
Schreib ieber wie Compiler- und Linkeraufruf aussehen.
Und bitte wirklich den Aufruf der Tools (Compiler, Linker), nicht
irgendwelche Makefile-Hieroglyphen...
Haben alle Aufrufe das gleiche -mmcu= ?
> "Post Build Steps":
Uninteressant. Das Problem entsteht durch falschen Linkeraufruf.
Soweit mal Danke Johann !
Hat etwas gebraucht da ich meine Files schon in den Müll geworfen hatte
um
reuemütig zum AVR Studio zurückzukehren.
Gut, die Info mit dem falschen Linkeraufruf ist ja schon mal ein
Einstiegspunkt.
Wie gesagt: von Makefile hab' ich praktisch keine Ahnung. Wenn ich
ehrlich bin muss ich zugeben deine Frage nicht richtig zu verstehen
(wenn du meinst: "Schreib lieber wie Compiler- und Linkeraufruf
aussehen"). Meinst du damit die Befehlsabfolge wie sie eben im Makefile
gemacht wird ?
Das Problem ist dass ich nicht weis wie ich diese Info aus Code::Blocks
rausquetschen kann. Ich habe gestern schon dannach gesucht und angeblich
gibt es ein Plug-in dass es erlaubt einen Makefile zu exportieren.
Dieser Website wird aber nicht mehr gewartet so dass ich das Schlimmste
fürchte.
Oder habe ich deine Frage schlicht falsch verstanden ?
Sorry für meine Unwissenheit, aber ich kann nicht auf allen Fronten
gleichzeitig kämpfen: Hermann
Ach ja,
hab' ich ganz vergessen: Die "-mmcu" müsste stimmen (überprüft).
Bei der Installation von C::B habe ich es (U.A. auch) wie hier
versucht:
"http://www.mikrocontroller.net/articles/Code::Blocks";
I.B. wie angegeben mit:
"C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain"
für den Toolchain Pfad: ohne Erfolg.
Vieleicht liegts aber auch in diesem Fall daran das C::B keine
Leerzeichen im Pfad verträgt.
Mit C::B arbeite ich schon ein paar Jahre für Windows Programme (mit
WxWidgets) und da läufts eigentlich super ..
Gruss: Hermann
It works now !
Code Blocks: "__mulqi3" and "__mulhi3" error:
for it to compile add:
"Project->Build Options->Linker Settings" for "Debug" and "Release"
(left top):
"C:\Program Files (x86)\Atmel\AVR Tools\AVR
Toolchain\lib\gcc\avr\4.4.3\libgcc.a"
("C:\Program Files (x86)" stands for your program directory, need AVR
studio to be installed))
Than: neither "Build" nor "Release" but click your "project name" above
the two tabs.
Add the following to your "Linker Settings" again:
C:\WinAVR-20100110\avr\lib\libc.a
C:\WinAVR-20100110\avr\lib\libm.a
(C:\WinAVR-20100110 or wherever your WinAVR resides)
Toolchain in "Global compiler Settings": under
"Setting" -> "Compiler and Debugger"
Selected compiler: "GNU AVR GCC Compiler"
Compiler Installation Directory: "C:\WinAVR-20100110"
C Compiler: avr-gcc.exe
off you go...
Hermann E. schrieb:> It works now !>> Code Blocks: "__mulqi3" and "__mulhi3" error:>> for it to compile add:>> "Project->Build Options->Linker Settings" for "Debug" and "Release"> (left top):>> "C:\Program Files (x86)\Atmel\AVR Tools\AVR> Toolchain\lib\gcc\avr\4.4.3\libgcc.a"
NO KRUZIFIX! THAT'S WRONG WRONG WRONG!!!
> Add the following to your "Linker Settings" again:>> C:\WinAVR-20100110\avr\lib\libc.a> C:\WinAVR-20100110\avr\lib\libm.a
SAME HERE
Und wozu soll es gut sein, eine Bibliotheksversion für einen ATmega324
zu verwenden, die
- kein MOVW enthält (stattdessen immer 2 MOV))
- keine MUL, MULS, MULSU enthält (stattdessen Software-Multiplikation)?
- kein LPM R,Z enthält (sondern stattdessen LPM und MOV)?
- kein LPM R,Z+ enthält (sondern stattdessen LPM und ADIW und MOV)?
- ...
Dadurch, daß ein Code übersetzt, wird das -L... nicht besser.
Und mit der Gießkanne -L auf alle Verzeichnisse wie avr/include zu
setzen... kein Kommentar.
Zudem geistert ne Atmel Toolchain neben dem WinAVR rum.
