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.
Du hast schon in deinem Hauptprogramm ein "#include spi.h" drin stehen? Woher soll dein Hauptprogamm die Funktionen kennen?
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.
Und hier noch das Makefile. Wäre super, wenn du oder jemand anders mir erklären könnte, was ich eventuell ändern muss. Danke schonmal.
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:
1 | @if [ 'x${VERBOSE}' = x ]; |
wird nicht erkannt. Fehlermeldung ist:
1 | "'x'" kann syntaktisch an dieser Stelle nicht verarbeitet werden. |
2 | cs-make: *** [gcc/startup.o] Error 255 |
Hat einer eine Idee, wie das in cs-make heißen muss?
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)
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.