Forum: Mikrocontroller und Digitale Elektronik STM32 HAL Tutorial


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich würde gerne von AVR´s auf STM32 umsteigen.
Da die Standard Lib durch HAL abgelöst wurde, würde ich gerne direkt mit 
der HAL einsteigen.
Leider finde ich kein Tutorial im Netz das die HAL beschreibt - was es 
mir als Hobby Einsteiger sehr schwer macht.

Habt Ihr eine Quelle zum Einstieg parat?

Danke und Gruß
technikus

von Arduinoquäler (Gast)


Bewertung
-9 lesenswert
nicht lesenswert
technikus schrieb:
> würde ich gerne direkt mit der HAL einsteigen.

Du gehst nicht mit der Zeit! Du bist hintendran!

Bald wird ein neuer Jünger auftreten und dir predigen
dass du gefälligst CubeMX nehmen sollst.

Und wenn du noch etwas wartest wird man die STMs in Java und
Visual Basic programmieren können/dürfen/müssen. Dann aber
wird es von Vorteil sein sich wieder mit den alten AVRs aus-
einanderzusetzen.

von Sebastian V. (sebi_s)


Bewertung
0 lesenswert
nicht lesenswert
HAL ist keine Library sondern steht für Hardware Abstraction Layer. Für 
die STM32 gibt es zwei HAL Libraries. Einmal die alte Standard 
Peripheral Libraries und das neuere STM32Cube. Wenn du danach suchst 
findest du eventuell was.

Arduinoquäler schrieb:
> Und wenn du noch etwas wartest wird man die STMs in Java und
> Visual Basic programmieren können/dürfen/müssen. Dann aber
> wird es von Vorteil sein sich wieder mit den alten AVRs aus-
> einanderzusetzen.

Genau. Wenn man Mikrocontroller nur noch in Java programmieren kann 
interessiert sich bestimmt jemand für einen AVR Programmierer...

: Bearbeitet durch User
von Lars F. (flemmy)


Bewertung
0 lesenswert
nicht lesenswert
Sieh dir mal Folgendes an:
https://stm32f4-discovery.net/2014/09/stm32f4-tutorials-one-place/

Das hat für mich für ein paar grundlegende Dinge gereicht, wenn ich mich 
recht entsinne...

von Robin S. (der_r)


Bewertung
0 lesenswert
nicht lesenswert
Sebastian V. schrieb:
> HAL ist keine Library sondern steht für Hardware Abstraction Layer. Für
> die STM32 gibt es zwei HAL Libraries. Einmal die alte Standard
> Peripheral Libraries und das neuere STM32Cube.

Falsch. ST beschreibt die Library ja selbst als CubeFx/HAL-Library (x = 
1,3...), auch wenn die Abkürzung natürlich richtig ist. Die SPL ist auch 
keine richtige Abstraktion.


Und STM32Cube ist keine Library, sondern ein "Ökosystem" für 
Hardware-Abstraktion, zu dem die STM32CubeFx HAL-Libraries und der 
STM32CubeMX Startup Code Generator gehören.

: Bearbeitet durch User
von Ralph S. (jjflash)


Bewertung
4 lesenswert
nicht lesenswert
technikus schrieb:
> ich würde gerne von AVR´s auf STM32 umsteigen.

... ist am Anfang etwas (untertrieben) "verwirrend". Du benötigst 
natürlich die Datasheets (man beachte: Mehrzahl) zu dem verwendeten 
Controller.

Hier kannst du schlicht unterscheiden in:

- Datasheet
   .. steht bspw. Pinbelegung, Alternative Pins etc. drin und vor allem 
die Adressen der Register OHNE deren Beschreibung
- Reference Manual
   .. KEINE Pinbelegung dafür Beschreibung der einzelnen Register

Von daher ist also erst einmal angesagt: Sondieren, wo steht was.

Die Einstellmöglichkeiten von STM32 bringen dich am Anfang schier um, 
angefangen mit der Einstellung, welcher Systemtakt herschen soll:

HSI für internen Oszillator
HSE für externen Oszillator

Aber, hier darfst dann gleich ermitteln, wie ein Takt weiter 
"aufbereitet" wird. Ein interner PLL erzeugt eine Taktvervielfachung so 
daß oft - wenn verwendet - ein externer Quarz 8MHz verschaltet wird der 
dann über PLL vervielfacht wird.

Dann mußt du dir immer vergegenwärtigen, dass jede interne Einheit 
grundsätzlich erst einmal den Takt eingeschaltet haben mag. Nicht, 
wirklich nichts läuft von alleine automatisch an. Unterm Strich wirklich 
gut, weil so keine Einheiten unnötig Strom verbraten, für den Anfänger 
allerdings schwierig weil er auch das konfigurieren muß. Auch hier muß 
man die Taktgeschwindigkeit für bspw. ein SPI oder I2C oder auch nur 
GPIO - Pins konfigurieren.

Sieht man in diverse Sourcen, dann erkennst du auch schnell Unterschiede 
bspw. im Behandeln von GPIO-Pins (für Bitbanging): Es gibt nicht ein 
Register, dass die einsen und nullen auf den Hardware-Pins abbildet. Zum 
setzen und löschen einzelner Bits hast du ein 32-Bit Register mittels 
derer du (je nach Controller) 16 Port-Pins ein- und ausschalten kannst, 
wobei ein setzen einer 1 an den oberen 16 Bit den Pegel am Pin löscht 
!!!! Ein setzen an  den unteren setzt diese.

Arduinoquäler schrieb:
> Bald wird ein neuer Jünger auftreten und dir predigen
> dass du gefälligst CubeMX nehmen sollst.

Ich bin sicherlich kein CubeMX - Jünger (und ich habe ein Template, das 
CubeMX erstellen kann nie verwendet), aber für den Anfang ist das schön 
zu sehen, welche Einheiten innerhalb des STM was beaufschlagen (und du 
lernst dort die Namen kennen).

Sebastian V. schrieb:
> Einmal die alte Standard
> Peripheral Libraries und das neuere STM32Cube.

Die Welt besteht nicht nur aus schwarz und weiss. Wenn man in die 
Sources von beiden schaut stellt sich oft auch ein "Aha-Erlebnis" ein, 
eine weitere Möglichkeit wäre jedoch auch:

libopencm3

(die ich persönlich verwende).

Hier kannst du dann (auch schmerzlich) lernen, an welchen 
Speicheradressen welche interne Peripherie liegt und du lernst was ein 
Linkerscript ist (ohne das mit Cortex Mx gar nichts geht).

Ich für meinen Teil habe für mich die libopencm3 weiter abstrahiert (mit 
genau der Namensgebung mit der ich auch mit anderen Controllern arbeite, 
sodaß ich oft gar nicht mehr merke - leider - mit welchem Controller ich 
es eigentlich zu tun habe).

Bspw. kann ein SPI mit derart vielen Einstellungen betrieben werden, die 
ich in aller Regel gar nicht benötige, also hab ich mir mit libopencm3 
eben die Einheiten weiter für mich vereinfacht und ein auf mich 
passendes Makefile geschustert.

Ein Vorteil von libopencm3 sind die vielen FUNKTIONIERENDEN Beispiele.

Die Beschreibung von libopencm3 findest du hier: 
http://libopencm3.org/docs/latest/html/index.html

Schaut man hier in die Sources und "studiert" diese etwas genauer, wirst 
du in einigen Fällen gar keine HAL verwenden sondern setzt diese selbst 
auf, dann weißt du auch, wie es funktioniert.

Wenn du allerdings einfach nur einen STM32 verwenden magst und mit den 
Eigenheiten nicht kämpfen magst, kannst du auch ein MBED-fähiges Board 
nehmen (bspw. die superbilligen STM32F103 BluePill Boards aus China, am 
besten in Verbindung mit einem ST-Linkv2 Clone ebenfalls aus China) und 
die Software online in MBED erstellen (was sehr stark nach Arduino 
anmutet).

Viele Wege führen hin zu STM32. Wenn du den Weg über die Datenblätter 
gehst, in ALLE verfügbaren Sourcen und Libraries reinschaust wirst du am 
meisten lernen und - so glaube ich - sich der Aha-Effekt am schnellsten 
einstellen.

von dasrotemopped (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Bald wird ein neuer Jünger auftreten und dir predigen
>dass du gefälligst CubeMX nehmen sollst.
Amen, ich sage dir, du MUSST CubeMX benutzen, die Silizium Götter wollen 
es so !

STMicro mit CubeMX,
Infineon mit DAVE
Microchip mit MPLAB Code Configurator
Atmel mit start.atmel.com

Alle bieten einen Code Generator an und Ihn nicht zu benutzen wird dich 
in die Hölle der Bitsetzerei verdammen.
Ein Codegenerator in Kombination mit einer IDE ist eine 
Arbeitserleichterung, so bald man verstanden hat wie es funktioniert. 
Allerdings ist der Weg dahin kein Zuckerschlecken. Aber alle 
Dokumentation der Libs ist darin enthalten.

Java geht auch:
http://www.stm32j.com/
Aber die Code Generatoren sind für C.

Es gibt viele Anleitungen im Web, aber die wenigsten sind 
einsteigerfreundlich. Oder auf deine Wunschkonfiguration zugeschnitten.
Fang mal damit an:
http://www.st.com/content/st_com/en/about/events/upcoming-events-and-technical-seminars.html
Besonders die online  MOOC sind interessant und gratis.
Und lies mal das PDF
https://community.st.com/docs/DOC-1250-hallabspdf
Oder das angehängte PDF, habe da gerade keinen Link zur Hand.


Gruß,

dasrotemopped.

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ralph S. schrieb:
> technikus schrieb:

> - Datasheet
>    .. steht bspw. Pinbelegung, Alternative Pins etc. drin und vor allem
> die Adressen der Register OHNE deren Beschreibung
> - Reference Manual
>    .. KEINE Pinbelegung dafür Beschreibung der einzelnen Register

- und dann gibt es noch das Programming Manual. Da gibt's u.a. das 
Befehlssatz, Interruptcontroller, Systick und Fließkomma-Einheit.

> Von daher ist also erst einmal angesagt: Sondieren, wo steht was.

Das ist übrigens AUCH angesagt, wenn man mit HAL arbeitet, weil die HAL 
gar keine eigentliche Abstraktion bietet, sondern eher Wrapperfunktionen 
für die Register. Um die HAL-Funktionsparameter zu verstehen, muß man 
trotzdem die Manuals lesen.

> Die Einstellmöglichkeiten von STM32 bringen dich am Anfang schier um,
> angefangen mit der Einstellung, welcher Systemtakt herschen soll:

Die HAL setzt den Takt normalerweise beim Init auf das spezifizierte 
Maximum (ohne sinnvolle Fehlerbehandlung bei kaputtem Quarz, fehlt 
einfach). Runtertakten ist dann nicht vorgesehen. Will man dynamisch je 
nach Betriebsmodus unterschiedliche Frequenzen, muß man das eh selber 
implementieren.

> Sieht man in diverse Sourcen, dann erkennst du auch schnell Unterschiede
> bspw. im Behandeln von GPIO-Pins (für Bitbanging): Es gibt nicht ein
> Register, dass die einsen und nullen auf den Hardware-Pins abbildet.

Doch, das gibt es zusätzlich auch noch, nämlich das Output Data Register 
(ODR). Was Du meinst, ist das Bit Set/Reset Register (BSRR). Man kann 
beide benutzen - mit dem BSRR spart man sich die ansonsten übliche Kette 
"auslesen, Bit maskieren, zurückschreiben". Dafür kann man das ODR auch 
auslesen, um den gegenwärtigen Zustand zu lesen, das geht beim BSRR 
nicht.

> libopencm3

Aufgepaßt mit der Lizenz. Das ist LGPL, man muß also zwar nicht seinen 
eigenen Quelltext offenlegen - aber, und das wird nicht leicht, man muß 
das so ausliefern, daß es kein statisch gelinktes Image ist.

Was das embedded heißt, ist eine riskante Grauzone, weil es IMMER ein 
Hexfile sein wird. Aber logisch gesehen ist das absolute Minimum, daß 
man es so ausliefert, daß man libopencm3 modifizieren und ein neues 
Hexfile linken kann. Das einzurichten wird einiges an Aufwand.

Ist natürlich kein Problem, wenn man seinen eigenen Quelltext ohnehin 
unter irgendeiner Opensource-Lizenz beilegt. Oder wenn man gar nichts 
ausliefert, sondern das nur im privaten Einsatz hat.

Aber man sollte sich von Anfang an überlegen, zu welchen Zwecken man das 
verwenden will, und ob dort langfristig Lizenzprobleme drohen. Will man 
sich auch für beruflichen Hintergrund in STM32 einarbeiten, ist 
libopencm3 wahrscheinlich eine Sackgasse.

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
dasrotemopped schrieb:
> Ein Codegenerator in Kombination mit einer IDE ist eine
> Arbeitserleichterung, so bald man verstanden hat wie es funktioniert.

Nachteil: man kann dann erstmal den Code anderer Leute debuggen. Sobald 
man das gemacht hat, ist man auf genau diese Version dann festgenagelt, 
es sei denn, man will seine Änderungen dann in die nächste Version 
selber reinporten.

Zudem wird sowas u.U. langfristig zu einem Problem, wenn nämlich der 
alte Codegenerator 10 Jahre danach auf einem neuen PC nicht mehr läuft, 
aber der Kunde noch eine klitzekleine Änderung will. Ja, sowas gibt es.

Aus meiner Praxis würde ich bei längerfristigen Projekten keinerlei 
externe Abhängigkeiten zulassen außer dem Compiler, und den würde ich 
auch in genau der benutzten Version archivieren.

Sofern auf dem Host beim Build irgendwelche Tools gebraucht werden 
(Datenkonvertierer, Checksummentools), ist das OK, wenn sie im Quelltext 
vorliegen, und zwar in irgendeiner etablierten Sprache, zu der es auch 
einen ISO-Standard gibt sowie Compiler/Interpreter, die den ausdrücklich 
implementieren (weil der auch 10 Jahre später noch zumindest 
einzustellen gehen wird). Etwa C und C++ sind da geeignet, z.B. Python 
hingegen nicht. Und proprietäre IDEs, die Code generieren, schon 
überhaupt nicht.

von dasrotemopped (Gast)


Bewertung
2 lesenswert
nicht lesenswert
CMSIS bietet Makros, um den CPU Core zu konfigurieren,
HAL bietet Funktionen, um die CPU Peripherie zu konfigurieren.
CubeMX bietet die Möglichkeit, das alles in einer GUI zu machen
und erstellt zusätzlich noch ein Projekt für die gewünschte IDE.

Wer will kann natürlich das Rad neu erfinden und die Bits selbst
kippen. Bei der Menge, die ein Cortex-M bietet eine abendfüllende
Aufgabe.

Einen 8085 / 8051, oder andere 8-Biter sind noch überschaubar, aber ab 
einem bestimmten Punkt wird es albern, das alles "im Kopf" zu haben.

Und Einsteiger / Anfänger mit der Komplexität eines Cortex-M 
abzuschrecken um Ihn in die Steinzeit zu schicken ist nicht nett.
Mit den bereits erwähnten Werkzeugen ist ein Cortex-M zu programmieren 
so einfach wie Schnecken fangen.

Gruß,

dasrotemopped.

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>man kann dann erst mal den Code anderer Leute debuggen
der selbst programmierte Code ist ja per Definition fehlerfrei

>würde ich bei längerfristigen Projekten keinerlei
>externe Abhängigkeiten zulassen außer dem Compiler
ach komm, den Compiler kannst du doch auch noch selbst schreiben

Der TO hat um Hilfe beim Einstieg gebeten, keine Branchenlösung für die 
Ewigkeit. Also mal kleine Brötchen backen und auf dem Teppich bleiben.

Gruß,

dasrotemopped.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:

> Und Einsteiger / Anfänger mit der Komplexität eines Cortex-M
> abzuschrecken um Ihn in die Steinzeit zu schicken ist nicht nett.

Der OP ist aber kein Anfänger, sondern ein Umsteiger. Ich gehe also 
davon aus, daß er weiß, wie man die Doku eines µC liest, und daß er auch 
programmiertechnisch schon fit ist. Wer das alles nicht ist und auch 
nicht sein will, nimmt sich eh den Arduino.

Zudem ist die HAL leider nicht das, was ihr Name suggeriert, sondern es 
sind Wrapperfunktionen, die sehr direkt die Register abbilden. Mit 
anderen Worten, um zu verstehen, was die diversen Parameter denn 
bewirken, muß man ohnehin die o.g. Manuals trotzdem lesen.

Dann kann man aber auch gleich die Register ohne den Bloat selber 
beschreiben.


dasrotemopped schrieb:
> der selbst programmierte Code ist ja per Definition fehlerfrei

Es ist zumindest wesentlich leichter nachzuvollziehen, was passiert. Die 
HAL ist IMO eher eine HOL - Hardware Obfuscation Layer, mit dem 
hauptsächlichen Zweck eines vendor-lock-in, deswegen macht ST das.

Daß z.B. die Fehlerbehandlung beim Takteinstellen einfach fehlt, habe 
ich ja schon erwähnt - so programmiert man bei ST halt. Also ich würde 
mich auf so eine wackelige Quelltextbasis nicht verlassen wollen.

von dasrotemopped (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores.
Und eine Fehlerbehandlung ist auch implementiert.

Beschäftige dich doch erst mal mit den HAL Libs, bevor du sie schlecht 
findest.

Gruß,
dasrotemopped.

von Vincent H. (vinci)


Bewertung
1 lesenswert
nicht lesenswert
Mit dem Download der HAL Libs bekommt man für so gut wie jede verfügbare 
Peripherie einen Haufen Demo-Beispiele. Mit Hilfe derer kann man sich 
eigentlich ganz gut einen Überblick darüber verschaffen, wie man mit der 
HAL arbeiten kann.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
dasrotemopped schrieb:
> Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores.

ja, aber die STM HAL macht das anders, siehe FAQ im Anhang der HAL Doku
http://www.st.com/content/ccc/resource/technical/document/user_manual/2f/71/ba/b8/75/54/47/cf/DM00105879.pdf/files/DM00105879.pdf/jcr:content/translations/en.DM00105879.pdf

'How do I configure the system clock?
Unlike the standard library, the system clock configuration is not 
performed in CMSIS drivers file (system_stm32f4xx.c) but in the main 
user application by calling the two main functions, HAL_RCC_OscConfig() 
and HAL_RCC_ClockConfig(). It can be modified in any user application 
section.'

Insgesamt sind die UserManuals eine Lektüre für lange Winterabende, für 
den F4 knapp 1000 Seiten und für die F0 sogar 1300 Seiten...

Diese Seite habe ich in meinen Lesezeichen, da sind einige Tutorials 
drin:
https://stm32f4-discovery.net/2014/09/stm32f4-tutorials-one-place/

und diese ist recht beliebt:
http://www.diller-technologies.de/stm32.html
weiss aber gerade nicht ob die auf neuere HAL aufbaut.

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:
> Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores.
> Und eine Fehlerbehandlung ist auch implementiert.
>
> Beschäftige dich doch erst mal mit den HAL Libs, bevor du sie schlecht
> findest.
>
> Gruß,
> dasrotemopped.

Die Aussage ist m.W. nach nicht ganz richtig (sh. auch Yiu Kapitel 14).

Der Core kann entweder extern oder intern geclockt werden. Keine von 
beiden Sources ist von ARM spezifiziert oder vorgegeben, nur was mit dem 
clock Signal dann im Kernel passiert.

Die CMSIS Library schreibt lediglich vor, welche Prototypen die 
Funktionen haben müssen, die die Chip vendors in ihrer Version der CMSIS 
Initialisierung zur Verfügung stellen müssen/sollen, und dass als 
Seiteneffekt davon eine globale Variable gesetzt werden soll (s.u.).

Bei den STM Cortex Prozessoren werden dabei Register im RCC Modul im 
Adreßbereich 0x40000000+ manipuliert, das ist der peripherals bus. Alle 
vom Cortex Kern verwalteten Register liegen im PPB (Private Peripheral 
Bus), das ist der Adressbereich 0xe0000000+.

Die CMSIS hat mit dem Core nur zum Teil zu tun, deswegen ist die Aussage 
"ein Teil der CMSIS, da Teil des CPU Cores" falsch (sh. 
https://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php). 
Im Submodul CMSIS_CORE (sh. 
http://www.keil.com/pack/doc/CMSIS/Core/html/index.html) sind die Kernel 
relevanten Teile dokumentiert, und das einzige, was sich hier über die 
clock findet, ist dies: "A variable to determine the system clock 
frequency which simplifies the setup the SysTick timer." Die muss von 
der konkreten Implementation der Sysclock_Init() Funktion gefüllt 
werden.

: Bearbeitet durch User
von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:
> Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores.
> Und eine Fehlerbehandlung ist auch implementiert.

Nein, ist sie nicht. Der Interrupt tut ja nichts Sinnvolles.

Es wäre vermutlich rocket science für ST, wenn man bei versagendem HSE 
die PLL-Faktoren passend umskaliert, die PLL dann auf den HSI umschaltet 
und die Funktion einen entsprechenden Fehlercode zurückgibt.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leute, bevor ihr euch und ST zerfleischt, bedenkt das der TE nur spielen 
will. Siehe Beitrag

Beitrag "stm32cube darstellungsprobleme"

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Aufgepaßt mit der Lizenz. ... - aber, und das wird nicht leicht, man muß
> das so ausliefern,...

Hm, glaubst Du wirklich, dass das für den TE ein Problem ist?

technikus schrieb:
> Hobby Einsteiger

Vielleicht ist Open Source da geradezu ideal.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leute - Hört auf! Der TO hat sich von dannen geschlichen.

W.S.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Da wartet wieder jemand um mit dem erhobenen Zeigefinger herein zu 
grätschen :-) Irgendwas hatte in diesem Thread doch gefehlt...

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
Hallo?

Und wenn das Thema interssant ist, unabhängig davon ob der TE es ernst 
meinte oder nicht?

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Leute - Hört auf! Der TO hat sich von dannen geschlichen.
>
> W.S.

Ne, ich bin noch da ;)
Vielen Dank für die zahlreichen Antworten!

Nur Spielen möchte ich nicht. Eher etwas dazu lernen und meine neuen 
Hobbyprojekte auf STM32 Basis umsetzen.

Wie schon richtig bemerkt ist der Einstieg ziemlich hart.

Ich habe hier ein STm32F051 Discovery und Cube MX sowie Visual GDB 
Installiert.
LED Anschalten klappt, RS232 auch, allerdings scheitert es hier schon 
den Empfangspuffer nicht "hintenrum" zu löschen.

Jetzt wollte ich mal Timer nutzen, hierzu habe ich folgendes Tutoriel 
als Grundlage genutzt

http://www.diller-technologies.de/stm32.html

Ich wollte mich da durch arbeiten und die Beispiele auf die HAL lib 
portieren - Pustekuchen - ich finde keinen Zugang.

Dazu dann diese Dokument

http://www.st.com/content/ccc/resource/technical/document/user_manual/2f/77/25/0f/5c/38/48/80/DM00122015.pdf/files/DM00122015.pdf/jcr:content/translations/en.DM00122015.pdf

Allerdings fehlt reicht mir dieses PDF nicht um zu verstehen was hier 
abgeht.

Könnt Ihr mir den Einstieg erleichtern und z.B. anhand des Timer PEM 
Beispiels die herangehensweise und nötige Dokumente nennen ?


Danke und Gruß
Daniel

von Vergessen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Google doch mal "visualgdb timer hal"

von Basti (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Eigentlich ist die HAL recht simpel, wenn man verstanden hat wie sie 
funktioniert.

Es gibt meist drei Möglichkeiten für Kommunikationsinterface:

- Blocking/Timeout (kein Interrupt im CubeMX aktivieren)
- Interrupt getrieben (Interrupt immer im CubeMX aktivieren, sonst 
klappt es nicht
- DMA Transfer (DMA Interrupt + !Periferie-Interrupt! aktivieren)

Dann kanns eigentlich schon los gehen. Alles per CubeMX anschalten.
Anschließen mal fix auf eine I2C EEPROM schreiben?

HAL_I2C_Mem_Write_DMA(...)

Einfach geht es bald nicht. Ich war am Anfang auch sehr negativ 
eingestellt. Mittlerweile gefällt mir die HAL und die StdPer gehört zum 
alten Eisen.

Achtung: Man kommt NIE damit aus, nicht in den CubeMX Codebereich 
einzugreifen (z.B. wegen kleiner Bugs). Also versucht erst gar nicht zu 
wiederstehen. Zwei Optionen:

1. Projekt nur ein mal mit CubeMX generieren -> Erweiterungen notfalls 
selbst hinzufügen
2. Mit CubeMX (möglchst selten) euer Projekt "überspielen" und eure 
Anpassungen über ein git reset vor den ungewollten Änderungen des CubeMX 
schützen.

IMO kommt man so sehr schnell recht weit! Ohne Controller- und 
Programmiererfahrungen natürlich am Anfang (wie immer) ein Kampf...

Aber die Leute die für die komplexesten Prozessoren immer alles selbst 
neu schreiben haben viel Zeit für ihr Hobby oder keinen Chef... 
Besonders witzig, wenn die dann noch behaupten fehlerfreien Quellcode zu 
schreiben... nicht wie der Quellcode der durch die gesamte Community 
getestet wird ;)

VG

Basti

von Nop (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Basti schrieb:

> Aber die Leute die für die komplexesten Prozessoren immer alles selbst
> neu schreiben haben viel Zeit für ihr Hobby oder keinen Chef...

Deswegen mache ich doch solche Hobby-Projekte, eben weil es keine 
Deadlines gibt. Da kann ich mich dann auch in der Tiefe und in aller 
Ruhe mit der Controller-Doku befassen. Der Lerneffekt ist meiner Meinung 
nach beim harten Weg am höchsten.

Ist natürlich etwas anderes, wenn man nicht lernen will, sondern schnell 
mal eben etwas umsetzen will, aber das wird vom Arduino-Ökosystem schon 
ganz gut abgedeckt.

> Besonders witzig, wenn die dann noch behaupten fehlerfreien Quellcode zu
> schreiben...

Opensource variiert auch sehr stark zwischen professioneller Entwicklung 
und "bei mir läuft's doch"-Dreck. Zumal bei Opensource oftmals die Doku 
grottig ist, weil es mehr Spaß macht, etwas Halbgares zusammenzuhacken, 
als es zu dokumentieren. Das Ergebnis ist, daß es mich bei kleineren 
Sachen weniger Zeit kostet, es gleich selber zu machen.

> nicht wie der Quellcode der durch die gesamte Community
> getestet wird ;)

Klar, das vier-Augen-Prinzip. So wie bei Heartbleed. Weil sich alle 
darauf verlassen, daß irgendwer anders ganz bestimmt einen Blick auf das 
Gefrickel geworfen haben wird. Oder zumindest getestet haben wird.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Nur Spielen möchte ich nicht. Eher etwas dazu lernen und meine neuen
> Hobbyprojekte auf STM32 Basis umsetzen.

OK, ist doch ein Wort!

Aber zum Dazulernen solltest du dich nicht auf zusätzlichen Krempel wie 
ST-Lib, HAL, Cube und dergleichen verlassen. Bedenke mal, daß all dies 
eben NICHT dazu gedacht ist, die ganze Sache zu vereinfachen oder gar 
den Horizont des angehenden Programmierers zu erweitern, sondern es ist 
dazu gedacht, die Kunden an das eigene Portfolio zu binden. Vergiß das 
NIE.

Ansonsten ist die Cortex-Welt nicht wirklich schwieriger als das, was du 
bereits kennst. Es ist etwas mehr an jeder Stelle, jaja, aber dafür 
gibt's auch ne dickere Dokumentation - und die ist bei ST nicht 
schlecht. Nebenbei gesagt, sind auch die LPC von NXP und deren Doku 
nicht schlecht.

Du brauchst definitiv KEIN "Tutorial im Netz das die HAL beschreibt", 
denn das Wesentliche darüber, wie die Hardware funktioniert, steht im 
Referenzmanual - und die sogenannte HAL ist definitiv eben keine HAL, 
aber das ist dir weiter oben schon mal gesagt worden.

Also konzentriere dich auf einen konkreten Chip und dessen Dokumentation 
und nicht auf zusätzliches Software-Geschwurbel. Wenn es denn schon ein 
STM32 sein soll, dann schau dir eher die STM32F30x als alle anderen für 
den Anfang an. Die STM32F30x haben nämlich eine angenehmere Art, die 
Funktionalität der Port-Pins einzustellen als z.B. die STM32F1xx und das 
hilft am Anfang.

W.S.

von hp-freund (Gast)


Bewertung
2 lesenswert
nicht lesenswert
@ W.S.
Ist es wirklich Nötig das Du bei so ziemliche jedem Beitrag, in dem HAL 
auch nur erwähnt wird, deiner HAL Phobie freien Lauf lassen musst?

Lass die Leute doch einfach mal machen.
Einer mag das Konzept, ein anderer eben nicht!

von avr (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Abgesehen davon ist es egal ob man die hal verwendet oder nicht. In 
beiden Fällen ist man von der Peripherie des Herstellers abhängig. Ohne 
Code Modifikation portiert man das sowieso nicht. Dann bleibe ich lieber 
bei der fertigen "hal" und mache mir das Leben einfacher. Zudem kann ich 
zwischen den stm32 Controllern einfacher migrieren. Und wenn man es 
portabel haben will kommt man in beiden Fällen nicht um eine zusätzliche 
Abstraktionsschicht herum.

Seit lto ist Performance auch kein Argument mehr.  Der einzige Nachteil 
meiner Meinung ist die miese Dokumentation.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Bedenke mal, daß all dies
> eben NICHT dazu gedacht ist, die ganze Sache zu vereinfachen oder gar
> den Horizont des angehenden Programmierers zu erweitern, sondern es ist
> dazu gedacht, die Kunden an das eigene Portfolio zu binden.

Das ist deine Interpretation. Im User Manual gibt es eine FAQ mit der 
Frage 'Why should I use the HAL drivers?' und einigen schlüssigen 
Argumenten. Natürlich steht da Kundenbindung nicht mit drin, aber ST 
hätte ein mieses Marketing wenn sie nichts für Kundenbindung tun würden. 
Viele haben mit dem AVR Studio angefangen und es lieferte genau das was 
der Hobbyist für den Einstieg haben wollte, auch wenn es nur für Atmel 
µC taugte. Da der Wettbewerb bei den Cortex-M sehr groß ist reicht es 
nicht mehr ein Eval Board in die Menge zu werfen. Was ST da kostenlos 
anbietet finde ich schon sehr bemerkenswert und andere versuchen auch da 
etwas ähnliches gegen zu setzen, früher hat man für solche Tools und 
Libraries locker 5-stellige Beträge bezahlt. Das ST da soviel Druck 
macht gefällt sich nicht allen, aber der Plan geht doch auf. Dem 
Hobbyisten ist es egal das die HAL nur für STM32 zu nutzen ist, mit der 
Riesenauswahl von F0 - F∞ ist für Bastelprojekte doch alles abgedeckt 
und dazu wesentlich leistungsfähiger als alles was man in der 
ATtiny/Atmega Schiene hatte.
Trotzdem nutze auch ich lieber die LPC von NXP und das mit der mbed lib. 
Damit ist nämlich die Tür für STM32 genauso offen wie für alle anderen 
Cortex-M Anbieter. Und ein PWM Ausgang wird zum 3 Zeiler, unabhängig von 
NXP, ST, Atmel uvm:
1
PwmOut mypwm(PWM_OUT);
2
   
3
mypwm.period_ms(10);
4
mypwm.pulsewidth_ms(1);

Die HAL abstrahiert schon einiges und man muss nicht jedes Register 
kennen und z.B. ein I2C/SPI read/write wird auch sehr einfach, aber 
gerade für PWM muss man GPIO, Timer Clock und Timer Match konfigurieren, 
das sind schon drei Kapitel die man zusammensuchen muss.

von W.S. (Gast)


Bewertung
3 lesenswert
nicht lesenswert
hp-freund schrieb:
> Ist es wirklich Nötig das Du bei so ziemliche jedem Beitrag, in dem HAL
> auch nur erwähnt wird, deiner HAL Phobie freien Lauf lassen musst?

Ja, das ist aus hygienischen Gründen EXTREM notwendig.

Du siehst es ja in diesem Forum an jeder Ecke: Da kommen Neulinge von 
AVR oder von nirgendwo und suchen zu allererst einmal irgend eine 
Orientierung - und was wird ihnen von allen möglichen Leuten zu 
allererst empfohlen? Eben genau DAS, was den tatsächlichen Einstieg in 
die Materie zunächst erstmal gründlichst verschwurbelt.

Mir ist schon klar, daß man als Neuling zuerst denkt, "oh, ich weiß ja 
noch so wenig, da laß ich mir erstmal von Erfahrerenen sagen, wo es lang 
geht". Bloß die "Erfahrenen", die keinen Fuß auf den Teppich kriegen, 
sondern allzeit sich in XY_InitStructur.abcdef ergehen, die einen UART 
nicht selbst benutzen können und nicht mal ein Portpin ohne 
Hersteller-Bibliothek aufsetzen können, sind wahrlich KEINE echte Hilfe, 
sondern sie steuern jeden Neuling gnadenlos in eine Ecke, wo er nicht 
mehr rauskommt.

Ich rate deshalb jedem Neuling dazu, sich auf den Chip und dessen 
Primär-Literatur zu konzentrieren und all den Sekundär- und Tertiär-Kram 
beiseite zu lassen. Sowas kann man bei Bedarf später mal inspizieren, 
wenn man selber schon sattelfest ist. Aber eben NICHT zum Anfang.

Ein Gleiches gilt übrigens auch für das Thema IDE. Zu allererst sollte 
ein Jeder lernen, seine Tools selber aufzurufen und zu benutzen. Wenn 
man das kann und weiß, was ab geht, dann kann man auch ne IDE benutzen - 
wohlgemerkt dann, wenn man nicht auf selbige angewiesen ist, sondern 
selber laufen gelernt hat.

W.S.

von temp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich kann auch nicht verstehen wie jemand das Gefühl haben kann mit der 
HAL geht es besser und einfacher. Das können eigentlich nur die 
behaupten die das ausschließlich machen. Jeder der beides durch hat, 
weiß dass es außer zusätzlichen Aufwand nichts bringt. Oder man ist 
wirklich so benebelt im Kopf, dass man z.B. DMA benutzt ohne das 
Refmanual gelesen zu haben. Und wenn ich das gelesen habe, interpretiere 
ich das dann auf schlecht kommentierte HAL Routinen? Dümmer gehts 
nimmer...

Spätestens wenn man dann bei der Fehlersuche auf die Registerebene 
abtauchen muss nützt einem der zusätzliche Brei überhaupt nichts.

von H. R. (hacker_r)


Bewertung
0 lesenswert
nicht lesenswert
Hi
kennst du diesen kurs?
fand ich sehr hilfreich!

https://st-mooc.udemy.com/?next=%2Forganization%2Fdiscovery%2Fbrowse%2Fstmicroelectronics-learning-portal%2F4031580%2F%3Fpage%3D1

technikus schrieb:
> Hi,
>
> ich würde gerne von AVR´s auf STM32 umsteigen.
> Da die Standard Lib durch HAL abgelöst wurde, würde ich gerne direkt mit
> der HAL einsteigen.
> Leider finde ich kein Tutorial im Netz das die HAL beschreibt - was es
> mir als Hobby Einsteiger sehr schwer macht.
>
> Habt Ihr eine Quelle zum Einstieg parat?
>
> Danke und Gruß
> technikus

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
hp-freund schrieb:

> Ist es wirklich Nötig das Du bei so ziemliche jedem Beitrag, in dem HAL
> auch nur erwähnt wird, deiner HAL Phobie freien Lauf lassen musst?

Komischerweise beschwerst Du Dich nicht über die wiederholten positiven 
Beiträge zur HAL.

> Einer mag das Konzept, ein anderer eben nicht!

Eben, und genau das sollten Anfänger auch wissen. Deswegen gehören AUCH 
Postings wie das von u.a. W.S. in jeden Thread, den ein Anfänger dazu 
aufmacht.

Was Du sichtlich gerne hättest, wäre die Vermittlung des (falschen!) 
Eindrucks, daß es allgemein üblich sei, mit der HAL zu arbeiten. Du 
möchtest das erreichen, indem nur die Fans posten sollen und die 
Kritiker bitteschön irgendwann mal die Klappe halten sollen.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Deswegen gehören AUCH
> Postings wie das von u.a. W.S. in jeden Thread, den ein Anfänger

Ich hätte auch gerne so eine Kristallkugel wie W.S. Jeden Fremden den 
man nie gesehen hat und dessen Skills man nicht kennt, gleich als 
Anfänger der auf dem Holzweg ist zu erkennen, finde ich schon enorm.

Der HAL ist low level und da setzen weitere Libs und Middleware auf, das 
ist auch ein Grund so etwas nutzen zu wollen. Nur um einen IO Pin 
wackeln zu lassen braucht man das nicht, aber das ist ja schliesslich 
nicht alles was der HAL bietet. Aufbauend kann man RTOS, Speicherkarten, 
Grafik uvm nutzen und da fängt es an spannend zu werden. Und 
freundlicherweise ist das alles Quelloffen und man kann sich ansehen was 
da abgeht.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:

> Ich hätte auch gerne so eine Kristallkugel wie W.S. Jeden Fremden den
> man nie gesehen hat und dessen Skills man nicht kennt, gleich als
> Anfänger der auf dem Holzweg ist zu erkennen, finde ich schon enorm.

Ich hätte auch gerne so eine Kristallkugel wie die HAL-Fans. Jeden 
Fremden, den man noch nie gesehen hat und dessen Skills man nicht kennt, 
gleich als planlosen, lernunfähigen und doku-allergischen Anfänger zu 
erkennen, finde ich schon enorm. Zumal er dann auch gleich Arduino hätte 
nehmen können.

> Der HAL ist low level und da setzen weitere Libs und Middleware auf, das
> ist auch ein Grund so etwas nutzen zu wollen.

Klingt nach einem Cluster-Vendor-Lock-In. Es gibt genug RTOS, mit denen 
man sich das nicht ans Bein bindet, schon weil sie älter als SPL und HAL 
sind.

Das kann ST später dann Möglichkeiten wie die geschickte Abkündigung 
bestimmter Chips ermöglichen (TI hat sowas schon gemacht), so daß Kunden 
zähneknirschend auf die teureren Varianten umsteigen müssen. Obwohl, 
angesichts des Bloats müssen sie das ja im Grunde schon von Anfang an 
machen. Deswegen ist Software von einem Hardwarehersteller meistens ein 
Danaergeschenk, weil der Interessenkonflikt zwischen hersteller und 
Käufer immer zulasten des Käufers gehen wird.

Das Problem hat man nicht, wenn man sich eine wirkliche HAL schreibt. 
Also nicht nur den umständlichen Register-in-structs-Mapper wie bei ST. 
Dann braucht die Applikationsschicht nämlich gar nicht mehr zu wissen, 
auf welchem Chip sie läuft. Schnelle Dinge wie IO-Pins realisiert man 
natürlich per Macro.

Als Hobbyist ist STs Ansatz jedenfalls zum Lernen auch nicht so toll, 
weil man damit nichts Wirkliches lernt, sondern nur irgendwelche Structs 
zu befüllen. Die resultierenden Anfängerfragen hier sind ja auch 
dementsprechend. Außerdem ist sowas vollkommen wertlos, wenn man dann 
irgendwann mal z.B. einen NXP-Chip nutzen will.

von hp-freund (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Genau das meine ich.

Da stellt jemand einen einfache Frage, in diesem Fall zu HAL.

Als Folge gibt es Seitenweise Diskussionen darüber ob man das besser 
lassen sollte oder nicht. Ob man zu dumm sei mal schnell mehrere tausend 
Seiten Datenblätter und RM zu lesen. Wenn dann noch etwas unklar ist, 
könne man noch mal nachfragen. In ein paar Monaten oder so.

Es gibt sicher viele die alles ganz genau wissen wollen und für die es 
besser ist auf Registerebene anzufangen, aber vielleicht will ja jemand 
einfach nur etwas nachbauen oder leicht für seine Bedürfnisse anpassen.

Ich denke/hoffe wer Fragen wie diese hier stellt hat nicht beruflich 
damit zu tun.

Zu 8 bit Zeiten war das einfach mal überschaubarer und somit leicht 
nachvollziehbar. Bei ARM kann man auf verschiedene Arten an die Sache 
heran gehen.

Darum meine Meinung - und damit ist das Thema für mich auch durch:

Lasst doch jedem seine Entscheidung, wie er an die Programmierung heran 
gehen möchte, bzw. ob es überhaupt sein Ding ist.

Ende.

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
H. R. schrieb:
> Hi
> kennst du diesen kurs?
> fand ich sehr hilfreich!
>
> 
https://st-mooc.udemy.com/?next=%2Forganization%2Fdiscovery%2Fbrowse%2Fstmicroelectronics-learning-portal%2F4031580%2F%3Fpage%3D1

Danke für den Tipp! Leider kann ich mich dort nicht registrieren weil 
ich "nicht eingeladen wurde"

Wie komme ich da dran?

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Da stellt jemand einen einfache Frage, in diesem Fall zu HAL.
>
> Als Folge gibt es Seitenweise Diskussionen darüber ob man das besser
> lassen sollte oder nicht. Ob man zu dumm sei mal schnell mehrere tausend
> Seiten Datenblätter und RM zu lesen. Wenn dann noch etwas unklar ist,
> könne man noch mal nachfragen. In ein paar Monaten oder so.
>
...

Amen!

Ähnlich wie früher, bevor es Arduino gab, die Bascom Diskussionen.

Ich suche IMMER NOCH ein gutes HAL basiertes STM32 Tutorial in 
englischer oder deutscher Sprache ;)

Danke

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
hp-freund schrieb:

> Da stellt jemand einen einfache Frage

Falls Du es noch nicht mitbekommen hast: das läuft hier immer so, und 
das ist auch gut so. Beispielsweise bei Programmierfragen wird auch 
nicht nur genau das geantwortet, was der Fragesteller gefragt hatte, 
sondern es wird oftmals auch der ganze Ansatz schon auseinandergenommen, 
wenn er nicht so dolle ist.

Das ist ein Feature dieses Forums. Und nur, weil Du in die HAL so 
verknallt bist, daß es Dir den Tag verdirbt, sobald jemand das nicht so 
dolle findet, ist das kein Grund, durch Schweigen diesen Mist auch noch 
zu promoten.

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
technikus schrieb:

> Ich suche IMMER NOCH ein gutes HAL basiertes STM32 Tutorial in
> englischer oder deutscher Sprache ;)

Lies Dir das reference manual durch, dann wird offensichtlich, welcher 
Parameter in den structs was bedeutet. Wie, das ist Arbeit? Naja was, es 
abstrahiert die Hardware (dem Namen zum Trotze) ja eben gerade NICHT. Es 
wäre auch sinnfrei, dafür nochmal abgeleitete Doku zu schreiben, die man 
dann parallel pflegen müßte, die aber auch nicht mehr Information 
enthält.

Ansonsten, die Inits für die Clockpfade sollten ja schon automatisch 
generiert werden, also welche Peripherals und Busse für welchen Zweck 
geclockt werden müssen.

von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
Habe mir die neuen HAL / STM32F0Cube Sachen mal angeschaut. Also das 
ganze ist schon sehr umfangreich und ich finde es für einen Anfänger 
(auch Umsteiger von AVR) relativ verwirrend.

Vor lauter includes, defines etc. blickt man kaum noch durch, selbst bei 
einem einfachen I/O-Toggle Beispiel.

Wie auch immer, wenn Du HAL machen willst, findest Du eigentlich alles 
in:

- Latest release of STM32CubeF0 firmware package
- Getting started with the STM32CubeF0 firmware package for STM32F0 
Series (UM1779)
- Description of STM32F0xx HAL drivers (UM1785)

: Bearbeitet durch User
von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Lies Dir das reference manual durch, dann wird offensichtlich, welcher
> Parameter in den structs was bedeutet. Wie, das ist Arbeit?

Das ist geil hier!
Wer hat denn gesagt das ich nicht arbeiten will???
Da ich zunächst von der Fülle aller Informationen erschlagen war, habe 
ich hier den Thread angestoßen.

Aber Ihr habt mich überzeugt! Der erste Blick geht jetzt immer über das 
reference manual.

Nichts desto trotz mach ein HAL Tutorial doch Sinn und ich gebe nicht 
auf.
Auch wenn ich mir gerade aus den Erkenntnissen selbst eins schreibe.

Mir geht es um die Interpretation der Funktionen. Ein gutes Beispiel ist 
ein per Cube erstelltes Projekt mit Interrupt gesteuertem UART.

Beitrag "Verständnisfrage stm32 uart"

HAL_UART_Receive_IT(&UartHandle, rx_data, 10);

Füllt fleißig den Puffer bis 10 Bytes empfangen wurden und beginnt dann 
wieder von vorne - alles Interrupt gesteuert.

Was ist aber, wenn ich in der Hauptschleife auslese ob schon was da ist 
und dann den Startzeiger vom Puffer neu initialisieren möchte?
Qick and dirty kriege ich das hin, geht aber irgendwie am HAL Gedanken 
vorbei...


Gruß

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zusammengefasst:

Man muss einzelne fertige Funktionen schon "begreifen" um sie sinnvoll 
nutzen zu können.

O.k. ich beschäftige mich erst wenige Stunden mit den STM32.

Wie geht Ihr daran und welche Dokus nutzt ihr hierfür?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Mir geht es um die Interpretation der Funktionen. Ein gutes Beispiel ist
> ein per Cube erstelltes Projekt mit Interrupt gesteuertem UART.
>
> Beitrag "Verständnisfrage stm32 uart"

eine Antwort habe ich in den genannten Thread geschrieben.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Dieser udemy.com link funktioniert bei mir auch nicht, das ist scheinbar 
eine Site mit kostenpflichtigen Inhalten oder der Kurs ist nicht mehr 
verfügbar.

Es gibt aber noch ein Dokument (für die F0 Serie z.B.) 
https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef0.html

Da ist als letztes ein Link zum Firmware Package das in UM1779 
beschrieben ist. In dem Paket sind eine Menge Beispiele, auch zu PWM und 
UART.
Kann sein das dieser Link nur nach Registrierung bei ST zu öffnen ist.

: Bearbeitet durch User
von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke!
Lade ich mir und arbeite ein...

von W.S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Nichts desto trotz mach ein HAL Tutorial doch Sinn und ich gebe nicht
> auf.
> Auch wenn ich mir gerade aus den Erkenntnissen selbst eins schreibe.
>
> Mir geht es um die Interpretation der Funktionen. Ein gutes Beispiel ist
> ein per Cube erstelltes Projekt mit Interrupt gesteuertem UART.
>
> Beitrag "Verständnisfrage stm32 uart"
>
> HAL_UART_Receive_IT(&UartHandle, rx_data, 10);
>
> Füllt fleißig den Puffer bis 10 Bytes empfangen wurden und beginnt dann
> wieder von vorne - alles Interrupt gesteuert.
>
> Was ist aber, wenn ich in der Hauptschleife auslese ob schon was da ist
> und dann den Startzeiger vom Puffer neu initialisieren möchte?
> Qick and dirty kriege ich das hin, geht aber irgendwie am HAL Gedanken
> vorbei...


Siehst du, so ist es, wenn man mit Fleiß einem im Grunde falsch 
angelegtem Konzept nachgeht. Zumindest sind dir schon jetzt die ersten 
Ungereimtheiten aufgefallen.

Ich sag's mal so: Hier kommen immer wieder Leute mit Problemen an, die 
etwa so lauten: "Ich will mit dem Kopf durch die Wand. Jetzt bin ich 
schon 100 mal dagegen gesprungen, aber es funktioniert nicht und ich 
hole mir nur jedesmal ne Beule. Was soll ich bloß tun?" - und da kommt 
unsereiner und sagt demjenigen: "Laß das Springen gegen die Wand lieber 
komplett bleiben, das ist definitiv der falsche Weg. Geh lieber einen 
Schritt zur Seite, dort ist eine Tür, die kannst du aufmachen und 
einfach durchgehen - ohne dir ne Beule zu holen".

Zu deinem UART-Beispiel:
Sowas braucht einen Lowlevel-Treiber, der die zugrundeliegende HW 
kapselt und damit abstrahiert. Das zitierte 
"HAL_UART_Receive_IT(&UartHandle, rx_data, 10);" sieht mir jedoch 
überhaupt nicht danach aus.

Ich gebe dir mal ein Gegenbeispiel im Anhang. Schau dir zuerst die 
"serial.h" darin an. Dann weißt du, wie eine tatsächliche HAL 
funktioniert. Das übergeordnete Programm wird nicht mit irgendwelchen 
treiberinternen Details belästigt, in der Headerdatei steht nur genau 
das drin, was zum Benutzen des seriellen Ports vonnöten ist. Der Treiber 
puffert beide Datenströme und das übergeordnete Programm kann eben 
ASYNCHRON und zeichenweise (so wie die Bezeichnung "UART" es suggeriert) 
senden und empfangen und braucht selbstverständlich nicht auf 
Sendeabschluß zu warten oder vorher bekannte Anzahl von zu empfangenden 
Zeichen oder sonstwelche schrottige und unüberlegte Beschränkungen zu 
beachten.

W.S.

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ich gebe dir mal ein Gegenbeispiel im Anhang.
>Schau dir zuerst die "serial.h" darin an.
Habe ich gemacht. Gefällt mir nicht. Bleibe doch bei CubeMX.
Kann aber damit leben, das andere es anders machen als ich.
"jedem tierchen sein pläsierchen" sagt man hier.

>Siehst du, so ist es, wenn man mit Fleiß einem im Grunde
>falsch angelegtem Konzept nachgeht.
Ich kann nur feststellen, das ST keinen Alleingang mit der
Struktur der HAL macht. Und wenn man das zugrundeliegende Konzept
kennt, erkennt man es in anderen herstellerspezifischen Libs wieder.
Aber die Wahl der Adjektive bei der Bewertung der verschiedenen
Möglichkeiten macht klar, das es hier nicht um eine rationale
Diskussion geht.

Gruß,

dasrotemopped.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Vielleicht kann ich hier ein paar Gedanken beisteuern, wie ich als 
Hobbyist den Übergang von PSoC zu STM32F7 ziemlich schnell geschafft 
habe.
Es gibt nämlich eine Anleitung nebst Bibliothek und Beispielen von Uwe 
Becker, die man hier findet:
http://mikrocontroller.bplaced.net/wordpress/
Als IDE verwende ich Eclipse in der Version von SW4STM32 von dieser 
Quelle:
http://www.openstm32.org/HomePage

Ich habe als konkretes Ziel ein User- Interface für ein Funkgerät mit 
Red Pitaya als Transceiver und STM32F7Disco als Anzeige- und 
Bedieneinheit.
Der gegenwärtige Stand ist hier zu sehen:
http://www.wkiefer.de/x28/Red%20Pitaya.htm

Ohne die Vorarbeit von Uwe Becker wäre ich längst noch nicht auf diesem 
Stand... Deshalb mein Dank an ihn.

von Nop (Gast)


Bewertung
2 lesenswert
nicht lesenswert
technikus schrieb:

> Wie geht Ihr daran

Stückweise, vom Einfachen zum Schwierigen.

Erstmal die jeweilige Toolchain ans Laufen kriegen bis dahin, daß von 
irgendeinem Simpel-Projekt im Netz, das zu meinem Board paßt, ein 
Hexfile generiert wird.

Dabei prüfe ich dann zumindest Stackpointer und Resetvektor (also den 
Anfang des Hexfiles) gegen das Mapfile, ob das hinkommt. Kleine Falle - 
der Resetvektor im Hexfile ist um genau 1 höher als die Adresse aus dem 
Mapfile, was für den Thumb-Mode der STM32 aber genau richtig ist.

Dann das Interface mit dem Programmer, also zumindest ein Verify muß 
laufen, damit ich sehe, daß er eine Verbindung kriegt. Die Überprüfung 
scheitert natürlich, weil ich noch nichts eingespielt habe, aber das ist 
erstmal egal.

Dann einspielen des Simpel-Projektes, optimalerweise einfach ein Blinky. 
Wenn das geht, bin ich schonmal sehr zufrieden, denn die Toolchain 
funktioniert.

> und welche Dokus nutzt ihr hierfür?

Danach kommt das Reference Manual (manchmal auch das Programming 
Manual). Ich lese mir die Beschreibung von den Dingen durch, die ich 
nutzen will, um erstmal ein Gefühl dafür zu kriegen, wie das 
funktionieren soll. Da steht oftmals auch drin, was an Randbedingungen 
zu beachten ist. Beispielsweise die PLL-Einstellung hat noch 
Anforderungen an die Zwischenfrequenzen, und außerdem spielen Waitstates 
und Voltage-Scaling auch noch eine Rolle.

Da ich Applikationen ohnehin schichtenmäßig baue, habe ich irgendeine 
Art von logischer Lowlevel-Abstraktion mit definiertem Interface, und 
nur diese Funktionalitäten hängen überhaupt von der Hardware ab, also 
muß ich die implementieren.

Was genau ich da brauche, hängt von der Funktionalität ab. Aber die 
üblichen Bausteine wie IO-Debouncing, AD-Glättung, DA-Ausgabe, 
Datenqueues usw. sind ja Standardmuster, das kennt man. Oftmals muß man 
Zeugs zwischen Applikationskontext und Interruptkontext tauschen, wo man 
möglichst wenig Logik in den Interrupt packt, aber soviel wie nötig.

Wenn das Lowlevel-Interface zu groß wird, splitte ich das auch nochmal 
in zwei Schichten, deren untere sich um die Sequenz der physikalischen 
Registerzugriffe kümmert (nach Reference Manual), und die obere um die 
Verwaltung der Hardware und die Kreuzeffekte zwischen den Einstellungen 
(z.B. CPU-Frequenz vs. Systemtimer).

Allerdings lasse ich die untere Schicht auch gerne noch Makros 
exportieren, damit z.B. das IO-Toggling aus der oberen Schicht nicht 
unnötig lahm wird.

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das hier ist übrigens auch ganz nett für den ersten Einstieg:

http://letanphuc.net/2015/06/stm32f0-timer-tutorial-and-counter-tutorial/

Bei mir läuft jetzt, dank euerer Hilfe:
- Timer Interrupt
- PWM
- UART

von H. R. (hacker_r)


Bewertung
0 lesenswert
nicht lesenswert
Also der CUBEMX + STM32 HAL kurs ist kostenlos. UDEMY ist ein 
kommerzieller anbieter, aber ST stellt es frei zur Verfügung.
Kann ich dir sehr empfehlen. Hier kannst du dich wie gesagt for free 
anmelden:
https://my.st.com/content/my_st_com/en/events/registration-for-stm32cube-basics--online-course-with-hands-on-e.html
Wenn ich mich anmelde sehe ich 4 verschieden Kurse,  Alls ganz 
interessant

: Bearbeitet durch User
von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich war damals (2013?) auch bei einem kostenlosen ST-Seminar zur 
Einführung in die STM32-Reihe in Dortmund. Das war ganz nett, 
STM32F0-Discovery gab es kostenlos, Essen auch, dazu natürlich etwas 
Werbung der bekannten Distributoren. Zumindest gewinnt man so einen 
guten ersten Überblick über die Reihe.

Und aus dem Seminar habe ich zwei sehr wertvolle Kontakte mitgenommen, 
davon einen direkt bei ST, falls es mal brennt. Alleine deswegen hat 
sich das schon gelohnt.

Zur Frage des OP:

Ich sehe das alles (HAL oder selbst Register füllen) nicht so kritisch.

Ich hab damals mit der STLib begonnen und wirklich schlecht fand ich sie 
nicht. Man hat schnell ein Erfolgserlebnis, weil im Netz fast überall 
dieser Code verwendet wird.

Sehr hilfreich waren/sind die Kommentare in den einzelnen Quelldateien 
der Peripheriemodule (bspw. stm32f0xx_dma.c) gewesen, das sollte man 
sich unbedingt ansehen. Da hat man eine kurze Zusammenfassung dessen, 
was man zum Einsatz benötigt. Das kann ich jedem Anfänger wärmstens 
empfehlen.

Mittlerweile sind wir von der STLib weg und schreiben direkt in die 
Register bzw. über eine eigene HAL.

Aber zum ersten Reinschnuppern und schauen, was man an konkreten 
Registern überhaupt benötigt, finde ich den Quellcode nicht schlecht. 
Das Reference Manual ist ja doch für Einsteiger abschreckend groß.

von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich buddel den mal wieder aus ..... bisher bin ichn mit meinen 
StdPeriphLibs ja recht glücklich im Hobbybereich. Das Moped fährt dahin 
wo es hin soll nachdem ich es zusammen geschraubt habe. Habe da ja auch 
keinen Zwang auf Teufel komm raus was Neues erfinden zu müssen.

Aber mehr und mehr erscheinen Codes mit dieser "HAL" und dieses ominöse 
Case Tool CubeMX wird erwähnt. Case Tools gab es schon Ende der 90iger, 
setzten sich nie wirklich durch. EmBitz wird nicht unterstützt, EmWin 
auch nicht und natürlich auch kein CooCox. Kostet ja nix, verdient 
keiner was dran.

Ist hier jemand mit diesem CubeMX glücklich geworden? Odrer dient das 
nur dazu den Überblick zu kriegen wie was funktioniert, damit man es 
später selbst umgeschrieben und angepasst verwendet?

Gruss,
Christian

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Ist hier jemand mit diesem CubeMX glücklich geworden?

Ja.
Zusammen mit SW4STM32 läuft das prima.

Ohne Begrenzung und ohne Kosten.

von gnugnu (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Jaaaa, die Ökosysteme sind sind ca. 3 Jahren das ganz heisse Ding in 
Herstellerkreisen. Jeder Hersteller bringt sein eigenes Ökosystem auf 
den Markt oder bundled Drittherstellerkomponenten zu dem "one stop 
shopping ultrafast time to market don't worry about the details" 
Entwicklungserlebnis. Faszinierenderweise fast immer umsonst, äh 
kostenfrei...

Aber natürlich gibt es nichts umsonst auf der Welt. Das Geschäftsmodell 
ist natürlich vendor lock in und die Hoffnung, genügend Leute mit soviel 
Erfahrung in "meinem" Ökosystem auszustatten, dass die kostenpflichtige 
Version davon dann auch dort zum Einsatz kommt, wo Geld fliessen darf.

Ist auch erstmal nichts dagegen zu sagen. Irgendwie muss sich ja die 
Arbeit, die man darein gesteckt hat, rentieren. Mit Software Geld zu 
machen ist heutzutage nicht einfach.

Blöd wird's wirklich nur da, wo aus politischen Gründen mehrere dieser 
Ökosysteme miteinander in Konkurrenz stehen. ARM z.B. pusht sehr 
aggressiv ihr CMSIS 2 und will es zum universellen Standard erklären - 
was natürlich kein Chiphersteller gern sieht, weil damit sein 
Alleinstellungsmerkmal verloren geht und im Super GAU Fall (aus 
Herstellersicht; von ARM aus gesehen das Paradies) alle ARM Chips 
sofotwaremässig komplett austauschbar sind. Codebasen, in denen CMSIS 
und vendorspezifische HALs gemeinsam benutzt werden müssen (weil z.B. 
die eine genutzte Middleware auf CMSIS aufsetzt und die andere auf ST 
HAL), sind irgendwann so dermassen mit Abstraktionslayern und wrappers 
aufgebläht, dass die Les- und Wartbarkeit des Codes enorm darunter 
leidet, vom Blähfaktor mal ganz zu schweigen.

Wer mal versucht hat, irgendein Codebeispiel vom Kinetis SDK auf Minimum 
zu strippen, wird irgendwann mal die 27 OS wrappers alle in die Tonne 
schmeissen, dann wird es einfacher, back to the roots zu gehen.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> EmBitz wird nicht unterstützt, EmWin auch nicht und natürlich auch kein
> CooCox.

Such mal nach CubeMX2Makefile, das ist ein simples Pythonskript.

von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
Es geht mit EmBitz. Allerdings muss man manuell einige Sachen machen:

Erstmal das Projekt im EmBitz anlegen, dann alles bis auf die .ld und .s 
Files löschen. Dann den von CubeMX generierten Kram in das 
Projektverzeichnis kopieren und die Files (rekursiv) dem Projekt 
hinzufügen.

Alles sehr unschön leider.

EDIT: Evtl. hilft auch das hier, kommt mir aber etwas verworren vor:

https://www.embitz.org/forum/thread-670.html

: Bearbeitet durch User
von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mir geht es da wie beim Arduino 1.0.5 und beim PIC mit CCS. ich habe mir 
da eine funktionierende Umgebung zusammen gestrickt, etliche Chips per 
Hand eingefpflegt in die Scripte, kann einen Attiny84 programmieren usw. 
Und auf einmal kommt was Neues raus, inkompatibel natürlich, andere 
Config Files. Und man fängt von vorne an oder blibt bei dem was man hat.

So ist es mit dem ARM dran oder ARM ab auch: Mit der SPL fahre ich gut, 
kann sie anwenden und die letzte Version ist auch recht fehlerfrei. Im 
Hobbybereich wohlgemerkt! EmBitz 1.1 hat alles was man braucht, außer 
einen Code Analyzer und auch keine Runtime Analyse. Aber Debugger, 
gelben Balken, Watch Fenster mit Live Updates und alles besser als eine 
rote LED, die man als Debugger verwendet.

Schätze mal ich friere das auch auf dem Stand ein, alter Hase (48) muss 
keine neuen Tricks mehr lernen.....

Christian

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
gnugnu schrieb:
> Jaaaa, die Ökosysteme

Danke!

Dein Beitrag spricht mir aus der Seele.

W.S.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.