Hallo zusammen,
ich verwende einen LPC2103 und WinARM und habe mir das folgende Projekt
als Beispiel genommen, um mit dem Controller zu starten:
http://ieee.ucsd.edu/news/item.php?id=104
Das Programm ist wohl das Beispielprogramm von Martin Thomas, nur für
den LPC2103 angepasst.
Nun kann ich das Programm kompilieren und es läuft auch prima, nur eine
Sache geht nicht: Das Einbinden von anderen C-Files. Ich habe jeweils
das C-File und ein entsprechendes Headerfile, die an sich auch korrekt
sind. Wenn ich eine Funktion aus diesen Dateien aufrufe, hängt sich der
Controller aber irgendwie auf.
# List C source files here. (C dependencies are automatically
generated.)
# use file-extension c for "c-only"-files
SRC = blinky.c
#SRC =
# List C source files here which must be compiled in ARM-Mode.
# use file-extension c for "c-only"-files
SRCARM = VIClowlevel.c interrupts.c
Egal ob ich meine spi.c an SRC oder SRCARM dranhänge, das Compilieren
klappt und beim Aufruf einer Funktion aus spi.c steigt der Controller
dann aus. Das Problem habe ich mit allen c-Files, daher glaube ich
nicht, dass es die Files selber sind.
Ich mache doch noch irgendwas beim Einbinden falsch, oder?
Keiner eine Idee? Eigentlich müssten andere doch auch schon vor dem
Problem gestanden haben und es hinbekommen haben, gerade weil es ja das
Makefile aus vielen der Beispiele von WinARM ist.
Natürlich habe ich das #include in meinem Hauptprogramm drin, sonst
würde das Kompilieren ja bereits scheitern. Ich habe das Gefühl der
Linker würde die Sachen nicht richtig verknüpfen und meiner Meinung nach
müsste sich das Problem im Makefile finden lassen. Aber momentan komme
ich da einfach nicht weiter.
Ich verwende das Makefile nicht mehr. Statt dessen verwende ich Eclipse
mit entsprechendem Plugin, mit dem man keine Makefile mehr braucht.
Was sagt die MAP-Datei? Eventuell liegt der Startupcode an der falschen
Stelle? Kannst du per JTAG debuggen?
Ich habe die map-Datei mal angehängt, vielleicht kannst du damit etwas
anfangen. Auf Eclipse möchte ich mittelfristig auch irgendwann wechseln,
nur momentan wäre mir ein funktionierendes Projekt für WinARM lieber.
Debuggen kann ich mangels JTAG leider nicht.
Das makefile basiert auf einer ziemlich alten Vorlage von mir und wenn
ich dass richtig sehe, wurden auch einige Optionen verändert. Im
Map-File finde ich auf Anhieb kleinen Hinweis, was aber nichts heißen
mag, nur drübergeflogen.
Der Code von der im ersten Beitrag verlinkten Seite benutzt die
gcc-Attributes zur Deklaration der Interruptserviceroutienen. Hatte
damit öfter Probleme (andere wohl auch) und empfehle, stattdessen lieber
eigene entry/exit-Macros oder noch besser einen Assembler-Wrapper zu
verwenden.
Am Besten alle Projektdateien zusammenpacken (Quellcodes, startup-code,
linker-script und makefile), so dass man ein make all darauf loslassen
kann. Damit kann man (zumindest ich) dann mehr anfangen als mit
herausgepickten Teilinformationen wie makefile und/oder map-file. Habe
allerdings keine Hardware mit LPC2103 zum Test am "lebenden" Objekt
(Zusendungen sind willkommen ;-) ).
Vielleicht noch hilfreich (obwohl hier ja das gcc-Forum ist): der
Simulator von Keils uVision/RV-MDK (auch der der Eval.-Version) kann
auch mit den von der GNU-Toolchain generierten elf-Dateien umgehen. Das
ist ein sehr brauchbares Werkzeug, um v.a. Startprobleme auch ohne
JTAG-Hard-/Software zu analysieren.
Hallo Martin,
anbei einmal das ganze Projekt.
Es wäre super, wenn du mir sagen könntest, wo das Problem liegt bzw. wie
man es behebt. Ich bin auch gerne bereit, danach vielleicht zwei
Blink-Blinkbeispiele (einmal mit, einmal ohne Interrupts) entsprechend
zu kommentieren und dir zur Verfügung zu stellen - für den LPC2103 gibt
es ja auf deiner Seite leider noch keine Beispiele. Vielleicht bleibt ja
auch noch eine Platine für den LPC2103 übrig. ;-)
Danke jedenfalls schonmal.
Sodenn ich das jetzt im User-Manual auf die Schnelle richtig nachgesehen
habe: PINSEL1 |= (1<<6) in initSP1 aufgerufen aus main schaltet Pin 0.19
auf Funktion MISO und dieser ist damit kein GPIO-Pin mehr. Die
Umschaltung des Pins über FIO in der Timer-ISR bewirkt dann nichts.
Wahrscheinlich läuft das Programm, man sieht halt nur nichts mehr
blinken. Testweise LED an anderen Pin, Code anpassen und nochmal
ausprobieren. Falls es immer noch nicht klappt, einfach nochmal melden.
Leider ist es das nicht, das Problem habe ich auch mit anderen
c-Dateien, die nicht auf den Pin der LED zugreifen. Ansonsten
funktioniert das aber, zuerst die SPI-Pins zu initialisieren und danach
trotzdem wieder auf die alte IO-Funktionalität zu wechseln. Das hatte
ich schon getestet. Also kurzum: Egal welche Funktion ich aus einer
externen c-Datei aufrufe, der Controller verabschiedet sich.
Danke, Martin. Momentan klappt das Kompilieren noch nicht (Fehler in
Zeile 541 des Makefiles, Separator oder so fehlt.), aber das liegt wohl
daran, dass es für Codesourcery geschrieben ist. Ich installiere mir mal
die Toolchain und berichte dann.
Ganz lieben Dank, Martin. Nachdem ich Codesourcery installiert habe und
einige Anpassungen vorgenommen habe, bis das richtige make ausgeführt
wurde, funktioniert das Kompilieren jetzt problemlos und das Einbinden
externer Dateien auch.
Freut mich, dass es geholfen hat. Betr. Codesourcery G++ Installationen
auf MS-Windows und "make": einfach statt make cs-make verwenden.
Zumindest unter Windows sollte allein die CS G++ lite f. arm-eabi
Installation für ein "cs-make all" reichen.
Habe bisher mit Codesourcery G++ lite und unxutils gearbeitet.
Habe jetzt einen neuen Rechner mit Vista und habe es mit cs-make
probiert.
Da kommt allerdings direkt Gemecker.
Der Ausdruck:
Hat wenig bis garnichts mit dem Problem des OP zu tun. Bitte in neuem
Thread mit mehr Kontext, also Minimalbeispiel um Problem
nachzuvollziehen und evtl. Korrekturen testen zu können.
Wie auch immer, mögliche Ursachen:
- genutzte shell unterschiedlich, vorher wahrscheinlich ein "unixoide"
Shell, nun MS Windows cmd.com (wahrscheinlich)
- unterschiedliche Versionen von Make (unwahrscheinlich)
