Wie fange ich am besten mit ARM an?

[playOvation]

Hi,

manchmal in Leben darf man sich aussuchen, wie die Projekte gesteuert werden (mittlerweile hab ich mich ja an die MSP430 gewöhnt...),
aber es passiert ab und zu auch, dass Vorgaben umgesetzt werden müssen. Und wegen einer solchen Vorgabe sollte ich mich so langsam
in die ARM-Welt einarbeiten. Doch da gibt es ja erstmal von jedem Hersteller mindestens eine Handvoll Baureihen mit unzähligen Typen,
woraus resultiert, dass ich da in etwa gar nicht durchblicke
Wikipedia sagt, der Kern sei immer der gleiche, also auch der Befehlssatz. Hört sich gut an, bringt mir in der Hinsicht auch schon etwas,
da ich nicht weiß, welcher Prozessor später eingesetzt wird.
Aber wie fange ich am besten damit an, dieses "allgemeine" Verständnis für die Architektur aufzubauen? Beim googeln pendle ich zwischen
"anwendungsorientiert", d.h. speziell auf einen Prozessor bezogen, und "allumfassend", d.h. vor lauter Bäumen...
Ist hier schonmal jemand durch dieses Tal geschritten und kann mir ein paar Tipps geben?

MfG

[hboy007]

Hi,

I'm glad you asked. Zu ARM möchte ich dir zunächst CMSIS vorstellen (Cortex-M Software Interface Standard) - hierdurch muss man nicht für jeden Hersteller neu kennenlernen, wie die CPU und die grundlegende Architektur funktioniert.

[ externes Bild ]

Für den Einsteiger handelt es sich hierbei zunächst mal um einen größeren Satz von defines, enum-Blöcken, Typendeklarationen und Grundfunktionen. Als Middleware bezeichnet man bei Atmel etwa ASF (Atmel Software Foundation), das sind vorgefertigte Pakete, die auf CMSIS aufsetzen und komplexere Funktionen wie etwa Unterstützung für LC-Displaycontroller implementieren oder herstellerspezifische Anteile des Microcontrollers (wie etwa die IO-Treiber und diverse peripherals abstrahieren.

Ich selbst arbeite intensiv mit Atmel SAM µCs, muss da aber immer wieder feststellen, dass die Community sich nicht viel von ASF wegtraut, wenngleich die Funktionen selbst zu implementieren oftmals genau so leicht wäre. Da gibt es eine gewisse Lücke zwischen der ausgiebigen Erklärung der low level - Funktionalität im Datenblatt und ASF. Letztlich wird das aber bei anderen Herstellern nicht viel anders sein.

Ebenso habe ich den Einsteig mit Keil und den Stellaris / Tiva launchpads von Ti versucht. Der Cortex-M4 Kern ist vom Geschmack her der gleiche, zu dem Zeitpunkt gab es durch die Einführung und Verbesserung von CMSIS sehr viel Verwirrung, die mich frustriert hat. Das mag heute anders sein, war aber seinerzeit ausschlaggebend dafür, dass ich nun effektiv mit Visual Studio + integrierter arm gcc toolchain (aka Atmel Studio 6/7) entwickle.

[playOvation]

Hi,

das ist etwas, worauf ich aufbauen kann. Da werde ich übernächste Woche gleich mal anfangen zu lesen.
Das heißt also wirklich, ich kann Code für den einen Prozessor entwickeln und, wenn dieser "nur" Basisfunktionen enthält,
direkt auf einem anderen Prozessor weiterverwenden, falls dies nötig sein sollte.

Du schreibst, die Entwicklung mit dem Visual Studio zu machen. Gibt es da irgendwelche Löcher, wenn man nicht die
IDEs der Hersteller nimmt? Aus reiner Überlegung fände ich das jedenfalls ziemlich praktisch,
zumal ich mir auch noch Visual Basic oder C++ aneignen sollte. Zwei in einem, wenn ich schon Windows entstaube
Da werde ich mir wahrscheinlich doch irgendein DevKit zum Basteln holen.

MfG und Danke für die Infos!

[hboy007]

Atmel bietet hierzu die XPlained Pro boards an, das sind effektiv breakout boards mit Beispielcode:
http://www.atmel.com/tools/SAM4S-XPLD.aspx

Atmel Studio ist eine Adaption von Visual Studio und die offizielle IDE. Du kannst dir auch
- Code Composer Studio (Ti)
- Code Red Suite (NXP)
- Keil Microvision (ARM allgemein)
- GNU ARM Eclipse

anschauen

[Spitzi]

Aus reiner Überlegung fände ich das jedenfalls ziemlich praktisch,
zumal ich mir auch noch Visual Basic oder C++ aneignen sollte. Zwei in einem, wenn ich schon Windows entstaube

An dieser Stelle möchte ich mal einhaken und dir einen Tipp geben: Die Programmierung der AVR / ARM Konsorten geschieht in den C/C++ Sprachen. Sicherlich, für schnelle Test-GUIs sind die .NET Sprachen wie Visual Basic / C# gut geeignet. Wenn du dir das schon anschauen willst, dann lern aber doch bitte C#. Syntaktisch eine Mischsprache aus Java und C++ sind viele Befehle / Sprachkonstrukte ähnlich wie in C++. Wenn man die Programmierdenkweise einmal raus hat gilt halt einfach: "Kennse eine kennse alle".
Beruflich muss bin ich allerdings darauf angewiesen auch mal Basic / Basic-Script Sachen zu programmieren, man kommt sich dann aber doch relativ doof vor, wenn man alle 2 Wochen mal nachschauen muss wie eine switch / case Struktur aufgebaut ist, weil man das vergessen hat. (Die bei Basic btw.: Select ... Case... heißt)

[playOvation]

hboy007, so langsam wird's was Das CCS von TI hab ich ja schon für meine MSP430 installiert (etwas, das ootb inkl. Hardware auf Linux funktioniert!),
aber die ARM-Sachen damals weggeklickt und vergessen... Danke für den Tipp, somit habe ich alles aus einer Hand Was will ich mehr?

Spitzi, keine Sorge, ich mach's "g'scheid" Für Mikrocontroller nehme ich seit meinem Neuanfang C und das soll im Großen und Ganzen so bleiben.
Also kein Basic mehr auf einem µC. Man kann sich das Leben auch selbst schwer machen
Ich muss mich aber etwas korrigieren:

(...) auch noch Visual Basic und C# aneignen (...)

Wie mir da C++ reingerutscht ist... Also beides. Und zwar, genau, für GUI-Sachen. Basic ist einfach und schnell, C# für die Notfälle, wenn es nicht anders geht

MfG

[Spitzi]

Gut, da gehen die Meinungen wohl auseinander, ich bin ja der Meinung das C# flotter geht. Aber sei es drum, dann hat sich das ja geklärt. Das schlimmste an der Basic Sprache ist meiner Meinung nach aber, das man kein Semikolon am Zeilenende macht, das ist so ein hart eingelernter Reflex für mich, das ich mir inzwischen ein Precompiler Macro gemacht habe, das mir die Semikolonata am Zeilenende weglöscht. (Regex FTW)