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.
Hier die Zeilen:
#include <nibo/niboconfig.h>
#include <nibo/display.h>
#include <nibo/gfx.h>
#include <nibo/delay.h>
#include <nibo/iodefs.h>
#include <nibo/bot.h>
#include <nibo/floor.h>
#include <stdio.h>
int main()
{
bot_init();
floor_init();
display_init();
gfx_init();
gfx_move(22, 0);
gfx_set_proportional(1);
gfx_print_text("Floor sensor test");
gfx_set_proportional(0);
gfx_move(5, 10);
gfx_print_char('R');
gfx_move(118, 10);
gfx_print_char('L');
while (1==1);
{
delay(10);
char text[20]="-- -- -- -- --";
//Bodensensoren
floor_update();
sprintf(text, "%02x %02x %02x %02x",
(uint16_t)(floor_absolute[FLOOR_RIGHT]/8),
(uint16_t)(floor_absolute[LINE_RIGHT]/8),
(uint16_t)(floor_absolute[LINE_LEFT]/8),
(uint16_t)(floor_absolute[FLOOR_LEFT]/8));
gfx_move(20, 30);
gfx_print_text(text);
sprintf(text, "%02x %02x %02x %02x",
(uint16_t)(floor_relative[FLOOR_RIGHT]/8),
(uint16_t)(floor_relative[LINE_RIGHT]/8),
(uint16_t)(floor_relative[LINE_LEFT]/8),
(uint16_t)(floor_relative[FLOOR_LEFT]/8));
gfx_move(22, 40);
gfx_print_text(text);
//Spannung
bot_update();
float volt = 0.0166 * bot_supply - 1.19;
sprintf(text, "%3.1fV", (double)volt);
gfx_move(30, 10);
gfx_set_proportional(1);
gfx_print_text("supply: ");
gfx_set_proportional(0);
gfx_print_text(text);
}
return 0;
}
Ende!
Henry schrieb: > Hier die Zeilen: Nein, das ist der Quellcode. Jörg Wunsch fragte nach den Aufrufen der Toolchain, also sowas wie
1 | gcc.exe --libm --prozessor-abc-123 --produce-bad-code |
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 oder noch: avr-gcc -I"C:\Users\Hoyer\Documents\..\..\..\NiboLib\include" -I"C:\Users\...\Documents\..\..\..\Winavr-20100110\avr\lib" -mmcu=atmega128 -Wall -gdwarf-2 -std=gnu99 -D_NIBO_2_ -Wl,-u,vfprintf -DF_CPU=16000000UL -Os -funsigned-char -funsig ned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Linienboden.o -MF dep/Linienboden.o.d -c ../Linienboden.c
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!
Johann L. schrieb: > äh... und wieso eigentlich -L"C:\Winavr-20100110\avr\lib" was soll das? Genau darin wird das Problem liegen.
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
Linking console executable: bin\Debug\CB_Avr.elf Using built-in specs. Target: avr Configured with: ../gcc-4.3.3/configure --enable-win32-registry=WinAVR-20100110 --with-gmp=/usr/local --with-mpfr=/usr/local --prefix=/c/WinAVR --target=avr --enable-languages=c,c++,objc --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-pkgversion='WinAVR 20100110' --with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse'; Thread model: single gcc version 4.3.3 (WinAVR 20100110) COMPILER_PATH= c:/winavr-20100110/bin/../libexec/gcc/avr/4.3.3/; c:/winavr-20100110/bin/../libexec/gcc/; c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ LIBRARY_PATH=c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/avr5/; c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/; c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/; c:/winavr-20100110/bin/../lib/gcc/; c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ COLLECT_GCC_OPTIONS='-LC:\WinAVR-20100110\avr' '-LC:\WinAVR-20100110\avr\lib' '-LC:\WinAVR-20100110\avr\lib' '-LC:\WinAVR-20100110\avr\include' '-o' 'bin\Debug\CB_Avr.elf' '-mmcu=atmega324p' '-v' '-mmcu=atmega324p' '-mmcu=atmega324p' c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe -m avr5 -Tdata 0x800100 -o bin\Debug\CB_Avr.elf c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/crt m324p.o -LC:\WinAVR-20100110\avr -LC:\WinAVR-20100110\avr\lib -LC:\WinAVR-20100110\avr\lib -LC:\WinAVR-20100110\avr\include -Lc:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/avr5 -Lc:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5 -Lc:/winavr-20100110/bin/../lib/gcc/avr/4.3.3 -Lc:/winavr-20100110/bin/../lib/gcc -Lc:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib obj\Debug\Action_Handler.o obj\Debug\Comm_Handler.o obj\Debug\Control.o obj\Debug\InitMP3.o obj\Debug\My_ISR_uart.o obj\Debug\Pulse_Generator.o obj\Debug\Timebase.o obj\Debug\Timer2_Speed_Control.o obj\Debug\Utilities.o obj\Debug\wd.o -Map=bin\Debug\CB_Avr.elf.map --cref C:\WinAVR-20100110\avr\lib\libm.a C:\WinAVR-20100110\avr\lib\libc.a C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\lib\gcc\avr\4.4.3\libgcc.a -lgcc -lm -lgcc -lc -lgcc Output size is 47.11 KB Running project post-build steps avr-objcopy -O ihex -R .eeprom -R .eesafe bin\Debug\CB_Avr.elf bin\Debug\CB_Avr.elf.hex avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin\Debug\CB_Avr.elf bin\Debug\CB_Avr.elf.eep.hex cmd /c "avr-objdump -h -S bin\Debug\CB_Avr.elf > bin\Debug\CB_Avr.elf.lss" Process terminated with status 0 (0 minutes, 1 seconds) 0 errors, 3 warnings
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.
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.