Hallo ich bin in Sachen AVR-GCC ein Greenhorn, also bitte nicht schimpfen. Ich habe auch mit der Suche die Hinweise auf diese Fehler verfolgt. Ich habe nun die Frage, wo kommt dieser Fehler her. Ausserhalb scheint Alles zu gehen. Das Übersetzen ist fehlerfrei. Ich kämpfe nur noch mit ein paar Warnungen, die ich dank dieses Forums schon stark reduziert habe. Gewohnheitsmässig möchte ich ALLE Warnungen, wie bei der PC-Softwareerstellung beseitigen. Nun zur Frage: Kann ich diese Fehlermeldung beseitigen (die Ursache natürlich). Das Ganze ist fehlerfrei compiliert. gcc plug-in: Error: Object file not found on expected location D:\www\atmel\webserver\Wil\avr-webserver101\avr-webserver\default\avr-we bserver.elf Ich habe AVR-Studio 4 Version 4.13 Build 571 in Verbindung mit avr-gcc 20070525 Vielen Dank für jegliche Unterstützung Achim
Guck dir mal das Fenster mit den Compilermeldungen an.
Hallo @Jörg vielen Dank für die Antwort. Diese Antwort habe ich im Forum schon gefunden und auch einige Fehler beseitigt. Mein Problem ist ja, dass "Build succeeded with 9 Warnings..." nur 9 Warnings vorhanden sind. Liegt es daran? Keine Frage, dass ich diese auch noch beseitigen möchte. Könntest Du bitte mal über die Compilermeldungen "fliegen" und mir vorgehens Tipps geben.Ich erwarte keinesfalls, dass DU mir Fehler suchst! Da das ja im ComandZeilenMode geht, möchte ich eben ergründen warum das im AVR Studio nicht geht (rote Markierung). Ich habe zunächst mal ALLE ROTEN beseitigt und habe derzeit nur noch Grüne und 9 GELBE. Selbst Warnungen machen mich krank und möchte diese beseitigen. Aber FEHLER (Rote) müssen ja raus. Vielen Dank Achim
Du hast das gleiche Problem wie das Plugin selbst: die Fehler (nicht die Warnungen!), die nicht als solche erkannt worden sind, sind aber trotzdem tödlich:
1 | (.text.fplib+0x34): relocation truncated to fit: R_AVR_13_PCREL against symbol `__floatsisf' defined in .text section in c:/winavr-20070525/bin/../lib/gcc/avr/4.1.2/avr5\libgcc.a(_si_to_sf.o) |
2 | c:/winavr-20070525/bin/../lib/gcc/avr/4.1.2/../../../../avr/lib/avr5\libc.a(modf.o): In function `modf': |
3 | (.text.fplib+0x2c): relocation truncated to fit: R_AVR_13_PCREL against symbol `__floatsisf' defined in .text section in c:/winavr-20070525/bin/../lib/gcc/avr/4.1.2/avr5\libgcc.a(_si_to_sf.o) |
Du musst die libm.a mit in die Bibliotheken aufnehmen. (Das sollte man immer machen.)
Hallo @Jörg Deine Antwort(n) hat mir viel gebracht. Jetzt geht es. Aber bitte erlaube mir noch ne Frage: Wie kommt man ausser Deiner Erfahrung darauf, dass man die libm.a in den Pfad aufnehmen muss? Es werden da ja "viel mehr" Libs angeboten. Wie kann man aus den Fehlermeldungen die "richte" Lib finden. Alle angeben ist sicherlich nicht der richtige Weg. Ich kann ja nicht immer den Meister fragen, schließlich muß man ja mal selbständig werden. Nochmals herzlichen Dank Achim
Sucher wrote: > Wie kommt man ausser Deiner Erfahrung darauf, dass man die libm.a in > den Pfad aufnehmen muss? Man muss einfach wissen, dass das ein uralter Bug ist, im Prinzip identisch zu diesem hier: https://savannah.nongnu.org/bugs/?3485 Allerdings ist die Auflösung des Bugs nicht so trivial, da hier Dateien zwischen den Projekten in für das jeweilige Projekt (hier GCC) akzeptabler Form (Lizenzen, Testcases) weitergereicht werden müssen. Das macht einfach (viel) Arbeit. :( Was den Machern von AVR Studio jedoch anzulasten ist ist, dass sie eigentlich über diesen Bug wissen sollten und -lm immer und ständig mit aufnehmen (bzw. wenigstens voreingestellt aktiviert haben). Das kostet rein gar nichts und hilft ihren Kunden, derartige Probleme zu vermeiden. Wäre interessant zu wissen, ob das in der nächsten AVR-Studio-Version mal der Fall wäre... Zumindest kann ich dir aber sagen, dass mein vor geraumer Zeit eingetüteter Bugreport dafür, dass AVR Studio den Rückkehrstatus von make nicht sauber auswertet und es dadurch zu diesem "Object file not found"-Fehler kommt statt gleich das Fenster mit den Meldungen aufzuklappen, mittlerweile als erledigt abgemeldet worden ist, d. h. in der nächsten Version von AVR Studio sollte dir (und all den vielen anderen, denen es genauso ging) zumindest das nicht mehr passieren.
Hallo @Jörg noch ne Frage die mit dem jetzigen Ploblem nichts zu tun hat. Bei den delay.... Routinen ist da der Interrupt offen? Vermutlich werden doch da die Zeiten um die Interruptdauer verlängert, oder liege ich da falsch? Danke Achim
Sucher wrote: > Bei > den delay.... Routinen ist da der Interrupt offen? Ja, um sowas kümmern die sich nicht. Wer Interrupten kann, kann ja auch gleich einen Timer nehmen. ;-)
Hallo bei kleinen, genauen Delays (festes Timing) Ds18S20 leider nicht (Timer) MfG Achim
Sucher wrote: > bei kleinen, genauen Delays (festes Timing) Ds18S20 leider nicht > (Timer) Könnte auch gehen, muss man nur pollen. Aber dort ist es wahr, da sollte man wohl eher eine Bibliothek machen, die während aller zeitkritischer Teile die Interrupts abklemmt. Aber das sollte dann wirklich besser ein separater Thread werden.
Hallo @Jörg abschließend ...Danke... bis zu den nächsten avr-GCC Fragen... Achim
p.s.: Ich habe gerade erfahren, dass auf http://www.atmel.no/beta_ware/ ein "public preview" der nächsten AVR-Studio-Version liegt, und dass dort -lm nun standardmäßig dabei sein soll. Vielleicht mag ja jemand von den Windows-Benutzern hier einen Blick drauf werfen. Noch wäre es vermutlich nicht zu spät, Kleinigkeiten an Bugfixes für ein endgültiges Release einzukippen (Mailadresse dafür steht mit auf der Webseite).
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.