ARM-Beginn mit einem eigenen Board

Hallo liebe Gemeinde,

nachdem ich meine armen 8-bit-Mikrocontroller (AVR) mehrmals komplett voll bekommen habe (und das nicht nur auf den Speicher bezogen), habe ich einen Blick auf die 32-bit MCUs gewagt. Wegen der Preis-/Leistungsverhältnisse neige ich eher zu der ARM-Architektur. Habe die ersten Tests mit einem STM32F4-Discovery-Board gemacht und fand meinen Gefallen daran.

Nun möchte ich mir eine, für die nächsten paar Jährchen, aktuelle ARM-Ausrüstung, schaffen. Also auch ein eigenes Board. MCU: STM32F746. Von den Resourcen her wird es vollkommen für meine Zwecke ausreichen (wenn nicht mehr).

Jetzt kommen die typischen Anfängerfragen, also entschuldigt mich im Voraus :)

1) Frage nach Bibliotheken: Man kann das Ganze mit der Standard Peripheral Library (SPL) programmieren oder auch mit Hardware Abstraction Layer (HAL) unter STM32CubeMX. Oder auch ohne eine Zuhilfenahme von Bibliotheken etc. Meine ersten STM-Programmierversuche fanden mit SPL statt. Nun die Frage: Wird SPL künftig gänzlich von der HAL abgelöst? Müsste ich unter Umständen gleich mit HAL beginnen?

2) Programmer: Ich würde ganz gern den STM genauso einfach wie meinen AVR programmieren. Auf dem Discovery-Board ist bereits ein STLINK drauf, bei welchem man auf den SWD zugreifen kann. Den kann ich doch eigentlich auch für mein Board "abzapfen" oder? Oder müssten vorher die Leitungen zum, auf dem Discovery befindlichen, STM32F4 gekappt werden? Mir missfällt etwas, dass die Programmiergeräte im Handel irgendwie nur die häßliche 20-polige Schnittstelle haben :(
Außerdem habe ich gesehen, dass die STMs wohl einen integrierten Bootloader über UART haben. heißt es dann, dass ich ganz normal über FTDI232->USB den Mikrocontroller flashen kann?
Welches (Programmier-)Gerät verwendet ihr selbst? Welche IDE?

3) Hier keine Frage, aber ein Paar Links, die ich gefunden habe. Werden hoffentlich solchen Anfängern wie mir paar Fragen beantworten können (Zusätzlich zu den Foren-Wikis).
http://www.olliw.eu/2013/stm32-this-and-that/
http://diller-technologies.de/stm32.html

4) Im Gegensatz zu einem 8bit-AVR kann man hier nun vernünftig externe Speicherbausteine anbinden. Während ich beim ersten alle Speicherzellen direkt ansprechen musste - sieht der STM die Speicherplatzerweiterung also als eine logische Erweiterung an? Sprich: Wird dem RAM- und/oder Flashbaustein automatisch ein Adressbereich zugeteilt?

Das war es (erstmal) an Fragen. Wer ebenfalls Anfänger ist und Hilfe braucht, kann diesen Thread gerne ergänzen. Und alle erfahrenen Leute und Leute mit guten Ideen sind natürlich herzlich willlkommen :D

Grüße,
Nik

Hallo,

ich bin nicht der typische Bastler, der seine IC-Familie heiratet, sondern nur ein wenig mit mbed (dort unter anderem auch ST Nucleo) und Arduino (u.a. Teensy) unterwegs. Die spezifischen Dinge werden dann noch die richtigen Experten erzählen können.

zu 1) Da ST sich in den letzten Jahren sehr viel Mühe gemacht hat in der internen Implementierung von mbed alles auf CubeMX umzustellen, ist das wohl offiziell derzeit die angesagte Variante. Aber ich lese öfter Sachen von Leuten, die anders unterwegs sind. Daher ist es zumindest nicht alternativlos.

zu 2) ST-Link Programmer gibt es wohl am billigsten an jedem ST-Nucleo Board. Da ist das abbrechbare obere Viertel ein Programmer. Da man den, wie gesagt, entweder abbrechen oder Jumper ziehen muss, würde ich mal sagen: Du müsstest das Discovery auftrennen.
Ach ja: Meine "IDEs" sind mbed-cli (die Kommandozeilenversion für den eigenen PC) oder platformio.org, plus meist Notepad++ oder für größeres Visual Studio.

zu 4) Wenn ich von den Erfahrungen von mbed Board mit zusätzlichem Speicher ausgehe (dort aber LPC4088 ) würde ich nicht davon ausgehen, dass das mit externem Speicher vollautomatisch geht. Braucht wahrscheinlich entsprechende Bibliotheksunterstützung.

Ich hoffe, da ist was nützliches dabei. Weitere Infos würden mich auch interessieren.

Ok, das Thema scheint ja nicht sonderlich jemanden zu interessieren... Danke dir, Mxt, für die Informationen :)

Haben wenige im Forum damit zu tun oder ist es schon Ewigkeiten her, seitdem ihr damit begonnen habt? :D
Dann wird das wohl zu meinem Einstiegsthread, wo ich über meine Fortschritte berichten werde :)

Habe inzwischen zum Testen zwei Programmer, einmal ST-Link vom Discovery-Board und einmal ein Segger J-Link Lite. Beim ersten habe ich Zugriff auf SWD-Schnittstelle (sprich: geringerer Platzverbrauch durch die Programmierschnittstelle, ähnlich ISP bei AVR), beim zweiten 20-polige Buchse. Allerdings ist der J-Link sehr niedlich-klein gehalten, kann direkt auf die Platine gesteckt werden und wird gänzlich von Keil uVision5 unterstützt (s.Bild).
Genau, meine erste IDE wird vermutlich die Keil-Software werden, vom Aufbau ähnlich dem AVR-Studio.

Über weitere Einzelheiten berichte ich, sobald der erste Überblick über die ganzen Bibliotheken steht :D

Anhang 32133

Hallo,

tja, so richtig viel hardcore ARM Entwickler scheint es hier nicht zu geben.

Aber zumindest einen Leser für deine Berichte hast du schon mal.

Viel Erfolg !

Na dann geselle ich mich auch mal dazu, ich bin hier die nächsten Wochen damit beschäftigt einen ATSAML21 zu programmieren und habe mich schon relativ intensiv eingearbeitet.

Allerdings muss ich direkt abbremsen und sagen, dass ich eine gespaltene Persönlichkeit habe was die Embedded Programmierung angeht. Zum einen setz cih gern auf Abstraktion und Modularisierung, aber bei den Low Level Geschichten verlass ich mich ausschließlich auf eigenen Code oder Code den ich auch vollständig verstehe!
Also von Bibliotheken kann ich dir da leider nichts sagen, aber ich weis dass zumindest der SAML21 sehr sehr sehr viel Detailwissen vorraussetzt wenn man ihn Low Level programmieren möchte. Oder du verlässt dich auf die Hersteller Libs (Atmels Software Framework namentlich und die Atmel.START Webseite für Demo Code ... SEHR empfehlenswert)

Für private Zwecke habe ich mir zwei Featherweight M1 gekauft, die sind handlich, günstig und kommen dem L21 am nächsten wenn ich z.B. versuchen will was zu verstehen aber auf Arbeit damit nicht zu Rande komme :)

Zitat:

---

.. 8-bit-Mikrocontroller (AVR) mehrmals komplett voll bekommen habe .. 32-bit MCUs .. Preis-/Leistungsverhältnisse .. eher zu der ARM-Architektur ..

---

Genau den gleichen Antrieb hatte ich mit meinen 8Bittern - die ich derzeit als I²C-Master+etliche-9-Slaves betreibe. Dazu kommen Vermutungen/Hoffnungen zu schnell(er)en FloatingPoint-Rechnungen, schnellerer Arbeitsweise überhaupt und so.

Zitat:

---

.. tja, so richtig viel hardcore ARM Entwickler scheint es hier nicht zu geben ..

---

Ich zähle zu den vielen, die KEINE ARM-Erfahrung haben, hatte ich bisher nicht geschafft. Trotz des schicken STM32F407-Discoverybords. Es liegt seit vielen Monaten, unbenutzt, undurchsichtig und unverstanden hier herum. Ich kenne es nur von einigen Testfahrten mit der aufgespielten Demosoftware.

Zitat:

---

.. bei den Low Level Geschichten verlass ich mich ausschließlich auf eigenen Code oder Code den ich auch vollständig verstehe ..

---

ABER ich fürchte den Wechsel in neue Controllerhardware, neue, SEHR umfangreiche Dokumentationen, kompliziertes Handling mit so vielen Möglichkeiten und Varianten der einzelnen Hardwarefunktionsblöcke und bin in Bezug auf Bibliotheken praktisch unberührt und unerfahren. Dazu dann die Wahl der (kostenlosen) IDE und die Einarbeitung in deren Dschungel. Also - mögen täte ich schon wollen - aber das wars dann, leider.

Zitat:

---

SEHR umfangreiche Dokumentationen

---

Leider nicht, ich hab diverse EMails mit dem FAE von Atmel austauschen müssen um die wirklich extrem lückenhafte Doku soweit zu verstehen um überhaupt erstmal einen stabilen Takt vom Externen Quarz über die DFLL an den Core zu bekommen bzw. die sehr verwürfelten Angaben der diversen Abweich Parametern bei den Clocks zusammenzufassen.

Am Ende benutze ich einen 16Mhz Oszillator extern mit 0.3% Abweichung über volle Temperatur um damit ein 32kHz Referenz Signal runterzuteilen und damit die DFLL auf 48MHz für den Core zu bringen. Die Peripherie taktet direkt von den 16Mhz weil auf die DFLL zu viel Jitter hat für unsere COM-Spec ... der Stromverbrauch ist dennoch winzig im vergleich zu den XMegas

Ich habe auch so gut wie keine praktische Erfahrung mit dem ARM, hab mich da seit ein paar Monaten dann und wann eingearbeitet und lege grad erst richtig los.

Zu 1)
Ich arbeite grade viel mit der HAL. Der CubeMX macht einem da den Einstieg relativ einfach. Du kannst dir die komplette Initialisierung per Hand sparen und bekommst sehr schnell einen Überblick, was deine CPU eigentlich alles so kann. Ich komme auch aus der AVR-Ecke und da ist es dann recht befremdlich, auf was man auf einmal alels achten muß. Da muß jeder Scheiß erstmal mit Takt versorgt werden bevor man irgendwas einstellen kann-selbst Ports, sonst kannst du nichtmal eine einfache LED einschalten. und während es für die gesamte IO-Steuerung beim AVR insgesamt gerademal drei popelige Register gibt, kannst du beim STM32 an jedem IO Pullups oder Pulldowns zuschalten, den Pin als Push-Pull-Stufe oder Open-Drain betreiben und die Schaltgeschwindigkeit beeinflussen. Das Einlesen und Ausgeben oder das Benutzen alternativer Funktionen (z.B. ADW) ist da noch gar nicht mit einberechnet.

Soweit ich weiß wird die SPL nicht mehr weitergepflegt. Meines Erachtens macht das aber auch nichts...hat ja keinerlei Nutzen. Letztendlich schreibt man imemr noch direkt in die Register, das Ganze ist bloß als Enumeration getarnt. Der Aufwand hingegen ist derselbe. Dagegen sind in der HAL schon ein paar Extra-Funktionen drin. Ich werde künftig wohl zweigleisig fahren: Einerseits Hal, andererseits Register direkt beschreiben. Ersteres hauptsächlich, um Arbeit auf den CubeMX abwälzen zu können. Letzteres weil ich gerne verstehe, was ich da eigentlich mache.

Zu 2)
Die weißen Nucleoboards haben auf einer Seite eine Stiftleiste (ich glaub 5-polig), da ist die SWD-Schnittstelle rausgeführt. Wenn du den Controller auf dem Board abschaltest (Jumper ziehen), könnte es klappen daß du damit auch externe Sachen programmieren kannst.
Andererseits, ganz ehrlich...einen Adapter für den 20-poligen Stecker zu schnitzen ist doch auch nicht so schwer.

Ich selber arbeite aber mit dem J-Link. kostet in der Edu-Version nur 40 Euro, und funktioniert mit dem Embedded Studio recht gut. Und im Hersteller-Forum findet man auch gute Hilfe, wenn etwas nicht geht.

Hallo liebe Gemeinde,

leider wird es zum Jahresende ziemlich hektisch auf der Arbeit, da kommt man nicht zu anderen Sachen (bzw. man will außerhalb seiner Arbeitszeit keine Elektronik und keine Programmcodes sehen :D ).
Nichts desto trotz, gibt es ein Paar, wenn auch kleinere Neuigkeiten: An erster Stelle mein neues Experimentierboard, Quelle: RS-Online
Das Board kann so ziemlich alles, was man zum Testen braucht und erstmal werde ich auch damit auskommen. Zumindest solange, bis ich weiß, was genau ich von diesem Mikrocontroller erwarte.

Fotos dürfen natürlich nicht fehlen ;)

Anhang 32243Anhang 32242

Habe mir viel Inspiration eingeholt und eines der Ziele besteht in der Entwicklung einer eigenen Mensch-Maschine-Schnittstelle, sprich eine hübsche und graphisch (animierte) Oberfläche anstatt meiner üblichen Dot-Matrix-LCD-Menüs.

Beispiel:

Anhang 32244Anhang 32245

Wenn das nicht hammer aussieht, weiß ich auch nicht. Der Bildschirm ist ein etwas anderer (nicht kapazitiv, sondern resistiv), jedoch gibt es dazu fertige "Menu-Builder", wo man sich die einzelnen Elemente zusammenclicken kann. Quelle: Nextion. Das Menü (und dazugehörige Gerät entstammen dem EEV-BLog. Für den Anfang könnte man unter Umständen so etwas verwenden, bevor man mit einer kompletten Neuentwicklung beginnt. (Die natürlich so ihren Reiz hat :) )

Jedenfalls lassen sich diese Nextion-Displays in den Hobby-Projekten sehen. Aber ich werden erstmal langsamer treten und fange bei dem Datenblatt und den restlichen Tausend Seiten der AppNotes an :D
In dem Sinne - frohes Schaffen, Leute!

Hallo,
ich bin neu hier, aber ich habe einen ähnlichen Plan und möchte mir auch gerne ein ARM Breakout Board bauen, vielleicht können wir uns ja zusammen tun. Ich habe gute Erfahrung insgesamt, allerdings bisher nicht mit ARM, ich habe mal den ATSAME70Q21 gesamplet und wollte mich mal an diesen Probieren.
Ein paar Dinge habe ich noch nicht ganz verstanden dazu gehört leider auch der Speicher Controller.
Wie auch immer, du kannst mir ja schreiben wenn du Interesse hast.
Beste Grüße
MasterQ

Nachtrag:
Also ich dachte daran einen SD-Card slot zu installieren, etwas SDRAM, USB und wenn ich es schaffe eine Ethernet-Schnittstelle, naja und natürlich einen haufen IO's (am liebsten alle) und JTAG rausführen.