Hallo zusammen! Ich habe bisher viel und intensiv mit AVR 8-Bit Mikrocontrollern gearbeitet und möchte nun in die Welt der ARM 32-Bit Controller einsteigen. Ausgesucht habe ich mir dafür den LPC1768 von NXP. Folgende Vorraussetzungen konnte ich mir schaffen: - das ARM LPC1768 Cortex M3 LCD Board - einen JLink JTAG Adapter - WinARM Leider stehe ich jetzt etwas auf dem Schlauch, denn bisher habe ich leider keine Anleitung gefunden, die mich lückenlos in die ARM Programmierung einführen konnte... Oft sind sie für andere Controllerfamilien oder IDEs ausgelegt, so dass ich Euch bitte wollte mir bei meinen Fragen etwas Starthilfe zu geben. 1) Was für zusätzliche Dateien muss ich in meinen Quellcode einbinden, um mit dem LPC1768 zu arbeiten? In einem Demoprojekt was ich für einen anderen LPC gefunden habe, wurden scheinbar nur die Registeradressen und Interruptvektoren eingebunden. Bei WinAVR war es ja so, dass man diese über die "stdio.h" automatisch eingebunden bekommen hat. WinARM unterstützt den LPC1786 aber nicht von Haus her. Auf der NXP Website habe ich hier http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768 die "AN10918 NXP LPC Cortex-M3 IEC60335 Class B library V1" gefunden, die einiges an Headerdateien für den LPC1768 enthält, aber nichts was direkt für WinARM gemünzt ist. Es fällt mir schwer zu entscheiden, welche dieser Dateien ich nutzen kann/muss. Schade dass die letzte WinARM Version von 2006 ist... Gibt es da kein Community-Interesse das Projekt weiterzuentwickeln und auf neuere Controller vorzubereiten? 2) Ein kleines Mysterium bildet für mich der "StartUp-Code". Ich habe den Begriff in unterschiedlichen Zusammenhängen gelesen, daher wollte ich mich mal bei Euch erkundigen was es damit auf sich hat. Ist der StartUp-Code quasi die "Init"-Funktion für den ARM zur Konfiguration des Taktgebers, der Portpins u.s.w.? Oder enthält er den Bootloader? Muss der Startup-code in einen anderen Speicherbereich abgelegt werden wie das eigentliche Programm? 3) Das Testboard hat eine serielle Programmierschnittstelle an UART0, die wohl mit einem Bootloader funktioniert. Wenn ich diese Schnittstelle aber nicht zum Programmieren nutzen möchte oder mir irgendwie den Bootloader beschädige, kann ich das Programm dann auch einfach mit dem JLink JTAG Adapter auf den LPC1768 laden (das Testboard hat einen JTAG Anschluss)? Vielen Dank schonmal für Eure Hilfe! Gruß, André
André Wippich schrieb: >... > 1) Was für zusätzliche Dateien muss ich in meinen Quellcode einbinden, > um mit dem LPC1768 zu arbeiten? In einem Demoprojekt was ich für einen > anderen LPC gefunden habe, wurden scheinbar nur die Registeradressen und > Interruptvektoren eingebunden. Neben dem "normalen" C-Code der Anwendung braucht man bei GNU-Toolchain: - Linker-Script - Startup-Code > Bei WinAVR war es ja so, dass man diese über die "stdio.h" automatisch > eingebunden bekommen hat. Nicht stdio.h sondern avr/io.h. > WinARM unterstützt den LPC1786 aber nicht von Haus her. WinARM 2006/06 unterstützt nicht mal Cortex-M3, die "WinARM"-testing schon. Weiteres s.u. > Auf der NXP Website habe ich hier > http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768 > die "AN10918 NXP LPC Cortex-M3 IEC60335 Class B library V1" gefunden, > die einiges an Headerdateien für den LPC1768 enthält, aber nichts was > direkt für WinARM gemünzt ist. "Für WinARM gemünzt" heisst für die GNU ARM Crosstoolchain vorbereitet. WinARM ist (besser war) nichts anders als ein Packet, in dem die GNU toolchain und ein paar Hilfsdateien zusammengestellt sind. Für der NXP-Seite gibt es Beispiel-Anwendungen (nach CMSIS suchen). Das sollte ein guter Anfang sein (habe allerdings auch nur "quergelesen"). Startup-Code auch für GNU ist darin enthalten. Ob Linkerscripte drin sind, weiss ich nicht, man kann aber ohne viel Aufwand ein Linkerscript z.B. für LMI/TI oder STM CM3 für GNU anpassen. > Es fällt mir schwer zu entscheiden, > welche dieser Dateien ich nutzen kann/muss. Schade dass die letzte > WinARM Version von 2006 ist... Gibt es da kein Community-Interesse das > Projekt weiterzuentwickeln und auf neuere Controller vorzubereiten? WinARM selbst ist/war nicht wirklich ein "Community-Projekt" sonder nur eine Sammlung von Programmen. Ich habe das seinerzeit erst nur zur eigenen Verwendung aus "Community-Quellcode" zusammengestellt, da die verfügbaren Packete mit GNU ARM-Crosstoolchain für MS-Windows nicht meinen Wünschen entsprachen. Später habe ich das Packet auch "veröffentlicht" und der Erfolg war enorm. Inzwischen gibt es aber genug Alternativen zu WinARM: Yagarto, Codesourcery G++ für ARM EABI, DevkitARM, Anglia SARM und sicher noch andere. Darin sind aber meist nur die GNU Toolchain ohne Beispiele und Hilfsprogramme. > 2) Ein kleines Mysterium bildet für mich der "StartUp-Code". Ich habe > den Begriff in unterschiedlichen Zusammenhängen gelesen, daher wollte > ich mich mal bei Euch erkundigen was es damit auf sich hat. Ist der > StartUp-Code quasi die "Init"-Funktion für den ARM zur Konfiguration des > Taktgebers, der Portpins u.s.w.? Startup-Code ist ein recht dehnbarer Begriff. Üblicherweise werden im Startup-Code implementiert: - Vector-Table mit speziellen Einstellungen für die Toolchain zur Speicherposition (input-section o.ä.) - Bei CM3: die ersten beiden Elemente der Tabelle mit korrekten Adressen füllen (v.a. Reset-Vector). Ist ebenfalls abhängig von der Toolchain (Adresse der Reset-Routine wird erst vom Linker vergeben). - Bei Verwendung der GNU-Toolchain werden noch die Datenbereiche für Variablen im RAM vorbereitet werden (Stichworte .data-copy .bss-clear) und im Anschluss main() aufgerufen. - main() aufrufen Mehr ist bei Cortex-M3 schon nicht zu tun (bei ARM7TDMI wäre es noch etwas mehr). Eine "Init"-Funktion für die Hardware kann man normalerweise auch einfach als erstes in main() aufrufen, muss nicht im Startup-Code selbst sein. (Bei Beispielen für Keil/ARM MDK sind im Startup-Code oft auch Hardwareinitialisierungen untergebracht und statt "manuellem" data-copy/bss-init wird eine Funktion der Laufzeitbibliothek aufgerufen, in der das passiert und die dann main() ruft) >Oder enthält er den Bootloader? Bootloader auf LPC ist anderes und ist nicht-überschreibbar im Speicher des Controllers. Hat nichts mit dem Startup-Code zu tun. > Muss der Startup-code in einen anderen Speicherbereich abgelegt werden > wie das eigentliche Programm? Nicht unbedingt. Wichtig ist, dass der Vector-Table an der richtigen Adresse steht. Als zeites Element im Vector erwartet der MC3 die Startadresse (an erster Stelle den Initalwert des nach eine Reset verwendeten Stackpointers). > 3) Das Testboard hat eine serielle Programmierschnittstelle an UART0, > die wohl mit einem Bootloader funktioniert. Wenn ich diese Schnittstelle > aber nicht zum Programmieren nutzen möchte oder mir irgendwie den > Bootloader beschädige, kann ich das Programm dann auch einfach mit dem > JLink JTAG Adapter auf den LPC1768 laden (das Testboard hat einen JTAG > Anschluss)? Bootloader sollte man eigentlich nicht beschädigen können. Ja, das Programm kann man üer JLINK über JTAG oder SWD in den Flash-Speicher des Controllers übertragen. Details zu JLINK kenn ich nicht aber da kann sicher jemand anderes einspringen. Alles in Allem ist es mglw. einfacher, sich eine etwas besser "vorkaute" Umgebung (IDE, Compiler, Beispiele für den gewünschten Controller) zu besorgen und damit die ersten Schritt zu machen. Selbst wenn man später auf andere Werkzeuge umsteigen will, ist der Einstieg mit den Kommerziellen wahrscheinlich einfacher. Die Konzepte sind immer ähnlich. Selbst die "dicken Eisen" von Keil/ARM und IAR gibt es als Evaluierungsversionen für umsonst (Vollversionen allerdings alles andere als "Sonderangebote") und Rowleys Crossworks kostet als uneingeschränkte Version bei privater Verwendung auch nicht die Welt, hat einen guten Ruf und nutzt im Hintergrund die GNU-Toolchain. Ansonsten kann man sich auch an Beispielen/Informationen für LM3S und STM32 orientieren, die Unterschiede in Bezug auf die Verwendung der Entwicklungswerkzeuge sind bei gleichem Controllerkern relativ gering.
Hallo Martin! Danke für die ausführliche Antwort! Das hilft mir schonmal sehr weiter. Ich habe auch Deinen Rat befolgend mich mehr in Richtung "fertiger" IDE umgesehen (anstatt es von kleinauf aufzubauen) und bin dabei zufällig auf YAGARTO gestoßen. Die ist zwar kein richtiges Komplettpaket wie IAR oder Keil, aber dafür völlig unlimitiert, mit Unterstützung für meinen JTAG Adapter zum Debuggen und auch einem Codebeispiel für den LPC1768. Und letzteres bedeutet ja: Linkerskript & StartUpCode für den LPC1768 sind dabei! Das waren soviele positiive Zufälle, dass es schon Schicksal sein muss :-) Dann werde ich mich jetzt mal wieder an die guten alten Grundlagen machen: Knöpfchen drücken -> LED anschalten ;-) Gruß, André
Ebenfalls meinen Dank für die klärenden Worte zum Thema IDE / MCU ARM Cortex - wenn gleich dieser Thread schon älter ist, ist er für mich jedoch ausgeprochen hilfreich bei der Wahl des AVR-Nachfolgers für meine Bastelprojekte. Den ersten Fehler habe ich bereits gemacht und statt einem J-LINK einen ULINK2 erstanden. Für den Anfang dürfte der jedoch auch funktionieren und die µVision kenne ich schon aus meiner i51iger Zeit recht gut. Schaun' wah mah - oder wie Wir hier im Ruhrgebiet zu sagen pflegen - mal gucken watt geht. Besten Dank Gruß Juppeck
Bitte 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.