Hallo, kann man CubeMx von ST als graphische Benutzeroberfläche bezeichnen, oder wie wäre die korrekte deutsche Entsprechung. "CubeMx ist eine graphische Benutzeroberfläche von ST, in der die Konfiguration der Mikrocontrolller erfolgt. Abschließend lässt sich durch das Tool ein kompilierbarer C-Code generieren, der alle Konfigurationen erhält." Kann man das so 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...
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.
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: > Stefanus F. schrieb: >> Ich würde es Code-Generator nennen. > > Und die HAL dann als Code Obfuskator? Uwe, das ist jetzt aber sehr höflich ausgedrückt. :)
> 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?
Stefanus F. schrieb: > 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. Da du dir offenbar nie die Mühe gemacht hast, das zu lesen -geschwiege denn zu verstehen- solltest du dich mit solchen Urteilen einfach mal zurück halten! Deine "Kritik" entbehrt jeder Substanz. Sag doch einfach: "Ich bin zu faul mich in HAL einzuarbeiten, und kann daher nix dazu sagen." CubeMX wird von ST selbst als "Initialisierungs-Codegenerator" bezeichet, und das passt ziemlich genau.
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.
Stefanus F. schrieb: > 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. > > 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. Ich hab solche Wechsel in der letzten Zeit mehrfach und mit unterschiedlichen Familien gemacht, und das lief jedesmal weitgehend glatt. Man muß natürlich wissen, was man tut, und ganz ohne Anpassungen geht das selten, aber der Aufwand ist immer noch sehr deutlich geringer als der voll-manuelle Ansatz. Daß da Bugs drin stecken ist sicher, aber das gilt für nahezu ausnahmslos jede Software. HAL und Co. ist einfach ein fetter Brocken, und für Amateure schwer beherrschbar/verständlich, und wenn man nur ein paar LEDs blinken lassen will, kommt man ohne sich da ersteinarbeiten zu müssen vermutlich schneller ans Ziel. Die Einarbeitung ist auch nicht mal eben "übers Wochenende" zu stemmen. Daß der Einsatz von HAL das Studium des Referenz- und User-Manual erspart ist ein Mythos. Das sollte man in jedem Fall vorher können. Auffallend ist, daß beinahe alle, die über HAL schimpfen das nur vom Hörensagen kennen.
:
Bearbeitet durch User
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.
Dr. Sommer schrieb: > 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. Oh! Du hast ein Haar in der Suppe gefunden. Glückwunsch! Darfst du behalten. Aus so einem Einzelfall abzuleiten, daß das grundsätzlich Murks sei halte ich für falsch. Ich hab an keiner Stelle behauptet, daß das perfekt sei aber für mich überwiegt klar der Nutzen.
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.