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.
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 keinARM, 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.
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.
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
