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
:
Gesperrt durch Moderator
"ARM" anzufangen, das ist immer schwierig günstig hin zu bekommen.:-) SCNR
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.
:
Bearbeitet durch User
Zur Info: Bei ST Serien STM32F0 und STM32L0 kann man Keil ohne Code Einschränkung nutzen. http://www2.keil.com/stmicroelectronics-stm32/mdk
:
Bearbeitet durch User
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 | static int ftdi_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...
:
Bearbeitet durch User
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!
Vergess nicht Cypress PSOC3/4/5lp chips. Sehr billige devboards (zB CY8CKIT-049 fuer $4,- incuding ab-brechbarer USB)
"Günstig" = "minimal"? Die meisten (alle?) STM32Fxx haben einen fest eingebauten Bootloader. Damit kann man sie über eine serielle Schnittstelle flashen. Man braucht für diese Chips keinen SWD/JTAG/sonstwas-Programmieradapter, nur einen Downloader auf dem PC: https://www.google.de/?q=stm32+serial+bootloader Wer jede kleine Programmänderung sofort testen möchte: der Bootloader kann das Programm auch ins RAM laden und dort laufen lassen. Unter Debian reicht es, genau 2 Pakete zu installieren: https://packages.debian.org/jessie/binutils-arm-none-eabi https://packages.debian.org/jessie/gcc-arm-none-eabi optional: https://packages.debian.org/jessie/libnewlib-arm-none-eabi https://packages.debian.org/jessie/gdb-arm-none-eabi
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 :-)
:
Bearbeitet durch User
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.
Stefan schrieb: > Sorry falscher Thread mit dem a5 Wollt ich auch gerade sagen, ist eine Hausnummer zu weit für den Anfang. ;-)
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).
:
Bearbeitet durch User
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.
Jörg Wunsch schrieb: > das einzige Kriterium Nein ist es nicht, aber wenn du nur den Teil herauszitieren möchtest, der deine These unterstützt: nur zu.
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.
operator schrieb: > 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. http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/c2000_performance/control_automation/stellaris_lm3s/overview.page "Upgrade to TM4C12x MCUs Find compatible parts to your Stellaris LM3S products in TI's TM4C12x portfolio here. Enter your LM3S part:" und hier: http://www.heise.de/make/meldung/TI-streicht-M3-Stellaris-1773693.html
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 ATMega ARM 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 ;-)
Bernd K. schrieb: > Es gibt zum Beispiel den MKL05 bei Conrad ... bastlerfreundliches Package Zum einen gibt es vergleichbares auch in DIP oder SO zum anderen dürfte der MKL05 nach der Übernahme von Freescale durch NXP nicht mehr so lange existieren. http://www.watterott.com/de/LPC1114FN28/102 http://de.farnell.com/nxp/lpc810m021fn8fp/mcu-32bit-cortex-m0-30mhz-8dip/dp/2320692?ost=lpc810 http://de.farnell.com/nxp/lpc812m101jd20/ic-mcu-32bit-cortex-m0-so20/dp/2295531
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.
:
Bearbeitet durch User
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).
Hi, ich unternehme auch gerade die ersten Schritte mit ARM. Hier mein Vorschlag: IDE: CooCox http://www.coocox.org/ JTAG: Olimex https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY-H/ Board: Olimex https://www.olimex.com/Products/ARM/ST/STM32-H107/ Funktioniert hervorragend. Danke.
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.
:
Bearbeitet durch Moderator
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? Wer wohl übrig bleibt? http://www.nxp.com/news/press-releases/2015/03/nxp-and-freescale-announce-40-billion-merger.html Fusion?
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