Hallo, ich muss ein wenig etwas über STM32CubeMX schreiben und möchte
mal ganz genau die Zusammenhänge abklären, bevor ich etwas durcheinander
bringe.
Also so wie ich das verstanden habe generiert CubeMX einen C-Code,
dessen Headerdateien auf den herstellerunabhängigen CMSIS-Standard (für
diese Mikrocontroller-Familie) beruhen. Gleichzeitig bindet es aber wohl
auch eine ST-spezifische HAL-Bibliothek ein. In manchen Quellen wird
sogar CubeMX selbst als HAL bezeichnet.
Wie sind da nun die genauen Zusammenhänge? Danke schon mal im Voraus für
Antworten
Im Prinzip hast du das schon richtig verstanden.
HAL ist ein Abstraktionslayer, der on Top auf CMSIS aufsetzt, und CubeMX
ist ein Initialisierungs-Codegenerator, der dir basierend auf HAL das
Rumpf-Projekt inkl. der benötigten HAL-Librarys und den individuellen
Initialisierungs-Funktionen generiert.
dennis schrieb:> in irgendeinem Artikel von hier habe ich gelesen, dass HAL LL abgelöst> hat.. also genau umgekehrt ;)
Das bezog sich wohl auf STMs Bibliotheken vor HAL. Ich weiß grad nicht
wie genau die geheißen haben... irgendwas mit StandardPeriph...?
Die HAL und LL läuft jedenfalls parallel und die lösen sich bestimmt
nicht gegenseitig ab.
dennis schrieb:> in irgendeinem Artikel von hier habe ich gelesen, dass HAL LL abgelöst> hat.. also genau umgekehrt ;)
Nein, die LL-HAL ist Bestandteil von HAL.
Beide existieren nebeneinander, und im CubeMX kann man für jede
Peripherie individuell wählen, ob die Initialisierung in HAL oder LL-HAL
erfolgen soll.
Die LL-HAL-Funktionen sind generell kleiner, aber weniger portabel.
Wenn der Platz mal eng wird, kann die LL-HAL hilfreich sein.
Bei der Performance geben die sich nicht viel.
CubeMX benutzt im Wesentlichen nur die Core-CMSIS Funktionen für Systick
und NVIC.
Die Peripherie der STM32 µCs wird von den HAL-Libs direkt angesprochen.
In der Schichtansicht greift die Cube-HAL also nur teilweise auf CMSIS
zu. Die Peripheriezugriffe gehen an CMSIS vorbei.
Stefan schrieb:> Die Peripherie der STM32 µCs wird von den HAL-Libs direkt angesprochen.
Geht ja auch nicht anders. Die CMSIS-Core enthält ja nur Funktionen für
den ARM Kern (sowie die defines für die Peripherie Register). Systick
und NVIC sind Bestandteile des ARM Kerns.
Stefan schrieb:> Die Peripheriezugriffe gehen an CMSIS vorbei.
Natürlich!
Das gilt für Alles, was ST-spezifisch ist. (Und damt natürlich fast die
gesamte Peripherie)
Harry L. schrieb:> im CubeMX kann man für jede> Peripherie individuell wählen, ob die Initialisierung in HAL oder LL-HAL> erfolgen soll.> Die LL-HAL-Funktionen sind generell kleiner, aber weniger portabel.
Das ergibt IMNSHO keinen Sinn. Generierter Code ist generierter Code.
Den kann man sich jederzeit - also insbesondere auch bei einem Wechsel
des Targets - wieder neu erzeugen lassen. Wen interessiert da bitte die
Portabilität?
Stefan schrieb:> CubeMX benutzt im Wesentlichen nur die Core-CMSIS Funktionen für Systick> und NVIC.
Du wolltest das wohl anders herum formulieren: nur für Systick und NVIC
benutzt CubeMX die Core-CMSIS Funktionen. Und das ist kein bißchen
verwunderlich, weil CMSIS ja nur diese Komponenten überhaupt abdeckt.
> Die Peripherie der STM32 µCs wird von den HAL-Libs direkt angesprochen.
Ach! Alles, was außerhalb des von ARM standardisierten Lerns liegt, wird
nur von herstellerspezifischen Libs abgedeckt. Wer hätte das ahnen
können!
Vincent H. schrieb:> dennis schrieb:>> in irgendeinem Artikel von hier habe ich gelesen, dass HAL LL abgelöst>> hat.. also genau umgekehrt ;)>> Das bezog sich wohl auf STMs Bibliotheken vor HAL. Ich weiß grad nicht> wie genau die geheißen haben... irgendwas mit StandardPeriph...?
Die Standard Peripheral Library aka SPL war das. Wurde von ST zugunsten
von Cube/HAL aufgegeben. Existiert noch, wird aber nicht mehr gepflegt.
Und für neuere µC gibt es sie gar nicht erst.
Axel S. schrieb:> Generierten Code ... kann man sich jederzeit ...> wieder neu erzeugen lassen.> Wen interessiert da bitte die Portabilität?
Nur mal ein Beispiel:
Eine Anwendung verwendet den Sekunden-Interrupt der RTC des STM32F1,
diese soll auf den STM32F3 portiert werden. Der hat aber keinen
Sekunden-Interrupt, obwohl er als besserer Nachfolger gehandelt wird. In
diesem Fall muss man das Programm so umbauen, dass ein anderer Timer
(z.B. der Wakeup Timer) verwendet wird. Dabei hilft einem die HAL genau
gar nicht.
Insgesamt gibt es zwischen STM32F1 und F3 so viele kleine Unterschiede,
dass man den Chipwechsel nicht mit ein paar Klicks und 20 Minuten Tippen
anpassen kann.
Und wenn du jetzt denkst "der F1 ist alt", dann versuche mal einen
Wechsel von STM32F3 nach L0 oder umgekehrt. Das wird genau so aufwändig.
Axel S. schrieb:> Das ergibt IMNSHO keinen Sinn. Generierter Code ist generierter Code.> Den kann man sich jederzeit - also insbesondere auch bei einem Wechsel> des Targets - wieder neu erzeugen lassen. Wen interessiert da bitte die> Portabilität?
Ist aber so!
Auf dem Screenshot sieht man das.
Lt. Aussage von ST spart man damit ca. 50% Code-Grösse. Ist wohl für die
sehr kleinen M0(+) gedacht. (Aussage eines ST-Mann bei einem
Handson-Workshop)
Ich hab die LL-Funktionen für meine Projekte bisher nicht gebraucht.
Ehrlich gesagte erwarte ich nicht, dass mal mit einem Code-Generator
oder einer HAL wirklich unabhängig von der Hardware wird. Dann müsste
man sich entweder auf wenige grundlegende Funktionen (wie bei Arduino)
beschränken oder mit Betriebssystem und Treibern arbeiten, wie bei
Linux.
Mikrocontroller-Anwendungen sind Hardware nah, sie sollen schließlich
Hardware steuern. Ich kann auch nicht verlangen, dass mir jemand den
Pelz wäscht ohne mich nass zu machen.
Stefanus F. schrieb:> Ehrlich gesagte erwarte ich nicht, dass mal mit einem Code-Generator> oder einer HAL wirklich unabhängig von der Hardware wird.
Das war nie der Anspruch von HAL/CubeMX.
Es sorgt nur für weitgehende Kompatibilität in der eigenen Familie.
Ich hab es dir schonmal erklärt.
Du wirst es nicht verstehen, wenn du auf der anderen Seite nicht bereit
bist, dich intensiv damit zu beschäftigen.
Ich schrieb:
> Ehrlich gesagte erwarte ich nicht, dass mal mit einem Code-Generator> oder einer HAL wirklich unabhängig von der Hardware wird.Harry L. schrieb:> Das war nie der Anspruch von HAL/CubeMX.> Ich hab es dir schonmal erklärt.> Du wirst es nicht verstehen, wenn du auf der anderen Seite nicht bereit> bist, dich intensiv damit zu beschäftigen.
Und ich habe Dir schon mal gesagt, dass ich es durchaus verstanden habe.
Es sind andere, die überhöhte/falsche Erwartungen an die HAL stellen.
Jedes mal, wenn ich solche falsche Erwartungen korrigiere, bestätigst du
mich, und behauptest trotzdem im selben Atmemzug, dass ich keine Ahnung
habe weil ich mich nicht damit befassen würde. Kannst du das bitte mal
bleiben lassen?
Stefanus F. schrieb:> Und ich habe Dir schon mal gesagt, dass ich es durchaus verstanden habe.> Es sind andere, die überhöhte/falsche Erwartungen an die HAL stellen.
Danach hier hat niemand gefragt, aber scheinbar liebst du es deine
eigenen Texte zu lesen.
dennis schrieb:> herstellerunabhängigen CMSIS-Standard (für diese> Mikrocontroller-Familie)
Das ist doch widersprüchlich. Entweder es ist herstellerunabhängig oder
spezifisch für eine uC Familie. Vermutlich war spezifisch für eine CPU
Architektur gemeint.
Harry L. schrieb:> Axel S. schrieb:>> Das ergibt IMNSHO keinen Sinn. Generierter Code ist generierter Code.>> Den kann man sich jederzeit - also insbesondere auch bei einem Wechsel>> des Targets - wieder neu erzeugen lassen. Wen interessiert da bitte die>> Portabilität?>> Ist aber so!> Auf dem Screenshot sieht man das.
Abgesehen davon, daß ich nichts auf dem Screenshot sehen kann, was meine
Ansicht widerlegt ... was soll das für eine Antwort sein?
> Lt. Aussage von ST spart man damit ca. 50% Code-Grösse.
Klar. Das ist bestimmt gut. Noch besser wäre es gewesen, wenn ST die HAL
gleich etwas sparsamer gestaltet hätte. Wenn man - unter der Annahme
identischen Funktionsumfangs - die Codegröße auf die Hälfte eindampfen
kann, dann ist wohl von Anfang an etwas schief gelaufen.
Disclaimer: ich bin absolut kein Fan der ST "Abstraktions" Libs. Egal ob
SPL oder HAL. Das Design ist Mist, sie sind (zu) fett und vor allem
haben sie eine kürzere Lebensdauer als so manches meiner Projekte. Ich
verwende dieses Zeug nicht (bzw. nur das Headerfile mit den
Registerdefinitionen). Insofern ist es mir auch herzlich egal, wie
fett oder unportabel oder buggy das ist.
Mir kam halt nur die Ansage "dieser generierte Code ist portabler als
jener" etwas sinnlo^W seltsam vor.
Harry L. schrieb:> scheinbar liebst du es deine eigenen Texte zu lesen.
Zumindest lese ich sie lieber, als deine genialen Einwürfe. Wenn du
magst, darfst mich deswegen gerne mit einem medizinischen Fachausdruck
taggen.
