ARM-Beginn mit einem eigenen Board

[Mxt]

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 !

[Ceos]

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  

[oberallgeier]

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

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

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

[Ceos]

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

[White_Fox]

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.

[Liquidator]

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   ).
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  

   

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:

   

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  
In dem Sinne - frohes Schaffen, Leute!

[MasterQ]

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.