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)
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Mein Tipp. Nutze das alles sieht übersichtlicher aus. UNd wenn alles läuft Kannst du diese Funktionen immer noch optimieren.
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!
Würden folgende Dateien reichen? Projektordner: - main.c - Makefile + CMSIS - system_stm32f4xx.h - system_stm32f4xx.c - stm32f4xx_conf.h - stm32f4xx.h + startup - startup_stm32f4xx.c + core - core_cmFunc.h - core_cmInstr.h - core_cm4_simd.h - core_cm4.h
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.