Servus,
habe jetzt schon einige Projekte mit AVRs und zwei Projekte mit HC08's
gemacht. Das lief ok, jetzt möchte ich mich mit ARMs beschäftigen. Habe
mich dazu hier im Forum, im Wiki und auch so im Netz belesen. Die Frage
ist, was ich da jetzt tatsächlich brauche.
Es gibt ja wahnsinnig viele Entwicklungsboards die recht
studentenfreundlich bepreist sind, meistens von ST oder NXP direkt. Was
soll ich da nehmen?
Wichtig ist mir, dass da im Gegensatz zum HC08's auch was halbwegs
freies (open source) zum Programmieren verwendbar ist, damit wenigstens
die Chance besteht, ohne größere Komplikationen auch noch in ein paar
Jahren die Hardware verwenden zu können. Z.b. war das Eval-board mit dem
HC08 nur mit einer Uralt-Version der zugegebenen IDE verwendbar. Die
lief dann nur unter Windows XP (2012) und dann noch nicht mal stabil.
Das Board wird übrigens immer noch so verkauft.
So wie ich das verstanden habe, ist SWD quasi Atmel's ISP für
ARM-Prozessoren. Ich bezweifle es zwar, kann ich dann mit ST's ST LINK
wie es angeblich auf deren Eval-Boards verbaut ist z.B. NXP's
programmieren?
Oder doch einen Keil uLink2 in der Bucht schießen? Kann man damit dann
Chips von allen (oder zumindest einigen) Herstellern programmieren?
Mit OpenOCD (=Abstraktionsschicht für JTAG?) kann man wohl den Chip
flashen. Oder benötige ich dazu noch etwas? Wie sieht es da im
Linux-Umfeld aus? (habe irgendwo hier gelesen, dass man den Standard gcc
mit entsprechenden Parametern wohl auch Binaries für Cortex M0 erzeugen
lassen kann)
Danke auch noch für weitere Tipps.
Michael
Mir ist gerade ein Infineon XMC 2Go zugelaufen. Da ist ein M0 von
Infineon drauf. Und ein J-Link lite Programmier/Debug-Adapter.
Der gcc für ARM kommt bei den üblichen Linux-Distros frei Haus. Für das
J-Link gibt es bei Segger das entsprechende Tool zum Download.
Funktionierte hier auf Anhieb (ok, ich hab es nur mal angesteckt und
konnte den M0 anhalten und starten). Wenn ich mal ein paar freie Stunden
habe, spiele ich damit ein bisschen herum.
Ach ja: vom oben verlinkten Artikel geht ein Link ins Web, wo erklärt
wird wie man den M0 von der Linux-Kommandozeile zum Fliegen bringt.
Als Programmierschnittstelle hast Du JTAG (bei allen ARMs) und ab Cortex
M auch noch SWD. SWD ist eine Art Zweidraht-JTAG. So manche kleinen ARMs
haben JTAG gar nicht mehr herausgeführt, sondern nur noch SWD. Du tust
also gut daran, Dir einen Adapter zu besorgen, der JTAG UND SWD kann,
und das herstellerneutral. Also keinen ST-Link, keinen Atmel-Debug, kein
SAM-ICE, kein FT2232-basiertes Teil (kann kein SWD).
Der JLINK funktioniert gut und wird auch von vielen Tools unterstützt.
SWD geht allerdings erst ab HW Rev 8, wenn ich mich recht entsinne, also
aufpassen, wenn Du das Teil gebraucht oder auf ébay kaufst).
fchk
Und OpenSource wird es mit Eclipse und den passenden Plug-ins.
Wenn es gleich etwas Wumms haben soll und der Debugger integriert sein
darf, nimm' entweder eine STM32F4-Discovery (sehr günstig) oder die
STM32F429-Discovery, gleich mit 8 MByte RAM, Display und jeder Menge
Schnickschnack dabei.
http://www.ebay.de/itm/151289777040 STM32F4-Disco, inkl. Versand 19€
http://www.ebay.de/itm/161177600716 STM32F429-Disco, inkl. Versand 30€
Frank K. schrieb:> kein FT2232-basiertes Teil (kann kein SWD).
Bist du dir da sicher?
Wenn ich mir im OpenOCD-Quellcode die Datei jtag/drivers/ftdi.c ansehe,
dann findet sich da sowas:
1
staticintftdi_swd_init(void)
2
...
3
LOG_INFO("FTDI SWD mode enabled");
4
...
Hab's allerdings noch nicht selbst getestet, da ich bislang nur mit
Atmel-ARMs zu tun hatte, für die ich ohnehin schon ein Atmel-ICE
rumliegen habe.
Da er von „studentenfreundlichen Preisen“ schrieb, könnte so ein
einfacher FT2232-basierter Dongle schon eine sehr sinnvolle Alternative
zum Mercedes unter den Programmieradaptern namens „J-Link“ sein.
Jörg Wunsch schrieb:> Frank K. schrieb:>> kein FT2232-basiertes Teil (kann kein SWD).>> Bist du dir da sicher?
Ich habe bislang noch keinen Adapter in den Fingern gehabt, der das
konnte. Inzwischen gibt es eine Lösung, aber die braucht eine
Zusatzbeschaltung, damit SWD bidirektional arbeiten kann - das geht mit
der Standardbeschaltung nicht.
fchk
http://openocd.org/doc/html/Debug-Adapter-Hardware.html
“The FT2232 chips are flexible enough to support some other transport
options, such as SWD or the SPI variants used to program some chips.
They have two communications channels, and one can be used for a UART
adapter at the same time the other one is used to provide a debug
adapter.”
und:
“Stellaris Eval Boards
See: http://www.ti.com - The Stellaris eval boards bundle FT2232-based
JTAG and SWD support, which can be used to debug the Stellaris chips.
Using separate JTAG adapters is optional. These boards can also be used
in a "pass through" mode as JTAG adapters to other target boards,
disabling the Stellaris chip. ”
NXP schrieb:> JTAG Adapter, Eval Board, komplette IDE für 20€
Ist ja wohl aber nicht viel anders als das schon genannte Angebot
von STM und auch die XplainedPro von Atmel (nur dass Atmel etwas mehr
Geld nimmt).
Derartige Teile findet man auch hin und wieder hier im Markt-Forum.
STM32F429-Disco ist natürlich schon gut bestückt und lässt sich als
Standalone-SWD-Link verwenden (zumindest laut kurz-Datenblatt). Aber
noch mal die Frage von vorhin: Geht das auch mit MCU's von anderen
Herstellern?
Aber auch so ist das Board sehr interessant: Sollte ich damit Erfolg
haben, kann mann dran ja schön weiter basteln.
Der XMC 2Go ist dafür mal sehr günstig, auch wenn scheinbar kein SWD
herausgeführt wird. Aber bei dem Preis wäre es mir relativ wurscht.
Jörg Wunsch schrieb:> Da er von „studentenfreundlichen Preisen“ schrieb, könnte so ein> einfacher FT2232-basierter Dongle schon eine sehr sinnvolle Alternative> zum Mercedes unter den Programmieradaptern namens „J-Link“ sein.
Daher auch die Frage wegen uLink2. Angeblich kann der ja auch SWD. Und
ich gehe davon aus, dass DAS Referenz-Tool vermutlich die beste
Unterstützung hat. Oder liege ich da vollkommen falsch?
Im Wiki steht Eclipse + CDT + gcc (dort von CodeSourcery) + ARM-Plugin
wäre alles, ebenfalls im Wiki-Eintrag vom XMC 2Go. Softwareseitig sollte
das also kein Thema werden.
Vielen Dank schon einmal.
Ich werd mich morgen noch einmal etwas umsehen. Vielleicht fällt mir ja
noch die eine oder andere Frage ein.
EDIT: Da kamen wohl noch einige Posts, während ich den hier geschrieben
habe...
Michael W. schrieb:> Und ich gehe davon aus, dass DAS Referenz-Tool vermutlich die beste> Unterstützung hat.
Kommerziell auf jeden Fall, aber Segger lässt sich auch gern jeden
Pups bezahlen.
Bei OpenOCD wird das J-Link sicher auch gut unterstützt, aber dort
gibt es natürlich ausreichend Interessenten, die Arbeit in die
preiswerteren Alternativen zu investieren bereit sind. Dem TE war
ja Opensource ein wesentlicher Aspekt seiner Überlegungen.
Michael W. schrieb:> Es gibt ja wahnsinnig viele Entwicklungsboards die recht> studentenfreundlich bepreist sind, meistens von ST oder NXP direkt. Was> soll ich da nehmen?
Ehrlich gesagt, ob ST, NXP, TI, Atmel ist völlig egal. Jeder ARM dieser
(und anderer) Hersteller hat ausreichend viele Features um dich lange zu
beschäftigen.
> Wichtig ist mir, dass da im Gegensatz zum HC08's auch was halbwegs> freies (open source) zum Programmieren verwendbar ist,ARMs koennen typischerweise mit dem GNU GCC Compiler und entsprechendem
Toolchain programmiert werden. Gerne wird dabei Eclipse als IDE
drumherum verwendet.
Viele der billigen Boards haben mittlerweile eigene Debugger und
Programmer auf dem Board. Je nach Board brauchst du keinen externen
Programmer, sondern nur ein USB oder serielles Kabel. Zufällig
herausgepicktes Beispiel:
http://www.ti.com/ww/en/launchpad/launchpads-connected-ek-tm4c1294xl.html
$19,99 (plus Versandkosten etc.) So etwas findest du auch bei anderen
Herstellern. Wie gesagt, auf jedem solcher Boards ist genug Zeug um dich
für eine lange Zeit zu beschäftigen.
OPV 007 schrieb:> DAS Referenztool in der ARM Welt ist aber eher der J-Link von Segger
Unterschreibe ich nicht, ich entwickle mit dem ULINK pro wg. Streaming
Trace :-)
Für den günstigen (kostenlosen) Einstieg empfehle ich ein ST Discovery
Kit (da ist ein ST Link drauf, der vernünftig SWO kann) und die MDK-ARM
Demo.
Bis 32k Code kann man schon ne ganze Menge lernen, und - richtig genutzt
- sind 32k ne Menge Code!
Aktuell halte ich den Link von Christian N.
(http://www2.keil.com/stmicroelectronics-stm32/mdk) zusammen mit dem
NUCLEO-F091RC
(http://de.farnell.com/stmicroelectronics/nucleo-f091rc/entw-board-stm32f091rc-stm32-nucleo/dp/2456785)
für das interessanteste Einstiegskits.
Der Compiler ist zwar auf STM32F0 und STM32L0 eingeschränkt, hat aber
nicht das übliche Codesize Limit (16kB Cortex M0, 32kB Cortex M3/M4).
Das Board bringt neben der Debugschnittstelle über das gleiche USB Kabel
auch einen Virtuellen ComPort mit, so dass auch schon eine Schnittstelle
zum PC für die Applikation zur Verfügung steht.
Die vermisse ich bei dem STM32F407VGT6 DISCOVERY - dafür gibt's da die
wohl leistungsfähigste CPU im ganz unteren Preissegment Ich hab' das
Teil schon zusammen mit den Codesize limitierten Compilern von IAR und
Keil betrieben, hat prima geklappt.
Von Atmel gibt's mit dem Atmel Studio und dem SAM21D Xplained Pro ein
Kit, das zu einem etwas höheren Preis ähnliches bietet (also auch Debug
Interface und Virtuellen ComPort über USB Kabel), rate aber für ein
flüssiges Arbeiten mit dem Atmel Studio zu einem schnellen Rechner - auf
jeden Fall 64bit OS, ansonsten viel Speicher (8GB) und einen i5 oder i7
Prozessor.
Derartigen günstige Lösungen sind eigentlich immer auf einen bestimmten
Hersteller beschränkt - würde dennoch mit sowas anfangen.
Auch mir schweb' langfristig was "allgemeines" vor, etwa
http://www.coocox.org/ (wenn möglich in Verbindung mit einem schon
vorhandenen ULINK2), gehe aber davon aus, dass es da an der einen oder
anderen Ecke heftig kneift und zwickt :-)
Discovery-Boards von ST, z.B. STM32F4Discovery + CooCox IDE sind sehr
gut für den Einstieg
Den JLink gibt es auch als educational Version (nicht kommerziell) für
50 Euro.
Eines der günstigsten Einstiege ist der STM32F4Discovery mit CooCox IDE.
Kosten 12..20 EUR.
Das Demoboard ist mit Debugger/Programmieradapter.
Lese mehr dazu in diesem Artikel:
STM32 für Einsteiger
Hier sind die ersten Schritte mit der kostenlosen CooCox IDE
beschrieben:
STM32 CooCox Installation
- Installation
- Erstes Projekt "BlinkLED"
- Debuggen
Für später, wenn man mehr machen möchte:
Auf der CooCox IDE Webseite gibt es die Infos welche Programmieradapter
alle unterstützt werden. Der J-LINK von Segger unterstützt am meisten µC
von verschiedenen Herstellern und ist zudem auch sehr schnell.
Das wird für den ersten Einstieg jedoch noch nicht benötigt, da reicht
das STM32F4Discovery vollkommen aus.
Jay schrieb:> Ehrlich gesagt, ob ST, NXP, TI, Atmel ist völlig egal. Jeder ARM dieser> (und anderer) Hersteller hat ausreichend viele Features um dich lange zu> beschäftigen.
Das ist eine Aussage, die mir weiter hilft. Das bedeutet nämlich, das
ich tatsächlich das erste Board nach Features aussuchen kann. Und mir
dann evtl. einen extra Programmer irgendwann zu lege, sollte der auf dem
Board integrierte nicht mehr reichen.
Random ... schrieb:> Für den günstigen (kostenlosen) Einstieg empfehle ich ein ST Discovery> Kit (da ist ein ST Link drauf, der vernünftig SWO kann) und die MDK-ARM> Demo.U.G. L. schrieb:> Derartigen günstige Lösungen sind eigentlich immer auf einen bestimmten> Hersteller beschränkt - würde dennoch mit sowas anfangen.>> Auch mir schweb' langfristig was "allgemeines" vor, etwa> http://www.coocox.org/ (wenn möglich in Verbindung mit einem schon> vorhandenen ULINK2), gehe aber davon aus, dass es da an der einen oder> anderen Ecke heftig kneift und zwickt :-)
Also kann ein ST Link nur ST's programmieren. Aber nachdem ich mir erst
irgendwann einen universellen Programmer zu legen werde, hab ich kein
Problem damit. Zumal ich ich dann ja mit dem ersten Dev-Board u.U.
andere Boards flashen könnte und damit nicht so schnell ein reiner
Programmer notwendig wird.
Und zum uLink2: ich dachte eben der sei das Referenz-Tool, weil er eben
von Keil/ARM kommt. Naja mal sehen was nach dem Dev-Board kommt.
Ihr habt mir hier ja eine Menge an schönen Start-Boards genannt, was es
wird weiß ich noch nicht, da drüber muss ich noch mal schlafen. Danke
für die vielen Tipps und Antworten!
Grüße
Michael
Die neuen Samd11 xplain Mini gibt's inkl. Debugger/Programmer für
8.88usd. Dazu noch Platz auf der Platine im Lochrasterformat um etwas
eigenes draufzulöten.
Und atmel Studio mit vielen Beispielen und Compiler ohne
Einschränkungen. Aber zurück zur ersten Frage. Ich hab von einem Atmel
MA auf der embedded mitbekommen dass der sama5 bare-metal support im
neuen atmel Studio bekommt. Wann exakt konnte er mir leider nicht
sagen,nur soviel dass es noch vor Sommer sein soll.
Random ... schrieb:> OPV 007 schrieb:>> DAS Referenztool in der ARM Welt ist aber eher der J-Link von Segger>> Unterschreibe ich nicht, ich entwickle mit dem ULINK pro wg. Streaming> Trace :-)
Gibts bei Segger auch, heisst dort J-Scope.
Michael W. schrieb:> Also kann ein ST Link nur ST's programmieren.
Das wird vermutlich immer so sein, auch wenn es u.U. technisch möglich
wäre, mit dem Debug/Programming-Interface der einen Firma auch die
Prozessoren einer anderen Firma zu unterstützen - schließlich wird ein
SGS-Thomson niemand abstellen, um den Programming-Support für
Atmel-Prozessoren in den ST-Link-Treiber einzubauen :-)
> Und zum uLink2: ich dachte eben der sei das Referenz-Tool, weil er eben> von Keil/ARM kommt. Naja mal sehen was nach dem Dev-Board kommt.
kann gut sein, ich hab' diesbezüglich noch keine Recherchen angestellt -
allerdings hab' ich mich mit dem Ulink2 vertan, es ist ein UlinkPro, den
ich hier liegen habe - und weil der zu den eher teureren Debuggern
zählt, also vergleichsweise selten im Einsatz sein wird, vermute ich,
dass dessen Support nicht an erster Stelle stehen wird (natürlich
abgesehen von Keil).
Den UlinkPro würde ich nicht als DIE Referenz ansehen, eher den J-LINK
von Segger. Weil J-LINK wird von nahezu allen IDE's unterstützt und
nicht nur von Keil. Läuft auch sogar unter Linux und MacOS.
Der UlinkPro und der IAR-Link hingegen werden nicht von so vielen IDE's
unterstützt.
Markus Müller schrieb:> Den UlinkPro würde ich nicht als DIE Referenz ansehen, eher den J-LINK> von Segger. Weil J-LINK wird von nahezu allen IDE's unterstützt und> nicht nur von Keil. Läuft auch sogar unter Linux und MacOS.> Der UlinkPro und der IAR-Link hingegen werden nicht von so vielen IDE's> unterstützt.
Ist was dran, nur: Wozu brauche ich viele andere IDEs, wenn ich alles
aus einem Guss nutzen kann? :-)
Für mein Projekt "NetLase LC" (falls das einer kennt) war für mich ein
wichtiger Punkt, nicht alles aus verschiedenen Quellen zusammensammeln
und -basteln zu müssen (oder zu können).
Random ... schrieb:> Ist was dran, nur: Wozu brauche ich viele andere IDEs
z.B. wenn man Firmwareentwickler für fremde Firmen ist, dann schreiben
die vor welche IDE die denn gerne hätten. Dann ist man mit einem J-LINK
besser bedient.
Oder wenn man auch mal CoIDE oder EM:BLOCKS oder sonst was mal probieren
möchte, schließlich werden die auch weiter entwickelt und erhalten mehr
Features und werden immer komfortabler in der Benutzung.
Derzeit muss ich mit Keil arbeiten, ich mag den nicht so, Eclipse
gefällt mir da besser. (aber das ist Geschmackssache, auch Keil bietet
in Bereichen Vorteile gegenüber Eclipse, die absolut Perfekte IDE gibt
es wohl nie)
Random ... schrieb:> Für mein Projekt "NetLase LC" (falls das einer kennt) war für mich ein> wichtiger Punkt, nicht alles aus verschiedenen Quellen zusammensammeln> und -basteln zu müssen (oder zu können).
Bei mir ist es genau umgekehrt: Für mich ist es ein wichtiger Punkt eben
gerade nicht von einem einzigen Anbieter und dessen proprietären Tools
abhängig zu sein, so daß es möglichst einfach ist den Code auch in 10
Jahren noch und ganz ohne irgendwelche Spezialsoftware zu kompilieren.
Michael W. schrieb:> Es gibt ja wahnsinnig viele Entwicklungsboards die recht> studentenfreundlich bepreist sind, meistens von ST oder NXP direkt. Was> soll ich da nehmen?>> Wichtig ist mir, dass da im Gegensatz zum HC08's auch was halbwegs> freies (open source) zum Programmieren verwendbar ist, damit wenigstens> die Chance besteht, ohne größere Komplikationen auch noch in ein paar> Jahren die Hardware verwenden zu können.
Nanana.. SOOO viele Entwicklungsboards gibt es ja nun auch nicht.
Ich frage mich (und hiermit DICH), was du denn nun eigentlich tun
willst?
Also, hast du irgendwelche Projekte, die du durchzehen willst?
Oder willst du bloß in irgend einer IDE herumstochern und dir die Demos
angucken?
Dein komischer Ansatz (Wichtig ist mir, dass..), daß die benötigten
Tools gefälligst Open source sein sollen, sagt mir, daß du es eigentlich
überhaupt nicht wirklich ernst meinst und tatsächlich nur in einer IDE
zu daddeln beabsichtigst.
es gibt sowohl vom Keil als auch vom IAR jeweils freie Versionen, die
i.allg. einfach nur per Linker auf 32K oder so codebegrenzt sind.
Ausnahme dürfte ab jetzt ST mit seinen M0 sein, wo es nach aktueller
Info dafür einen speziellen codeUNbegrenzten Keil gibt. Aber bevor hier
jemand dazwischenruft sage ich: Mach mit deinen Anfangsprojekten erst
mal 32 K voll und dann reden wir weiter.
Also: Wenn dein studentischer Geldbeutel arg klein ist, dann empfehle
ich dir, den relativ teuren Weg über IDE+JTAG/SWD erstmal bleiben zu
lassen. Der m.E. einzige wirklich sinnvolle Weg wäre, sich einen
JLink-Edu zuzulegen. Natürlich gibt es auch einige Eval-Boards mit
eingebautem Programmier/Debug-Port wie z.B. ST-Link NU-Link und
Konsorten. Aber bei sowas bist du festgelegt.
Weitaus billiger ist es allerdings, sich einen Chip mit residentem
Bootlader herauszusuchen, der per COM-Port oder per USB direkt
programmierbar ist. Also schau auf den Herstellerseiten nach so etwas.
M.W. sind NXP und ST so ziemlich die einzigen, wo man solchen Komfort
kriegt. Bei solcher Lösung braucht man lediglich einen seriellen Port
(entweder naturell oder über USB) und die passende Programmier-App - bei
direkten USB-Ladern nicht mal dies, da erscheint der Bootlader am PC als
Massenspeicher, auf den man die Firmware nur draufkopiert.
Michael W. schrieb:> damit wenigstens> die Chance besteht, ohne größere Komplikationen auch noch in ein paar> Jahren die Hardware verwenden zu können.
Genau DAS halte ich für ausgemachten Quatsch. Wenn man ein wirkliches
Projekt hat, würde man eher den µC vom Evalboard ablöten und auf sein
zum Projekt passendes selbergestricktes Board drauflöten als das olle
Evalboard weiterhin zu benutzen. Und in ein paar Jahren bist du im Beruf
(sofern du was taugst) und kannst dir Eigenentwürfe mit den dann
aktuellen Chips sowohl pekuniär leisten als auch inhaltlich können.
W.S.
W.S. schrieb:> Dein komischer Ansatz (Wichtig ist mir, dass..), daß die benötigten> Tools gefälligst Open source sein sollen, sagt mir, daß du es eigentlich> überhaupt nicht wirklich ernst meinst
Ganz im Gegenteil. Darauf legt man Wert gerade wenn man es ernst meint.
Bernd K. schrieb:> so daß es möglichst einfach ist den Code auch in 10> Jahren noch und ganz ohne irgendwelche Spezialsoftware zu kompilieren.
Hihihi.. so ganz ohne Spezialsoftware? also programmierst du deine
Cortexe dann mit Open office oder was?
nee, von Anfang an ist IMMER Spezialsoftware für sowas vonnöten, nämlich
Compiler und seine Lib's, Linker, Assembler und ggf. das genau passende
JTAG-Geschirre.
Langsam ist es genug mit dem Getrolle...
W.S.
W.S. schrieb:> Langsam ist es genug mit dem Getrolle...
Yep, dann hör doch auf damit.
GCC gibt's auf jeden Fall schon länger als Openoffice, und auch
OpenOCD gibt es schon so lange, wie Keil beispielsweise zu ARM
gehört.
Ich hoffe ich trete damit keinen auf den Schlips, aber gibt es irgendwo
eine Auflistung von ARM Herstellern, wo gezeigt wird, was sie besonders
gut können oder gar nur sie können??
Also Beispielsweise: Hersteller A ist der einzige, der ARMs mit 16bit
DACs herstellt, Hersteller B ist dafür bekannt, besonders sparsame ARMs
zu bauen, Hersteller C ist dafür unschlagbar billig. Geschweige denn von
Hersteller D, der als einziger ARMs mit 2 CANs und USB macht...
Ich mein, nen ARM haben se alle, ADC, genug RAM und ROM gibts auch
immer... interessant wären die Unterschiede. Und irgendwas muss ja
anders sein, da ja bei gleichen Eigenschaften der billigere überlebt und
der andere nicht. Genug Hersteller gibt es ja...
Es wurden doch schon viele Herstellern erwähnt und bei jedem gibt es
unterschiedliche Ausführung von ihren Produkten. Oder allg.
http://de.m.wikipedia.org/wiki/ARM_Cortex-M
Christian N. schrieb:
[schnipp]
Und inwiefern soll das eine Antwort auf die gestellte Frage sein? Es
geht doch gerade nicht um die Gemeinsamkeiten, die alle ARMs gemeinsam
haben, sondern um die Unterschiede
Michael Skropski schrieb:> gibt es irgendwo eine Auflistung von ARM Herstellern, wo gezeigt wird,> was sie besonders gut können oder gar nur sie können??
Die wäre wohl übermorgen schon wieder veraltet, da natürlich Hersteller
B schnellstmöglich versuchen wird, den Rückstand gegenüber A
aufzuholen.
Da wirst du wohl oder übel jedesmal selbst vergleichen müssen.
Michael Skropski schrieb:> Ich mein, nen ARM haben se alle, ADC, genug RAM und ROM gibts auch> immer... interessant wären die Unterschiede. Und irgendwas muss ja> anders sein, da ja bei gleichen Eigenschaften der billigere überlebt und> der andere nicht. Genug Hersteller gibt es ja...
Ich hatte mich vor vielen Jahren, als es nur den STM32F1xx gab, für den
STM32 entschieden, da der:
- enorm viel Peripherie Einheiten drin hat
- sehr viele Variationen an Gehäusen, auch kleine Gehäuse mit großer CPU
Mit dem STM32F4xx gibt es bis zu 8 UARTs und sehr viele Timer, das
benötigt man zwar nicht immer, jedoch ist da so viel drin dass man damit
so ziemlich alles erschlagen kann. Beim LPCxxxx ist die Auswahl zwar
auch enorm groß, aber nicht ganz so Umfangreich wie beim STM32.
Schlussendlich sollte man entscheiden zwischen NXP (LPC) und ST (STM32),
damit man eine Linie nutzt.
Datenblätter laden und lesen, die Hersteller bieten Auswahltabellen mit
den Features, Verfügbarkeit bei den bekannten Lieferanten prüfen,
Erratas lesen, Compiler heraussuchen und schauen welche µC er
unterstützt, Preise vergleichen.
Danach sollte einem die Auswahl leichter fallen.
Diese Aufgabe kein einem keiner hier aus dem Forum abnehmen.
Manchmal sind auch Sonderfeatures interessant wie z.B. "Random Number
Generator" oder "Unique Serial Number" oder "Crypto Einheiten" oder die
Aufteilung der RAM Bänke damit mehrere DMA's gleichzeitig arbeiten
können oder SDRAM Interface oder ...
Was der STM32 so alles kann ist im Artikel STM32 aufgelistet.
Markus Müller schrieb:> Schlussendlich sollte man entscheiden zwischen NXP (LPC) und ST (STM32),> damit man eine Linie nutzt.
Warum bitte willst du den geneigten Leser schon wieder nur auf zwei
der vielen Hersteller einengen?
Dass du großer STM-Fan bist, ist bekannt, aber bitte überlass es doch
den anderen, ihre Entscheidungen selbst zu treffen. Da führt nun
mal nach Lage der Dinge nichts um einen eigenhändischen Vergleich,
denn alle anderen, die man fragt, sind (sofern sie nicht gerade in
der gleichen Situation sind und gerade anfangen) zwangsläufig in
irgendeiner Richtung voreingenommen.
Tatsache ist, dass sich praktisch vierteljährlich die Situation immer
wieder verschiebt, denn kein Hersteller kann es sich leisten, längere
Zeit hinterher zu hängen.
Jörg Wunsch schrieb:> Warum bitte willst du den geneigten Leser schon wieder nur auf zwei> der vielen Hersteller einengen?
Wieso das?
Markus Müller schrieb:> Datenblätter laden und lesen <snip>> Diese Aufgabe kein einem keiner hier aus dem Forum abnehmen.
Wieso darf ich nicht schreiben dass ich mich damals nach ausgiebiger
Recherche für den STM32 entschieden habe?
Michael W. schrieb:> Also kann ein ST Link nur ST's programmieren.
Nicht ganz, mit OpenOCD kann man beliebige ARM-MCUs nutzen. Und OpenOCD
unterstützt fast alles, was auf dem Markt ist.
Axel Schwenke schrieb:> Christian N. schrieb:> [schnipp]>> Und inwiefern soll das eine Antwort auf die gestellte Frage sein? Es> geht doch gerade nicht um die Gemeinsamkeiten, die alle ARMs gemeinsam> haben, sondern um die *Unterschiede*
Die Unterschiede, die jeweiliger Hersteller hat, findet man deren Seite.
Zu mindestens habe ich bis jetzt noch keine Datenbank gesehen, die
solcher Vergleich bietet, geschweige den pflegt.
=================================================================
Wenn ich mich jetzt bei Google (YouTube) umschauen, dann sehe ich, dass
es ziemlich viele Beispiele mit ST Boards gibt (vor allem F4 Discovery)
und allg. ist ST ziemlich aggressiv bei der Preisgestaltung. Deswegen
wohl oder übel werden manche zu Fan von ST, ob das schlimm ist, ist
dahin gestellt.
Jörg Wunsch schrieb:> Warum bitte willst du den geneigten Leser schon wieder nur auf zwei> der vielen Hersteller einengen?
Finde ich jetzt aber auch nicht falsch. Für den Hobbybereich sind nunmal
vor allem die zwei Interessant.
Bei den 8-Bittern wurde und wird auch immer Atmel oder PIC empfohlen und
es stört sich niemand daran.
Wer das ganze für den professionellen gebrauch evaluieren möchte, wird
wohl kaum hier im Forum um Rat fragen, bzw. schon die Frage anderst
stellen.
operator schrieb:> Für den Hobbybereich sind nunmal vor allem die zwei Interessant.
Sehe ich nicht so, aber ich bin natürlich zugegebenermaßen ebenfalls
voreingenommen.
Wenn ich das Rad der Zeit zurückdrehen könnte, würde ich mit Freescale
anfangen. Und nicht mit ST. Bin zwar mit ST alles andere als
unglücklich; aber wenn ich so über den Zaun gucke, scheint mir das Gras
bei Freescale doch etwas grüner zu sein. Insbesondere deren ADCs ...
seufz.
operator schrieb:> Finde ich jetzt aber auch nicht falsch. Für den Hobbybereich sind nunmal> vor allem die zwei Interessant.
Wieso sollte das so sein? Es gibt keinen Grund, warum zum Beispiel TI
weniger interessant oder weniger geeignet sein soll. Die tun sich
ehrlich gesagt alle nix. Alle genannten Boards sind erhältlich,
sau-preiswert, kommen mit uCs mit einer Unmenge an Features.
Kann sein, dass mir die nachzügler entgangen sind, aber von Cypress,
Infineon, Atmel, etc. finde ich kaum Boards auf den Chinamärkten. Auch
einzelchips zu vernünftigen Preisen zu finden empfinde ich als
schwierig. Ganz zu schweigen von OpenSource Projekten oder Foren wo man
sich Hilfe holen könnte, ebenso Tutorials.
Sollte nicht der Weg das Ziel sein, so holt man sich etwas, das schon
verbreitet ist.
Und zu TI - keine Worte.
Musste vor einem Jahr Cortex-M evaluieren und habe mir auch TI
angeschaut:
http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/overview.page
Die Stellaris Reihe taucht schon gar nicht mehr auf...
Entweder übersehe ich krass etwas bei TI, oder die haben wirklich nicht
allzuviel. (sehe nur die TM4C welche interessant sein könnte (Hercules
mal weggelassen))
Cortex-A sind sie aber ziemlich stark.
operator schrieb:> finde ich kaum Boards auf den Chinamärkten
Naja, wenn das das einzige Kriterium ist …
> Auch einzelchips zu vernünftigen Preisen zu finden empfinde ich als> schwierig.
Es gibt hier im Markt-Forum eine regelmäßige Sammelbestellung bei
Mouser, da bekommt man sowas recht problemlos.
operator schrieb:> Nein ist es nicht, aber wenn du nur den Teil herauszitieren möchtest,> der deine These unterstützt: nur zu.
Ich habe mir zwei deiner drei Argumente genommen, wobei ich das
genannte das abstruseste fand, da die Hersteller allerorten viele
preiswerte Devboards selbst anbieten. Ja, die sind vielleicht ein
paar Euro teurer als chinesische Nachbauten, aber sofern das Budget
nicht gerade nur das Taschengeld eines Grundschülers ist, sollten sie
alle unter „preiswert“ rangieren.
Was deine Bemerkung zu den Cortex-M von TI angeht, kann ich mir kein
Urteil bilden. Die Website könnte sicher etwas übersichtlicher sein,
da gebe ich dir recht (dass man die ARMs unter “Performance MCUs”
suchen muss, da muss man schon einen Moment nachdenken).
Jörg Wunsch schrieb:> Warum bitte willst du den geneigten Leser schon wieder nur auf zwei> der vielen Hersteller einengen?
Oh du MODERATOR!
Ich will hier zwar nicht in das Horn von Markus tröten, aber eines muß
mal deutlich gesagt sein: NXP und ST sind so ziemlich die Einzigen, von
denen man ARM-Chips ohne große Umstände bekommt. Das ist nicht nur für
Bastler wichtig, sondern eben auch für unsereinen als Industriekunden.
Bei allen anderen mir bekannten Herstellern sieht das wesentlich
klemmiger aus. Entweder Muster von Distri unter Angabe des
Entwicklungsprojektes (!!!) und zu erwartenden Stückzahlen - oder eben
nur trayweise.
Und noch etwas: sowohl die Chips als auch deren Doku von den beiden
obengenannten finde ICH rundweg gut.
W.S.
Auch als Hobby Bastler ist einem wichtig dass ein µC über sehr viele
Jahre verfügbar ist. Bestes Beispiel ist der ATMega - eben weil es den
so lange gibt, gibt es auch eine große Fangemeinde und Comunity.
Kleine Firmen wie Stellaris werden von großen geschluckt (TI) und dann
einfach eingestampft. Oder andere Firmen könnten unrentable
Firmenbereiche abstoßen und verkaufen (z.B. µC Fertigung, z.B. Atmel
hatte das mit den DataFlash auch gemacht).
Das Risiko ist bei ST und NXP äußerst gering dass die von anderen
aufgekauft oder ausgelagert werden.
Als Hobbyist ist mir das auch wichtig. Ich will auch 10 Jahre Garantie
haben - die ich wohl niemals von einem Distri zugesagt bekommen bei den
wenigen Stückzahlen. Also ist der einzige Weg große Firmen heraus zu
suchen bei denen der µC Zweig ein Haupt Standbein ist.
Bei den Gecko oder Analog µC wäre ich mir da nicht sicher, die sind
einfach zu klein. Freescale ist eher für Großkunden weniger Hobby
geeignet.
(nur um mal auch dieses eine Kriterium zu beleuchten)
W.S. schrieb:> ziemlich die Einzigen, von denen man ARM-Chips ohne große Umstände> bekommt
Naja, jetzt können wir völlig aufhören zu reden. Vermutlich leben
wir beide auf völlig anderen Planeten, anders ist deine Aussage nicht zu
erklären.
> Oh du MODERATOR!
Was hat das überhaupt damit zu tun? Moderatoren müssen nicht
allwissend sein.
Markus Müller schrieb:> Das Risiko ist bei ST und NXP äußerst gering dass die von anderen> aufgekauft oder ausgelagert werden.> Als Hobbyist ist mir das auch wichtig. Ich will auch 10 Jahre Garantie> haben - die ich wohl niemals von einem Distri zugesagt bekommen bei den> wenigen Stückzahlen. Also ist der einzige Weg große Firmen heraus zu> suchen bei denen der µC Zweig ein Haupt Standbein ist.> Bei den Gecko oder Analog µC wäre ich mir da nicht sicher, die sind> einfach zu klein. Freescale ist eher für Großkunden weniger Hobby> geeignet.
Muss ich zustimmen. ST und NXP scheinen derzeit die besten im Geschäft
zu sein. Die haben beide ein großes Portfolio (viele Chips für
untershiedliche Zwecke, viele Packages), das sieht meiner Recherche nach
bei TI z.B. relativ klein aus. Bei Infinion hab ich auch mehr das
Gefühl, das richtet sich an Großkunden.
Der Doku nach tendiere ich momentan zu einen STM32F4, welchem weiß ich
aber noch nicht. Wobei die Doku von TI sich auch gut lesen lässt.
Produkte können immer aufgegeben werden. Firmen werden ver- oder
aufgekauft, da gegen kann man nichts machen. Aber das ST, NXP oder TI
aufgekauft werden, glaube ich, passiert nicht so schnell.
Grüße
Michael
Michael W. schrieb:> Der Doku nach tendiere ich momentan zu einen STM32F4, welchem weiß ich> aber noch nicht. Wobei die Doku von TI sich auch gut lesen lässt.
Nimm ihn :-) Kann man schöne Sachen mit machen, zb Texteditor bauen.
https://www.youtube.com/watch?v=0KfbD7rJqQA
U.G. L. schrieb:> "Upgrade to TM4C12x MCUs
Damit bekräftigst du doch gerade, dass TI einfach die LM3S Reihe
eingestellt hat und nun den Wechsel auf TM4C erzwingt.
Was die Verfügbarkeit der Chips angeht, da ist vermutlich vor allem auch
die Anzahl der Breakoutboards gemeint, wo man nicht gleich ein eigenes
Board Layouten muss. Wie gesagt geht es hier um den Hobbybereich.
Markus Müller schrieb:> Das Risiko ist bei ST und NXP äußerst gering dass die von anderen> aufgekauft oder ausgelagert werden.
In diesem Geschäft ist doch alles möglich. NXP hat (wird?) Freescale
übernommen. Und besonders ST war noch vor den Cortex-M eher klein.
operator schrieb:> In diesem Geschäft ist doch alles möglich. NXP hat (wird?) Freescale> übernommen.
Ich dachte, dir kaufen nur die Kinetis-Reihe!? Die haben ja noch andere
uCs und auch noch was außer uCs..
Markus Müller schrieb:> Freescale ist eher für Großkunden weniger Hobby> geeignet.
Warum?
Es gibt zum Beispiel den MKL05 bei Conrad:
http://www.conrad.com/ce/de/product/1183445/Embedded-Mikrocontroller-MKL05Z32VLF4-LQFP-48-Freescale-Semiconductor
für 3 Euronen, der ist sehr angenehm zu programmieren, hat ein
bastlerfreundliches Package, übersichtliche Peripherie, exzellentes
Datenblatt, freie Toolchain und IDE existieren, Demoboard von Freescale
gibts ebenfalls spottbilig, er ist nur marginal komplizierter als ein
großer ATMega, dafür nur halb so teuer und doppelt so leistungsfähig.
Sehr empfehlenswert.
Bernd K. schrieb:> Es gibt zum Beispiel den MKL05 bei Conrad:> bastlerfreundliches Package
32/48 Pin LQFP? Da gibts bastler-freundlicheres...
> doppelt so leistungsfähig
Leistungsmäßig völlig überdimensioniert.
Wobei man natürlich auch das locker in Hochsprache verbraten bekommt.
Und aller möglicher zu konfigurierender Krempel inside, aber nur 1 UART.
> nur marginal komplizierter als ein großer ATMegaARM und nur marginal komplizierter... Aber sicher doch:
http://www.freescale.com/files/32bit/doc/ref_manual/KL05P48M48SF1RM.pdf
Nee nee, da zahlt man lieber etwas mehr und hats hinterher etwas
einfacher ;-)
Lothar schrieb:> gibt es vergleichbares auch in DIP oder SO
Sicher, es gibt dieses nette Merkmal hier und jenes dort,
nur eben nicht alle schönen in Kombination- so wie beim einfachen,
universellen, in weitem Versorgungs-Spannungsbereich verwendbaren AVR.
Und
Lothar schrieb:> nicht mehr so lange> existieren
wird AVR jedenfalls ... auch nicht!
Lothar schrieb:> um anderen dürfte> der MKL05 nach der Übernahme von Freescale durch NXP nicht mehr so lange> existieren.
Das ist reine Spekulation. Ich persönlich glaube eher nicht daß die
Kinetis Reihe eingestellt wird.
Aber es ging ja in dem Post auf das ich geantwortet habe darum daß ohne
Begründung behauptet wurde Freescale sei nicht für Bastler geeignet, das
ist Unsinn, die kleinen Kinetis sind weder teuer noch irgendwie
komplizierter, eher einfacher als so manch anderer ARM und auch nicht
schwerer zu beschaffen oder teurer und die üblichen Toolchains, die
kommerziellen wie auch die freien funktionieren hier kein bisschen
schlechter oder anders als bei STM oder NXP.
Und die Datenblätter sind erste Sahne in Puncto Kompaktheit,
Übersichtlichkeit, Strukturiertheit und Vollständigkeit, besser noch als
bei STM32.
Moby AVR schrieb im Beitrag #4060655:
> Lothar schrieb:>> nicht mehr so lange existieren>> wird AVR jedenfalls ... auch nicht!AVR wird nicht mehr so lange existieren ? Das wäre mal eine gute
Nachricht :-)
Moby AVR schrieb im Beitrag #4060655:
> in weitem Versorgungs-Spannungsbereich verwendbaren AVR
Dafür nimmt die Industrie lieber 8051 wie z.B.
http://www.silabs.com/products/mcu/8-bit/efm8-busy-bee/Pages/efm8-busy-bee.aspx
Moby AVR schrieb im Beitrag #4060549:
>> doppelt so leistungsfähig>> Leistungsmäßig völlig überdimensioniert.
Du kennst natürlich alle möglichen Projekte eines Bastlers, weshalb du
diese Schlussfolgerung ziehst...
Wer nur LEDs blinken lässt braucht keinen ARM, aber auch keinen AVR.
Moby AVR schrieb im Beitrag #4060549:
> Wobei man natürlich auch das locker in Hochsprache verbraten bekommt.
Ist ja nicht das Erste Mal, dass du deine Unkenntnis unter Beweis
stellst.
Moby schrieb im Beitrag #4060764:
> Das zeugt jetzt inwiefern von Unkenntnis?
Dass ein Hochsprach-Compiler in der Regel besseren Code abliefert
als ein Assembler-Anfänger. Bei RISC-CPUs sowieso.
Moby schrieb im Beitrag #4060764:
> Obiges verlinkte Datenblatt eines KL5 mit "marginal" fast doppeltem> Umfang eines Mega128ers ist in erster Linie kryptisch und völlig> unübersichtlich- jedenfalls dramatisch schlechter lesbar als alles das> was man vom AVR kennt.
Unfug. Wenn Du ein gut strukturiertes und übersichtliches Datenblatt wie
dieses als kryptisch empfindest dann wirst Du auch mit keinem anderen
Datenblatt zurecht kommen und auch generell mit
Mikrocontroller-Programmierung ziemlich überfordert sein.
Wahrscheinlich hast Du Dich aber keine einzige Sekunde lang damit
beschäftigt und willst nur trollen, wie üblich.
Wenn Du Dich mit irgendwas nicht beschäftigen willst dann ist das
natürlich vollkommen in Ordnung, zwingt Dich ja keiner, aber dann hör
wenigstens auch auf dauernd ungefragt irgendwelchen sinnlosen Bullshit
zu labern der Dir spontan durch den Kopf schießt über Dinge von denen Du
keine Ahnung hast (und erklärtermaßen gar keine Ahnung haben willst).
Jörg Wunsch schrieb:> Dass ein Hochsprach-Compiler in der Regel besseren Code abliefert als> ein Assembler-Anfänger. Bei RISC-CPUs sowieso.
Das mag ja sein, nur ändert das nichts daran, daß man in Hochsprache
seinen Controller generell schneller vollbekommt, als wenn man mit Asm
alle Fäden selber in der Hand behält (und das mit AVR immer noch
sinnvoll kann). Je höher der Abstraktionslevel, desto ineffizienter,
wenn nicht parallel hoher (Lern-) Aufwand zur Optimierung des Kompilats
getrieben wird. Sonst braucht es auch sehr schnell die 48 MHz eines KL5,
um ein paar LEDs blinken zu lassen ;-(
Der ARM Einstieg mag ja mittlerweile ein paar Cents weniger kosten, nur
zahlt man hinterher in der anderen Währung Zeit und Nerven doppelt und
dreifach drauf- und solls hinterher beruflich/professionell werden dann
doch noch viel Geld für entsprechende Tools. Billig und günstig sind
eben immer noch zwei paar Schuhe.
Bernd K. schrieb:> Unfug. Wenn Du ein gut strukturiertes und übersichtliches Datenblatt wie> dieses als kryptisch empfindest dann wirst Du auch mit keinem anderen> Datenblatt zurecht kommen und auch generell mit> Mikrocontroller-Programmierung ziemlich überfordert sein.
Da mach Dir mal keine Sorgen.
Möge die Dokumentation jeder selber vergleichen ;-)
> Wahrscheinlich hast Du Dich aber keine einzige Sekunde lang damit> beschäftigt und willst nur trollen, wie üblich.
Wenn man AVR Standard gewohnt ist langt schon ein kurzer Blick.
In der Tat.
Moby schrieb:> Der ARM Einstieg mag ja mittlerweile ein paar Cents weniger kosten, nur> zahlt man hinterher in der anderen Währung Zeit und Nerven doppelt und> dreifach drauf-
Du schreibst so (ein Neuling könnte den Eindruck gewinnen es wäre so)
als würdest Du aus den Nähkästchen plaudern und die gesammelte und
überlieferte Weisheit und Erfahrung aus mehr als 5 Jahrzehnten
wiedergeben.
Aber dem ist nicht so: Du hast noch nie was anderes gemacht als ein
bisschen LED blinken in Assembler auf irgendeinem AVR den Du vor 10
Jahren mal irgendwo gefunden hast, seither optimierst Du jeden Samstag
Nachmittag dieses Blinkprogramm.
> und solls hinterher beruflich/professionell werden
Du machst das nur hobbymäßig und hast von beruflichem und
professionellem Einsatz von Microcontrollern nicht die leiseste Ahnung.
Nicht die leiseste.
Moby schrieb:> daß man in Hochsprache seinen Controller generell schneller vollbekommt
Klar: so viel Lebenszeit, entsprechend viel Assemblercode zu schreiben,
hat man einfach gar nicht. :-))
Liebe Leute,
geht es hier nicht um ARM? Bitte beim Thema bleiben. Es gibt doch schon
genug Threads in denen ARM vs. AVR besprochen wird.
Ich finde man sollte solche Diskussionen in einem separaten Thread
führen.
:-)
Jörg Wunsch schrieb:> Moby schrieb:> daß man in Hochsprache seinen Controller generell schneller vollbekommt>> Klar: so viel Lebenszeit, entsprechend viel Assemblercode zu schreiben,> hat man einfach gar nicht. :-))
Die Betonung lag ja auch auf dem 'vollbekommt' ...
Ansonsten gilt wie überall: Übung und System macht den Meister.
Wenn man dann noch die Vorteile effizienten, schnellen Assemblers und
eines bastlerfreundlichen SimplyAVR mitnehmen kann, umso besser.
Moby schrieb:> Das mag ja sein, nur ändert das nichts daran, daß man in Hochsprache> seinen Controller generell schneller vollbekommt,
Verallgemeinerung. Wenn man Haar genau das Gleiche macht wie im ASM
Programm, dann ist da normalerweise nix größer, außer man lässt auf
Geschwindigkeit optimieren, dann wird das Programm selbstverständlich
größer, aber eben schneller.
Moby schrieb:> Je höher der Abstraktionslevel, desto ineffizienter,
Kann man so nicht sagen Beispiel C++ Templates, allerdings ist bei C und
Pascal das Abstraktionslevel so niedrig, das man schon von einem
Highlevel-Assembler sprechen kann. Dazu gibts bei den Sprachen auch
Werkzeuge, die das Verhalten genau Steuern lassen.
Moby schrieb:> wenn nicht parallel hoher (Lern-) Aufwand zur Optimierung des Kompilats
Heute so gut wie nicht nötig, Compiler sind so verdammt gut geworden,
Rechenleistung noch nie so billig und die µC noch nie so handlich
gewesen. Wer sich dann von der Maschine knechten lässt ist selber
Schuld, verschwendet Lebenszeit und Silizium.
Moby schrieb:> weniger kosten, nur> zahlt man hinterher in der anderen Währung Zeit und Nerven doppelt und
Passt bei Assembler wie die Faust aufs Auge, nur hier sind die Kosten
Laufzeitkosten.
Moby schrieb:> Sonst braucht es auch sehr schnell die 48 MHz eines KL5,> um ein paar LEDs blinken zu lassen ;-(
Darauf braucht man gar nicht einzugehen. Du hast halt keine Ahnung wovon
du da sprichst.
Moby schrieb:> Wenn man AVR Standard gewohnt ist langt schon ein kurzer Blick.> In der Tat.
Wenn man ARM Standard gewohnt ist langt schon ein kurzer Blick. In der
Tat.
Merkste jetzt was?
BTW wir kommen schon wieder dank Moby vom ursprünglichen Thema ab.
Bernd K. schrieb:> Moby schrieb:>> Der ARM Einstieg mag ja mittlerweile ein paar Cents weniger kosten, nur>> zahlt man hinterher in der anderen Währung Zeit und Nerven doppelt und>> dreifach drauf->> Du schreibst so (ein Neuling könnte den Eindruck gewinnen es wäre so)> als würdest Du aus den Nähkästchen plaudern und die gesammelte und> überlieferte Weisheit und Erfahrung aus mehr als 5 Jahrzehnten> wiedergeben.> ...> Aber dem ist nicht so: Du hast noch nie was anderes gemacht als ein> bisschen LED blinken in Assembler auf irgendeinem AVR den Du vor 10> Jahren mal irgendwo gefunden hast, seither optimierst Du jeden Samstag> Nachmittag dieses Blinkprogramm.> ...> Du machst das nur hobbymäßig und hast von beruflichem und> professionellem Einsatz von Microcontrollern nicht die leiseste Ahnung.> Nicht die leiseste.
Besser hätte man es nicht ausdrücken können.
Er hat weder die Datenblätter mehr als nur überflogen noch jemals mit
ARMs gearbeitet und schon gar nicht damit sein Geld verdient.
Dementsprechend sind dann auch die Einschätzungen zu bewerten.
Der Thread war wunderbar themenbezogen. Eine Suche nach "AVR" zeigt, wer
und ab wann sich das (mal wieder) änderte ...
Und jetzt bitte wieder zurück zum Thema: "Günstiger Anfang mit ARM".
Mediator schrieb:> Liebe Leute,>> geht es hier nicht um ARM? Bitte beim Thema bleiben. Es gibt doch schon> genug Threads in denen ARM vs. AVR besprochen wird.>> Ich finde man sollte solche Diskussionen in einem separaten Thread> führen.>> :-)
Genau so ist es.
Weitere Beiträge "ARM vs. AVR" werden ab jetzt gelöscht. Das gilt für
beide Seiten.
Ok, zurück zum Thema.
Hier mal als eine der zahlreichen möglichen Alternativen eine
Auflistung von Dingen die zusammen einen Einstieg ermöglichen mit
Einstiegskosten im 10€..20€-Bereich.
Hardware:
* Freescale FRDM-KL05Z
http://www.exp-tech.de/freescale-frdm-kl05z-arm-cortex-m0-development-board?gclid=CILytI2YucQCFebHtAodNmkAtg
Software:
* Eclipse CDT: https://eclipse.org/cdt/
* Eclipse GNUARM-Plugin incl. Toolchain:
http://gnuarmeclipse.livius.net/blog/ (dort gibts fertig zusammenpassend
und als bequeme Windows installer die Plugins, die Toolchain und die
Build-Tools (make & friends), den Debugger, alles dort herunterzuladen,
alles aus einem Guss und zusammenpassend.)
* Minimales Demo-Programm für das obige Board, IDE-agnostisch aber ohne
Änderung mit Eclipse nutzbar (siehe unten) :
https://github.com/0xc0170/kinetis_klxx_gcc
* Segger Firmware als Ersatz für den ansonsten untauglichen on-board
Programmer auf dem FRDM-Board, das emuliert einen vollwertigen J-Link
Adapter (vorsicht Suchtfaktor ;-) https://segger.com/opensda.html
* Segger Software für eben jenen, inclusive GDBServer (vor allem wegen
diesem): https://segger.com/jlink-software.html
---
So, die ganze obige Software fügt sich nahtlos ineinander, zum Beispiel
ist das GNUARM-Plugin bereits für den Segger J-Link vorbereitet, bietet
spezielle Unterstützung dafür an, umgekehrt ist der Segger speziell für
die Verwendung mit gdb bestens geeignet und empfohlen, es wird also
alles direkt zusammenpassen, da muss nichts mehr umständlich
zurechtgefrickelt werden. Es wird ohne Klimmzüge funktionieren.
In Eclipse kann man nun einfach hergehen und "import" -> "existing code
as makefile project", dann noch sicherstellen dass als Build Kommando
"make" eingestellt ist, dann kann man das Projekt schon bauen, und wenn
das Board angestöpselt ist kann man es auch mit ein paar Mausklicks
schon auf das Board laden und dort debuggen.
Der ganze Spaß kostet 11€ zzgl Versand.
Der nackte MKL05Z32 ist auch für eigene Projekte in etwas
bastlerfreundlicherem LQFP Package erhältlich, die Preise gehen von 1€
bis 3€ (Conrad Apotheke).
Für eigene Boards empfiehlt sich dann später die Anschaffung eines
Segger J-Link EDU (50€), diese Investition würde ich nicht scheuen, zwar
ist es auch möglich mit einfacheren Mitteln einen JTAG-Adapter zu
bekommen/bauen und mit Openocd anstelle von Segger zu verwenden (auch
hier volle Unterstützung in Eclipse), aber das ist eine Entscheidung die
Du auf später verschieben kannst, zunächst machtst Du Dich erstmal mit
dem Demo-Board vertraut, eigene Designs und damit einhergehende
Entscheidungen kommen dann später.
Bernd, danke für die detailierten Infos. Werde mal damit versuchen mich
in die Kinetis einzuarbeiten.
Wenn man sich in der STM32-Familie sehr gut ausgekennt, ist halt die
Hemmschwelle sehr gross, in eine andere Familie Zeit zu investieren.
Aber ein Versuch werde ich auf alle Faelle wagen.
Mehmet Kendi schrieb:> Wenn man sich in der STM32-Familie sehr gut ausgekennt, ist halt die> Hemmschwelle sehr gross, in eine andere Familie Zeit zu investieren.> Aber ein Versuch werde ich auf alle Faelle wagen.
Ich vermute das ist bei jedem Hersteller so. Stichwort: Gewohnheitstier.
Bei mir sollte demnächst ein STM32F429-Board eintrudeln - mal sehen, ob
ich dann auch Sehnsucht nach Freescale empfinde. Auch wenn die mich mit
dem HCS08 etwas verschreckt haben.
Ich möchte mich an der Stelle noch einmal für die Vorschläge bedanken.
Grüße
Michael
Michael W. schrieb:> Sehnsucht nach Freescale
Wurden die nicht von NXP geschluckt? Zwei parallel Reihen wird man sich
doch nicht leisten, oder? Wer wohl übrig bleibt?
unsicher schrieb:> Zwei parallel Reihen wird man sich> doch nicht leisten, oder?
Es wird voraussichtlich ne Weile lang parallel gehen, bei den
BlueStreaks war das ja auch so. Aber eines halte ich für recht
wahrscheinlich: daß nämlich die ganzen Kinetisse kräftig ausgedünnt
werden. Da gibt es einerseits viel zu viel Wildwuchs, viel zu viele
Familien, Unterfamilien, UnterUnter.. usw. und andererseits nicht eine
Familie, die nen residenten Bootlader hat. Sieht im Vergleich zu den
LPC's eher ärmlich aus.
Mein einstweiliger Rat: Erstmal Finger weg von den MKE-Typen, obwohl die
per Werbung erstmal nett aussehen und so ziemlich die einzigen sind, die
noch 5 Volt vertragen. Der Grund: die Zuordnung der Pins zu den
Funktionen ist bei der MKE-Reihe miserabel gestalten - fast hätte ich
'gelöst' geschrieben. Bin momentan grad beim MichGrünÄrgern über
selbige. Aber vielleicht liest hier einer mit, der die Dinger näher
kennt und dazu mal was postet.
Bei den MKL-Reihen sieht das lt. RefMan viel freundlicher aus: da gibt
es ne Reihe Register, wo man für jeden Pin schön separat dessen Funktion
einstellen kann. Hab's aber noch nicht selber ausprobiert.
Bernd K. schrieb:> Der nackte MKL05Z32 ist..
bei Conrad für 2.70 .. 2.95 erhältlich. Sieht m.E. ganz OK aus.
W.S.
Thread beobachten
Seitenaufteilung abschalten