Moin, ich versuche gerade das USB-Beispiel für den AT91SAM7S64 von Atmel zu kompilieren. Da ich vorher nur mit AVRs gearbeitet habe und diese sich noch problemlos in Assembler programmieren ließen, bin ich mit GCC noch nicht besonders vertraut. Zum Kompilieren des Beispiels habe ich das Makefile des AT91SAM7S64-Beispiels, dass bei den Win-ARM-Examples dabei war, mehr auf gut Glück angepasst. Nun kommt eine Fehlermeldung beim Linken, deren Ursache ich nicht habe herausfinden können. Wäre nett, wenn mal jemand, der ein bißchen fitter mit GCC ist, einen Blick drauf werfen könnte. (Fehlermeldung und Makefile sind im Anhang) Danke schon mal, jörn
"und diese sich noch problemlos in Assembler programmieren ließen" Geht doch auch mit den ARMs. Oder wo liegt Dein Problem?
Assembler geht zwar sicherlich auch für den ARM, bei aufwendigeren Anwendungen scheint es mir aber ein wenig unhandlich. Die gesteigerte Leistungsfähigkeit des Controllers wollte ich aber gerade mit umfangreicheren Programmen ausnutzen. C ist mir auch weder fremd noch zuwider, mein Problem liegt vielmehr in der Anwendung des GNU-Compilers, weil ich da noch recht neu bin. Da ich den Quelltext unverändert übernommen habe und der Linker auch irgendwelche Fehler in Standard-Bibliotheken anzeigt, glaube ich, dass das Problem eher im Makefile oder irgendeiner Konfiguration liegt, weiß dann aber nicht weiter. Für Hilfe wäre ich also dankbar. Gruß, jörn
Problem mit benötigter Library, und zwar der libc. Ob es gut ist, dass -lc gleich zweimal in der im Makefile und der Kommandozeile aufkreuzt?
Viele Informationen aus den WinARM Makefile Vorlagen sind aus Mailinglisten und diversen Beispeilen fuer verschiedene ARM-Controller zusammengetragen worden. Einiges ist auch durch ausprobieren herausgefunden worden. Die "Doppelnennung" der libc sollte so o.k. sein, bei Tests vor vielen Monaten hat es ohne nicht richtig funktioniert. Habe das seit dieser Zeit fuer alle LPC2000-Projekte so ohne Probleme genutzt und daher ist es auch in meinen Beispielen immer so eingestellt. Sollte beim SAM7 nicht anderes sein, hat wenig mit der Zielplattform sondern mit Compiler/Linker/Library zu tun. Die Ausgabe von make zeigt, dass die sogennanten "syscalls" (sbrk, readr etc.) fehlen. Diese muessen durch den Entwickler bereitgestellt werden und sind prozessorspezifisch. Die newlib, die WinARM als "libc" beiliegt, benoetigt diese Funktionen (malloc z.B. sbrk). Als Beispiel vgl. stdio- und c++-Beispiele fuer LPC auf meiner Seite (google, winarm, erster treffer), sollte relativ einfach auf den SAM7 uebertagbar sein. Details finden sich in der newlib-Dokumentation (pdf-Datei habe ich bei WinARM ins /doc-Verzeichnis aufgenommen). Hoffe, die Information hilft etwas weiter Martin Thomas
Danke für die ausführliche Antwort! Ganz verstanden habe ich es aber leider noch nicht. Habe ich es richtig verstanden, dass alle Controller-Typen die gleichen Standardbibliotheken verwenden, so dass für jeden eine verschiedene newlib hinzugelinkt werden muß, die prozessorspezifische Funktionen implementiert, die von den Standardbibliotheken verwendet werden. Für die LPC-Familie habe ich diese Funktionen auch in meiner GCC-Distribution gefunden. Wo finde ich aber diese newlib für die AT91-Serie und wie muß sie beim linken einbezogen werden? Gruß, jörn
Die "prozessorspezifischen Funktionen" sind nicht in der newlib. Die newlib ist die "Standardbibliothek" und benoetigt einige Funktionen zuzusagen als Verbindung zur Hardware (system calls). Das Gesuchte ist nicht die newlib fuer AT91 sondern die system calls fuer AT91. Ist anhand der lpc-Vorlage wenig Arbeit. Was Fertiges aber auch noch nicht gesehen.
Beim Durchforsten der WinARM-Verzeichnisse bin ich auf ein syscalls.c für die LPC-Familie gestoßen. Da es die benötigten Funktionen zur Verfügung stellt, ließ es sich auch super verlinken und nun läßt sich mein Programm auch kopilieren. Aber wird es auch funktionieren??? So richtig Controllerspezifisches (zumindest hatte ich mir das ganz anders vorgestellt.) konnte ich nicht entdecken, weshalb ich nicht weiß ob und was ich anpassen soll. Da Du ja wirklich mächtig Ahnung davon zu haben scheinst (oder wenigstens einen begabten Namensvetter vorweisen kannst) wäre es nett, wenn Du mir vielleicht die entscheidene Funktion _sbrk_r ein bißchen erklären könntest. (wo zum Beispiel wird extern char end[] initialisiert?) Kann ich die Funktion einfach so wortwörtlich für den SAM übernehmen? Gruß, jörn
Disclaimer: habe weder die von dir genannte Datei gesehen noch vom ARM Ahnung... > wo zum Beispiel wird extern > char end[] initialisiert? Der Linker generiert dieses Symbol. Müsste im Linkerscript (irgendwo in einem Verzeichnis ldscripts?) zu finden sein. Dass es sich dabei um ein array of char handeln soll, ist natürlich simple Phantasie desjenigen, der den Code gezimmert hat. ;-)
Jörn: Das sbrk sollte in der Form, wie in meinem "lpc2129_adc_stdio"-Beispiel enthalten, auch fuer den SAM7S64 funktionieren. Ist wie richtig erkannt wenig controllerspezifisch. Der Name der Funktion mit _r am Ende markiert den "reentrant" syscall. Muss so bezeichnet sein, da ich die newlib fuer WinARM so compiliert habe, dass reentrant syscalls erwartet werden. Das "end" wird, wie von Jörg geschrieben, im Linkerskript festgelegt, man suche PROVIDE(end...) in *.ld. Jörg: char[] ist nicht meine Idee, 1:1 vom "newlib-lpc" sbrk-code uebernommen. Tatsaechlich ungluecklich/missverstaendlich, aber in dem Fall "Jacke wie Hose".
> char[] ist nicht meine Idee, 1:1 vom "newlib-lpc" sbrk-code > uebernommen. Das war ja auch keine Kritik, ich wollte damit nur andeuten, dass eine Typinterpretation eines Symbols, das vom Linker definiert wird, natürlich komplett Angelegenheit desjenigen ist, der dieses Symbol benutzt. Ich hätte es vermutlich als void * benutzt, aber ich kenne den Quelltext hier überhaupt nicht. Der Vorteil von char[] ist zumindest, dass man darauf (im Gegensatz zum void *) auch Adressarithmetik ansetzen darf (auch wenn der GCC es für void * ebenfalls zulässt).
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.