STM32 mit HAL Tutorial

Wozu willst du selbst ein Tutorial schreiben, wenn du bzgl. HAL von 
Tuten und Blasen keine Ahnung hast? Das wird sich keiner durchlesen, 
wobei es auch ein richtiges Manual gibt.

PS: Nutzt CMSIS! Ich bin dann mal weg ;) ..

>Wozu willst du selbst ein Tutorial schreiben, wenn du bzgl. HAL von Tuten und 
Blasen keine Ahnung hast

Das war sicher mehr als "Zusammenfassung/Einführung" gemeint als ein 
vollwertiges Tutorial, damit sich Einsteiger beim Thema HAL nicht so 
schwer tun und eine Orientierung bekommen.

Noob hilft anderen Noobs.

Na wenn es Spass macht...

Dreikommaeinsvier schrieb:
> Noob hilft anderen Noobs.

Das prinzipiell nicht schlecht, denn der Noob weist auch Dinge hin, die 
man beachten muss, welche erfahrene Entwickler für selbstverständlich 
halten.

Der Noob findet auch heraus, was man aktuell alles machen muss, um die 
Software an laufen zu bringen, während der erfahrene Entwickler 
typischerweise auf eine mehrere Jahre altes Setting aufbaut.

Für die HAL würde ich mich aber nicht abrackern Zum einen, weil ich sie 
doof finde und zum anderen, weil ST sie bereits Anfängertauglich 
dokumentiert hat. Ein Hello-World Programm klickt man sich zu 99% 
schnell mit Cube-MX zusammen - was will man mehr?

Stefanus F. schrieb:
> weil ich sie
> doof finde

Sehr fundiert, sehr sachlich. Bist auch ein Noob, nicht wahr! :-[

labertaschen schrieb:
> Stefanus F. schrieb:
>> weil ich sie doof finde
>
> Sehr fundiert, sehr sachlich. Bist auch ein Noob, nicht wahr! :-[

Ich habe hier schon oft genug erklärt, wie ich zu dieser persönlichen 
Meinung komme. Muss ich nicht nicht schon wieder breit treten. Die Leute 
die das gerne ausdiskutieren, kennen meine Argumente bereits. Die 
anderen interessiert es nicht.

Harry L. schrieb:
> Die HAL User-Manuals kennst du bereits?
>
> Für F1xx:
> 
https://www.st.com/content/ccc/resource/technical/document/user_manual/72/52/cc/53/05/e3/4c/98/DM00154093.pdf/files/DM00154093.pdf/jcr:content/translations/en.DM00154093.pdf

Kenne ich. Für mich ist das was zum Nachschlagen, aber ich könnte damit 
kein CAN ans laufen bekommen.

Jens schrieb:
> Wozu willst du selbst ein Tutorial schreiben, wenn du bzgl. HAL von
> Tuten und Blasen keine Ahnung hast? Das wird sich keiner durchlesen,
> wobei es auch ein richtiges Manual gibt.
>
> PS: Nutzt CMSIS! Ich bin dann mal weg ;) ..

CMSIS nutzt man dann doch auch. Ich würde mir das erarbeiten und 
mitschreiben.

Stefanus F. schrieb:
> Für die HAL würde ich mich aber nicht abrackern Zum einen, weil ich sie
> doof finde und zum anderen, weil ST sie bereits Anfängertauglich
> dokumentiert hat. Ein Hello-World Programm klickt man sich zu 99%
> schnell mit Cube-MX zusammen - was will man mehr?

Ich denke zu HAL gibt es keine wirkliche Alternative, wenn es das 
einzige ist was zur Verfügung gestellt wird. Auf Register einzeln 
schubsen ist mir auch meine Hobby Zeit zu schade.

Stefanus F. schrieb:
> weil ST sie bereits Anfängertauglich
> dokumentiert hat.

Das würde mich noch interessieren, wo ich das finde.


Danke für euer Feedback. Dann mache ich das nur für mich, geht dann eh 
schneller.

Der Umgangston und Umgangsweise in diesem Forum ist eh so schlecht wie 
sonst nirgenwo. Eigentlich total schade, da es hier echt Leute mit 
Ahnung gibt.

Lieben Gruß
Jan

Stefanus F. schrieb:
> Die Leute
> die das gerne ausdiskutieren, kennen meine Argumente bereits. Die
> anderen interessiert es nicht.

... und wer nicht für mich ist, ist gegen mich!

Komischer Zeitgenosse du bist.

labertaschen schrieb:
> ... und wer nicht für mich ist, ist gegen mich!
> Komischer Zeitgenosse du bist.

Genau Gegenteil davon propagiere ich. Unterschiedliche Meinungen sind 
Ok, es besteht keine Notwendigkeit, zu einem gemeinsamen Konsens zu 
kommen. Wer die HAL mag, darf sie benutzen. Wer sie nicht mag, muss sie 
nicht benutzen.

habe ich schon mal erwähnt das Mbed auch sehr gut geeignet ist um die 
STM32 (und viele andere Cortex-M) einfach zu programmieren? Ein 
einheitliches objektorientiertes API für viele Cortex-M, für die STM32 
wird dafür intern die HAL genutzt. Die Standardschnittstellen 
DigitalIn/Out, AnalogIn/Out, SPI,  I2C, CAN uvm. sind als Basis 
vorhanden und man muss sich nicht mit dem HAL API quälen. Wenn spezielle 
Hardware wie FSMC, SDIO, Graphic genutzt werden möchten kann das immer 
noch über Cube generierten Code oder die STM Board Support Packages dazu 
gebaut werden.
Dazu bietet Mbed ein Kommandozeileninterface über das Projekte ohne 
Konfigurationsaufwand angelegt, kompiliert und geflasht werden können.

Johannes S. schrieb:
> habe ich schon mal erwähnt das Mbed auch sehr gut geeignet ist

Noch ein weiteres Framework über dem Framework entpuppt sich schnell als 
Sackgasse, sobald mal etwas nicht wie gewünscht funktioniert. Dann muss 
man sich plötzlich intensiv mit beiden Frameworks beschäftigen, um den 
Code anzupassen bzw. den Fehler erst einmal zu verstehen.

Das wird aber von den Mbed Machern und auch STM exzessiv getestet. Es 
ist nicht wie bei Arduino.cc die mit der STM Umsetzung des API nix zu 
tun haben.
Und die HAL ist STM und nur für diese verfügbar, das Mbed API gibt es 
auch für LPC, Kinetis, Nordics nRF, Atmel SAM uvm.
Die Panik mit 'Framework über Framework' ist Quark. Beim PC interessiert 
micht auch nicht ob ein Intel oder AMD drinsteckt, die SW soll 
unabhängig davon laufen. Und genau das kann man heute auf einem µC auch 
erreichen. Ja, die Performance... Laste einen F4 mit 168 MHz erstmal 
aus, dann können wir weiter reden. Für meinen Heizkreisregler mit 
LPC1549 habe ich an einem WE den Rumpf mit RTOS, PID Regler Task mit 
Ni1000 RTD, Kommandointerpreter über serielle Schnittstelle und 
Messwertübertragung per CAN hinbekommen. Alternativ kann ich das auf 
einem STM laufen lassen. Das sind Vorteile die zählen.

Johannes S. schrieb:
> Das Mbed API gibt es
> auch für LPC, Kinetis, Nordics nRF, Atmel SAM uvm.

Das ist natürlich ein starker Vorteil - solange es funktioniert.

Es funktioniert sehr gut und immer besser weil da ein professionelles 
Team dran arbeitet. Es werden Unmengen an Tests gemacht, angefangen mit 
CI für PRs, automatisierten Tests und Unittests sowie strengen Reviews 
für die PR. MBed ist aus einem Guss, wenn eine Änderung gemacht wird 
wird trotzdem für andere Targets mitgestet. Natürlich passieren da 
trotzdem noch Fehler, aber die werden alle Ernst behandelt, in den 
letzen zwei Jahren hat sich dss genial weiterentwickelt. Ich kann es 
immer wieder nur empfehlen.

https://leanpub.com/mastering-stm32

Kauf dieses Buch es ist jeden Cent wert!
Viele anschauliche beispiel mit Erklärung der Prinzipien.

Johannes S. schrieb:
> habe ich schon mal erwähnt das Mbed auch sehr gut geeignet ist um die
> STM32 (und viele andere Cortex-M) einfach zu programmieren? Ein
> einheitliches objektorientiertes API für viele Cortex-M, für die STM32
> wird dafür intern die HAL genutzt. Die Standardschnittstellen
> DigitalIn/Out, AnalogIn/Out, SPI,  I2C, CAN uvm. sind als Basis
> vorhanden und man muss sich nicht mit dem HAL API quälen. Wenn spezielle
> Hardware wie FSMC, SDIO, Graphic genutzt werden möchten kann das immer
> noch über Cube generierten Code oder die STM Board Support Packages dazu
> gebaut werden.
> Dazu bietet Mbed ein Kommandozeileninterface über das Projekte ohne
> Konfigurationsaufwand angelegt, kompiliert und geflasht werden können.

Nun bin ich ja mal neugierig geworden. Folgendes Programm erzeugt auf 
einem LPC1549 sage und schreibe 10428 byte (DEBUG-build), wenn ich es in 
MCUXpresso importiere (und 10104 byte im RELEASE-build):

1

#include "mbed.h"

2

3

DigitalOut myled(LED1);

4

5

int main() {

6

    while(1) {

7

        myled = 1;

8

        wait(0.4);

9

        myled = 0;

10

        wait(0.4);

11

    }

12

}

Und schrittweise debuggen geht da auch nicht, weil das als 
libs/object-Dateien vorliegt. Mache ich da gerade einen Anfängerfehler 
oder ist der Gedanke eher der, daß das niemanden etwas angeht und die 
libs schon funktionieren und nicht debuggt werden können müssen?

Lutz schrieb:
> Mache ich da gerade einen Anfängerfehler

Ja, du erwartest kompakten Code auf Mikrocontrollern. Wir erleben gerade 
die Wende, wo das bald nicht mehr gilt. Mbed ist das neue Arduino, nur 
will man damit die Profis bedienen.

Auch bei Android beobachte ich diesen Wechsel. Noch kann man den ganzen 
Ballast, den das Android Studio in deine Programme einbaut wieder 
entfernen. Aber ich denke, bald werden diese Komponenten zum 
Pflichtfaktor.

Auf dem PC Markt haben wir uns längst daran gewöhnt, das selbst minimale 
Hello-World GUI Programme nicht mehr 15kB sondern 150kB gross sind und 
zusätzliche eine Laufzeitbibliothek von einigen hundert MB mit sich 
herum schleppt.

Gerade noch gab Volkswagen öffentlich zu, dass sie keine Ahnung haben, 
wie ihre Software funktioniert. Ähnliches habe ich auch bereits 
persönlich von SAP gehört.

Lutz schrieb:
> Nun bin ich ja mal neugierig geworden. Folgendes Programm erzeugt auf
> einem LPC1549 sage und schreibe 10428 byte (DEBUG-build)

Wie hast du das Projekt erzeugt, über den Online Compiler und dann 
exportiert? Dann bekommst du ein Mbed2 mit vorkompilierter Lib die sich 
schwieriger debuggen lässt. Die Quellen zu Mbed2 findet man unter 
mbed-dev, ein Projekt mit dem mbed-cli anlegen geht dann so:

1

mbed new . --mbedlib

2

mbed add https://os.mbed.com/users/mbed_official/code/mbed-dev/

3

mbed compile -m LPC1549 -t GCC_ARM

und der export nach MCUXpresso:

1

mbed export -m LPC1549 -i mcuxpresso

Mittlerweile gibt es auch wieder die Option das als zip zu exportieren 
mit Schalter '-z'. Da gab es nur noch einen Fehler in .tools/project.py, 
man kann zwei Zeilen mit 'notify.info' mit # auskommentieren und dann 
geht das.
Beim LPC1549 war noch ein Fehler im Linkerfile, mein PR mit dem fix ist 
vor ein paar Tagen übernommen worden:
https://github.com/ARMmbed/mbed-os/pull/8978/files

Das binaray hat seine Grösse weil ein OS natürlich einen Overhead 
mitbringt, in deinem Beispiel die DigitalOut Klasse und der Timer der 
sowieso immer drin ist. Dafür ist das schon ein Stück Komfort und gerade 
der Timer ist da gut implementiert.

Der LPC1549 hat genug Speicher um auch das mbed-os (Mbed5) zu nutzen. 
Das ist die aktuelle Entwicklung, die Änderungen für Mbed2 werden noch 
mit Verzoögerung nachgezogen aber inrgendwann wird das sicher 
eingestellt. Mbed2 ist für kleine µC besser und man kann die newlib-nano 
unter gcc verwenden, das mbedö-os enthält das RTOS und die Nanolib ist 
nicht threadsafe, deshalb ist da die volle newlib drin.
Ich benutze den LPC1549 auch mit mbed-os, der hat 256 kB Flash und da 
jucken mich die +20 kB nicht. Dafür muss man in der target.json die 
release Einstellung anpassen:

1

"release_versions": ["2", "5"],

Christopher J. schrieb:
> Genaueres findest du unter
> 
https://github.com/adamgreen/gcc4mbed/blob/master/notes/size_analysis.creole#analyzing-firmware-size

das gcc4mbed von Adam Green ist aber nicht mehr aktuell und scheinbar 
auch nicht mehr weitergepflegt, war ein abgespeckter Fork für gcc. 
Besser das 'originale' mbed von ARM benutzen.

Wenn man in der Kommandozeile mit 'mbed compile' übersetzt bekommt man 
eine Statistik ausgeworfen was wieviel Speicher braucht, wird aus dem 
mapfile erzeugt. Da gibt es noch einen Schalter mit dem man den Level 
der Ausgabe detailierter stellen kann, der ist aber noch nicht 
dokumentiert, müsste ich raussuchen.

Christopher J. schrieb:
> Warum weiß ich auch nicht und
> finde es auch ziemlich dämlich.

Es gab die Möglichkeit mit Rechsklick in der Online IDE auf der mbed-lib 
die in die Quellen umzuwandeln, dann wurden die auch exportiert. Aber da 
das mbed so stark gewachsen ist dauerte das ewig und ist wohl 
rausgeflogen. Man kann aber auch im Online Compiler die lib löschen und 
das mbed-dev importieren. Aber mit dem mbed-cli geht das mittlwerweile 
alles besser, den Online Compiler benutzte ich auch nur noch in seltenen 
Fällen. Das ist der Keil Compiler, für Cortex-M0 erzeugt der immer noch 
kompakteren Code als der gcc der für M0 schlecht optimiert.

Mw E. schrieb:
> Online IDE?
> Das wird ja immer grauenvoller!

Die Online IDE gibt es mittlerweile schon an die 10 Jahre und 
funktioniert immer noch. Mbed wurde von zwei ARM Mitarbeitern ins Leben 
gerufen und war als Ausbildiungssystem gedacht. Da die Schulen keine 
fetten Computer und spezielle Programmierhardware hatten waren die 
Säulen der Idee ein Online Compiler der im Browser läuft und keine 
lokale Installation benötigt und ein Bootloader der das binary File vom 
Webbrowser direkt per USB auf den Controller flashen kann. Um die 
leistungsfähige ARM HW zu programmieren war also nur ein USB Kabel 
nötig.
Die Idee war leider der Zeit vorraus, die Hobbyprogrammierer hielten die 
AVR für völlig ausreichend und das etwas einfachere Arduino mit einem 
ähnlichen Ansatz wurde viel populärer.
Mbed wurde weiter ausgebaut, das HDK mit dem Zusatzprozessor für die 
Programmierung über USB wurde offengelegt und zu dem Urvater LPC1768 
kamen weitere Targets hinzu. Das dümpelte so vor sich hin bis vor zwei 
Jahren etwa massiv daran weitergearbeitet wurde. Einmal um es in den IoT 
Bereich zu pushen und jetzt auch für professionelle Anwendungen. Da gibt 
es jetzt eine Seite mit Anwendungen mit Mbed: 
https://www.mbed.com/built-with-mbed/ und ARM bietet Unterstützung für 
die Umsetzung mit Mbed an.
Es ist aber OpenSource und unter Apache 2.0 Lizenz und darf auch 
kommerziell verwendet werden, da profitiere auch ich als Hobbyanwender 
sehr davon das es sich so gut weiterentwickelt.
Und auch wenn der Online Compiler immer noch funktioniert, die aktuelle 
Entwicklung setzt sehr auf das mbed-cli. Einem Kommandozueilen Interface 
wo man mit wenigen Befehlen alles nötige machen kann. Auch die 
Projektdateien für eine IDE erzeugen. ARM arbeitet auch an einer eigenen 
IDE, aber da gibts noch nix öffentliches. Ich benutze jetzt viel VSCode 
und darin Tasks die das mbed-cli aufrufen und mit der Extension 
Cortex-Debug auch debuggen kann.
Da geht die Reise hin.

Johannes S. schrieb:
> Wie hast du das Projekt erzeugt, über den Online Compiler und dann
> exportiert?
Ja. Mit RTOS usw. ergibt die Größe dann schon einen Sinn. Wobei man das 
"online" nicht einstellen kann, nun ja. Und online werden nur 
object-files exportiert, ebenso nun ja. Wegen traffic etwas 
nachvollziehbar, aber dann sollte es schon eine Mechanismus geben, der 
bei Auswahl/wenn explizit gewünscht die Quellen aus dem 
offlinebereich/lokale Platte holt.
> Dann bekommst du ein Mbed2 mit vorkompilierter Lib die sich
> schwieriger debuggen lässt. Die Quellen zu Mbed2 findet man unter
> mbed-dev, ein Projekt mit dem mbed-cli anlegen geht dann so:
> mbed new . --mbedlib
Jetzt habe ich plötzlich 2,8 GB mehr auf der Festplatte, vielen Dank...
> mbed add https://os.mbed.com/users/mbed_official/code/mbed-dev/
Timed out, "unable to to clone repository"

Auf etwas anderem Weg hatte ich heute Mittag auf die Schnelle was 
installiert.
> mbed compile -m LPC1549 -t GCC_ARM
Da kam dann "[Warning] @,: Compiler version mismatch: Have 7.3.1; 
expected version >= 6.0.0 and < 7.0.0". Der mag den Compiler vom 
mcueclipseplugin nicht, da zu neu??? Müßte 2018q2 sein. Vor 3 Tagen ist 
sogar 2018q4 rausgekommen.

Schade, ich dachte mal auf die Schnelle eine Toolchain zum 
Zusammenklicken von Komponenten und Boards die ich habe, aber war wohl 
(zumindest so) nix.

Lutz schrieb:
> Jetzt habe ich plötzlich 2,8 GB mehr auf der Festplatte, vielen Dank...

Es ist das ganze Paket für alle unterstützten Targets, das ist schon 
recht gross geworden. Aber das sollte im Zeitalter grosser Festplatten 
kein Problem sein.

Lutz schrieb:
> Da kam dann "[Warning] @,: Compiler version mismatch: Have 7.3.1;
> expected version >= 6.0.0 and < 7.0.0".

es ist mit den gcc 6-7 getestet. Bei anderen Compilerversionen kann es 
Probleme geben, in den meisten Fällen aber nicht. Die Tests sind sehr 
aufwändig und werden nicht sofort mit den neuesten Versionen gemacht. 
Ich benutze aber auch einen neueren und habe bisher keine Probleme 
bekommen. Ebenso funktioniert es mit neueren C++ Standards, aber da gcc 
+ Keil * IAR unterstützt werden ist das nicht offiziell freigegeben.

Ich empfehle ebenfalls die HAL von Chibios, die ist effizient und 
wirklich sauber durchgezogen, inkl. Treiber für alles was das Herz 
begehrt!

http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:hal:start

Zum einsteigen am besten gleich ChibiStudio downloaaden, auf C:\ 
entpacken und loslegen. Hat  ganz viele Beispiele, da ist fast jedes 
Board schon vertreten.

Mike schrieb:
> Ich empfehle ebenfalls die HAL von Chibios,

Ist wohl fast nur für STM32.

Johannes S. schrieb:
> Lutz schrieb:
>> Jetzt habe ich plötzlich 2,8 GB mehr auf der Festplatte, vielen Dank...
>
> Es ist das ganze Paket für alle unterstützten Targets, das ist schon
> recht gross geworden. Aber das sollte im Zeitalter grosser Festplatten
> kein Problem sein.

Das nicht, aber es muß ja auch runtergeladen werden. Im 
Flatratezeitalter im Hintergrund auch fast egal, aber man sollte 
zumindest per Haken auswählen können, welche targets man haben will. Ich 
brauche von den 2,8 GB gerade mal 7,4 MB für mein target! Ich hab's 
gerne effektiv.

Ich muß da wohl zwischen den Tagen noch mal kurz nachschauen, wo es bei 
mir hakt.

>> Ich empfehle ebenfalls die HAL von Chibios,
>
>Ist wohl fast nur für STM32.

STM32 ist fast vollständig, hat aber auch Beisppielprojekte für AVR, 
LPC21xx, SPC5 und ARM (generic) für eigene Portierungen.

Mw E. schrieb:
> Fürs Bitschubsen musst du nur as RefMan lesen.
> Für den HAL darfste RefMan und die gruselige HAL Doku lesen.
> Zudem ist die Peripherie jetzt nicht so schwer zu verstehen.

Genau meine Meinung. Allerdings wirst du damit die Ohren der meisten 
nicht mehr erreichen. Es macht sich heute keiner mehr Gedanken wie viel 
Softwareschichten verwendet werden, hauptsache schnell zusammengenagelt.
Eines der krassesten Beispiele dafür ist nodejs. Um ein Byte über die 
serielle Schnittstelle zu schubsen kann man wunderschön serialport 
verwenden. Und wie der Blitz erzeugt ein Aufruf von "npm install 
serialport" 587 Dateien in 129 Verzeichnissen die ab jetzt zum Projekt 
gehören. Das ist krank in meinen Augen.
Auch wofür man für die einfachsten Sachen auf dem µC eine HAL-Schicht 
dazwischen braucht erschließt sich mir nicht. Was am Anfang einfach ist, 
ist am Ende doppelter Aufwand für Code und Verständnis. Und wenn man 
wirklich alle Spezialfälle der Baugruppen benutzen will, wird es sowieso 
nichts mehr mit der Hardwareunabhängigkeit. Die fetten Bestandteile wie 
z.B. USB und Ethernet lassen sich noch am ehsten auf eine gemeinsame 
High-Level-Schicht abbilden. Beim ADC und den Timern hört der Spaß aber 
auf wenn  man mehr will als das was Arduino oder mbed bieten.