Guten Tag.
Ich beschäftige mich aktuell etwas mit den STM32.
Dabei bin ich auf die Begriffe HAL, CMSIS und SPL gestoßen, welche ich
mir über das Internet nicht vollends erklären konnte.
Die CMSIS ist eine Hardwareabstraktionsschicht, eine Schnittstelle
zwischen Hard- und Software. Diese kommt von ARM selbst, wohingegen die
SPL und HAL von ST stammt.
Warum sieht man in manchen Projekten CMSIS und SPL zeitgleich?
Macht es Sinn direkt mit HAL zu starten?
Gruß, Tim.
Lade dir den Krempel mal selbst herunter und guck dir mit eigenen Augen
an, was da geboten wird. Meine Erfahrung ist, daß es eine große
Schaumschlägerei ist und leider überhaupt keine Hardware-Abstraktion
bringt. Es werden lediglich zusätzliche Bezeichner eingeführt für all
das, was das jeweilige Referenz-Manuals zum Chip zu bieten hat. Dazu
noch Funktionen, die nichts weiter tun, als die primitivsten HW-Zugriffe
eben in Funktionen zu packen. Wo ist der Gewinn bei sowas im Stil wie
SetPort(PortA, Bit4, hi) gegenüber PortA.4 = hi; - natürlich gibt es da
gar keinen Gewinn, sondern nur viel heiße Luft.
Mein Rat: Laß all diesen Krempel links liegen und stütze deine unterste
Treiberschicht beim Programmieren direkt auf das, was du im RefMan lesen
kannst.
W.S.
Ja nutze auf jeden Fall keinerlei Abstraktion Schichten und mach alles
selber. Nur so ist garantiert dass du noch mindestens 20 Foren Einträge
schreibst in denen du um Hilfe bitte musst nur um eine LED zum Blinken
zu bringen. Auch ist garantiert, dass du Fehler widerholst die andere
vor dir auch schon gemacht haben.
Anstatt beim Bäcker ein Brot zu kaufen solltest du viel auf jeden Fall
nur die Zutaten besorgen um dein Brot selber zu backen.
Auch wenn die ersten paar mit Sicherheit ungenießbar sind
Ich setze auch auf möglichst direkte registerzugriffe ohne libs.
Lediglich bei initialisierungsroutinen benutze ich die spl. Wenn du mal
ein größeres Projekt hast, wirst du schnell merken, dass der code so
auch kürzer und verständlicher wird. Zumindest für Anfänger (wie mich).
Nachteil wäre wohl das umschreiben bei Benutzung eines anderen mc.
Ob man den HAL oder die SPL oder was eigenes benutzt (was letztendlich
ja auch in Funktionen endet, die der SPL sehr ähneln...) sei dir
überlassen.
Im Gegensatz zu W.S. find' ich aber CMSIS (insbesondere also
stm32f10x.h) verdammt nützlich, denn da stehen eben alle Bits und
Register genau so drin, wie im reference manual, sodass man beim Lesen
des refman über die Makros direkt die passenden Configbits setzen kann.
Das ist das selbe Argument wie beim USB Beispiel in dem "c goto" Thread;
Wenn man das Datenblatt (zur CPU oder USB) einigermaßen kennt, weiß man
auch nach einiger Zeit noch, welche Bits gesetzt wurden (ganz im
Gegensatz zu einem wilden Haufen Hex magic numbers). Und wenn einem die
Bezeichnungen entfallen sind, muss gibts möglicherweise noch einen
zusammenfassenden Kommentar oder wenn man was ändern muss, liegt eh das
Datenblatt daneben.
Die Mathefunktionen aus der CMSIS-DSP find' ich übrigens auch ganz
praktisch.
Jan
edit: oder meinst du wirklich das "nackte" CMSIS (sprich core_cmX.h,
arm_math.h)? Da steht doch kaum was drin, nur ein paar nette
Definitionen für den Systick, NVIC und die Debug Ports (ITMx, DWTx etc)
W.S. schrieb:> Mein Rat: Laß all diesen Krempel links liegen und stütze deine unterste> Treiberschicht beim Programmieren direkt auf das, was du im RefMan lesen> kannst.
Das ganze nennt man "versuchte Kundenbindung", weil Deinen Code außer
Dir dann keiner mehr lesen kann.
Ist Klasse für den Dienstleister der nach Dir kommt, der darf das ganze
dann nämlich richtig machen und nochmal verkaufen. ;)
>Im Gegensatz zu W.S. find' ich aber CMSIS (insbesondere also>stm32f10x.h) verdammt nützlich, denn da stehen eben alle Bits und>Register genau so drin, wie im reference manual,.....
Aber dafür braucht man doch kein sep. Layer!
MCUA schrieb:>>Im Gegensatz zu W.S. find' ich aber CMSIS (insbesondere also>>stm32f10x.h) verdammt nützlich, denn da stehen eben alle Bits und>>Register genau so drin, wie im reference manual,.....> Aber dafür braucht man doch kein sep. Layer!
Willst du das selbst schreiben? So der riesen Layer ist das nicht...
CMSIS hat doch quasi keinen overhead.
MCUA schrieb:>>Im Gegensatz zu W.S. find' ich aber CMSIS (insbesondere also>>stm32f10x.h) verdammt nützlich, denn da stehen eben alle Bits und>>Register genau so drin, wie im reference manual,.....> Aber dafür braucht man doch kein sep. Layer!
Das ist kein Layer. Das sind nur Headerfiles mit den defines und
Typdeklarationen für die ganzen Register und die Namen der Bits in den
Registern. Wenns der Hersteller nicht mitliefern würde müsstest Du es
von Hand schreiben und heraus käme mehr oder weniger exakt das gleiche
(zzgl. deiner Tippfehler beim Abschreiben aus dem RefMan).
Jan K. schrieb:> Im Gegensatz zu W.S. find' ich aber CMSIS (insbesondere also> stm32f10x.h) verdammt nützlich, denn da stehen eben alle Bits und> Register genau so drin, wie im reference manual, sodass man beim Lesen> des refman über die Makros direkt die passenden Configbits setzen kann.
Wenn du W.S. Post nicht nur gelesen, sondern auch verstanden hättest,
dann wäre dir klar geworden daß er nicht gegen die Verwendung dieses
Headerfiles (respektive die Verwendung der darin enthaltenen Makros)
argumentiert hat, sondern gerade dafür. Denn selbstverständlich will
man auch beim direkten Registerzugriff symbolische Namen für die
Register und die darin befindlichen Bits verwenden.
Was man hingegen nicht braucht, sind die Funktionen, die das Lesen und
Schreiben eben jener Register kapseln.
Axel S. schrieb:> Jan K. schrieb:>> Im Gegensatz zu W.S. find' ich aber CMSIS (insbesondere also>> stm32f10x.h) verdammt nützlich, denn da stehen eben alle Bits und>> Register genau so drin, wie im reference manual, sodass man beim Lesen>> des refman über die Makros direkt die passenden Configbits setzen kann.>> Wenn du W.S. Post nicht nur gelesen, sondern auch verstanden hättest,> dann wäre dir klar geworden daß er nicht gegen die Verwendung dieses> Headerfiles (respektive die Verwendung der darin enthaltenen Makros)> argumentiert hat, sondern gerade dafür. Denn selbstverständlich will> man auch beim direkten Registerzugriff symbolische Namen für die> Register und die darin befindlichen Bits verwenden.>> Was man hingegen nicht braucht, sind die Funktionen, die das Lesen und> Schreiben eben jener Register kapseln.
Ich muss zugeben, da wehte auch noch etwas Erinnerung aus anderen Posts
von W.S. mit, in denen er immer propagiert, dass CMSIS aufgeblasen und
absolut unnötig sei.
Interessant, dass man hier bei so simplen Themen direkt auf
Konfrontation geht.
Nur zuer Info, CMSIS-CORE bietet (von mir aus bis auf NVIC und SYSTICK)
überhaupt keine Funktionen an, sondern ermöglicht es einem, die
Peripherie- und Bitnamen aus dem reference manual zu verwenden.
Guten Morgen,
inspiriert von diesem Thread möchte ich nun ebenfalls auf diese weise
mit der STM32 Programmierung beginnen.
Aktuell bin ich noch etwas überfordert. Vielleicht kann mir jemand von
euch weiterhelfen?
OpenOCD habe ich installiert und bekomme auch eine Verbindung zu meinem
Board (welches übrigens dieses hier ist:
http://www.waveshare.com/core429i.htm ). Anfangs würde ich gerne einen
Editor meiner Wahl benutzen.
Was ich nun absolut nicht verstehe: Welche Dateien der CMSIS benötige
ich und wie würde die Makefile für so ein Projekt aussehen?
Könnte mir jemand ein Beispielprojekt hochladen, wo ein einfaches make
reicht, um die bin Datei zu erhalten?
Es ist gerade alles Neuland und ich bin auch etwas erschlagen.
Danke für eure Hilfe!
Das ist zwar ein anderes Board, evtl müsstest Du es erst passend machen
aber als grobe Orientierung wie sowas aufgebaut sein kann hier ein
Beispiel für ein STM32 NUCLEO-F401RE Board:
https://github.com/prof7bit/bare_metal_stm32f401xe
