Genaue Bezeichnung von CubeMx

Ja ich denke so kann man das schreiben.

ich würde es vielleicht noch etwas erweitern:
> in der die Konfiguration der Schnittstellen eines Mikrocontrollers erfolgt

und achte auf deinen Typo in Mikrocontroller

marcel schrieb:
> CubeMx ist eine graphische Benutzeroberfläche von ST

Typische Ingenieurs-Ausdrucksweise ? CubeMX hat eine grafische 
Oberfläche, aber es ist keine Oberfläche. Ein Auto ist ja auch nicht 
identisch zum Armaturenbrett. Besser " CubeMX ist eine grafische 
Anwendung " oder "eine Anwendung mit grafischer Oberfläche ".

Und lass dieses Unwort "Tool" weg. Irgendwie ist alles immer ein Tool. 
"Abschließend" ist in diesem Kontext auch komisch, da du ja kaum 
erläuterst, was vor dem Abschluss kommt...

Ach ja, und es heißt STM32CubeMX, nicht CubeMx.

Ich würde es Code-Generator nennen.

STM32CubeMX ist eine grafische Anwendung von ST für den PC zur 
interaktiven Konfiguration von Hardware und Software der Mikrocontroller 
und Anwendungsprozessoren der STM32-Familie. Insbesondere wird die 
Zuordnung von Pins zu Peripherie-Modulen und die Einstellung des 
Systemtakts übersichtlich dargestellt. Die Anwendung kann C-Code 
erzeugen, welcher die gewünschte Konfiguration auf dem Prozessor 
einstellt. Der erzeugte Code basiert dabei auf dem Hardware Abstraction 
Layer (HAL) der entsprechenden STM32Cube-Bibliothek und stellt ein 
Grundgerüst für eigene Anwendungen dar.

Stefanus F. schrieb:
> Ich würde es Code-Generator nennen.

Und die HAL dann als Code Obfuskator?

UweBonnes schrieb:
> Und die HAL dann als Code Obfuskator?

Jedenfalls ist die HAL keine richtige HAL.

Wirklich vereinfachen tut sie auch nur wenig, wenn man bei jedem Problem 
erstmal hinterfragen muss, ob es eventuell ein Bug in der HAL ist und 
zusätzlich zu 1500 Seiten Referenzhandbuch noch 2000 weitere Seiten HAL 
Handbuch und dessen Quelltext lesen muss, um Sicherheit zu bekommen.

> UweBonnes schrieb:
> Und die HAL dann als Code Obfuskator?

Marcus H. schrieb:
> Uwe, das ist jetzt aber sehr höflich ausgedrückt. :)

Ein passender Name fällt mir dazu auch nicht ein. Wie soll man diesen 
Dingsbums-Layer denn sonst nennen?

Harry L. schrieb:
> CubeMX wird von ST selbst als "Initialisierungs-Codegenerator"
> bezeichet, und das passt ziemlich genau.

Ja, das passt.

Mir wurde mal erzählt, CubeMX wurde deshalb erfunden, um den Code über 
die ganzen STM32-Derivate portabel zu halten. Darum soll das eben eine 
Hardware-Abstraktionsschicht darstellen.
Die haben ja bekanntlich sehr unterschidliche Peripherie, da wäre das 
sehr praktisch, würde es gut funktionieren.

Die Qualität des Codes soll aber nicht so toll sein. Unsere Firmwerker 
schimpfen zumindest ziemlich drüber, und verwenden weiter die alte Lib. 
Nach ein paar ziemlich spektakulären Bugs, die das Cube so mitgebracht 
hat. Ob das Gemecker gerechtfertigt ist, kann ich aber nicht beurteilen.

Einige Teile sind jedoch sehr praktisch, wie zum Beispiel dieses 
Pinconfig-Tool. Das ist für Hardwareentwickler eine echte Erleichterung.

Weil aber die STM32 passabel dokumentiert und einigermassen 
Verstädndlich sind, gibt es ja keinen Zwang das Gelumpe zu benutzen. Ich 
zumindest mache meine Inbetriebnahme-Mini-Firmware Sachen pople einfach 
in den Registern herum. Das ist auch nicht schwieriger als bei anderen 
µC. also was solls...

Man kann sich ja ein paar ekelige Dinge (wie dieses verkorkste USB oder 
Komplexitätsmonster wie Ethernet) aus der Lib ziehen, und den Rest 
ordentlich machen.

HALAL schrieb:
> Die haben ja bekanntlich sehr unterschidliche Peripherie, da wäre das
> sehr praktisch, würde es gut funktionieren.

Genau, wenn es funktionieren würde. Aber letztendlich sind die 
Unterschiede zwischen den Serien zu groß. Das klapp nicht einmal bei 
simplen GPIO Zugriffen, wenn du mal einen Wechsel von der F1 Serie zu F3 
versuchst.

> Unsere Firmwerker schimpfen zumindest ziemlich drüber...
> Nach ein paar ziemlich spektakulären Bugs, die das Cube so
> mitgebracht hat.

Meine ersten beiden Versuche scheiterten an Bugs. Dadurch kam ich zu der 
Erkenntnis, dass ich die Programmierung der STM32 Chips besser mit Hilfe 
des Referenzhandbuches "zu Fuß" lerne.

Den dritten Versuche habe ich dann erst Monate später gewagt, nachdem 
ich meine eigentliche Aufgabe längst ohne HAL am laufen hatte. Wenn man 
bereits weiß, was man da macht, kann man den HAL Code auch verstehen und 
anwenden (abgesehen von zeitraubenden Bugs - als hätten die Chips nicht 
schon genug Bugs).

> Man kann sich ja ein paar ekelige Dinge (wie dieses verkorkste USB
> oder Komplexitätsmonster wie Ethernet) aus der Lib ziehen, und den
> Rest ordentlich machen.

Und da muss ich die HAL mal loben. Man kann sie teilweise nutzen und 
andere Teile an ihr vorbei programmieren. Das wäre bei vielen anderen 
Frameworks von vorne herein unerwünscht. Außerdem ist der Quelltext gut 
kommentiert.

Harry L. schrieb:
> Ich hab solche Wechsel in der letzten Zeit mehrfach und mit
> unterschiedlichen Familien gemacht, und das lief jedesmal weitgehend
> glatt.

Dann mach so einen Wechsel mal zwischen F4 und F7 bei einem Programm 
welches auf die SDIO Schnittstelle zugreift. Bei direktem Register 
Zugriff kein Problem, da die Register zu 99% gleich sind. Bei Verwendung 
der HAL ist das aber ein großer Aufwand, weil alle Bezeichner von 
SDIO_xxx mach SDMMC_xxx umbenannt wurden. Die HAL ist hier also mehr so 
ein Deabstraktionslayer. Toll.