Bisher bin ich ziemlich vertraut mit Microchip, möchte aber ein blick in die ARM welt werfen. Habe jedoch einige Fragen dazu. Der Artikel: http://www.mikrocontroller.net/articles/ARM_GCC erklärt wie man mit GCC scheinbar die meisten ARM-Cortex serien COmpiliert und Programmiert bekommt. bei Microchip war die Sache einfach. ne Dicke auswahl an Chips als Programmieradapter hat man die wahl zwischen PICKit3, ICD3 und noch nem ziemlich teuren. Dazu gibt MPLABX für Windows und Linux. Damit war die sache überschaubar. Sieht man sich jetzt aber in der ARM Welt um, warten gleich massig Hersteller. Atmel, Texas Instruments .... selbst SiLabs bietet eine Hand voll Microcontroller mit Cortex-M0/M3/M4 kern an. http://www.silabs.com/products/mcu/Pages/default.aspx dazu gibt es wieder einen Adapter für ~36 EUR http://www.silabs.com/products/mcu/Pages/default.aspx Aber mal zu meiner Frage, wenn man sich für Texas Instruments entscheided, fällt einem später der Umstieg auf andere Hersteller schwer? Gibt es Programmieradapter die mit allen Microcontroller (ARM) klar kommen und sich unter linux mit gcc und ein und der selben IDE anständig Programmieren lassen? Die Hersteller bieten für Ihre µC auch jedemenge Beispielcode, ist dieser dann auch problemlos compilebar mit dem gcc, wenn man nicht den Ihre IDE verwendet? Wie macht man das wenn man weder nen riesen Haufen adapter rumliegen haben will, noch bereit ist für KEIL und co riesen summen auszugeben? Kann mir jemand einen Programmieradapter für Texas Instruments ARM-Cortex MCUs nennen, der Preislich noch verkraftbar ist? Vielen Dank
Hallo Simon, schau dier bei TI mal die ARM Launchpad's an. Die haben alle den debug adapter onboard. zb das MSP-EXP432P401R (cortex M4F) ist sehr günstig zum einstieg in ARM. Habe ca 12Eur dafür bezahlt, billiger bekommst du keinen debug adapter. zitat: XDS110-ET Onboard Emulator To keep development easy and cost effective, TI's LaunchPad evaluation kits integrate an onboard emulator, which eliminates the need for expensive programmers. The MSP‐EXP432P401R has the XDS110-ET emulator, which is a simple low-cost debugger that supports nearly all TI ARM device derivatives. mfg Peter
Die meisten ARMe sollten sich mit OpenOCD und FT2232-basierenden Programmieradaptern programmieren und debuggen lassen. Selbst ein "Wiggler" für den Frickelport sollte funktionieren, aber dieses Fass will man wohl 2015 endgültig nicht mehr aufmachen.
Nimm den Segger, der ist quasi "Standard" bei den meisten Firmen, und als J-LINK EDU für Schüler / Hobbyisten auch bezahlbar: http://shop.segger.com/J_Link_EDU_p/8.08.90.htm
Simon schrieb: > Gibt es Programmieradapter die mit allen Microcontroller (ARM) klar > kommen und sich unter linux mit gcc und ein und der selben IDE anständig > Programmieren lassen? Ja, zB der J-Link, der geht mit eclipse unter Linux, Windows, Mac. Die Einrichtung von eclipse ist etwas fummelig, aber dafür unter Linux+Windows gleich. Simon schrieb: > Die Hersteller bieten für Ihre µC auch jedemenge Beispielcode, ist > dieser dann auch problemlos compilebar mit dem gcc, wenn man nicht den > Ihre IDE verwendet? Ja, denn die meisten kommerziellen IDE's verwenden ja auch nur den GCC. Die CMSIS/Standard-Librarys enthalten sogar extra Anpassungen für den GCC. Simon schrieb: > Wie macht man das wenn man weder nen riesen Haufen adapter rumliegen > haben will, noch bereit ist für KEIL und co riesen summen auszugeben? Freie IDE (für Windows gibts diverse) und J-Link. Letzterer ist zwar teurer als die herstellerspezifischen "kleinen" Adapter (wie auch ST-Link bei ST), kann dafür eben auch alle ARM Cortex. Schau im Wiki mal unter STM32, da ist das Vorgehen sehr ähnlich, halt nur andere Libraries.
Vielen Dank schonmal für die Antworten. Was mir aufgefallen ist, der MSP430 wird von den debuggern von Ti (XDS100, XDS200) nicht unterstützt, der braucht einen extra FET430. Wie sieht das beim j-link aus, kommt man da auch auf die MSP430 chips?
Simon schrieb: > Wie sieht das beim j-link aus, kommt man da auch auf die MSP430 chips? Ziemlich wahrscheinlich nicht. MSP430 ist kein ARM, sondern eine völlig eigene 16-Bit-Architektur. MSP432 hingegen verwendet einen Cortex M4F-Kern und ist damit ein ARM.
Also nochmal, nur um sicherzugehen: Der J-Link und Eclipse unterstützen (praktisch) alle ARM, unabhängig vom Hersteller? Kann man vor dem Kauf eines Controllers erkennen, wenn dieser nicht unterstützt wird? Läuft das wie beim AVR, also Anschluss für den Adapter in die Platine einbauen und im System programmieren? Vor grob zwei Jahren hatte ich mal nach sowas gefragt und da klang es für mich so, als gäbe es keine Einzellösung für alle.
Rufus Τ. F. schrieb: > Ziemlich wahrscheinlich nicht. MSP430 ist kein ARM, sondern eine > völlig eigene 16-Bit-Architektur. ja klar, nur ich hatte die Hoffnung das er doch unterstützt wird, weil der j-link selbst über jtag die PIC32 kann.
Dussel schrieb: > Also nochmal, nur um sicherzugehen: Der J-Link und Eclipse > unterstützen > (praktisch) alle ARM, unabhängig vom Hersteller? Ja. Eclipse ist der Controller sowieso egal, da stellst du nur die Architektur ein und kopierst die Hersteller-Library, Startupcode und Linkerscript hinein. Nur zum Debuggen ist interessant (aber nicht zwangsweise erforderlich), ob es die Definitionen der Peripherie-Register gibt zur hübschen Anzeige. > Kann man vor dem Kauf eines Controllers erkennen, wenn dieser nicht > unterstützt wird? Die Liste der vom J-Link unterstützten Contröller (man beachte dass MSP430 nicht dabei ist): https://www.segger.com/jlink_supported_devices.html In Eclipse selbst kannst du sehen, für welche Controller Register-Definitionen zwecks Anzeige beim Debugging verfügbar sind: http://gnuarmeclipse.livius.net/blog/assign-device-project/ > Läuft das wie beim AVR, also Anschluss für den Adapter in die Platine > einbauen und im System programmieren? Ja, zB der 20-polige Standard-ARM-JTAG-Stecker der auch am J-Link selber dran ist, oder was kleineres mit selbstgebasteltem Adapter.
Danke. Das ist ja interessant. Bei etwa 5000 unterstützten Controllern sollte schon einer dabei sein, der passt. :-)
ehm Jungs, ich habe da was gefunden: nen J-Link bei ebay für 14 eur? Hat das ding mal einer Probiert? ich erspare mir mal die Frage ob das nen original ist. http://www.ebay.de/itm/271867826353
Laut Berichten aus Foren sollten solche Adapter eigentlich laufen. Aber dir muss klar sein, dass es nicht alles läuft bzw. zu Problemen kommen könnte . Wenn du was universelles willst, nimm halt Edu Version von Segger. Es kostet halt nicht die Welt. Wenn du aber dafür kein Geld ausgeben willst, kaufe Boards mit dem integrierten Programmer. Für Privat reicht es in der Regel eine onboard Lösung.
Ich seh gerade 42 EUR das original, naja gut komm.. soviel darf es dann auch kosten, muss nur noch schauen das ich das unter linux sauber ans laufen bekomme
Simon schrieb: > Gibt es Programmieradapter die mit allen Microcontroller (ARM) klar > kommen und sich unter linux mit gcc Schmeiß mal nicht alles in einen Topf. Also: mit dem GCC oder irgend einer anderen Toolchain erzeugst du dein zu programmierendes Image. Also Quelle rein, Hex oder Bin oder S19 Datei raus. Diese Datei ist das dann, die du in den Controller brutzeln mußt. Was für eine Quelle, was für eine Sprache, was für eine Toolchain - ist egal. So. Manche Hersteller bieten zum Programmieren nix in ihren Chips an außer JTAG oder SWD. Für diese Chips mußt du einen JTAG/SWD-Adapter anschaffen, dessen Brennsoftware den betreffenden Chip kennt und bedienen kann. Andere Hersteller (vor allem NXP und ST) erleichtern einem die Sache, indem sie fest in einen Sonder-ROM-Bereich ihres Chips (der Adreßraum ist ja ausreichend groß) einen Bootlader einbauen. Je nach Chip kann man diesen dann per seriell (UART, SPI, I2C oder so - Doku lesen!!!) oder gar direktemang per USB benutzen, um seine Firmware in den Chip zu bekommen. Also: Wenn du nicht gerade brennend dafür interessiert bist, dich mit JTAG/SWD-Adaptern unter Linux herumzuschlagen, dann würde ich dir ganz heftig zu einem Chip raten, der sich direkt per USB braten läßt. Zweite Wahl wären dann solche, die einen eingebauten Bootlader via UART haben und dritte Wahl dann der Rest per SWD. Merke eines: Bei der USB-Variante erledigt eine Firmware vom Hersteller auf dem Chip das Geschäft und man darf davon ausgehen, daß die es 100% tut. Bei der seriellen Bootladervariante brauchst du ein Partnerprogramm auf dem PC (bei NXP FlashMagic, bei ST ..hmm Erfos ;-)), was aber dank der ordentlich dokumentierten Protokolle auf der Seriellen kein echtes Problem ist. Bei der SWD-Variante brauchst du alles passend zu deinem Chip auf dem PC. Natürlich gibt es beim Klassenprimus J-Link auch ne Möglichkeit, ihn unter Linux zu benutzen, aber m.W. sind alle die eigenständigen Programme, die es dafür von Segger gibt, erstmal nur für Windows gedacht. Also überlege nochmal, ob es tatsächlich TI sein soll. Und ob es Linux sein muß, DAFÜR. W.S.
W.S. schrieb: > Merke eines: Bei der USB-Variante erledigt eine Firmware vom Hersteller > auf dem Chip das Geschäft und man darf davon ausgehen, daß die es 100% > tut. Bei der seriellen Bootladervariante brauchst du ein Partnerprogramm > auf dem PC (bei NXP FlashMagic, bei ST ..hmm Erfos ;-)) stm32flash (nur flashen via UART/I2C) stlink (flashen und Debug-Server via ST-Link) > Natürlich gibt es beim Klassenprimus J-Link auch ne Möglichkeit, ihn > unter Linux zu benutzen, aber m.W. sind alle die eigenständigen > Programme, die es dafür von Segger gibt, erstmal nur für Windows > gedacht. Nicht korrekt. Bei Segger kann man mittlerweile auch Tools für Linux herunterladen. Neben dem Brennprogramm (J-Link Commander) gibt es auch hier wieder einen Debug-Server.
W.S. schrieb: > Wenn du nicht gerade brennend dafür interessiert bist, dich mit > JTAG/SWD-Adaptern unter Linux herumzuschlagen, dann würde ich dir ganz > heftig zu einem Chip raten, der sich direkt per USB braten läßt. Der Vorzug von JTAG/SWD ist die Möglichkeit des Debuggens. Insofern kann es schon lohnend sein, sich damit herumzuschlagen.
Rufus Τ. F. schrieb: > Der Vorzug von JTAG/SWD ist die Möglichkeit des Debuggens. Ich sehe das nicht als eine derart wichtigen Vorzug an - denn eigenständige Debugger gibt es im großen und ganzen nicht, man ist immer auf das Gewurschtel mit irgend einer verdammten IDE angewiesen - was mich nicht stören würde, wenn man von diesen Dingern nicht einerseits bevormundet würde (Thema eigener Startup usw) und andererseits das Projektdirectory nicht vollgemüllt würde mit unsäglichem Zeugs, was die eigentliche Toolchain garnicht braucht. Andererseits sehe ich ganz klar, daß der Hauptanwendungsfall für den Debugger das Lernen von C ist - die meisten wundern sich, was der Compiler aus ihrer Quelle tatsächlich gemacht hat. Die Dinge, die ICH debuggen wollen würde, kriegt man nur mit sowas wie nem Postmortem-Debugger heraus. Versuche du doch mal, nen USB-Driver zu debuggen... Also: Den Maschinencode in die Maschine zu befördern, ist essenziell. Das Gucken, wie der selbstgeschriebene Code abgearbeitet wird, ist hingegen zweitrangig. Da ist Denkvermögen weitaus wichtiger. W.S.
Ich benutze ein Tiva LaunchPad von TI direkt unter Linux. http://www.ti.com/tool/ek-tm4c123gxl Programmentwicklung mit gcc (direkt oder mit Eclipse - wobei ich inzwischen die Makefiles und geany vorziehe). Flashen per USB und debuggen auch - entweder mit Eclipse oder mit ddd und gdb. Es sind meines Wissens nur 4 Haltepunkte möglich. Weiß nicht, ob das per Jtag anders ist. War ein bisschen gefrickel bis alles gelaufen ist - aber 12 Euro für die Hardware (incl. Flash und Debug-Interface auf dem LaunchPad). Kann dir schon die entsprechenden URLs raussuchen zum starten wenn du dich für die Lösung entscheidest. Müsstest dann hier noch mal nachhaken. Gerhard Ach und ja, Floating Point Hardware und DSP Funktionalität on Board.
W.S. schrieb: > Rufus Τ. F. schrieb: >> Der Vorzug von JTAG/SWD ist die Möglichkeit des Debuggens. > > Ich sehe das nicht als eine derart wichtigen Vorzug an - denn > eigenständige Debugger gibt es im großen und ganzen nicht Doch, natürlich. gdb. Und für Kommandozeilenhasser halt eines der ca. ein Dutzend GUIs oben drauf. Einige der GUIs sind komplette IDE, andere wie DDD oder KDbg sind reine Debugger. https://sourceware.org/gdb/wiki/GDB%20Front%20Ends > man ist immer > auf das Gewurschtel mit irgend einer verdammten IDE angewiesen - was > mich nicht stören würde, wenn man von diesen Dingern nicht einerseits > bevormundet würde (Thema eigener Startup usw) und andererseits das > Projektdirectory nicht vollgemüllt würde mit unsäglichem Zeugs, was die > eigentliche Toolchain garnicht braucht. Wie gesagt: nackter gcc + binutils für die Zielplattform und dazu gdb. Und natürlich make und ein Editor deiner Wahl. Dann behältst du zu 100% die Kontrolle und kannst auch debuggen falls du es mal brauchst. > Also: Den Maschinencode in die Maschine zu befördern, ist essenziell. > Das Gucken, wie der selbstgeschriebene Code abgearbeitet wird, ist > hingegen zweitrangig. Da ist Denkvermögen weitaus wichtiger. Da stimme ich dir tendenziell sogar zu. Man kommt schon mit einem UART- Kanal für "printf() Debugging" oder sogar nur einer einzelnen LED recht weit. Allerdings geht man auf den fetten ARM Teilen ja normalerweise auch die etwas komplexeren Projekte an. Ab einer gewissen Projektgröße ist ein richtiger Debugger einfach sehr wertvoll.
W.S. schrieb: > man ist immer > auf das Gewurschtel mit irgend einer verdammten IDE angewiesen - was > mich nicht stören würde, wenn man von diesen Dingern nicht einerseits > bevormundet würde (Thema eigener Startup usw) und andererseits das > Projektdirectory nicht vollgemüllt würde mit unsäglichem Zeugs, was die > eigentliche Toolchain garnicht braucht Das stimmt doch gar nicht! Du kannst doch eine nackte vollkommen neutrale IDE nehmen wie zum Beispiel Eclipse CDT mit dem GNU-ARM-Plugin dann hast Du erstmal ne komplett neutrale IDE die einfach nur C/C++ editieren, ein Makefile aufrufen und mittels J-Link & gdb debuggen kann. Dann wirfst Du 5 Dateien in einen Ordner: * Makefile (minimal und selbergemacht oder irgendwo abkekupfert) * linkerscript.ld * startup.s * registerdefines_vom_hersteller.h * main.c Und fertig. Wenn das auf der Konsole kompiliert dann kannst Du das auch in Eclipse importieren (als Makefile-Projekt!) und es wird Dir überhaupt nichts zusätzliches da reinmüllen oder vermurksen, woher auch und wieso auch sollte es das tun? Wenn Du in Eclipse ein Makefile-Projekt als solches (!) importierst wird es überhaupt keine eigenmächtigen Dinge tun und nichts daran antasten und stets nur das Makefile verwenden um das Projekt zu bauen, jedoch hast Du dann dennoch die ganze Macht von Eclipse und gdb unter Deinen Fingerspitzen. Und wenn Du dann irgendwann keine Lust mehr hast auf Eclipse nimmst Du die selben 5 Dateien von oben und arbeitest stattdessen mit Netbeans oder Qt-Creator oder K-Develop oder code::blocks oder emacs oder vim weiter. Je nach Geschmack. Edit: * noch die core-Dateien von ARM, sind glaub ich 2 Stück oder so, die hab ich noch vergessen. Edit2: Und übrigens ich schließe mich der schon anfangs ausgesprochenen Empfehlung an einen J-Link EDU von Segger zu kaufen. Der ist jeden einzelnen Cent seines Preises wert und noch viel mehr! Das wird in kürzester Zeit Dein liebstes Werkzeug werden im Umgang mit ARM-Controllern.
> * Makefile (minimal und selbergemacht oder irgendwo abkekupfert) > * linkerscript.ld > * startup.s > * registerdefines_vom_hersteller.h > * main.c Gibt es von den Herstellern (einigermaßen durchgängig) gebrauchbare Registerdefines oder ist das immer so ein Riesenpaket, was man dann auseinanderfrickeln muss? Atmel bewirft einen ja erstmal mit einem 380 MB großen, registrierungspflichtigen Download für seine SAM3X, wo kreuz und quer Abhängigkeiten zu deren Bibliothek auftauchen.
S. R. schrieb: > Gibt es von den Herstellern (einigermaßen durchgängig) gebrauchbare > Registerdefines oder ist das immer so ein Riesenpaket, was man dann > auseinanderfrickeln muss? Unterschiedlich. Aber einen Packen Header ist schon normal, da sich vieles überschneidet. Und auch entsprechende Downloadpakete sind normal. Abhängigkeiten zu Libs oder zusätzlichen C-Files hab ich eher selten erlebt.
S. R. schrieb: > Gibt es von den Herstellern (einigermaßen durchgängig) gebrauchbare > Registerdefines oder ist das immer so ein Riesenpaket, was man dann > auseinanderfrickeln muss? Letzteres. Frickeln ist angesagt. Die Hersteller verfahren entweder so, daß es ihnen schnurz ist, was der Kunde mit ihren Chips anfängt oder sie tun das Gegenteil, indem sie einen in ihre (oft unerträgliche) Schublade pressen wollen - mit Headerfiles und anderem Zeug, das wie ein Dschungel kreuz und quer vernetzt ist, so daß man nicht ein einziges Projekt machen kann, ohne wirklich allen Schrumms dieses Herstellers mit reinziehen zu müssen. Ich hab's mir deshalb angewöhnt, den ganzen Bockmist bleiben zu lassen, mir das, was ich an Headerfiles brauche, selbst zu machen, den Startupcode ebenfalls und mir die Hardware-Register aus dem RefMan herauszukopieren. Das macht anfangs ein klein wenig Arbeit, aber die ist nicht umsonst, weil man ja nebenher auch liest, was der Chip denn so drin hat. Und später ist das Ganze goldwert, denn man ist unabhängig von aller aufgesetzter Schaumschlägerei. W.S.
Angehängte Dateien:
-
stm32_minimal.png
79 KB
W.S. schrieb: > Ich hab's mir deshalb angewöhnt, den ganzen Bockmist bleiben zu lassen, > mir das, was ich an Headerfiles brauche, selbst zu machen, den > Startupcode ebenfalls und mir die Hardware-Register aus dem RefMan > herauszukopieren. Ich mach es ähnlich (eigener Startup, eigenes Linkerscript, eigene SystemInit), aber für die Registerdefines hab ich bis jetzt jedesmal immer genau die Orginal-Datei(en) des Herstellers gefunden die genau das (und nichts anderes) enthalten. Diesen Teil kann man normalerweise vollständig von den ganzen unnötigen Libraries trennen. * Im Anhang zum Beispiel ein Screenshot von nem STM32F401RE nach dem Ausmisten, das sind sogar alles unmodifizierte Orginaldateien des Herstellers (bei diesem Beispiel hab ich sogar den Startup noch orginal so gelassen wie er war, war OK so), ohne jedoch auch nur eine einzige Datei von der HAL mit reinzuziehen. Es mach einmalig ein bisschen Arbeit das so aufzuräumen und den Bloat vollständig rauszuwerfen aber es geht und es lohnt sich.
Hallo, W.S. schrieb: > Ich hab's mir deshalb angewöhnt, den ganzen Bockmist bleiben > zu lassen, mir das, was ich an Headerfiles brauche, selbst zu > machen, den Startupcode ebenfalls und mir die Hardware-Register > aus dem RefMan herauszukopieren. Also ungefähr das, was ich auch vorhatte. Nur fehlt mir dabei Wissen. Mich stört, dass ich evtl. Dinge übersehe, die mich später böse in den Hintern beißen. In den Linkerfiles sind Dinge drin, die ich nicht verstehe, und auch im Binary tauchen mir unverständliche Funktionen auf (die ganzen ARM*-Sections, Konstruktor-/Destruktor- und C++-Zeug, register_tm_clones, usw.) und ich weiß nicht, was wie kaputtgeht, wenn ich das alles rauswerfe. Und wenn da irgendwelche wichtigen Funktionen reingelinkt werden, die ich nicht kenne und im Startup-Code auch nicht aufrufe, dann hat das sicherlich auch Folgen, die ich nicht abschätzen kann. Und langfristig möchte ich auch die libc (newlib) nutzen, die im gcc irgendwie mit drin ist. Ich habe bisher keine ordentliche Beschreibung gefunden, wie das alles zusammenhängt und was man genau wofür braucht. Das ist alles Compilerwissen und nur begrenzt meine Welt. Bernd K. schrieb: > Im Anhang zum Beispiel ein Screenshot von nem STM32F401RE [...] Ja, ST ist da noch eher gutmütig. Wie gesagt, das Fass zum Überlaufen gebracht hat Atmel; das Downloadpaket von denen ist ein Monster und überhaupt nicht mit den AVRs vergleichbar (leider). Gruß, Svenska
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.