www.mikrocontroller.net

Forum: Compiler & IDEs GCC Fehlermeldung bei ARM


Autor: jörn (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"und diese sich noch problemlos in Assembler programmieren ließen"

Geht doch auch mit den ARMs. Oder wo liegt Dein Problem?

Autor: jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.