Beziehung zwischen CubeMX, HAL und CMSIS

[dennis (Gast)]

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

[Harry L. (mysth)]

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.

[Devil (Gast)]

Aber es gibt bei STM nicht nur die HAL sondern neuerdings auch LL (Low 
Level)

[dennis (Gast)]

in irgendeinem Artikel von hier habe ich gelesen, dass HAL LL abgelöst 
hat.. also genau umgekehrt ;)

[Vincent H. (vinci)]

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.

[Harry L. (mysth)]

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.

[Stefan (Gast)]

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 F. (Gast)]

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.

[Harry L. (mysth)]

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)

[Axel S. (a-za-z0-9)]

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.

[Stefan F. (Gast)]

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.

[Harry L. (mysth)]

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.

[Stefan F. (Gast)]

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.

[Harry L. (mysth)]

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.

[Stefan F. (Gast)]

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?

[Harry L. (mysth)]

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.

[void (Gast)]

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.

[Axel S. (a-za-z0-9)]

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.

[Stefan F. (Gast)]

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.

[Vor-und N. (analogon)]

Ich glaube es ist eine Dreiecksbeziehung. Aber im moment leben alle 
getrennt!