Hallo liebes Forum,
derzeit evaluiere ich die STM32F für den echten Einsatz im
Industrieumfeld. Dazu gehört natürlich auch die Entwicklungsumgebung und
die Libs.
Jetzt muss ich sagen, dass der neue HAL seit CubeMX nicht voll
überzeugen kann. Das Ding tut einfach zu oft nicht das, was man
erwartet. Natürlich geht nichts über Manual lesen und dann den HAL-Code
durchforsten. Allerdings gehe ich bei etwas, das sich HAL nennt
eigentlich davon aus, dass es die Hardware auch tatsächlich abstrahiert
und nicht nur Register umbenennt und verschleiert was eigentlich
passiert.
Anfangs war ich auch geblendet von "Projekt inkl. Betriebssystem in
wenigen Klicks". Für mich ist das aber alles sehr halbgar.
Nun zur eigentlichen Frage: Verwendet jemand im professionellen Umfeld
den STM HAL (oder die alte Peripherielib) und kann kurz die Erfahrungen
schildern? Oder auch: Warum wird es nicht verwendet?
Viele Grüße
Karl
Karl schrieb:> Nun zur eigentlichen Frage: Verwendet jemand im professionellen Umfeld> den STM HAL (oder die alte Peripherielib) und kann kurz die Erfahrungen> schildern? Oder auch: Warum wird es nicht verwendet?
Wir verwenden es exakt wegen der Erkenntnisse, die Du auch gewonnen
hast, nicht.
Hallo,
In StdPeriph_Driver von ST sind alle Dateien für HAL vorhanden. Die
Registerprogrammierung wie „DMA1->LIFCR = DMA_Stream0_IT_MASK;“ bedarf
einen tiefen Einblick in den Dokumenten von ST.
Sonst kann ich nur sagen dass auch in ST-Codes Bugs existieren die
gefunden werden sollen, aber im allgemeinen funktionieren die Methoden
sehr gut. Ich würde auf jeden Fall die HAL-Funktionen von ST verwenden,
wenn ich Probleme bekomme suche nach gezielten Infos.
Gruß
Milad
Ja, wir setzen seit einigen Jahren die STM Lib professionel ein.
Es gibt auf Nachfrage bei STM sogar eine Tüv zertifizierte mit
Speichertests gemäß EN 61508.
So schlecht wie das hier von dem Amateuren gemacht wird, sind die libs
also nicht.
Vielen Dank für die Hinweise.
Wie ist denn bei Verwendung der Lib das übliche Vorgehen?
Bis jetzt kam ich nicht um ein exaktes Studium des Datenblatts (inkl.der
Register) herum. Dann muss ich oft auch die Lib-Quellen studieren, um
herauszufinden welchen Parameter man setzen muss um welches Register zu
beschreiben. Habe ich einfach Pech mit meiner Auswahl der Peripherie
gehabt oder ist das durchaus normal? (CAN und USB-FS)
In dem USB-Stack ist dann auch noch ein übler Bug drin, der den
Interrupt nicht zurücknimmt und folglich den Rest des Frames in einer
"Interrupt-Endlosschleife" hängt.
So ganz überzeugt bin ich nicht, aber evtl. läuft es auf eine Koexistenz
hinaus. Lib für eine Peripherie solange bis sie negativ auffällt
verwenden. Dann selbst machen...
Meint ihr mit HAL die Funktionen der StdPeriphLib (derzeit v3.5), oder
gibt es da noch was anderes?
Wir benutzen jedenfalls das CMSIS für die ganzen netten Registernamen
etc. und die stdlib primär, um peripherie zu initialisieren, da man
dadurch weniger Fehler beim rumwürfeln mit den Control Register Bits
macht.
Die einfachen Sachen (spi, dma, adc etc) danach schreiben wir "direkt",
ohne Umweg über die Lib. Sie kann aber z.B. bei flash oder gar eeprom
emulation hilfreich und ein Anhaltspunkt sein.
Schöne Grüße,
Jan
adenin schrieb:> Karl schrieb:>> In dem USB-Stack ist dann auch noch ein übler Bug drin,>> Da sind noch mehr üble Bugs im USB-Stack drin :P
Habt ihr / gibt es da eine genauere Beschreibung?
Karl schrieb:> Seit STM die CubeMX-Software eingeführt hat, haben sie einen HAL> eingeführt. Darin findet sich im Großen und Ganzen die alte Lib wieder.
Leider haben sie einmal wieder die API geändert. Auch wenn es
größtenteils nur die Namensgebung ist. Heißt für uns mal wieder
Fleißarbeit.
Aus dem Stehgreif fallen mir zwei Bugs ein:
- Der Interrupt wird beim Senden nicht mehr deaktiviert, so dass der
Prozessor quasi 100% damit ausgelastet wird
- Beim Verschicken von Paketen mit z.B. 64 Byte wird kein ZLP
nachgeschickt, so dass die Daten im PC erst auftauchen, wenn zufällig
mal wieder was geschickt wird.
Jan K. schrieb:> Wir benutzen jedenfalls das CMSIS für die ganzen netten Registernamen> etc. und die stdlib primär, um peripherie zu initialisieren, da man> dadurch weniger Fehler beim rumwürfeln mit den Control Register Bits> macht.> Die einfachen Sachen (spi, dma, adc etc) danach schreiben wir "direkt",> ohne Umweg über die Lib. Sie kann aber z.B. bei flash oder gar eeprom> emulation hilfreich und ein Anhaltspunkt sein.
witzig, genau so gehen wir auch vor
Ich arbeitete nur noch mit der StdLib von STM. Habe keine Zeit/Lust mich
mit dem ganzen Zeug auf der Registerebene herumzuschlagen. Hatte schon
ein paar unschöne Sachen erlebt, aber im großen kann man sich auf die
StdLib von ST verlassen.
Hallo Gemeinde,
ich muss das Thema noch mal aus der Versenkung holen...
Benutzt mittlerweile jemand STM32Cube/HAL?
Habe ein Nucleo64-Board (STM32L467RGxx) und möchte
einen (vorhandenen) CANopen-Stack implementieren.
Wenn ich solche Konstrukte sehe kriege ich aber eher die Krise:
uint32_t HAL_SYSTICK_Config(uint32_t TicksNumb)
{
return SysTick_Config(TicksNumb);
}
aus "stm32l4xx_hal_cortex.c":
Wie es bis jetzt aussieht würde SPL oder evtl. CMSIS ausreichen.
Das HAL-Zeugsl maximal für die Init-Routinen.
Wie ist eure Meinung zu "To HAL or not to HAL"?
Runout
Ich arbeite sehr gerne mit der StdLib, da ich dort die Schritte
nachvollziehen kann, um dann das, was mir nicht passt, selbst zu
schreiben.
Dort, wo es keine StdLibs mehr gibt (z.Bsp. STM32L0xx) sondern nur noch
HAL, habe ich auf die direkte Register-Programmierung gewechselt. Denn
beim geschwaetzige HAL-Stakkato habe ich keinen Durchblick mehr.
Hallo!
Ich bin gerade dazu übergegangen, mir meine eigene Lib zu stricken und
da immer Funktionen reinzutun, die ich gerade brauche. Vorallem will ich
auch mehr als eine "Registerabstraktion" machen, sondern für meine
Anwendungsfälle ausgelegten Code. Dazu zählt bspw. UART/SPI/I2C die
komplett im Hintergrund ablaufen, mit Puffern, Queues und allem.
Aktuell läuft
- ISR Vektoren
- RCC teilweise
- GPIO
- USART incl. printf
- I2C
- SPI
- EXTI
- darauf aufgesetzt: Buttons mit Polling/EXTI und Entprellung, Callbacks
etc
Gegenwärtig bin ich dran, USB auf nem L052 zu implementieren, das ist
ein ziemlicher Brocken.
Wenn man mit StdPeriphLib / HAL nicht zufrieden ist, lohnt es sich evtl.
auch, das libopencm3-Projekt anzuschauen, die sind ziemlich weit in
ihrer Umsetzung.
Thomas T. schrieb:> Wie ist eure Meinung zu "To HAL or not to HAL"?
Ich kann zumindest die Kritik, dass die "abstraction" Library nicht
wirklich eine Abstraktion ist, gut verstehen.
Ich nutze die HAL, da wo es das ganze einfacher macht. Die Dokumentation
steckt zum Teil eher in den Beispielen.
An die ganzen HAL-Kritiker, bitte gebt doch mal ein Beispiel an wie
Hardware-Abstraktion für euch aussieht.
HAL macht:
- Initialisierung mit Enum Klarnamen
- Statusmeldungen in den zugehörigen Strukturen
- Verlinkung von Peripherie, DMA und IRQ
- Handhabung von exclusive access an die Hardware
Was fehlt da noch?
neverHAL. Das selbst tun, was notwendig ist.
Man kann es nicht allen recht machen, bzw. ists dann stark aufgeblasen,
und teilweise komplizierter, als wenn man direkt auf die Register geht
:-)
Ich hab den HAL Kram noch nicht verwendet - aber soll das nicht
eigentlich dazu da sein, dass es einfacher mit einem RTOS zu nutzen ist?
Könnte auch ein Grund sein warum manches etwas aufgeblasen ist - ist im
Linux Kernel ja auch so ;-)
Hallo,
wir arbeiten überwiegend auch mit den Standard Bibliotheken von ST. Im
großem und ganzem kann man damit schon recht gut arbeiten. Es kommt aber
drauf an welchen Core Typen du verwenden willst.
Ich persönlich bin vom STM32F0 mittlerweile etwas enttäuscht. Er macht
zwar alles was man will, aber einige Sachen sind nicht so komfortable
wie ich es von anderen Controllern, auch abseits des Arm Bereiches,
kannte.
Beispiele die mir auf Anhieb einfallen wo wir doch arg gekämpft haben:
- EEproms mit 1Mbit bzw mit mehr als 10bit Adressraum lassen sich nicht
besonders gut via I2C an den F0 anbinden. Das Funktioniert so nicht.
Scheint aber mehr an der Hardware als an den Libs zu liegen. Da muss man
schon reichlich in die Trickkiste greifen.
- Das Alligment bei den AD Werte lässt sich über die libs nicht
vernünftig einstellen. Was wir auch taten, es war immer links
ausgerichtet. Da half nur manuelles schieben.
- Bei Umstellung des Controllers auf einen größeren mit gleichem Pinning
haben sich die Zuordnung der SPIs verändert (trotz gleichem Pinnings
wurde aus SPI1 -> SPI2)- damit auch die Zuordnung der DMAs. Das habe ich
nicht mehr ans laufen bekommen via DMA. Mit der neuen DMA Nummer ging
das dann aber gar nicht mehr.
- Generell hat sich DMA und SPI als Slave sehr zickig angestellt und
immer die ersten 2 Bytes beim senden verschluckt.
- Nen vernünftigen Zufallsgenerator gibt es auch nicht. Hier muss man
auch tricksen.
Wir haben in jedem dieser Fälle die libs verwendet und sind an Grenzen
gekommen.
Also zumindest den F0 Typen finde ich relativ zickig. Kollegen haben
aber schon mit anderen ST Arm Derivaten gearbeitet und sind sehr zu
Frieden gewesen. Kommt aber sicher auf die Anwendung an die man hat. Für
viele unser Anwendungen reicht das Ding aber voll aus. Es kommt eben
immer drauf an was man tun will...
Grüße
Jens
Die STM32F4 und STM32F7 haben eine identische SDIO-Peripherie u.a. zur
Kommunikation mit SD-Karten (bis darauf dass im F7 ein paar
Hardware-Bugs gefixt sind). Leider hat sich irgendein Schlaumeier
ausgedacht, die beim F7 nach "SDMMC" umzubenennen. Dementsprechend sind
auch die HAL-Funktionen umbenannt - somit kann man mit der STM32-HAL
nichtmal die gleiche Peripherie auf unterschiedlichen Controllern mit
dem selben Code nutzen! Das ist für mich keine Hardware-Abstraktion.
Weiteres Beispiel: Die GPIO-Peripherie der F1 und der F4 unterscheiden
sich. Dementsprechend sind auch die HAL-Funktionen unterschiedlich, und
man kann den gleichen Code nicht auf beiden Controllern verwenden.
Somit ist mit der "HAL-Library" nichts gewonnen, da kann man aus den
oben bereits genannten Gründen lieber direkt auf die Register
zugreifen...
Also privat nutze ich gern ChibiOS/RT bzw. ChibiOS HAL:
http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:hal:start
Der Abstraktionsgrad ist hier schon sehr hoch, im beruflichen Umfeld hab
ichs bisher nur für kleine Prototypen genutzt, bei der ich sehr schnell
eine funktionierende Lösung brauchte...
Hat hier schon jemand Erfahrung bei größeren Projekten gesammelt?
Vincent H. schrieb:> HAL macht:> - Initialisierung mit Enum Klarnamen
Das könnte man auch haben, wenn ST gescheite Header ausliefern würde,
die für Bitfelder in Registern benannte Konstanten enthalten.
Hallo,
dass es mit CubeMX ein Programm gibt bei dem man Pins zuordnen kann und
ein Codegeruest mit Initialisierung erzeugen kann finde ich schon ganz
praktisch. Die HAL Treiber sind dann jedoch schon mit Vorsicht zu
geniessen. Damit der USB Device Port eines STM32L1 funktionierte habe
ich mal ewig gesucht. Da kommt man dann auch nicht darum herum
Datenblaetter zu studieren und schauen was welches Bit in welchem
Register bedeutet.
Die Performanz wird zwar durch Compiler-Optimierung schon sehr gut,
jedoch ist hald von Hand immer noch ein wenig schneller.
Wer Zeitunkritisches machen will und wenn es fertige funktionierende
Funktionen (z.B. PWM-Erzeugung mit einem Timer, Daten mit UART im
Interrupt-Modus versenden, etc.) gibt kann hier durchaus zu HAL greifen.
Wenn es aber ins eingemachte geht kommt man mit HAL schnell an die
Grenzen bzw. an die Bugs...
Cheers
Matthias K. schrieb:> Also privat nutze ich gern ChibiOS/RT bzw. ChibiOS HAL:> http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:hal:start
Ja, das nutze ich auch gerne. Im Gegensatz zu dem "HAL" von ST bekommt
man hier wirklich eine echte Abstraktion geboten.
Nachteil ist daß nicht alle Details der Peripheriemodule unterstützt
werden. Z.B. kann man im Chibios-HAL den Ausgang der Komparatoren nicht
direkt als Stop fürs PWM verbinden.
Wenn ich sowas brauche, setze ich an dieser Stelle das Register direkt.
Zusätzlich kommt ein einheitlich formatierter Kommentar an die Stelle.
So kann ich alle betroffenen Stellen mit einem grep ruckzuck im gesamten
Projekt finden, den Anpassungsaufwand abschätzen und bei Bedarf auch
schnell migrieren.
Bastler schrieb:> Matthias K. schrieb:>> Also privat nutze ich gern ChibiOS/RT bzw. ChibiOS HAL:>> Hallo,>> darf ich Fragen wie lange du dich einarbeiten musstest?
Sehr sehr kurz (~ 2 Hobby-Tage). Wobei meine bisherige Anwendungen eher
klein sind/waren.
Ich muss eher sagen, dass ich mich mit den Controllern (STM32F407 und
STM32F3103) bzw. der Architektur selber noch zu wenig beschäftigt habe.
Beispiel: Lichtwecker mit RGBW-Dimmer mit IRMP, kleiner Shell. Vieles
geht eben schon einfach out-of-the-box.
Oder ein kleiner Stimulator für eine unserer Industriesteuerungen
(einlesen von 5x ADC, phasenverschobene Frequenz erzeugen, CAN-Bus
senden/empfangen ...). Ich musste mich dazu kaum mit den Datenblättern
beschäftigen, sondern hatte das ganze Ding innerhalb von ein paar
Stunden fertig. Inklusive komfortabler Cmd-shell...
Klar hätte man das alles mit einem 8bit Controller machne können und
ganz sicher auch "bare-metal" mit dem STM32.
Ich persönlich fand die ST-lib eher abschreckend, da ich das gefühlt
hatte dass eigentlich nur die Register in structs gepresst sind ohne
wirkliche Abstraktion. Könnte aber auch nur ein Vorurteil sein, da ich
mich nie wirklich damit befasst habe..
Gerd E. schrieb:> Nachteil ist daß nicht alle Details der Peripheriemodule unterstützt
Ja das stimmt leider. Aber dafür ist der Rest wirklich durchdacht und
sehr sauber. Ich fand mich im Code sehr schnell zurecht.
Eine USB-Host Funktion gibt es z.B. auch nicht. Genauso fehlt I2C Slave
und SPI Slave...
Wir nutzen die HAL auch.
Aber so richtig sind wir trotzdem nicht überzeugt!
Beispiel:
Im UART Interrupt führt der HAL ein obligatorisches Flush aus, man
könnte ja in der recv vergessen das Byte zu holen...
Finde ich nicht sauber, bei schneller UART und langsamer Clock. So ist
die HAL teilweise so ineffektiv, dass es ein Byte wegflusht.
Trotzdem denken wir, wenn nur wir an der Lib arbeiten, dann ist es noch
wahrscheinlicher Fehler im Quellcode zu haben.
Ob wir nun Fehler im HAL suchen oder im eigenen Quellcode ist dann
soweit auch egal!
Bastler schrieb:>> Also privat nutze ich gern ChibiOS/RT bzw. ChibiOS HAL:> darf ich Fragen wie lange du dich einarbeiten musstest?
Ich fand die Einarbeitung ins ChibiOS, also sowohl das HAL, als auch das
RT oder NIL, ziemlich schnell machbar. Innerhalb von wenigen Stunden
kann man da richtig loslegen, also nicht nur ein Blinky, sondern mehrere
Threads, die untereinander mit Events kommunizieren, Locking, etc.
Zum Einstieg empfehle ich unbedingt das hier:
http://chibios.org/dokuwiki/doku.php?id=chibios:book:start
Karl schrieb:> Allerdings gehe ich bei etwas, das sich HAL nennt> eigentlich davon aus, dass es die Hardware auch tatsächlich abstrahiert> und nicht nur Register umbenennt und verschleiert was eigentlich> passiert.
Eben.
Das Zeugs, was ST da verzapft hat, ist nur zusätzlicher Ballast, der
auch noch Bugs mit sich bringt. Deswegen benutze ich dies nicht.
Es sind ja nicht nur die vielbeschworenen Bugs, die man lieber im
eigenen Code sucht als in Fremdcode, es ist vor allem die viele
Schaumschlägerei um nichts. Eben Registerumbenennerei.
W.S.
Und wehe dem, der manche hal Funktionen in der nicht von St gewünschten
Reihenfolge aufruft. Da musste dann eh jedes mal die Funktionen komplett
durchblättern um sicherzugehen, dass der fehler nicht am "eigenen" code
liegt.
Aber Holla,
da hat sich einiges angstaut...
Vielen Dank erstmal für die guten Hinweise.
Ich weis jetz ungefähr wo die Reise hingehen muss.
Werde mich wohl weiterhin in den "Niederungen" bewegen ;-)
Viele Grüße
Runout
Was ist DMA_REQUEST_2? Die ganzen Felder, die da gefüllt werden sind 1:1
auf die Register der Pheripheral gemünzt.
Aber das eigentlich Problem ist, dass die Hardware nicht abstrahiert
wird. Wenn ich eigentlich eine UART habe und von der Daten empfangen
möchte, dann möchte ich eigentlich beschreiben, in welcher Granularität
ich Daten vorgelegt bekommen möchte. Ob die MCU nun DMA kann und mein
Problem evtl. am besten unter Verwendung der DMA gelöst wird, ist mir
doch egal.
Die HAL bekommt es ja nicht mal hin, dass ich nicht im Datenblatt
nachschlagen muss, das DMA in 2 Einheiten mit mehreren Kanälen arbeitet
und ich muss dann raus suchen, welcher Kanal nun derjenige ist, denn
ich verwenden muss, wenn ich den an eine UART ran binden möchte.
Ich denke das mit der Abstraktion kann man noch deutlich hoher ansetzen,
als knapp über der Register-Nabe ;-) Und dann würde es die Produktivität
auch deutlich erhöhen.
mfg Torsten
Thomas T. schrieb:> Wie ist eure Meinung zu "To HAL or not to HAL"?
für mich ganz klar: NOT TO HAL
HAL gaukelt einen vor dass man sich um die HW Niederungen
nicht mehr kümmern muss und mit Cube x ist sowieso alles easy going.
Meistens läuft es doch so, dass man den CUBE x verwendet um
die Anschlüsse des Prozessors zu sortieren (dieser Teil ist sehr
gut) der Rest ...
Die Intialisierung geschieht dann mit HAL d.h. wenn ich es richtig
verstanden habe muss ich den Rest mit HAL weitermachen.
Wenn man nun eine anspruchsvolle I2C Schnittstelle realisieren muss
( z.B. EEPROM , Bausteine ) dann startet mann damit, das man sich
bei Google von überall Beispiele zusammen kopiert
und daraus dann ein Geflickwerk implementiert.
Mit der Folge dass nichts funktioniert.
Spätestens zu diesem Zeitpunkt muss man nun doch in die
HW NIEDERUNGEN einsteigen !
Warum dann nicht gleich unten einsteigen ?
wie mach ich es ?
zuerst mal 3 Bildschirme am PC anschliessen.
Auf den Linken das Referenzmanuel des entsprechenden Prozessors legen.
in der Mitte die Coocox IDE und auf den Rechten
die Beispiel Suchergerbnisse von "LOW End" Anwendungen.
Und dann: DIY .
Der Weg ist steinig aber es geht von mal zu mal besser.
Irgendwann ist man dann schneller wie die HAl'er ;-)
Nochmals: ich bin kein Glaubensverfechter
und wenn jemand mit HAL bestens zu recht kommt dann sei es ihm gegönnt.
Sepp aus Hintertupfing
zumindest bei der STM32L4-Serie gibt es keine Alternative...
Entweder mit CubeMx oder "from the scratch".
CubeMx hat auch noch einen Low-Level-Treiber (LL)
aber da heißt es erst Mal: reinlesen...
Viele Grüße
Runout
Ich hatte mir letztens mal libopencm3 für USB angesehen und war recht
überzeugt.
- Deutlich übersichtlichere API
- git pull , make und das Beispiel baut
- beispielcode verwendet designated initalizers für deskriptoren
Mit POSIX/Linux-Hintergrund wird man sich bei libopencm deutlich
heimischer fühlen als bei der HAL von ST. KISS, Worse is better und so
internen ST mitarbeitern zu folge ist eine LL auch fpr die STM32F4 für
2017 geplant.
aus den bisherigen Erfahrungen würde ich je nach projekt größe entweder
ChibiOS/HAL oder CubeMX einsetzen.
eine weitere alternative wäre die libopenCM3, da habe ich aber bisher
keine Erfahrung.
Stefan K. schrieb:> Aber besser einmal zu viel geklammert als zuwenig (alte> Kieferorthopäden-Weisheit).
Ich frage mich eher ob da nicht eine der Klammern an anderer Stelle sein
müsste - aber ohne den Kontext zu kennen ist das schwer zu sagen. Also
sowas:
Micha schrieb:> Stefan K. schrieb:>> Aber besser einmal zu viel geklammert als zuwenig (alte>> Kieferorthopäden-Weisheit).>> Ich frage mich eher ob da nicht eine der Klammern an anderer Stelle sein> müsste - aber ohne den Kontext zu kennen ist das schwer zu sagen. Also> sowas:>
1
>hi2c->Instance->TXDR=(*pData)++;
2
>
Sicher nicht. Damit würde der Wert, der bei *pData steht erhöht werden,
bevor er ins Senderegister kommt.
Das Ziel wird aber ganz sicher sein, den Lesepointer nach dem
dereferenzieren um eine Adresse weiterzuschieben.
Micha schrieb:> Ich frage mich eher ob da nicht eine der Klammern an anderer Stelle sein> müsste - aber ohne den Kontext zu kennen ist das schwer zu sagen. Also> sowas:>
1
>hi2c->Instance->TXDR=(*pData)++;
2
>
Naja, wenn wir mal davon ausgehen, dass der Code "merkwürdig" aber
Fehlerfrei ist, dann meinte der Autor bestimmt:
1
hi2c->Instance->TXDR=*(pData++);
dann würden die Klammern zwar immer noch überflüssig sein, aber beim
Lesen helfen.
Ich würde dann aber immer:
Sepp aus Hintertupfing schrieb:> Nochmals: ich bin kein Glaubensverfechter> und wenn jemand mit HAL bestens zu recht kommt dann sei es ihm gegönnt.
Da stimme ich dir zu, aber ich hab darüberhinaus noch einige andere
Bedenken und Ansichten. Da ist z.B., daß man sich mit allen solchen
Dingen wie ST-Lib, CMSIS und Konsorten ja nicht nur ne Menge
zusätzlichen Zeuges inclusive tonnenweise zusätzlicher Identifier
reinzieht, man zieht auch ganz leicht jedoch unbeabsichtigt einiges an
ungewollten Bibliotheksfunktionen in sein System mit hinein. Ich habe in
der Vergangenheit des öfteren sowas wie _main und __main und _break und
Konsorten gehabt, die schlußendlich dafür gesorgt haben, daß mein System
nicht so läuft, wie gewollt. Also Vorsicht mit sowas.
Weiters sieht es ja so aus, daß man - wenn man kein wirklich blutiger
Anfänger ist - bereits ein ziemliches Portfolio an Peripherie-Treibern
und hardwareunabhängigen Units hat, die man recht leicht weiterverwenden
kann. Stellenweise sogar herstellerübergreifend - ich denke grad an die
SD-Karten-Treiber von NXP, die man auch für die STM32 benutzen kann.
Solche Treiber, die die HW tatsächlich abstrahieren, sind allemal
nützlich - aber jedes Zeugs, daß aus einem Bit eines HW-Registers zwei
#defines macht und sonst nichts weiteres dazu beiträgt, verdient die
Bezeichnung HAL nicht. Das ist der Knackpunkt.
W.S.
W.S. schrieb:> ...- aber jedes Zeugs, daß aus einem Bit eines HW-Registers zwei> #defines macht und sonst nichts weiteres dazu beiträgt, verdient die> Bezeichnung HAL nicht.
Das ist doch gerade der Punkt an Hardware Abstraction Layers. Und die
von dir so gefürchteten Unmengen an #defines werden von jedem mindestens
mittelmäßigen Compiler ohne weiteres beherrscht und in der sehr großen
Mehrheit aller Fälle mindestens so performant übersetzt wie geekige
unlesbare Bitschieberei.
Di P. schrieb:> Das ist doch gerade der Punkt an Hardware Abstraction Layers.
Nein, das ist es eben nicht. Das schiere Erzeugen von zusätzlichen
Bezeichnern ist eben keine Hardware-Abstraktion.
Di P. schrieb:> Und die> von dir so gefürchteten Unmengen an #defines werden von jedem mindestens> mittelmäßigen Compiler ohne weiteres beherrscht..
Ja klar, aber der Compiler schreibt keinen Quellcode, sowas macht ein
Mensch (jedenfalls in den meisten hier vorliegenden Fällen). Kurzum,
es geht nicht um die Bedürfnisse und Grenzen eines Compilers, sondern um
die Bedürfnisse und Grenzen des Menschen.
Grad eben haben wir hier in einem anderen Thread jemanden, der
verzweifelt nach einer Funktion in seiner ST-Lib sucht, um mehrere
Portpins zu setzen - bloß weil er vor lauter Pseudo-HAL der ST-Lib den
Wald vor Bäumen nicht zu sehen vermag.
W.S.
W.S. schrieb:> Grad eben haben wir hier in einem anderen Thread jemanden, der> verzweifelt nach einer Funktion in seiner ST-Lib sucht, um mehrere> Portpins zu setzen - bloß weil er vor lauter Pseudo-HAL der ST-Lib den> Wald vor Bäumen nicht zu sehen vermag.
Weiß jetzt nicht was an
1
HAL_GPIO_WritePin(
2
GPIOA
3
,GPIO_PIN_0 | GPIO_PIN_3 | GPIO_PIN_7
4
,GPIO_PIN_SET
5
);
so schwierig ist.
Man muss halt - wie immer - den Kopf anschalten, und eine grobe Ahnung
davon haben, was man tun möchte. Den kurzen Blick in die Implementierung
erspart auch kaum eine andere Lib.
Zum Bits setzen / löschen bietet sich bei der STM32-Familie das
BSRR-Register an. Damit kann man atomar beliebig viele Pins eines Ports
setzen UND/ODER löschen:
GPIOx_BSRR (x = A..I/J/K)
In den oberen 16 Bit des Registers werden alle Portpins markiert, die
verändert werden sollen. In den unteren 16 Bits wird der gewünschte
Pegel des Portpins eingetragen.
Es gibt eine HAL-Funktion, die dieses Register benutzt:
void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin,
GPIO_PinState PinState)
Leider beschneidet diese Funktion völlig die Möglichkeiten, die das
BSSR-Register bietet.
Mit dem BSSR-Register lassen sich übrigens auch hervorragend einzelne
Pins oder Pingruppen per DMA modifizieren (set/reset). Zusammen mit
einem Timer lassen sich so sehr komplexe Signalformen komplett ohne
CPU-Intervention realisieren.
Gruß, Stefan
Stefan K. schrieb:> Leider beschneidet diese Funktion völlig die Möglichkeiten, die das> BSSR-Register bietet.
Nur dass du nicht gleichzeitig Pins setzen und löschen kannst. Wer das
Vorhat kann ja das BSRR einfach benutzen. Es mag Fälle geben, in denen
das nötig ist, aber ein Großteil der Anwender wird auch mit zwei
HAL-Aufrufen gut bedient sein. Wer eine DDS aufbauen möchte, wird das
wohl kaum mit HAL-Funktionen machen.
Di P. schrieb:> Nur dass du nicht gleichzeitig Pins setzen und löschen kannst.
Das ist noch gar nicht einmal das, was mich am meisten stört.
Erstens suggeriert die HAL-Beschreibung, dass mit dieser Funktion nur
ein Pin modifiziert werdn kann, und dass die Pin-Nummer und nicht die
Pin-Maske übergeben werden muss.
Zweitens wird in der Funktion eine if-else-Konstruktion verwendet, die
bei einer geschickteren Definition einfach überflüssig gewesen wäre:
Auszug aus der HAL-Library:
1
/**
2
* @brief Sets or clears the selected data port bit.
3
*
4
* @note This function uses GPIOx_BSRR register to allow atomic read/modify
5
* accesses. In this way, there is no risk of an IRQ occurring between
6
* the read and the modify access.
7
*
8
* @param GPIOx: where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
9
* x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
10
* @param GPIO_Pin: specifies the port bit to be written.
11
* This parameter can be one of GPIO_PIN_x where x can be (0..15).
12
* @param PinState: specifies the value to be written to the selected bit.
13
* This parameter can be one of the GPIO_PinState enum values:
Aber Du hast schon Recht: für den letzten Performance-Kick ist die HAL
nicht konzipiert. Und der größte Vorteil des BSRR, der atomare Zugriff
auf einzelne Portpins, wird damit auch erreicht.
Gruß, Stefan
Stefan K. schrieb:> In den oberen 16 Bit des Registers werden alle Portpins markiert, die> verändert werden sollen. In den unteren 16 Bits wird der gewünschte> Pegel des Portpins eingetragen.
Hö?
Also vielleicht mache ich das ja verkehrt, aber ich setzte die Bits in
den ersten 16bit und lösche in den letzten 16bit.
Aber vielleicht ist mein STM32F411 ja anders...
Nico W. schrieb:> Also vielleicht mache ich das ja verkehrt, aber ich setzte die Bits in> den ersten 16bit und lösche in den letzten 16bit.
Stimmt, sorry für die falsche Beschreibung.
Gruß, Stefan
Thomas T. schrieb:> zumindest bei der STM32L4-Serie gibt es keine Alternative...> Entweder mit CubeMx oder "from the scratch".> CubeMx hat auch noch einen Low-Level-Treiber (LL)> aber da heißt es erst Mal: reinlesen...
An der Stelle war ich die Tage auch gestanden:
Ich hatte eine Firmware fertig auf F407 laufen und wollte zur
Kostenoptimierung mal kurz auf L476 umsteigen.
Da die F4-Anwendung auf vor-HAL-Bibliotheken basierte, habe ich mich
beim L476 erstmal wahnsinnig gefreut.
Aber tatsächlich kann man vorhandene Firmware relativ einfach auf LL
übertragen. "relativ einfach" heißt in diesem Fall, dass praktisch JEDES
Register, JEDE Funktion und JEDES Makro umbenannt wurde. Mit so
Highlights wie "DAC_SetChannel2Data" ->
"LL_DAC_ConvertData12RightAligned".
Ende von Lustig war dann die PLL-Programmierung. Dafür habe ich keine
kompakte Funktion gefunden. Da ist mir dann die Geduld ausgegangen und
ich habe das PLLCFG-Register in einer Zeile direkt mit der Info aus dem
Datenblatt programmiert, statt hunderte von Codezeilen aus der HAL zu
übernehmen.
Mein Fazit:
- Ein bestehenden Projekt auf HAL umzurüsten dauert länger als neu
schreiben.
- Ein bestehendes F4-Projekt auf den L4 zu portieren geht mittels LL und
ein paar selbstgeschriebenen #defines in endlicher Zeit.
- beim Projektstart muss man sich entscheiden, was man vom STM32 will:
- einen high-Performance Hack -> LL
- eine Applikationsentwicklung, an die fremde Middle-Ware / Treiber
angeschraubt werden sollen -> HAL
Ich finde grade die Quelle nicht, aber in einer Präsentation bezeichnet
STM die Portierung von F4-alt nach L4-HAL als "hard".
Worst understatement ever...
Hallo Marcus,
danke für die Info.
Es gibt die STM AN4616 "Migrating from STM32F401/411 lines to STM32L4
Series
microcontrollers".
Wenn alles schon mal HAL-basiert ist ginge angeblich der Umzug F4->L4
rucki-zucki...
Aber wer braucht das schon jeden Tag.
In deinem (typischen) Fall ist Neu-Aufsetzen angesagt.
Grüße Runout
Hi Thomas,
danke für den Link. Das war nicht das Dokument, das ich meinte, aber das
sollte man gesehen haben, bevor man die Umstellung angeht.
Für die Umstellung F4-alt nach L4-HAL habe ich ca. einen guten Manntag
gebraucht, allerdings war das natürlich nur eine Untermenge der Treiber
und die meiste Zeit war Lesen und Verstehen, was STM uns da serviert
hat.
Langjährige Erfahrung mit der STM32-Hardware war dafür nicht schädlich.
Ich habe das Zählen aufgegeben, aber seit 2009 hatten wir mehrere
Umbrüche im Firmware-Framework. Und jedesmal wird meine Liebe zu dieser
wirklich tollen MCU-Familie auf eine harte Probe gestellt.
Zur Wartung von verschiedenen langlebigen Produkten bleibt einem nichts
anderes übrig, als mehrere Codestämme mit ähnlicher Funktion parallel zu
pflegen. seufz
Grüße,
marcus
Hallo zusammen,
wir steigen zurzeit von der Std-Periph.-Library auf die HAL mit CubeMX
um und versuchen so weit wie möglich Tutorials zu schreiben..
- SPI: http://blacbird.de/tutorial-stm32-cubemx-spi
- SDIO + FATFS: http://blacbird.de/tutorial-stm32-cubemx-sdio
Im Grunde hat sich die Qualität der Bibliothek (und vor allem CubeMX) im
Vergleich zum Anfang sehr stark verbessert und für Standard-Funktionen
kann man es mittlerweile tatsächlich verwenden.
Vielleicht können unsere Beiträge dem einen oder anderem bei seiner
Entscheidung helfen, wir sind aber derzeit doch ziemlich zufrieden.
PS: Wir haben mit diesen Artikeln erst angefangen und werden diese auch
noch ergänzen, deswegen sind Verbesserungsvorschläge immer willkommen!
Viele Grüße,
Fabian
Hi Fabian,
Fabian B. schrieb:> wir steigen zurzeit von der Std-Periph.-Library auf die HAL mit CubeMX> um und versuchen so weit wie möglich Tutorials zu schreiben..
was ich mich bei so etwas immer frage, ist: bin ich der einzige der mit
anderen Kollegen zusammen an Projekten arbeite und
Quellcode-Verwaltungen verwende?
Was passiert, wenn ein Kollege einen Pull-Up Widerstand falsch
konfiguriert und das eincheckt. Kann man das am Commit erkennen oder
erscheint das nur als eine kaum erkennbare Änderung an einer kryptischen
XML-Datei?
mfg Torsten
Hallo Torsten,
nehmen wir mal genau deinen Fall an (siehe Beispiel). Es ändert sich
natürlich das "kryptische" cubeMX-File, aber auch der generierte
Source-Code, und der ist eigentlich gut verständlich (bei default
Einstellungen in der main.c zu finden):
Konfigurierter Pulldown (siehe Kommentar):
Wir verwenden SVN und solche Fehler sind durch einen Vergleich mit alten
Version schnell gefunden. Wichtig ist aber, dass das CubeMX-File und der
generierte Code in der Versionsverwaltung zusammenpassen!
Viele Grüße,
Fabian
Fabian B. schrieb:> Wir verwenden SVN und solche Fehler sind durch einen Vergleich mit alten> Version schnell gefunden. Wichtig ist aber, dass das CubeMX-File und der> generierte Code in der Versionsverwaltung zusammenpassen!
Normalerweise checkt man generierte Files nicht in das VCS ein. Genau
deswegen, weil man dann die Konsistenz separat prüfen muß. Prinzipiell
kann man solche Checks zwar über die entsprechenden Hooks nachrüsten [1]
aber es ist halt extra Arbeit für kaum einen Gegenwert.
[1]
http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.pre-commit.html
wir haben damit bei einem früheren AG mal eine statische Syntaxprüfung
gemacht, weil es immer wieder Deppen gab, die Code einchecken wollten
der es nicht mal durch den Compiler schaffte.
Axel S. schrieb:> Normalerweise checkt man generierte Files nicht in das VCS ein. Genau> deswegen, weil man dann die Konsistenz separat prüfen muß. Prinzipiell> kann man solche Checks zwar über die entsprechenden Hooks nachrüsten [1]> aber es ist halt extra Arbeit für kaum einen Gegenwert.
Und wie macht ihr dass dann, wenn sich jemand das aktuelle Projekt
herunterladen möchte (neuer Entwickler z.B.), mit der Code-Generierung
aber nichts zu tun hat (wir nutzen wirklich nur die Grundfunktionen von
SVN, sry falls ich da ein offensichtliches Feature übersehe)?
Meiner Meinung bietet CubeMX den Vorteil, dass sich auch Leute, die
nichts mit den unteren Schichten zu tun haben, über die GUI einen
Überblick über die verschiedenen Funktionen (oder Taktraten von
Peripherien) verschaffen können (spricht meiner Meinung nach dafür das
CubeMX-File mit hochzuladen).
Die Grundkonfiguration des Chips zum Projekt wird bei uns meist von
einer Person betreut und durchgeführt (der Großteil der Arbeit steckt ja
dann doch in der Applikation), weswegen die Konsistenz dann zwangsläufig
gegeben ist (ist bei großen Unternehmen sicher ein relevanteres
Problem).
Viele Grüße,
Fabian
Fabian B. schrieb:> Vielleicht können unsere Beiträge dem einen oder anderem bei seiner> Entscheidung helfen, wir sind aber derzeit doch ziemlich zufrieden.
Wir nutzen die neue HAL in verschiedenen Produkten.
Unser Fazit: Die Qualität ist eine reine Katastrophe. Sobald du von den
einfachen Standard-Funktionen abweichst, findest du schnell üble Bugs.
USB ist nahezu nicht verwendbar, da werden teilweise kritische Flags
nicht gesetzt/zurückgesetzt.
Stellenweise sind wir dazu übergegangen, uns eine eigene HAL zu
implementieren. Die Zeit, die hierfür drauf geht, sparen wir uns später
bei der Bug-Suche doppelt und dreifach.
Examples kompilieren teilweise nicht und sind stellenweise einfach
fehlerhaft.
Davon kann ich noch duzende mehr aufzählen.
Also im Hinterkopf behalten: Wenn's nicht läuft, liegts mit oher
Warscheinlichkeit nicht an euch :-)
ac1 schrieb:> Davon kann ich noch duzende mehr aufzählen.
Zusatz:
Es empfiehlt sich, die offiziellen STM32-Foren zu lesen (alle Beiträge
der letzten 6 Monate) um ein Überblick über die kritischsten Bugs zu
bekommen.
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx
Irgendwo gibt es auch noch eine gigantische Liste an Fehlern in der
STM32 Chip Dokumentation. Den hab ich gerade leider nicht griffbereit.
Fabian B. schrieb:> Axel S. schrieb:>> Normalerweise checkt man generierte Files nicht in das VCS ein. Genau>> deswegen, weil man dann die Konsistenz separat prüfen muß. Prinzipiell>> kann man solche Checks zwar über die entsprechenden Hooks nachrüsten [1]>> aber es ist halt extra Arbeit für kaum einen Gegenwert.>> Und wie macht ihr dass dann, wenn sich jemand das aktuelle Projekt> herunterladen möchte (neuer Entwickler z.B.), mit der Code-Generierung> aber nichts zu tun hat
Gar nicht. Wer unfähig oder unwillig ist, den Codegenerator
anzuschubsen, der kann dann halt nicht aus dem Repo bauen, sondern muß
ein Release oder Nightly verwenden.
Wobei ich persönlich ja einen eher weiten Bogen um alles mache, was nur
aus der GUI geht. Der komplette Buildvorgang muß von der Kommandozeile
funktionieren. Dann kann man den auch in ein Makefile oder Build-Skript
verpacken, was dann wieder die Hemmschwelle für Dritte senkt.
Keine Ahnung wie es in diesem Punkt bei CubeMX aussieht.
Dennis X. schrieb:> Hammer! Danke man! Gerade SDIO finde ich interessant. Werde mir das bei> Zeit mal durchlesen.
Vielen Dank, wobei der Artikel zeitnah noch ergänzt wird, da noch zu
oberflächlich (vor allem im Bezug auf die Einstellmöglichkeiten der
FATFS).
Marcus H. schrieb:> - beim Projektstart muss man sich entscheiden, was man vom STM32 will:> - einen high-Performance Hack -> LL
"high performance hack" - der Ausdruck gefällt mir. :-)
Hi Fabian,
Fabian B. schrieb:> Und wie macht ihr dass dann, wenn sich jemand das aktuelle Projekt> herunterladen möchte (neuer Entwickler z.B.), mit der Code-Generierung> aber nichts zu tun hat (wir nutzen wirklich nur die Grundfunktionen von> SVN, sry falls ich da ein offensichtliches Feature übersehe)?
Das man generierte Binaries / Artefakte irgendwo ablegt, damit andere,
die nicht so tief in der SW-Entwicklung stecken, diese nutzen können,
ist hilfreich. Aber:
Wenn jetzt jemand im Team meint, er möchte nur die Hälfte generieren,
die andere Hälfte möchte er sich aus irgend einem Repository ziehen (die
Quellcodeverwaltung ist dafür ungeeignet) finde ich "ungewöhnlich". Es
kommt doch auch keiner auf die Idee und installiert nur den Linker und
erwartet, dass die passenden Object-Files mit im Repo abgelegt sind.
> Meiner Meinung bietet CubeMX den Vorteil, dass sich auch Leute, die> nichts mit den unteren Schichten zu tun haben, über die GUI einen> Überblick über die verschiedenen Funktionen (oder Taktraten von> Peripherien) verschaffen können (spricht meiner Meinung nach dafür das> CubeMX-File mit hochzuladen).
Den Vorteil würde ich Dir auch nicht absprechen. Ich würde Ihn mir aber
nicht gegen den Nachteil, dass ich Änderungen nicht mehr an einem Diff
erkennen kann und meinen build wahrscheinlich(?) nicht mehr
automatisieren kann, erkaufen. Build-Artefakte im SCV abzulegen, könnte
ich mir nur vorstellen, wenn die automatisch mit irgend einem
commit-hook aktualisiert werden (das bedingt aber, dass man die
überhaupt automatisiert bauen kann).
Selbst die kleineren Projekte an denen ich so beteiligt war, hatten
meist mehr als ein build target. (Die Firmware für den einen Controller
vom Hersteller A, die Firmware auf dem anderen Controller von Hersteller
B. Das Test-Tool auf dem PC. Die Unit-Tests auf dem PC usw.) Wenn man da
für jedes Artefakt eine GUI braucht, bekommt man automatisierte builds
nur sehr schwer hin.
mfg Torsten
Da Cube Code generiert, welcher durch den Anwender gepflegt werden soll,
erübrigt sich fast die Frage, ob dieser Code einzuchecken ist.
/* USER CODE BEGIN Includes */
/* USER CODE END Includes */
Oft genug wird auch in Fehlern im HAL Code berichtet, der ggf.
korrigiert wird.
Wir nutzen Cube nur zur initialen Erstellung des Codes, welcher dann
durch uns weiterbearbeitet wird.
Das sind die Gründe, warum wir den von Cube erstellten
(Hardwareanpassung) bzw. umkopierten (HAL, USB) Code einchecken.
Ansonsten gehe ich auch in den meisten Fällen so vor, dass generierter
Code nicht extra eingecheckt wird.
Ich finde diese Debatte schon Grenzwertig. Wenn gleich sie nicht neu
ist, wie hier unschwer zu erkennen ist, ist sie noch immer aktuell.
Was man bei all dieser Argumente pro und kontra zu HAL/STDLIBS noch
ergänzen muss ist, dass die STDLIBS nur bis F4 verfügbar sind - sie sind
obsolete. Es gibt eben nur die Wahl zwischen HAL_LL und HAL. Das CMSIS
mit oder ohne OS hat mit dem HAL erstmal nichts zutun.
Was der CUBEMX da raushaut ist bestenfalls als Tutorial geeignet.
Die zusammengehauene Baustelle aus Eclipse, CubeMX und Compiler
toolchain names CubeIDE 1.01 ist grauenhaft. Atollics Umgebung war nie
mein Liebling, jedoch dass, was ST da nun aus dem TrueStudio und CubeMX
zusammengebacken hat, will man nicht haben. Erst recht nicht dass, was
das Zeug produziert.
Mir gefällt derzeit nur WinIDEA-OPEN und Segger Embedded-Studio (Rowley
Crossworks). Die Segger-Variante hat schon ihren Scharm.
Code generieren sie nicht, schaffen aber ein Framework aus den genannten
Komponenten und bauen ein Projekt daraus.
Juppeck schrieb:> Ich finde diese Debatte schon Grenzwertig.
Ich finde deinen Beitrag schon grenzwertig.
Da er erst nach drei Jahren auf das Thema eingeht.
Ich persönlich finde Leute grenzwertig, die nicht mal lesen können aber
schon maulen.
:-)
Juppeck schrieb:> Ich finde diese Debatte schon Grenzwertig. Wenn gleich sie nicht neu> ist, wie hier unschwer zu erkennen ist, ist sie noch immer aktuell.Au Weia schrieb:> Ich finde deinen Beitrag schon grenzwertig.>> Da er erst nach drei Jahren auf das Thema eingeht.
Wie dem auch sei. Wir haben in der Firma vor etwa 10 Jahren auf Cortex-M
umgestellt und alle Bibliotheken komplett selbst geschrieben.
Wir haben es nicht bereut...
Dennis schrieb:> Wie dem auch sei. Wir haben in der Firma vor etwa 10 Jahren auf Cortex-M> umgestellt und alle Bibliotheken komplett selbst geschrieben.
Dann hat eure Bibliothek sicher schon länger bestand, als die drei von
ST.
Stefanus F. schrieb:> Dann hat eure Bibliothek sicher schon länger bestand, als die drei von> ST.
Das hat es...
Ist halt der Vorteil, wenn man eine Bib nicht nur zu Marketingszwecken
von ein paar Studenten erstellen lässt (und dann vom Erfolg überrascht
wird) sondern gleich von Anfang an drei Profis ransetzt. Unser Chef
damals war auch einer, der mit dem 8048 angefangen und mit dem 8051 groß
geworden ist und wusste worauf es ankommt. Genug Budget, 4 Monate Zeit
und keine anderen Projekte: fertig war die Laube. Seitdem erfolgt nur
noch behutsames Feintuning.
Stefanus F. schrieb:> die drei von ST.
Das erinnert mich an den hier: https://xkcd.com/927/Dennis schrieb:> 4 Monate Zeit und keine anderen Projekte: fertig war die Laube. Seitdem> erfolgt nur noch behutsames Feintuning.
Schon Mal überlegt, diese lib zu mit pro-Projekt-Lizenz, NDA und
Endprodukt-stückzahlabhängigen Schmalz-Faktor zu verkaufen?
Sozusagen...
Marcus H. schrieb:> einen high-Performance Hack
...ohne alles selber stricken zu müssen?
Das dass das das !!! schrieb:> Schon Mal überlegt, diese lib zu mit pro-Projekt-Lizenz, NDA und> Endprodukt-stückzahlabhängigen Schmalz-Faktor zu verkaufen?>> Sozusagen...> Marcus H. schrieb:>> einen high-Performance Hack> ...ohne alles selber stricken zu müssen?
Denke nicht dass es Pläne in diese Richtung gibt. Wir verdienen unser
Geld mit klassischer Hardwareentwicklung und hardwarenaher
Programmierung, die Bibliotheken sind quasi Firmenkapital. Da muss schon
einer der Großen die ganze Firma kaufen um an die ranzukommen :-)
Fabian B. schrieb:> wir steigen zurzeit von der Std-Periph.-Library auf die HAL mit CubeMX> um und versuchen so weit wie möglich Tutorials zu schreiben..>> - SPI: http://blacbird.de/tutorial-stm32-cubemx-spi> - SDIO + FATFS: http://blacbird.de/tutorial-stm32-cubemx-sdio
Grauer Text auf weißem Hintergrund?
Wer hat das den verbrochen? Das lässt sich echt schlecht lesen.
Stellt das doch bitte mal auf schwarzen Text um!
Fabian B. schrieb:> wobei der Artikel zeitnah noch ergänzt wird, da noch zu> oberflächlich (vor allem im Bezug auf die Einstellmöglichkeiten der> FATFS).
Es empfielt sich das originale elmchan fatfs ins Projekt zu ziehen.
Alleine für spätere Updates, denn ST hat ganz schön an dem fatfs
rumgepfuscht (nicht zum guten).
ac1 schrieb:> Unser Fazit: Die Qualität ist eine reine Katastrophe. Sobald du von den> einfachen Standard-Funktionen abweichst, findest du schnell üble Bugs.>> USB ist nahezu nicht verwendbar, da werden teilweise kritische Flags> nicht gesetzt/zurückgesetzt.>> Stellenweise sind wir dazu übergegangen, uns eine eigene HAL zu> implementieren. Die Zeit, die hierfür drauf geht, sparen wir uns später> bei der Bug-Suche doppelt und dreifach.
Diese ST HAL ist vor allem garkein HAL, sondern eher eine
Registerabstraktion.
Beim DMA zB muss man immernoch DMA 1/2 und Channel selber raussuchen
anstatt zu sagen "Machmal DMA mit dem UART1 RX"
(Mein Eigenbau HAL kann das)
Habt ihr USB Host oder Device genutzt?
Der USB OTG Host in Verbindung mit einem OS ist richtig übel vergeigt.
Der Knaller: Wenn man sich OTG mit automatischer Umschaltung klicken
will, dann sagt CubeMX, dass man das selber proggen soll.
GANZ GROSSES KINO!
Dennis schrieb:
> Wie dem auch sei. Wir haben in der Firma vor etwa 10 Jahren auf Cortex-M> umgestellt und alle Bibliotheken komplett selbst geschrieben.
Zwar nicht vor 10 Jahren, aber willkommen im Club.
Mw E. schrieb:> Grauer Text auf weißem Hintergrund? Das lässt sich echt schlecht lesen.
Sehe ich auch so.
Das gleiche Thema hatte ich mal bei der ARD bemängelt, nachdem die fett
darauf hinwiesen, ihre Seite jetzt barrierefrei gemacht zu haben. Die
Antwort war geil: Das sei alles umfangreich mit gesunden und
benachteiligten Personen getestet. Es habe sich herausgestellt, dass der
reduzierte Kontrast den Text besser lesbar mache. WTF?
Karl schrieb:> Nun zur eigentlichen Frage: Verwendet jemand im professionellen Umfeld> den STM HAL (oder die alte Peripherielib) und kann kurz die Erfahrungen> schildern? Oder auch: Warum wird es nicht verwendet?
Ich verwende die LL API im professionellen Umfeld, den LL Api Code kann
man übrigens auch mit dem CubeMX generieren. HAL war mir zu abstrakt und
zu "CallBack" lastig, was ich in einer gewöhnlichen hardwarenahen
Programmierung nicht gerne habe. Ich bin froh, dass ST auch die LL Api
anbietet. So einen Controller mag man nicht zufuß, über die
Registerzugriffe programmieren...
A. F. schrieb:> So einen Controller mag man nicht zu fuß, über die> Registerzugriffe programmieren...
Ich betrachte das als sportliche Herausforderung. Ist spannender als
jedes Adventure Game. Die Zeit dazu habe ich, da es nur ein Hobby ist.
Ich hatte innerhalb von zwei Jahren drei mal versucht, mit der HAL zu
starten und jedes mal waren die nicht lauffähig, weil die HAL Bugs
hatte. Hier im Forum wurde mir dabei geholfen, die Bugs zu finden und zu
korrigieren.
Mein Vertrauen in die HAL ist damit im Keller.
Außerdem erfüllt die HAL nicht meine Erwartung, von der Hardware
unabhängig zu werden. Schon ein µC Wechsel innerhalb der gleichen Serie
klappt nicht, ohne Quelltext anzupassen. Und ein Wechsel von F1 nach F3
(welcher von STM als "pin-kompatibler" Nachfolger angepriesen wird)
erfordert ein Redesign sämtlicher HAL Aufrufe.
Stefanus F. schrieb:> Außerdem erfüllt die HAL nicht meine Erwartung, von der Hardware> unabhängig zu werden. Schon ein µC Wechsel innerhalb der gleichen Serie> klappt nicht, ohne Quelltext anzupassen.
Mit der Verwendung von LL API hat der Wechsel innerhalb der ST Reihe
problemlos. Was die Bugs angeht, habe ich bis jetzt in der LL API nur
einen gefunden. Der I2C Slave hat beim Initialisieren die SCK Leitung
kurz auf Low gezogen. Habe das ST berichtet inklusive Workaround. Die
von ST nehmen solche Hinweise gerne an und haben minten darauf, dass der
Bug in der neueren Version beseitigt wird.
A. F. schrieb:> Ich bin froh, dass ST auch die LL Api> anbietet. So einen Controller mag man nicht zufuß, über die> Registerzugriffe programmieren...
Dann guck dir mal die LL API als Source an.
Das ist meist nur ein Funktionsname um den Registerzugriff gestrickt ;)
Daher kommen da auch nicht allzuviele Bugs bei rum.
A. F. schrieb:> So einen Controller mag man nicht zufuß, über die> Registerzugriffe programmieren...
Warum nicht? Ich investiere 2,3 Stunden und schreibe von der Peripherie
die ich benötige kurz meine eigene HAL und habe später keinen Stress.
Die meisten Peripheriebausteine beim STM32 haben doch nur wenige
Register. USB oder Ethernet ist gewiss ein anderes Kaliber, aber NVIC,
GPIOS, Timer, ADC, DAC, DMA,... das lässt sich alles wirklich super
leicht per Register konfigurieren. Und ich auch übersichtlicher, denn
das sind max 100 Zeilen und alles ist initialisiert.
Der Thread ist zwar schon alt, aber eigentlich ist das Thema immer noch
aktuell.
Wollte letztlich mal den neuen STM32G031 (im kleinen 8-Pin Gehäuse fast
ein ATtiny-Killer :-) ausprobieren.
Die includes (HW-Definitionen) sind gut im CubeMX Pack versteckt, auch
die Taktconfiguration geht halbwegs komfortabel nur noch über CubeMX.
Also ließ ich mich verleiten doch mal wieder die HAL auszuprobieren.
War wieder wirklich zum abgewöhnen. Es ist eben einfach KEIN HAL. Eher
ein Hardware Obfuscation Layer. Die HAL-Funktionen tun (noch dazu
relativ ineffizient) Sachen, die auf den ersten Blick nicht ersichtlich
sind. Andere Sachen (Control-Flags) werden teilweise 1:1 an die
HW-Register durchgereicht, aber dann eben doch wieder mit zusätzlichen
Abfragen in der HAL. Am Ende guckt man sich dann doch den Source-Code
der HAL-Funktion an um zu verstehen, was sie eigentlich wie macht.
Ineffizienter (von der Entwicklung her) geht es kaum noch.
Ich wollte z.B. für eine WS2812-Ansteuerung nur den SPI-Datenausgang
verwenden. Dieser Fall ist aber in CubeMX garnicht vorgesehen, man muss
auch noch zwangsweise einen Pin für SPI Clock definieren.
Karl schrieb:> Jetzt muss ich sagen, dass der neue HAL seit CubeMX nicht voll> überzeugen kann.
Dann hast du noch nicht richtig damit gearbeitet.
Markus M. schrieb:> Dieser Fall ist aber in CubeMX garnicht vorgesehen, man muss> auch noch zwangsweise einen Pin für SPI Clock definieren.
Logisch. SPI ist nunmal ein Zweidrahtsystem. Das du es entgegen des
eigentlichen Verwendungszweckes benutzen willst kann man den Entwicklern
bei ST kaum vorwerfen.
Klaus schrieb:> SPI ist nunmal ein Zweidrahtsystem.
Du kannst trotz HAL auch zwischendurch ein paar Register setzen.
Die frage ist nur: funktioniert das überhaupt ohne CLK, oder landet man
im Hardfault?
Markus M. schrieb:> War wieder wirklich zum abgewöhnen...
In deinen weiteren Ausführungen hast du genau meinen ersten Eindruck
beschrieben, der mich davon abgehalten hat, die HAL ein zweites mal zu
versuchen.
Ich habe unlängst mal wieder etwas mit CubeMX gespielt, habe aber die
Low-Level-Library verwendet.
Es gibt dafür (noch?) etwas wenige Beispiele, aber das läßt sich schon
weitaus besser verwenden als die HAL. Finde ich jedenfalls.
Ich boxe mich zu 99% auf Registerebene durch. Denn wozu soll ich bei
SPI, USART, I²C, DMA etc. für normale Aufgaben mich darauf verlassen -
komplex sind diese nicht wirklich?
Sofern ich Ethernet oder USB mache, greife ich durchaus auf HAL zurück -
wobei ich auch hier der Meinung bin, dass man sich langfristig einlesen
sollte, so dass man diese auch ohne HAL bewältigen könnte.
Trotz aller Kritik bleibt die HAL eine Abstraktion. Die Abstraktion
betrifft allerdings ausschließlich die Nutzung einer Peripherie und
nicht, wie viele sich das wünschen, deren Initialisierung.
Hier etwa quer durch die Bank 3x "HAL_SPI_Transmit" von 3 vollkommen
verschiedenen µC Familien. Soweit ich mich erinner hab ich grad H7, F4
und F1 kopiert:
Wenn jemand von Abstraktion und im gleichen Atemzug von manuell Register
setzen spricht, dann muss ich leider sagen, dass die ursprüngliche Idee
noch nicht verstanden wurde. ST's Bibliothek tut (ohne Berücksichtigung
etwaiger Bugs) genau das was sie tun soll. Sie abstrahiert die Nutzung
einer Schnittstelle wie etwa in diesem Fall das Senden von Daten via SPI
in einer Funktion.
Es wird davon ausgegangen dass der Nutzer für die Initialisierung CubeMX
verwendet und für jede separate Hardware eigene Init-Funktionen
erstellt. Die Kern-Applikation kann jedoch unverändert bleiben und wie
in diesem Fall etwa die Funktion "HAL_SPI_Transmit" nutzen, unabhängig
davon ob nun ein H7, F4 oder F1 zum Einsatz kommt. Welche der SPI
Schnittstellen, welcher Interrupt, welcher DMA usw. wirklich zum Einsatz
kommt muss dann halt via CubeMX zusammengeklickt werden.
Ist diese Lösung perfekt? Nein, sicherlich nicht. Meiner Meinung nach
liese sich mit modernen Sprachfeatures von C++ oder Rust eine wesentlich
bessere Abstraktionen bilden. So könnten etwa Interrupts und DMA-Kanäle
in die Typen der Schnittstellen integriert werden. Folglich müsste man
sich weder merken welcher Kanal wo zu geordnet ist, noch wäre man wie
aktuell auf Code-Generation angewiesen.
Nachdem sich aber seit Erstellung dieses Threads 2014 absolut nichts auf
diesem Gebiet getan hat seh ich eher schwarz dass so eine Bibliothek
jemals das Licht der Welt erblickt...
Mir ist selbst der HAL Level zu niedrig und zuviel Schreibarbeit. Kann
hier jemand aus dem Kopf eine SPI Schnittstelle implementieren? Ich kann
mir gerade noch sowas merken: 'SPI spi(SPI_MOSI, SPI_MISO, SPI_CLK,
SPI_CS);'
Und ich möchte auch keine HAL die nur auf STM oder NXP oder Nordic
funktioniert. Und schon garnicht meine restliche Lebenszeit damit
verschwenden für jeden µC aufs Neue den Registerkram raussuchen um eine
LED zum Blinken zu bekommen. Es gibt genug Arbeit aufbauend auf
funktionierenden Schnittstellen Komponenten zu bauen wie
Kommandointerpreter, HTTP Server, Sensor/Aktor Komponenten usw. Und das
müssen als Baukasten einfach zusammenpassende Objekte sein. Soviel
Komfort ist heute mit µC locker möglich, dank der hochoptimierten und
optimierenden Compiler kostet das auch erstaunlich wenig Leistung.
vielleicht ist der Anwendungsfall für HAL mit CubeMX nur etwas
missverständlich von ST dargestellt.
Beides ist nicht für Einsteiger die noch nicht wissen wie ein uC
funktioniert, sondern für Fortgeschrittene und Profis, die nicht jedes
Mal stupide Routinearbeit wie Config von Uart, SPi usw. jedes Mal von
Hand machen wollen sondern schnell zum Wesendlichen ihres Projekts
kommen wollen.
Nicht jeder hat einen Azubi neben sich sitzen und kann Routinearbeit
weggeben.
Natürlich schüttelt der Profi diese Settings mit links aus dem Ärmel und
kennt sie ohne Blick ins Datenblatt auswendig, aber irgendwann muss man
diese Routinearbeit abstreifen und automatisieren. ST hat vielleicht
einen holprigen Start mit CubeMX und HAL gehabt, aber ich will nicht
nachschauen müssen ob irgendwo vielleicht ein Bit falsch gesetzt ist.
Allerdings war es auch einige Einarbeitungszeit, das Konzept von CubeMX
und HAL zu verstehen. Nur danach konnte ich es effizient einsetzen. Ohne
die Einarbeitungszeit kommt einem das System natürlich wie eine
Fehlkonstruktion vor.
Ich denke, dass man wenigstens einen STM32 mal ernsthaft auf
Registerebene mit dem Reference Manual programmiert haben muss, um die
HAL verstehen zu können.
Mit dem 8085 und Assembler habe ich angefangen, war Pflicht in der
Ausbildung. PIC16F887 und ATtiny/ATmega sind die letzten uC, die ich auf
Registerebene und C verstehen wollte. Alle ARM Cortex sind zu komplex um
das Rad noch mal neu erfinden zu wollen. Es hilft allerdings, die
8-bitter programmiert zu haben um keinen Unfug auf Embedded Systemen zu
machen.
Wenn Einsteiger gleich mit Cortex-M auf Registerebene einsteigen, dann
müssen Sie entweder einen guten Tutor haben oder extrem frustresistent
sein. Die alten Hasen vergessen oft wie sie selbst die ersten wackeligen
Schritte gemacht haben, in der guten alten Zeit. In der Erinnerung war
alles viel bunter ...
Thread beobachten
Seitenaufteilung abschalten