STM32 - wo gibt es Literatur, Kochbücher etc. in deutsch?

[STM32Newbee (Gast)]

Liebes Forum,

viele kleinere Steuerungsaufgaben konnte ich mit atmels 8-Bit 
Prozessoren relativ einfach lösen. Jetzt bin ich an eine Leistungsgrenze 
gestoßen.

Ich habe mich für STM 32 + Systems Workbench (eclipse) + CubeMX + HAL 
Lib entschieden. Es läuft. Nachdem ich eine LED zum Blinken gebracht 
habe und ein PWM-Muster mittels Timer3 (Nucleo STM32F411RE) erzeugt 
habe, indem ich den Code anderer mehr oder weniger in main.c einkopiert 
habe und in CubeMX wie ein kleines Äffchen (also ohne eigenes 
Verständnis) Timer Konfigurationen zusammengeklickt habe, frage ich 
mich, ob es das sein kann.

Zwar kann ich vom Code unter Zuhilfenahme der HAL Lib Doku (1800 Seiten 
(!)) und anderer Literatur erkennen, warum es so funktioniert, wie es 
funktioniert. Aber der umgekehrte Weg, von der Doku zur Problemlösung 
ist mir völlig unklar. Es scheint mir nicht sinnvoll, eine Doku nach 
geeigneten Systemaufrufen zu durchforsten, die evtl. mein Problem lösen.

Um z.B. ein GPIO Ausgang zu setzen, muß man
RCC_AHBPeriphClockCmd(AHB_GPIOC, ENABLE); und diverse andere Dinge tun:

    GPIO_StructInit(&gpio);
    gpio.pins = GPIO_P13;
    gpio.mode = GPIO_OUTPUT;
    gpio.otype = GPIO_OT_PP;
    GPIO_Init(GPIOC, &gpio);
wo steht so was? Möglichst systematisch.

Findet man Codeschnipsel, so scheint es wichtig zu sein, welche Libs man 
in seiner Umgebung nutzt, ob HAL, CMSIS, SPL oder was auch immer, 
andernfalls drohen Compilierfehler.

Es fehlt mir also an Durchblick, Ordnung und Orientierung. Und ich finde 
für STM32 kaum Literatur in deutsch (die Transferleistung von Englisch 
--> Deutsch möchte ich mir sparen, wenn das Thema an sich schon komplex 
ist.)

.. und ja, ich kenne die gute Seite von Diller technologies, es läßt 
sich in meiner Umgebung (HAL) nur nicht kompilieren (--> Ursache: 
mangelnder Durchblick, Ordnung und Orientierung) und ich kenne auch den 
Link zu von Sisy (leider C++, nicht mein Ding).

Jetzt die Frage:
Habt Ihr einen Tipp für didaktisch geschickt aufbereitetes, praktisches 
Wissen, auch käufliche Bücher zur STM32,  STM32 Peripherie, zu nutzbaren 
Libs, Code Schnipsel, Kochrezepte, ich würde dann meine IDE darauf 
abstimmen, zu Not auch ohne HAL

Dank und Gruß
STM32Newbee

andere mit ähnlicher Fragenstellung hier im Forum waren:

-> Beitrag "Suche etwas Hilfe bei ATM/STM32 Einstieg"
-> Beitrag "STM32 Tutorial"
-> Beitrag "[ARM - STM32F7] Tutorial/Grundlagen C-Code"

[Dr. Sommer (Gast)]

Ohne Englisch wird's im technischen Bereich sehr dünn. Mit solchen 
Einschränkungen wird es schwierig. Und das Englisch in technischen 
Dokumentationen ist auch nicht schwierig - ST sind schließlich 
Franzosen, die können das auch nicht besser.

STM32Newbee schrieb:
> Aber der umgekehrte Weg, von der Doku zur Problemlösung ist mir völlig
> unklar

Man lese im Reference Manual das Kapitel über Timer. Da steht genau drin 
was du tun musst um was zu erreichen. Mit diesem Vorgehen kannst du alle 
Hardware Module erschlagen, da alle so dokumentiert sind. Du wirst kein 
Tutorial finden was derart umfassend alles abdeckt.

[Patrick B. (p51d)]

Die alte StdPeriphLib von ST war in meinen Augen auch sehr gut 
dokumentiert. Für einfache Anwendungen reichte es schon, wenn man die 
Funktionsbeschreibungen im Code durchgelesen hat. Zusätzlich gab es 
schöne Beispiele für fast jede Peripherie und Anwendung mit und ohne 
DMA...

Aber wie schon gesagt wurde, Englisch ist ein Muss. Ansonsten wird es 
sehr schwierig.

[Ohman (Gast)]

Du solltest als ersten Schritt den Weg weg von der HAL machen - auch 
wenns unbequem ist. Die HAL-Bibliothek ist meines Erachtens nach völlig 
unbrauchbar und bewirkt genau das Gegenteil: durch die zigfache 
Verschachtelung selbst einfachster Funktionen entfernst du dich immer 
mehr von der eigentlichen Hardware und wirst es sehr schwer haben 
nachzuvollziehen, was genau passiert. Empfehlen kann man die 
StdPeriphLib - dort wird zwar auch manchmal etwas übertrieben was 
Funktionen angeht (z.B. die I2C_ReceiveData Funktion ist nichts als ein 
unnötig aufgeblähtes Auslesen eines Registers I2Cx->DR), aber wesentlich 
direkter an der Hardware als die HAL.

[Lama (Gast)]

...alternativ einfach mal Datasheet und RefMan lesen? So, wie das jeder 
halbwegs taugliche Ingenieur auch macht?

Ich frage mich, wieso damals bei AVR die Anfänger noch in der Lage waren 
im Datenblatt zu blättern und heute nicht mehr.

[STM32Newbee (Gast)]

okay, okay. Englisch. Berg, Prophet, ich weiß schon. STM32Newbee

[Cyblord -. (cyblord)]

Lama schrieb:
> ...alternativ einfach mal Datasheet und RefMan lesen? So, wie das jeder
> halbwegs taugliche Ingenieur auch macht?

Sehe ich auch so. Die STM32 Datenblätter sind sehr gut, auch wenn der 
Umfang recht groß ist. Da es sich aber nicht um einen Roman handelt, 
muss man nicht von Anfang bis Ende lesen sondern kann sich am 
Inhaltsverzeichniss bedienen.

Es schadet aber auch nichts, für die für einen selbst interessanten 
Peripheriemodule mal die prosaische Einleitung zu lesen. Denn dort 
erfärt man tatsächlich etwas über deren allgemeine Verwendung und die 
Begrifflichkeiten.
DANN sind die Bezeichnungen in der StdLib oder der HAL auch 
selbsterklärend. Die sollen nämlich auch nicht die Lektüre der 
Datenblätter obsolet machen.

Was man eben wissen muss, im Gegensatz zum AVR gibt es halt nicht nur 
ein Datenblatt, sondern man muss das Datenblatt für den konkreten Chip 
und mindestens das Familiy-Reference Manual parat haben.
Das steht aber inzwischen auch überall.

Die Anforderung "Literatur in Deutsch" sollte man allerdings schnell 
vergessen.

[John Doe (Gast)]

Ohman schrieb:
> Empfehlen kann man die StdPeriphLib - dort wird zwar auch manchmal etwas 
übertrieben was



Nö, kann man nicht.

[ähm ja (Gast)]

Ohman schrieb:
> Du solltest als ersten Schritt den Weg weg von der HAL machen -
> auch wenns unbequem ist. Die HAL-Bibliothek ist meines Erachtens nach
> völlig unbrauchbar und bewirkt genau das Gegenteil: durch die zigfache
> Verschachtelung selbst einfachster Funktionen entfernst du dich immer
> mehr von der eigentlichen Hardware und wirst es sehr schwer haben
> nachzuvollziehen, was genau passiert. Empfehlen kann man die
> StdPeriphLib - dort wird zwar auch manchmal etwas übertrieben was
> Funktionen angeht (z.B. die I2C_ReceiveData Funktion ist nichts als ein
> unnötig aufgeblähtes Auslesen eines Registers I2Cx->DR), aber wesentlich
> direkter an der Hardware als die HAL.

Ich bin da anderer Meinung.

Wer Mal schon kompakten Spagetti Code von Registern befreit hat weiß was 
ich meine.

[STM32Newbee (Gast)]

Hallo Lama,

ich kann Dich verstehen, und RTFM ist mir ebenfalls ein Begriff, jedoch 
ist die Auswahl an Prozessoren groß und jeden Moment scheint ein neues 
Produkt auf den Markt zu kommen, da bleibt - anders als früher (TM) bei 
den kleinen AVRs oder bei Z80 - nur noch zwei Wochen zwischen "Hallo 
Welt" und "CAN Bus open".

Ich suche einen schnellen Einstieg in die STM32 Welt und da sind 1000 
seitige Dokumente und Inhaltsverzeichnisse, die länger sind, als meine 
Aufmerksamkeitsspanne, eher abträglich.

Aber ich werde mich bessern. :-)
Danke trotzdem für die Ermahnung
SMT32Newbee

[Pete K. (pete77)]

STM32Newbee schrieb:
> Ich suche einen schnellen Einstieg in die STM32 Welt und da sind 1000
> seitige Dokumente und Inhaltsverzeichnisse, die länger sind, als meine
> Aufmerksamkeitsspanne, eher abträglich.

Dann versuche es mal hiermit:
http://diller-technologies.de/stm32.html

[STM32Newbee (Gast)]

Hallo Pete, vielen Dank, ich versuche es nochmal, obwohl es Code für 
eine andere Lib ist, kann man manches aus HAL Sicht verstehen. 
STM32Newbee

[Daniel B. (daniel_3d)]

Hallo,

mir geht es ähnlich wie dir. Mittlerweile bin ich aber schon ein paar 
kleine Schritte weiter gekommen.
Ich habe mir ein Microsekunden-Delay gebastelt, eine Lib für den DS18B20 
und eine Lib für ein LCD mit HD44780 von AVR auf STM umgeschrieben.
Ich nehme Code (der bei mir natürlich nie Out-of-the-Box läuft), 
versuche ihn zu verstehen und lerne dadurch die Programmiersprache C und 
den uC.
Ich denke du arbeitest ähnlich.
Deshalb kann ich dir nur sagen wie ich es machen würde:

Ich würde weiterhin CubeMX und HAL benutzen, weil du sonst gerade am 
Anfang auf keinen grünen Zweig kommst. Der ARM hat einfach zu viele 
Möglichkeiten und dadurch auch Fallstricke und Seiteneffekte die du als 
Anfänger schwer überblickst - dabei hilft HAL wirklich.
Deshalb mein Tip: Genieße die Vorteile beider Welten.
Benutze CubeMX und HAL weiterhin, beschäftige dich aber auch mit 
direkten Registerzugriffen, weil mit HAL einige Dinge zu langsam oder 
unmöglich sind.
Einige Dinge sind mit HAL gut gelöst und machen dir das Leben erheblich 
leichter und auf CubeMX würde ich niemals verzichten wollen.
Beschäftige dich aber auch mit direkten Registerzugriffen (Reference 
Manual), um die Nachteile von HAL zu kompensieren.
Ein Beispiel ist der Temperatursensor DS18B20 mit seinem 1-wire Bus.
Dazu ist es sinnvoll den Pin auf Ausgang zu setzen als OpenDrain. Du 
musst aber auch den Zustand am Pin auslesen, was mit HAL aber bei einem 
Ausgangspin nicht möglich ist (zumindest habe ich es nicht gefunden).
In dem Fall liest du einfach direkt das IDR-Register aus. Alleine mit 
HAL hätte ich entnervt aufgegeben.
Die Arbeit mit dem Reference Manual ist auch näher an der Arbeitsweise 
des AVR.

Ich habe auch die Video-Tutorials von Ultr@FX angeschaut. Anfangs 
arbeitet er mit der StandardPeriphalLib später mit HAL. Mir half es beim 
Einstieg in STM32.

Falls du noch nicht so fit mit pointern und structs bist, solltest du 
das mal anschauen. Dann verstehst du die HAL-Magie viel besser.


Viele Profis werden wahrscheinlich anderer Meinung sein, aber ich 
vertrete die Position:
Einfach mal machen so wie es funktioniert, dadurch hat man 
Erfolgserlebnisse und macht weiter und dadurch lernt man weiter. Mit der 
Zeit geht es dann immer einfacher.

Gruß Daniel

[Stefan F. (Gast)]

Arbeite mal dieses Tutorial durch: 
http://stefanfrings.de/mikrocontroller_buch2/index.html

Es sorgt für ein paar erste Erfolgsmomente und bringt Dir behutsam bei, 
mit dem Reference Manual von ST zu arbeiten, indem es einfache Themen 
angeht und auf deutsch erklärt.

Danach brauchst du aber Englisch, geht nicht anders.

Falls Du Hemmungen hast, ohne Cube HAL zu programmieren, dann schau Dir 
mal meine Anfänger-Beispiele (http://stefanfrings.de/stm32/index.html) 
und die Erklärungen dazu an. Dann siehst du, dass die HAL eigentlich 
nicht viel vereinfachen kann (tut sie IMHO auch nicht).

Die Seite von Diller hat auf mich auch einen guten Eindruck gemacht, 
doch ich hatte das gleiche Problem wie du. Ich vermute, dass sie auch 
veraltete Software setzt. Dennoch ist voll von hilfreichen Erklärungen.

[W.S. (Gast)]

STM32Newbee schrieb:
> ich kann Dich verstehen, und RTFM ist mir ebenfalls ein Begriff, jedoch
> ist die Auswahl an Prozessoren groß und jeden Moment scheint ein neues
> Produkt auf den Markt zu kommen, da bleibt - anders als früher (TM) bei
> den kleinen AVRs oder bei Z80 - nur noch zwei Wochen zwischen "Hallo
> Welt" und "CAN Bus open".

Nana, tu nicht so.

Das, was du beizeiten lernen solltest, sind Herangehensweisen und 
Algorithmen, die darauf aufbauen. Und das ist erstmal völlig unabhängig 
vom konkreten Chip.

Ansonsten guck dich hier im Forum um, hier gibt's massenweise Beispiele 
zum etwaigen dran lernen - allerdings eben gute und weniger gute. Ich 
hatte hier auch schon mal ein Mini-System mit den allbekannten 
STM32F103C8T6 gepostet. Da ist der Grundbestand an LL-Treibern bereits 
drin, so daß man mit dem Teil per USB-VCP kommunizieren kann bis hin zu 
einem kleinen Kommandosystem. An sowas kannst du sehen, wie man 
lediglich mit dem RefManual und ohne sonstiges Zeugs eine schlanke und 
effiziente Firmware hinbekommt.

Dem Rat weiter oben, dich von möglichst vielen "Standard-Libs" der 
jeweiligen Hersteller fern zu halten und dir dein eigenes Portfolio an 
Lowlevel-Treibern zuzulegen, kann ich nur unterstützen. Wer all die 
tollen Libs und Wizzards der Hersteller benutzt, wird sich ganz schnell 
in einem Urwald von Firmware verlaufen - und sowas macht den Flash voll 
und den Prozessor lahm.

W.S.

[Walter T. (nicolas)]

Leider in Englisch, aber ganz hervorragend:

Joseph Yiu:
Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors

Als ich das Buch endlich in die Finger bekommen habe, habe ich es 
bereut, es nicht schon viel früher gelesen zu haben.

[derjaeger (Gast)]

Was mir immer geholfen hat bei neuen Mikrocontrollern war aus den ganzen 
Registern (z.B. DMA  I2C SPI / ADC) ein eigenes Modul zu machen (quasi 
seine eigene Lib zu programmieren) die man spaeter sowieso brauchen 
wird.

Bei jedem Mikrocontroller kann man immer mit einer simplen UART-Lib 
anfangen, die das Hardware-UART des Controllers ansteuert. Das Testen 
ist natürlich ganz simpel: Anschliessen an PC und gucken ob was ankommt 
:-)

Danach geht man an I2C, ADC, ... und weil das Module sind, verwendet man 
sie dann später für größere Projekte (wo man das UART Modul dann fürs 
Debugging nutzt)

So lernt man bei jedem Mikrocontroller seine Eigenheiten und 
programmiert quasi immer das gleiche!

[Stefan us (Gast)]

Diese Vorgehensweise halte ich auch für Sinnvoll. Jede Funktion bzw 
Schnittstelle einzeln ausprobieren bevor man sie ernsthaft anwendet.

[wauwi (Gast)]

> Die Anforderung "Literatur in Deutsch" sollte man allerdings schnell
> vergessen.

Das ist das eigentliche kapitale Problem in fast allen technischen und 
nichttechnischen Bereichen.

[Ohmann (Gast)]

John Doe schrieb:
> Ohman schrieb:
>> Empfehlen kann man die StdPeriphLib - dort wird zwar auch manchmal etwas
> übertrieben was
>
>
>
> Nö, kann man nicht.


Aha, und wieso nicht?

[Holger Stein (Gast)]

Dieses Buch ist eine Pflichtlektüre:

http://centaur.sch.bme.hu/~holcsik_t/sem/The%20Definitive%20Guide%20to%20the%20ARM%20Cortex-M3.pdf

[Stefan F. (Gast)]

Weil die StdPeriphLib laut ST deprecated ist.

[derjaeger (Gast)]

Wer sich nicht um Hardware-Kompatibilität und Hardware-Abstraktion 
sorgt, darf doch StdLib verwenden.

[Stefan F. (Gast)]

Natürlich darf man das. Man darf auch nich DOS Programme mit Turbo 
Pascal schreiben.

Aber wer jetzt einsteigt sollte besser nicht veraltetes Zeug lernen, 
sondern aktuelles.

[derjaeger (Gast)]

Aus der StdLib kann man lernen wie man einen STM32 zu bedienen hat. Ist 
nichts anderes als Registerschieberei mit hübschen Strukts als 
Schnittstellen. Ist ja nicht so als ob die HAL mit was anderem arbeitet 
als mit denselben Registern ...

Ich für meinen Teil lerne immer noch was neues durch die StdLib, 
natürlich liegt das Reference Manual des STM32 parallel daneben.

[Curby23523 N. (Gast)]

Holger Stein schrieb:
> Dieses Buch ist eine Pflichtlektüre:
>
> 
http://centaur.sch.bme.hu/~holcsik_t/sem/The%20Definitive%20Guide%20to%20the%20ARM%20Cortex-M3.pdf

Die Datenblätter sind Pflichtlektüre..

[John Doe (Gast)]

Nils N. schrieb:
> Holger Stein schrieb:
>> Dieses Buch ist eine Pflichtlektüre:
>>
>>
> http://centaur.sch.bme.hu/~holcsik_t/sem/The%20Def...
>
> Die Datenblätter sind Pflichtlektüre..


Zuallererst das ARM Cortex‑M3 (bzw. M4) Processor Technical Reference 
Manual.
Dann das Datenblatt (Data Sheet) von ST und dazu das Reference Manual 
zum Controller.

[derjaeger (Gast)]

>Dann das Datenblatt (Data Sheet) von ST und dazu das Reference Manual zum 
Controller.

Application Notes!
http://www.st.com/content/st_com/en/search.html#q=Application%20Note-t=resources-page=1

[SMT32Newbee (Gast)]

Hi ich als TO
wollte zusammenfassen, was an Infos zusammengekommen ist und was selbst 
noch gefunden habe. Vielleicht gibt es ja noch andere, die sich in STM32 
einarbeiten wollen.




1) etwas marketinglastig, zur Übersicht
www.st.com/content/st_com/en/support/learning/stm32f7-online-training.ht 
ml
www.st.com/content/st_com/en/support/learning/stm32l4-online-training.ht 
ml

2) der Link von Holger Stein

3) Diverse Datenblätter des jeweiligen STM32 Prozessors

4) siehe 9)

5) 
www.st.com/content/st_com/en/about/events/events.html/moving-from-8-to-3 
2-bits-hands-on-workshop-emea.html

6) 
www.st.com/content/st_com/en/support/learning/stm32-education/text-books 
.html
hier u.a. ein free download von "Discovering the STM32 Microcontroller
by Geoffrey Brown"


7) st-mooc.udemy.com/ Massive Open Online Courses, weiß aber nicht was 
dahinter steht

8) 
www.st.com/content/st_com/en/support/learning/video-page.html?q=stm32# 
viel Getting Startet Anleitungen

9)User Manual "Description of STM32L0 HAL and Low Layer drivers" UM1749 
o.ä.. Wenn man das 1400 Seitendokument auf Example scannt, findet man 
gelegentlich sinnvoll umzusetzende Beispiele.

10) www.st.com/content/st_com/en/support/learning/recorded-webinars.html

Möglicherweise gibt es trotz allem einen Bedarf nach einem 
anwendungsbezogenem Cook Book STM32, wie z.B. für Arduino,

www.amazon.de/Arduino-Kochbuch-Michael-Margolis-ebook/dp/B06XDCZVC1/ref= 
sr_1_1?ie=UTF8&qid=1520927754&sr=8-1&keywords=arduino+kochbuch

wenn man nur Zeit hätte...

Viele Grüße, STM32Newbee

[C. W. (chefkoch)]

derjaeger schrieb:
> Wer sich nicht um Hardware-Kompatibilität und Hardware-Abstraktion
> sorgt, darf doch StdLib verwenden.

Das mit der Kompatibilität erledigt sich spätestens dann wenn ein neuer 
Controller kommt für den es einfach keine StdLib mehr von ST gibt.

[Cyblord -. (cyblord)]

SMT32Newbee schrieb:
> Möglicherweise gibt es trotz allem einen Bedarf nach einem
> anwendungsbezogenem Cook Book STM32, wie z.B. für Arduino,

Kochbücher sind für Leute die vorgekaute Lösungen wollen anstatt etwas 
zu verstehen.
Da gibts bei AVR und Arduino sicher ne Menge, aber bei STM32 wird es da 
dünner. Also entweder du willst mit STM32 Entwicklen oder du suchst 
einen Lego-Baukasten und nimmst Arduino. Beides geht nicht.

Also sollte erstes bei dir tatsächlich der Fall sein, dann schmeiß deine 
süsse kleine Linkliste da oben ins Klo, nimm dir die scheiß Datenblätter 
vor und versuche zu verstehen was da drin steht. Was denkst du für wen 
die gschrieben sind? Den lieben Gott? Nein für ganz normale Menschen 
welche einen STM32 benutzen wollen.

[Christopher J. (christopher_j23)]

SMT32Newbee schrieb:
> 9)User Manual "Description of STM32L0 HAL and Low Layer drivers" UM1749
> o.ä.. Wenn man das 1400 Seitendokument auf Example scannt, findet man
> gelegentlich sinnvoll umzusetzende Beispiele.

Für STM32F0 und STM32L0 gibt es von ST sogenannte "Snippets". Das sind 
Beispiele in denen die Controller direkt auf Registerebene angesprochen 
werden. Der Quellcode ist auch ganz ordentlich kommentiert. In 
Kombination mit dem Reference Manual ist das schon fast ein "Kochbuch", 
auch wenn ich Cyblord mit

> Kochbücher sind für Leute die vorgekaute Lösungen wollen anstatt etwas
> zu verstehen.

... absolut recht gebe.

[Daniel V. (voda)]

Stefan U. schrieb:
> Arbeite mal dieses Tutorial durch:
> http://stefanfrings.de/mikrocontroller_buch2/index.html
>
> Es sorgt für ein paar erste Erfolgsmomente und bringt Dir behutsam bei,
> mit dem Reference Manual von ST zu arbeiten, indem es einfache Themen
> angeht und auf deutsch erklärt.
>
> Danach brauchst du aber Englisch, geht nicht anders.
>
> Falls Du Hemmungen hast, ohne Cube HAL zu programmieren, dann schau Dir
> mal meine Anfänger-Beispiele (http://stefanfrings.de/stm32/index.html)
> und die Erklärungen dazu an. Dann siehst du, dass die HAL eigentlich
> nicht viel vereinfachen kann (tut sie IMHO auch nicht).
>
> Die Seite von Diller hat auf mich auch einen guten Eindruck gemacht,
> doch ich hatte das gleiche Problem wie du. Ich vermute, dass sie auch
> veraltete Software setzt. Dennoch ist voll von hilfreichen Erklärungen.

Neben dem Diller ist Deins auch sehr interessant. Dein Programmierstil 
sowie Deine Anleitung für Kinder gefällt mir sehr gut. Danke Dir dafür.

Gruß
Daniel

PS: Den Kindern µC.net zu empfehlen ist bei dem rauen Unterton doch sehr 
gewagt ;)

[STM32Newbee (Gast)]

Cyblord -. schrieb:
> SMT32Newbee schrieb:
>> Möglicherweise gibt es trotz allem einen Bedarf nach einem
>> anwendungsbezogenem Cook Book STM32, wie z.B. für Arduino,
>
> Kochbücher sind für Leute die vorgekaute Lösungen wollen anstatt etwas
> zu verstehen.
> Da gibts bei AVR und Arduino sicher ne Menge, aber bei STM32 wird es da
> dünner. Also entweder du willst mit STM32 Entwicklen oder du suchst
> einen Lego-Baukasten und nimmst Arduino. Beides geht nicht.
>
> Also sollte erstes bei dir tatsächlich der Fall sein, dann schmeiß deine
> süsse kleine Linkliste da oben ins Klo, nimm dir die scheiß Datenblätter
> vor und versuche zu verstehen was da drin steht. Was denkst du für wen
> die gschrieben sind? Den lieben Gott? Nein für ganz normale Menschen
> welche einen STM32 benutzen wollen.

Lieber Cyberlord,

ich möchte nicht unhöflich sein ... und dann tat er es doch. :-)

(1) "Entweder Sie kaufen jetzt dieses Zeitungsabo oder Sie werden dumm 
sterben." Zwischen "entweder" und "oder" gibt es immer eine andere 
Lösung, an die vielleicht noch keiner gedacht hat. Ich werde bei Sätzen 
mit "Entweder/ Oder" immer ganz hellhörig (ausser in der formalen 
Logik).

(2) Das Verwenden markiger Worte macht eine Aussage beeindruckend, aber 
nicht wahrer.

(3) Ist die Verwendung von C anstatt von Maschinenbefehlen nicht auch 
eine Verwendung von vorgekauten Lösungsbausteinen?

(4) Ich möchte über zwei ADC Signale einlesen, über einen PID Regler 
einen Wert daraus berechnen, ein PWM Signal steuern und das möglichst 
flott. Ich will den Prozessor nicht heiraten, nur benutzen. Dazu muß es 
erlaubt sein, sich nur die Codestücke zusammenzustellen, die man auch 
braucht.

Ansonsten möchte ich mich bei allen bedanken, die mir sachliches 
Feedback gegeben habe.

STM32Newbee

[Johnny B. (johnnyb)]

STM32Newbee schrieb:
> Ich habe mich für STM 32 + Systems Workbench (eclipse) + CubeMX + HAL
> Lib entschieden.

Das war bis Ende letzten Jahres eine sehr gute Entscheidung, jedoch hat 
ST inzwischen ja die Firma Atollic mit deren Entwicklungsumgebung 
übernommen und mittelfristig wird das die bevorzugte Plattform werden. 
Da es ebenfalls auf GCC und Eclipse basiert, kannst Du bestehende System 
Workbench Projekte rel. einfach rübernehmen.
Die HAL Lib zu verwenden macht ebenfalls Sinn, da dies ebenfalls von ST 
so propagiert wird.
Meiner Meinung nach ist das der richtige Weg um einigermassen schnell 
Projekte realisieren zu können und über die nächsten paar Jahre auch 
Unterstützung seitens ST erwarten kann.

Atollic TrueSTUDIO für STM32 (ist jetzt Kostenlos)
https://atollic.com/truestudio/

[Nop (Gast)]

STM32Newbee schrieb:

> indem ich den Code anderer mehr oder weniger in main.c einkopiert
> habe und in CubeMX wie ein kleines Äffchen (also ohne eigenes
> Verständnis) Timer Konfigurationen zusammengeklickt habe, frage ich
> mich, ob es das sein kann.

Was, genau das wolltest Du doch. Nix Eigenes tun, nur bissel 
zusammenkopieren. Daß Du darüber kein Verständnis entwickelst für das, 
was Du da tust, ist doch klar. Wenn Du das ändern willst, ist das sehr 
löblich, aber es wird für Dich ein wenig Arbeit bedeuten.

> Um z.B. ein GPIO Ausgang zu setzen, muß man
> RCC_AHBPeriphClockCmd(AHB_GPIOC, ENABLE); und diverse andere Dinge tun:
>
>     GPIO_StructInit(&gpio);
>     gpio.pins = GPIO_P13;
>     gpio.mode = GPIO_OUTPUT;
>     gpio.otype = GPIO_OT_PP;
>     GPIO_Init(GPIOC, &gpio);
> wo steht so was? Möglichst systematisch.

Steht in Reference Manual in dem Abschnitt über GPIO. Die HAL ist ja 
gerade kein abstraction layer, sondern nur ein Wrapper. Um zu verstehen, 
was Du denn bei mode, type, evtl. auch noch speed für Werte hast und was 
sie bewirken, mußt Du im Refman nachschauen. ZUSÄTZLICH mußt Du dann 
auch noch durch den HAL-Dschungel durchsteigen.

> Es fehlt mir also an Durchblick, Ordnung und Orientierung. Und ich finde
> für STM32 kaum Literatur in deutsch

AUF deutsch. "In" wird an der Stelle nur auf englisch verwendet. Du bist 
also schon halb da. ;-)

> (die Transferleistung von Englisch
> --> Deutsch möchte ich mir sparen, wenn das Thema an sich schon komplex
> ist.)

Ist es erstens nicht, und zweitens, vergiß Übersetzungen einfach. Das 
ist nur noch eine weitere Stelle, an der sich Fehler einschleichen 
können.

> Habt Ihr einen Tipp für didaktisch geschickt aufbereitetes, praktisches
> Wissen

Ja, von ST: reference manual, datasheet, programming manual.
Außerdem von ARM: generic user manual und technical reference manual für 
Cortex-M4.

Das Gute: per default ist aus Energiespargründen nichts eingeschaltet. 
Was Du nicht brauchst, kannst Du einfach ignorieren. Damit konzentriert 
sich die Suche auf nur wenige Seiten, zumal die Dokumente ja auch 
Inhaltsverzeichnisse haben.

Oder Du willst Dir doch keine Arbeit machen, willst doch nichts 
verstehen und nur weiterhin Arduino-like irgendwas zusammenkopieren.

[Cyblord -. (cyblord)]

STM32Newbee schrieb:
> (3) Ist die Verwendung von C anstatt von Maschinenbefehlen nicht auch
> eine Verwendung von vorgekauten Lösungsbausteinen?

Nein. Aber ich denke dir das zu erklären wäre eine Verschwendung von 
Lebenszeit.

> (4) Ich möchte über zwei ADC Signale einlesen, über einen PID Regler
> einen Wert daraus berechnen, ein PWM Signal steuern und das möglichst
> flott. Ich will den Prozessor nicht heiraten, nur benutzen. Dazu muß es
> erlaubt sein, sich nur die Codestücke zusammenzustellen, die man auch
> braucht.

Ja klar du möchtest... Aber wollen reicht nicht, man muss halt können.
Und es ist erlaubt, aber es bringt dich halt nicht zum Ziel.

Allein deine Vorstellung, dass die Datenblätter und ein grundlegendes 
Verständis des Controllers wohl nur was für den Obernerd ist, aber der 
"normale" Benutzer braucht das alles nicht, zeigt doch wie weit du von 
jeglicher Realität weg bist.

Das ist keine Kaffeemaschine, die jeder Benutzen kann, aber nur 
Spezialisten müssen wissen wie sie funktioniert. DU willst eine komplexe 
Schaltung, dazu noch performant, auf einem modernen hochintegrierten 
Mikrocontroller realisieren. Woher kommt der irrglaube, dies MÜSSE doch 
auch einfach und ohne Mühe gehen? Nur weil du es gerne so hättest? Sich 
das zu wünschen reicht leider nicht.

[W.S. (Gast)]

STM32Newbee schrieb:
> Lieber Cyberlord,
>
> ich möchte nicht unhöflich sein ...

Unhöflichkeiten sind wir hier gewöhnt, das macht kaum jemandem hier noch 
was aus - aber was viele verärgert ist, wenn jemand anfragt, dann etwas 
gesagt bekommt und daraufhin das Gesagte ignoriert oder gar in Frage 
stellt.

Also nach meiner Einschätzung mußt du noch ne Menge dazulernen, vor 
allem prinzipielle Herangehensweisen und Hardwarekenntnisse aus 
Primärquellen. Und die sind schon seit langem nur auf englisch oder 
chinesisch zu haben.

All die Sekundärliteratur ist eben das, was der Name sagt: sekundär. 
Sowas taugt nur manchmal in besonderen Fällen, aber nicht generell. Ein 
Gleiches gilt für Sekundär-Software.

Also halte dich an die Dokumentation der Hardware und lerne ausreichend 
englisch.

W.S.

[STM32Newbee (Gast)]

Hi hier nochmal der TO, STM32Newbee,

etwas Konstruktives, für die, die in STM32 einsteigen wollen:

Dank an Johnny B. für den Tipp mit TrueStudio. Dort kann man für einige 
STM32 Prozessoren und Boards fertigen Beispielcode herunterladen und 
ansehen. Die Codebeispiele beschreiben (z.B. für STM32F4_Dicovery Board)

- ADC Modes
- DAC
- DMA auf Flash
- IO Toggle
- PWR Zustände
- RCC
- Timer für PWM

allerdings ohne HAL, aber das Prinzip wird klar.

prima, dass es sowas gibt. STM32Newbee

[Feldstecher (Gast)]

Also ich versteh den TE gut. Beim AVR schaut man ins Datenblatt und 
setzt seine Register. Beim (komplexeren) STM32 steht man vor einer 
Bibliothek (StdPeriph,  HAL), die erstmal nichts mit den Datenblaettern 
zu tun hat. Ich hatte die quasi undokumentierte StdPeriph-Bibliothek 
benutzt und habe anfangs nur geflucht. Es ist erst besser geworden, als 
ich versucht habe, die Hardware auf Registerebene anzusprechen. Die 
Register haben sich in der StdPeriph wiedergefunden und so wurde die 
Funktionsweise letztlich klar. Sie hilft dann auch, da alle notwendigen 
Register beteiligt sind und die Zugriffsreihenfolge stimmt. Aber es ist 
erstmal Reverse Engineering erforderlich.

Ich vermute der STM32 wird von Hobbyisten so gut wie nicht eingesetzt, 
daher auch die schlechte Informationslage auf deutsch.

[Dr. Sommer (Gast)]

Feldstecher schrieb:
> Beim AVR schaut man ins Datenblatt und setzt seine Register

Das kannst du beim STM32 exakt ganz genau so machen. Das ist m.M.n. auch 
die beste Möglichkeit. Da sind halt nur ein paar mehr Register, aber 
dafür auch mehr Möglichkeiten.

[Cyblord -. (cyblord)]

Feldstecher schrieb:
> Also ich versteh den TE gut. Beim AVR schaut man ins Datenblatt und
> setzt seine Register.

Kann man beim STM32 genau so machen.

> Beim (komplexeren) STM32 steht man vor einer
> Bibliothek (StdPeriph,  HAL), die erstmal nichts mit den Datenblaettern
> zu tun hat.

Praktisch alle Begrifflichkeiten aus der StdPerip entsprechen 1:1 denen 
im Datenblatt. Wer die Register aus dem Datenblatt kennt, kann mir nicht 
erzählen dass er nicht weiß was die Stinkeinfachen Shortcuts der StdLib 
machen. Das ist eine AUSREDE.

> Ich hatte die quasi undokumentierte StdPeriph-Bibliothek

Ääää undokumentiert?

http://www.st.com/content/ccc/resource/technical/document/user_manual/59/2d/ab/ad/f8/29/49/d6/DM00023896.pdf/files/DM00023896.pdf/jcr:content/translations/en.DM00023896.pdf

[Curby23523 N. (Gast)]

Feldstecher schrieb:
> Beim AVR schaut man ins Datenblatt und
> setzt seine Register. Beim (komplexeren) STM32 steht man vor einer
> Bibliothek (StdPeriph,  HAL), die erstmal nichts mit den Datenblaettern
> zu tun hat.

Ich hab beim STM32 noch nie in die HAL oder StdPeriph geschaut und kann 
trotzdem sämtliche benötigte Schnittstellen über die Register 
konfigurieren. Die Datenblätter sind vorzüglich strukturiert sauber 
dokumentiert. Mitnichten sind Peripherie wie ADC, DAC, TIM, SPI, USART 
etc. komplizierter als auf einem AVR. Bei DMA hast du z.B. ein(!) 32bit 
Register - die restlichen sidn nur Adresspointer, Zählvariablen etc.

Sie sind komplexer, da sie mehr Ausnahmefälle können. Brauchst das 
nicht, setzt du diese Bits einfach nicht. Dann ist auch z.B. ein Timer 
auf einem STm32 mit 4 Zeilen und zwei Bits aktiviert.

Ich habe 2 Wochen gebraucht (nebenbei wohlgemerkt, Wochenende und unter 
der Woche ab und zu mal n Stündchen), um den STM32 soweit 
kennenzulernen, um erste Projekte mit den gängigen Peripherien, DMA, 
PLL, I²S etc. umsetzen zu können. Ethernet und USB habe ich z.B. noch 
nie benutzt, das sind aber deutlich andere Kaliber. Aber auch hier würde 
ich erstmal nur ins Datenblatt schauen..

[Stefan F. (Gast)]

Mir ging es ebenso. Um die StdPeriphLib zu verstehen, muss man 
offensichtlich in dessen Quelltext schauen und mit dem Referenzhandbuch 
vergleichen. Wenn man das ein paar tage lang getan hat, braucht man die 
Library nicht mehr.

Da fast alle Tutorials noch diese alte Library verwenden, hatte ich erst 
sehr spät gemerkt, dass ich mich besser mit der Cube HAL hätte 
beschäftigen sollen. Jetzt bin ich aber schon so weit, dass ich mit dem 
Referenzhandbuch alleine gut zurecht komme und diese Libraries beide 
nicht brauche.

Gut kommentierte Code-Sniplets ind mir lieber. Das das bei mir nur ein 
Hobby ist, kann ich es mir aber auch leisten, mich mit jedem Bit einzeln 
auseinander zu setzen und die korrekte Reihenfolge der Initialisierung 
auszuknobeln.

> Praktisch alle Begrifflichkeiten aus der StdPerip entsprechen 1:1
> denen im Datenblatt

Ja, bei der Cube HAL ist das leider nicht so konsequent der Fall.

[temp (Gast)]

Ich kann auch nur jeden abraten diese StdLib oder HAL zu verwenden. 
besser ist man weiß was man tut. In der Regel hat man auch 
Standardaufgaben zu lösen die immer ähnlich sind. Bei den UARTS z.B. 
werden wohl 99% oder so nur eine einfache Ein/Ausgabe sein ohne 
Flowcontroll u.s.w. Sowas braucht man immer egal ob der Controller 
AVR,STM32 oder LPXxxx heisst. Da ist es um Längen besser man macht sich 
seine eigene abgespeckte HAL in die man nur das reinpackt was man 
wirklich braucht. Wenn die Schnittstelle nach außen dann auf allen 
Zielplattformen gleich ist hat man wirklich einen Mehrwert davon und ist 
nicht so sehr auf einen Hersteller angewiesen. Schließlich ist es auch 
der einzige Grund warum die Hersteller solche Libs anbieten. Man möchte 
es denen schwer machen die sich erdreisten auf eine andere Plattform 
wechseln zu wollen.

[Cyblord -. (cyblord)]

> Mir ging es ebenso. Um die StdPeriphLib zu verstehen, muss man
> offensichtlich in dessen Quelltext schauen und mit dem Referenzhandbuch
> vergleichen. Wenn man das ein paar tage lang getan hat, braucht man die
> Library nicht mehr.

temp schrieb:
> Ich kann auch nur jeden abraten diese StdLib oder HAL zu verwenden.
> besser ist man weiß was man tut.

In den Aussagen offenbart sich eine scheinbar hartnäckige 
Fehleinschätzung. Die Libs sind NICHT dazu da, damit man den Controller 
nicht verstehen muss, oder um einem den Blick in die Manuals zu 
ersparen. Sie sollen NICHT von Leuten verwendet werden, die nicht 
wissen, was sie da tun.
Es sind keine Lernhilfen für die Grundschule oder 
Arduino-Ersatz-Funktionen für "Künstler".

Sie sollen den Code lesbarer (=sprechender) machen und über die reinen 
Registerbits Abstrahieren.

Sie erfordern trotzdem dass der Benutzer weiß WAS er tun möchte und 
WARUM er es tun möchte und es im Zweifel auch ohne Lib tun könnte.
Damit er das weiß, muss er die grundlegende Funktion der Peripherie aus 
den Manuals eben schon kennen. Dabei hilft die Lib nicht. Er muss aber 
eben nicht jedes Bit in jedem Register einzeln nachschlagen. Diese 
Arbeit soll die Lib einem abnehmen.

Ich könnte mir vorstellen, die vielen geschilderten Entäuschungen mit 
der Lib, basieren auf einer solch falschen Einschätzung.

[Olaf (Gast)]

> Ich könnte mir vorstellen, die vielen geschilderten Entäuschungen mit
> der Lib, basieren auf einer solch falschen Einschätzung.

Aber du musst doch zugegeben das der Lib-Unsinn vor allem deshalb seit 
einiger Zeit von den Marketingabteilungen nach oben gespuelt wird weil 
man oft moeglichst viele (gerne auch weniger kompetente) Ingenieure dazu 
zu bringen will gerade den eigenen ach so tollen Controller zu 
verwenden.

Deine Einschaetzung ist natuerlich richtig vor dem Hintergrund eines 
erfahrenen Ingenieurs der es noch anders gelernt hat, aber als 
Nebeneffekt zuechtet man sich damit natuerlich eine neue Gruppe von 
Mausschubserentwicklern ran die wirklich glauben das man nicht mehr so 
viel wissen muss. Und in den ersten 30% ihres Projekts haben sie ja auch 
recht. :)

Olaf

[Conny G. (conny_g)]

Ich beginne auch gerade mit STM32 und nehme aus der Diskussion einiges 
mit, vielen Dank.

Ich würde sagen, dem TE geht es nicht darum zu vermeiden den Prozessor 
zu verstehen, sondern um einen „anschaulichen“ ersten Einstieg, also 
einen „Trail“ durch die wichtigsten Dinge bevor er dann 1.800 Seiten 
Referenz durchliest.
Trail drückt es m.E. ganz gut aus.

Daran wäre ich auch interessiert und es kamen schon ein paar Ressourcen 
zur Sprache.
Aber generell ist das wohl bei STM32 sehr viel dünner gesäht als bei 
Atmel, die Nutzergruppe ist ganz anders zusammengesetzt, mehr Pro / 
Industrie, weniger Einsteiger Hobbyisten.
Also ist in Relation zum Gesamtaufwand an Nutzung des uC in der Gruppe 
der Anteil der Einarbeitung so gering, dass dafür kaum Ressourcen 
entwickelt wurden.

[temp (Gast)]

Cyblord -. schrieb:
> In den Aussagen offenbart sich eine scheinbar hartnäckige
> Fehleinschätzung.

Nein, man lernt nur mit dem Alter nicht mehr jeder neuen Kuh hinterher 
zu laufen die durchs Dorf getrieben wird. Nehmen wir zum Beispiel den 
betagten STM32F103Cx der auf Grund des Preises (Bluepill) immer noch 
sehr attraktiv ist. Gefühlte 3/4 des verfügbaren Codes im Netz basieren 
noch auf der StdLib. Jetzt ist die HAL und CubeMX das einig wahre und 
schon passt keine Zeile Code mehr. Komisch nur dass die, die auf diesen 
Zug niemals aufgesprungen sind jetzt darüber lachen. Die Zeit um diese 
Libs zu lernen investiert man besser in was langlebigeres. Und wenn's 
ums Debuggen geht, da kann man auch bloß die Register sehen und mehr 
braucht kein Mensch.
Leider ist es in meinen Augen keine gute Entwicklung die das alles jetzt 
nimmt. Nicht nur bei den Controllern. Gutes Beispiel ist auch nodejs 
obwohl es hier jetzt nicht hin gehört. So schön wie das alles ist und 
vor allem man kann schnell mal eine einfache Lösung für etwas basteln. 
Allerdings darf man da auch nicht tiefer schauen. Ein einfaches npm 
install von irgendeiner kleinen Lib schaufelt da unter Umständen ein 
paar hundert Quelldateien ins Projekt. z.B. ein 'npm install serialport' 
zaubert 180 Packete an Abhängigkeiten dazu und daraus werden dann 1125 
Dateien in 269 Verzeichnissen. Wundert sich da wirklich noch einer 
darüber, daß die ganze Technik nicht mehr sicher zu kriegen ist? Aber 
das ist wohl die Mentalität heute.

[Cyblord -. (cyblord)]

Olaf schrieb:
> Aber du musst doch zugegeben das der Lib-Unsinn vor allem deshalb seit
> einiger Zeit von den Marketingabteilungen nach oben gespuelt wird weil
> man oft moeglichst viele (gerne auch weniger kompetente) Ingenieure dazu
> zu bringen will gerade den eigenen ach so tollen Controller zu
> verwenden.

Woran machst du das fest? Wo soll das so passiert sein? Tut mir leid ich 
sehe das nicht.
Spielst du auf die massenhaften Nucleo-Boards an?
Ich sehe nirgendwo aussagen von ST, dass man mit deren Libs fehlende 
Kompetenz ausgleichen kann oder die Manuals nicht mehr lesen muss.

Vielleicht verleitet die doch echt sprechende Syntax der Libs zu der 
Annahme, hier könnte man ohne Vorkentnisse mal schnell loslegen.

> Ich würde sagen, dem TE geht es nicht darum zu vermeiden den Prozessor
> zu verstehen,

Doch ganz genau darum geht es.

> sondern um einen „anschaulichen“ ersten Einstieg, also
> einen „Trail“ durch die wichtigsten Dinge bevor er dann 1.800 Seiten
> Referenz durchliest.

Man muss keine 1800 Seiten durchlesen um den Controller zu verstehen. 
Das habe ich weiter oben schon dargelegt.
Und es gibt Millionen von Snippets welche einen Eindruck davon geben, 
wie man grundlegende Funktionen mit den Libs abhandelt. DAS ist ein 
Punkt den man schnell erledigen kann.

Und der TE hat seine Grundhaltung schon deutlich gemacht:

> Ich will den Prozessor nicht heiraten, nur benutzen. Dazu muß es
> erlaubt sein, sich nur die Codestücke zusammenzustellen, die man auch
> braucht.

Das sagt leider alles.

> Jetzt ist die HAL und CubeMX das einig wahre und
> schon passt keine Zeile Code mehr. Komisch nur dass die, die auf diesen
> Zug niemals aufgesprungen sind jetzt darüber lachen. Die Zeit um diese
> Libs zu lernen investiert man besser in was langlebigeres.

Ganz ehrlich, wie lange braucht man denn um "die libs zu lernen". Mir 
ist es völlig egal ob ich die StdLib oder HAL verwende. Oder gar nichts.
Was muss man denn da groß lernen?
Und dein Post ist leider etwas am Thema vorbei. Ich empfehle ja gerade 
den Controller zu verstehen, anstatt blind irgendwelche Libs zu nutzen.
Und versteht man den Controller, sind die Libs Beiwerk, welches man 
nehmen kann oder auch nicht.

[Walter T. (nicolas)]

Warum wird eigentlich die ganze Zeit vom Datenblatt gefaselt? Im 
Datenblatt der STM32 steht nichts zur Programmierung.

Das, was man sucht, steht im "Programming manual" und noch viel 
wichtiger im "Reference manual".

Für die Kern-Programmierung (für alles außer der Peripherie) ist 
außerdem das obengenannte Buch von Yiu extrem hilfreich.

[Stefan F. (Gast)]

Wenn wir hier "Datenblatt" schreiben, meinen wir damit auch das 
Referenzhandbuch. Die beiden Dokumente gehören einfach fest zusammen.

"Döner" kürzen wir auch aus Gewohnheit ab (das wäre nur der Drehspieß).

[Cyblord -. (cyblord)]

Walter T. schrieb:
> Warum wird eigentlich die ganze Zeit vom Datenblatt gefaselt? Im
> Datenblatt der STM32 steht nichts zur Programmierung.

An den meisten Stellen ist vom Datenblatt und den Manuals die Rede. 
Ansonsten kann man es auch als Überbegriff sehen, vor allem weil bei 
AVRs allen im Datenblatt steht und sich der Begriff gut eingebügert hat.
Also keinen Grund hier ein Windchen zu machen wegen den 
Begrifflichkeiten.

[Nop (Gast)]

Walter T. schrieb:
> Warum wird eigentlich die ganze Zeit vom Datenblatt gefaselt?

Weil Du die Beiträge nicht gelesen hast. Siehe hier:

Nop schrieb:
> Ja, von ST: reference manual, datasheet, programming manual.
> Außerdem von ARM: generic user manual und technical reference manual für
> Cortex-M4.

[Olaf (Gast)]

> Ich würde sagen, dem TE geht es nicht darum zu vermeiden den Prozessor
> zu verstehen, sondern um einen „anschaulichen“ ersten Einstieg, also

Naja, zum programmieren muss man ausschliesslich C können. Im Prinzip 
kann man da Atmel Wissen zu 99% weiter verwenden. Die einzigen 
Unterschiede durften in der Deklaraton von Interruptfunktionen und der 
Ablage von Konstanten im Flash liegen. Da gibt es also eigentlich nichts 
zu lernen.

Die Hardware der STM32 ist sicher etwas aufwendiger, aber es liesst sich 
ja nie einer das Datenblatt komplett durch sondern immer nur die Seiten 
an der er gerade arbeitet. Ich sehe das auch nicht so das Problem.

Problematisch sind zwei Dinge. Manche Hersteller neigen dazu ein Manual 
fuer alles rauszugeben und im Datenblatt des Prozessors steht dann das 
TypXY nur 2Timer anstatt drei hat. Sowas kotzt mich ehrlich gesagt auch 
an.
Aber auch damit kommt man noch klar.

90% des Lernaufwands geht aber fuer die aktuellen Entwicklungsumgebungen 
drauf. Und das ist ja auch der Grund warum die Hersteller mittlerweile 
gerne ihre eigene Eclipse-Suppe aufkochen. Das nervt mich auch und 
deshalb bin ich mittlerweile wieder von Eclipse auf make zurueckgekehrt. 
Eventuell mache in in Zukunft noch mal eine Integraton in qtdesigner. 
Aber das wuerde ich Anfaengern nicht als erstes raten.

Olaf

[Sven K. (sven98de)]

Probier doch mal das mecrisp-stellaris Forth. Da kannst du im Forth 
Interpreter interaktiv alle Register manipulieren u. sofort sehen was 
das Ergebnis ist.

https://hackaday.com/2017/04/19/moving-forth-with-mecrisp-stellaris-and-embello/

https://www.youtube.com/watch?v=dvTI3KmcZ7I

http://hightechdoc.net/mecrisp-stellaris/_build/html/index.html

https://embello.jeelabs.org/flib/

[Stefan F. (Gast)]

> Manche Hersteller neigen dazu ein Manual fuer alles rauszugeben und
> im Datenblatt des Prozessors steht dann das TypXY nur 2Timer anstatt drei hat.

Lustig wird es, wenn du deswegen bei einem STM101 fleißig und 
erfolgreich mit USB rum machst, um dann zu lesen, dass er gar keine USB 
Schnittstelle hat (jedenfalls nicht offiziell). Huch!

[Axel S. (a-za-z0-9)]

Cyblord -. schrieb:
> Olaf schrieb:
>> Aber du musst doch zugegeben das der Lib-Unsinn vor allem deshalb seit
>> einiger Zeit von den Marketingabteilungen nach oben gespuelt wird weil
>> man oft moeglichst viele (gerne auch weniger kompetente) Ingenieure dazu
>> zu bringen will gerade den eigenen ach so tollen Controller zu
>> verwenden.
>
> Woran machst du das fest? Wo soll das so passiert sein? Tut mir leid ich
> sehe das nicht.

Das ist doch nicht schwer zu verstehen. HAL genauso wie die SPL sind 
STM-only. Code, der auf HAL aufsetzt, ist zwar zwischen verschiedenen 
Cortex-M von STM portabel. Aber eben nicht auf einen Cortex-M des 
Wettbewerbs. Und schon haben wir den Vendor lock-in.

Blöd halt, daß STM die SPL aufgegeben hat. Portabilität auf neuere 
Cortex-M? Fehlanzeige. Und umschreiben von SPL auf HAL ist genauso 
aufwendig wie umschreiben von SPL auf Registerzugriffe. Oder auf das 
Äquivalent von SPL/HAL eines anderen Herstellers. Sagen wir ASF von 
Atmel^W Microchip. Und schon wars das mit Vendor lock-in.

Aber schlimmer noch. Wer gesehen hat, wie STM die SPL fallen gelassen 
hat, der kann bis drei zählen und HAL ein ähnliches Schicksal 
vorhersagen. Und der wird um HAL gleich von Anfang an einen großen Bogen 
machen.

>> Jetzt ist die HAL und CubeMX das einig wahre und
>> schon passt keine Zeile Code mehr. Komisch nur dass die, die auf diesen
>> Zug niemals aufgesprungen sind jetzt darüber lachen. Die Zeit um diese
>> Libs zu lernen investiert man besser in was langlebigeres.
>
> Ganz ehrlich, wie lange braucht man denn um "die libs zu lernen".

Du kannst mit SPL oder HAL sofort, ohne Studium der Dokumentation 
produktiven Code schreiben? Du kannst die Namen von Konfigurationsbits 
und Peripherie-Registern aus dem Manual aus dem Kopf in die äquivalenten 
(aber eben trotzdem anders benannten) Konfigurationsstrukturen von HAL 
übersetzen? Du mußt also, mit anderen Worten, zusätzlich zum Studium des 
Manuals (das brauchst du ja in jedem Fall) keine weitere 
Transferleistung erbringen?

Wenn ja: Respekt! Du mußt dieser Gott sein, an den manche Leute glauben.

> Mir ist es völlig egal ob ich die StdLib oder HAL verwende. Oder gar
> nichts. Was muss man denn da groß lernen?

Tja. Jetzt glaube ich eher, daß du weder HAL noch SPL jemals verwendet 
hast.

[Walter T. (nicolas)]

Cyblord -. schrieb:
> Also keinen Grund hier ein Windchen zu machen wegen den
> Begrifflichkeiten.

Schon klar. Wenn der Anfänger nicht die korrekten Begrifflichkeiten 
nutzt, wird er direkt angeraunzt.

Wenn dagegen die Antwort so inpräzise ist, dass der Anfänger erst im 120 
Seiten Datenblatt verzweifelt sucht, dann im Reference Manual mit 1200 
Seiten nicht fündig wird und dann irgendwann selbst herausfinden muss, 
dass des auch ein 150-seitiges Programming manual gibt - dann ist das 
eine Kleinigkeit.

[Johnny B. (johnnyb)]

Axel S. schrieb:
> Du kannst mit SPL oder HAL sofort, ohne Studium der Dokumentation
> produktiven Code schreiben? Du kannst die Namen von Konfigurationsbits
> und Peripherie-Registern aus dem Manual aus dem Kopf in die äquivalenten
> (aber eben trotzdem anders benannten) Konfigurationsstrukturen von HAL
> übersetzen?

Ich finde, mit der HAL kann man schon grösstenteils ohne Studium von 
Zusatzdokus arbeiten, sofern man schon etwas Erfahrung mit 
Mikrocontrollern im Allgemeinen mitbringt.

Beispiel um per I2C etwas einzulesen, 1:1 aus der HAL:

/**
  * @brief  Read an amount of data in blocking mode from a specific memory address
  * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *                the configuration information for the specified I2C.
  * @param  DevAddress Target device address
  * @param  MemAddress Internal memory address
  * @param  MemAddSize Size of internal memory address
  * @param  pData Pointer to data buffer
  * @param  Size Amount of data to be sent
  * @param  Timeout Timeout duration
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
  uint32_t tickstart = 0x00U;

  /* Init tickstart for timeout management*/
  tickstart = HAL_GetTick();
  
  /* Check the parameters */
  assert_param(IS_I2C_MEMADD_SIZE(MemAddSize));

  if(hi2c->State == HAL_I2C_STATE_READY)
  {
    /* Wait until BUSY flag is reset */
    if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BUSY, SET, I2C_TIMEOUT_BUSY_FLAG, tickstart) != HAL_OK)
    {
      return HAL_BUSY;
    }

    /* Process Locked */
    __HAL_LOCK(hi2c);
    
    /* Check if the I2C is already enabled */
    if((hi2c->Instance->CR1 & I2C_CR1_PE) != I2C_CR1_PE)
    {
      /* Enable I2C peripheral */
      __HAL_I2C_ENABLE(hi2c);
    }

    /* Disable Pos */
    hi2c->Instance->CR1 &= ~I2C_CR1_POS;

    hi2c->State     = HAL_I2C_STATE_BUSY_RX;
    hi2c->Mode      = HAL_I2C_MODE_MEM;
    hi2c->ErrorCode = HAL_I2C_ERROR_NONE;

    /* Prepare transfer parameters */
    hi2c->pBuffPtr    = pData;
    hi2c->XferCount   = Size;
    hi2c->XferOptions = I2C_NO_OPTION_FRAME;
    hi2c->XferSize    = hi2c->XferCount;

    /* Send Slave Address and Memory Address */
    if(I2C_RequestMemoryRead(hi2c, DevAddress, MemAddress, MemAddSize, Timeout, tickstart) != HAL_OK)
    {
      if(hi2c->ErrorCode == HAL_I2C_ERROR_AF)
      {
        /* Process Unlocked */
        __HAL_UNLOCK(hi2c);
        return HAL_ERROR;
      }
      else
      {
        /* Process Unlocked */
        __HAL_UNLOCK(hi2c);
        return HAL_TIMEOUT;
      }
    }

    if(hi2c->XferSize == 0U)
    {
      /* Clear ADDR flag */
      __HAL_I2C_CLEAR_ADDRFLAG(hi2c);
      
      /* Generate Stop */
      hi2c->Instance->CR1 |= I2C_CR1_STOP;
    }
    else if(hi2c->XferSize == 1U)
    {
      /* Disable Acknowledge */
      hi2c->Instance->CR1 &= ~I2C_CR1_ACK;

      /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3
         software sequence must complete before the current byte end of transfer */
      __disable_irq();

      /* Clear ADDR flag */
      __HAL_I2C_CLEAR_ADDRFLAG(hi2c);

      /* Generate Stop */
      hi2c->Instance->CR1 |= I2C_CR1_STOP;

      /* Re-enable IRQs */
      __enable_irq();
    }
    else if(hi2c->XferSize == 2U)
    {
      /* Enable Pos */
      hi2c->Instance->CR1 |= I2C_CR1_POS;

      /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3
         software sequence must complete before the current byte end of transfer */
      __disable_irq();

      /* Clear ADDR flag */
      __HAL_I2C_CLEAR_ADDRFLAG(hi2c);
      
      /* Disable Acknowledge */
      hi2c->Instance->CR1 &= ~I2C_CR1_ACK;
      
       /* Re-enable IRQs */
       __enable_irq(); 
    }
    else
    {
      /* Enable Acknowledge */
      SET_BIT(hi2c->Instance->CR1, I2C_CR1_ACK);

      /* Clear ADDR flag */
      __HAL_I2C_CLEAR_ADDRFLAG(hi2c);
    }

    while(hi2c->XferSize > 0U)
    {
      if(hi2c->XferSize <= 3U)
      {
        /* One byte */
        if(hi2c->XferSize== 1U)
        {
          /* Wait until RXNE flag is set */
          if(I2C_WaitOnRXNEFlagUntilTimeout(hi2c, Timeout, tickstart) != HAL_OK)      
          {
            if(hi2c->ErrorCode == HAL_I2C_ERROR_TIMEOUT)
            {
              return HAL_TIMEOUT;
            }
            else
            {
              return HAL_ERROR;
            }
          }

          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;
        }
        /* Two bytes */
        else if(hi2c->XferSize == 2U)
        {
          /* Wait until BTF flag is set */
          if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, Timeout, tickstart) != HAL_OK)
          {
            return HAL_TIMEOUT;
          }

          /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3
             software sequence must complete before the current byte end of transfer */
           __disable_irq();

          /* Generate Stop */
          hi2c->Instance->CR1 |= I2C_CR1_STOP;

          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;

          /* Re-enable IRQs */
          __enable_irq();

          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;
        }
        /* 3 Last bytes */
        else
        {
          /* Wait until BTF flag is set */
          if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, Timeout, tickstart) != HAL_OK)
          {
            return HAL_TIMEOUT;
          }

          /* Disable Acknowledge */
          hi2c->Instance->CR1 &= ~I2C_CR1_ACK;

          /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3
             software sequence must complete before the current byte end of transfer */
          __disable_irq();

          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;

          /* Wait until BTF flag is set */
          if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, Timeout, tickstart) != HAL_OK)
          {
            return HAL_TIMEOUT;
          }

          /* Generate Stop */
          hi2c->Instance->CR1 |= I2C_CR1_STOP;

          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;

          /* Re-enable IRQs */
          __enable_irq();

          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;
        }
      }
      else
      {
        /* Wait until RXNE flag is set */
        if(I2C_WaitOnRXNEFlagUntilTimeout(hi2c, Timeout, tickstart) != HAL_OK)
        {
          if(hi2c->ErrorCode == HAL_I2C_ERROR_TIMEOUT)
          {
            return HAL_TIMEOUT;
          }
          else
          {
            return HAL_ERROR;
          }
        }

        /* Read data from DR */
        (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
        hi2c->XferSize--;
        hi2c->XferCount--;

        if(__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_BTF) == SET)
        {
          /* Read data from DR */
          (*hi2c->pBuffPtr++) = hi2c->Instance->DR;
          hi2c->XferSize--;
          hi2c->XferCount--;
        }
      }
    }

    hi2c->State = HAL_I2C_STATE_READY;
    hi2c->Mode = HAL_I2C_MODE_NONE;
    
    /* Process Unlocked */
    __HAL_UNLOCK(hi2c);

    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}

[Dr. Sommer (Gast)]

Johnny B. schrieb:
> Beispiel um per I2C etwas einzulesen, 1:1 aus der HAL:

Wunderschön. Wenn die Interrupts vorher aus waren, schaltet dieser Code 
sie ungefragt ein. Bezeichner wie __HAL_xxx sind in C für die Standard 
Library reserviert. Man könnte da garantiert einiges kürzen und 
verbessern. Bei der Software von ST hat man generell den Eindruck, die 
sei von Praktikanten geschrieben...

[Conny G. (conny_g)]

Das ist ja ein verschachteltes Monstrum. :-)
Und Ifs inflationär eingesetzt.

Warum nicht

if(hi2c->State != HAL_I2C_STATE_READY)
{
    return HAL_BUSY;
}
// other stuff here

Das systematisch angewendet spart man sich jede Menge Blocks und 
Verschachtelungen.

[Dr. Sommer (Gast)]

Johnny B. schrieb:
> (*hi2c->pBuffPtr++) = hi2c->Instance->DR;

Das ist auch niedlich - "wir sollten hier Klammern setzen um die 
Operator Präzedenzen klar zu machen - oh, leider sind die Klammern ganz 
außen und damit nutzlos".

[Conny G. (conny_g)]

Dr. Sommer schrieb:
> Bei der Software von ST hat man generell den Eindruck, die
> sei von Praktikanten geschrieben...

Das ist von ST? Krass!!

[Conny G. (conny_g)]

Axel S. schrieb:
> Aber schlimmer noch. Wer gesehen hat, wie STM die SPL fallen gelassen
> hat, der kann bis drei zählen und HAL ein ähnliches Schicksal
> vorhersagen. Und der wird um HAL gleich von Anfang an einen großen Bogen
> machen.

Was machst Du bzw. was würdest Du stattdessen empfehlen zu tun?
Eigene Libs schreiben, die Hersteller-unabhängig sind?

[Dr. Sommer (Gast)]

Conny G. schrieb:
> Das ist von ST? Krass!!
Schön finde ich auch sowas:

/**
  * @brief  Toggles the specified GPIO pins.
  * @param  GPIOx Where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
  *                      x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
  * @param  GPIO_Pin Specifies the pins to be toggled.
  * @retval None
  */
void HAL_GPIO_TogglePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
  /* Check the parameters */
  assert_param(IS_GPIO_PIN(GPIO_Pin));

  GPIOx->ODR ^= GPIO_Pin;
}

Das ist nicht atomar, wenn nebenher Interrupts auf GPIOx->ODR arbeiten 
geht das schief. Man könnte es korrekt machen:

  uint32_t msk = GPIOx->ODR & GPIO_Pin;
  GPIOx->BSRR = (msk << 16) | (msk ^ GPIO_Pin);

Aber warum sollte man auch von ST erwarten, dass sie ihre eigenen 
Controller vernünftig programmieren können. Die Libraries von denen sind 
voll mit solchen Sachen. Da kann man es besser selber machen.

Dazu kommt dass alle vordefinierten Konstanten einfach nur Makros sind. 
Wenn ich so etwas schreibe:

const GPIO_InitTypeDef i {
.Pin = (1 << 24),
.Mode = GPIO_NOPULL,
.Pull = GPIO_MODE_INPUT,
.Speed = GPIO_MODE_EVT_RISING };
HAL_GPIO_Init(GPIOA, &i);

dann kommt der einzige Compiler-Fehler in der letzten Zeile, welche die 
einzig sinnvolle in diesem Beispiel ist - weil natürlich der Eingabe 
-Parameter "GPIO_Init" nicht mit "const" markiert ist (warum auch 
Konstanten in den Flash auslagern, das wäre ja effizient!). Die völlig 
falsch angewendeten "Konstanten" werden klaglos angenommen. Toll.

[Axel S. (a-za-z0-9)]

Conny G. schrieb:
> Axel S. schrieb:
>> Aber schlimmer noch. Wer gesehen hat, wie STM die SPL fallen gelassen
>> hat, der kann bis drei zählen und HAL ein ähnliches Schicksal
>> vorhersagen. Und der wird um HAL gleich von Anfang an einen großen Bogen
>> machen.
>
> Was machst Du bzw. was würdest Du stattdessen empfehlen zu tun?

Hardwarezugriff auf Registerebene, natürlich mit den Namen aus den CMSIS 
Headern. Und dann anwendungspezifisch kapseln. Im Anwendungscode also 
nicht:

HAL_GPIO_WritePin(GPIOA, 7, GPIO_PIN_RESET);
// und später
HAL_GPIO_WritePin(GPIOA, 7, GPIO_PIN_SET);

sondern eher

LED_ERROR_on();
// und später
LED_ERROR_off();

Dann stimmt nämlich das "A" in HAL auch wieder.

[Stefan F. (Gast)]

> Was machst Du bzw. was würdest Du stattdessen empfehlen zu tun?
> Eigene Libs schreiben, die Hersteller-unabhängig sind?

Fast. Es gibt Hersteller unabhängig Libraries direkt von Arm. Die 
bekannteste ist die CMSIS-Core welche auch Basis von Cube HAL und 
StdPeriphLib ist. Darauf aufbauen hat Arm noch einiges anderes zu 
bieten.

Natürlich liefert Arm keinen Treiber für den USB Port von ST. Abber ich 
würde mir dennoch mal ansehen, wie die das mit der 
Hersteller-Unabhängigkeit so machen. Vielleicht kann man davon etwas 
lernen.

Hersteller-Abhängigkeit ist mir für die paar Hobby Projekte relativ 
egal. Mich störter eher, dass die StdPeriphLib so unerwartet und schnell 
fallen gelassen wurde. Deswegen schreibe ich meine Projekte auf Basis 
der CMSIS-Core. Das ist zwar aufwändiger aber langfristig hoffentlich 
besser Pflegbar.

Ich bin da ganz Axels Meinung.

[Feldstecher (Gast)]

Cyblord -. schrieb:
> Feldstecher schrieb:
> Praktisch alle Begrifflichkeiten aus der StdPerip entsprechen 1:1 denen
> im Datenblatt. Wer die Register aus dem Datenblatt kennt,
Ich war tatsaechlich davon ausgegangen, dass ich die einzelnen Register 
nicht kennen muss, vielmehr dass mir die Kenntnis im Umgang mit der Lib 
nichts nuetzen wuerde.

> Ääää undokumentiert?
> http://www.st.com/content/ccc/resource/technical/d...
Das kannte ich tatsaechlich nicht. Entweder das gabs damals noch nicht 
(2013) oder ST hats ziemlich gut versteckt~
Ist auch egal, war mein Fehler...

Ich bin aber nach wie vor der Meinung, dass es nicht gerade fuer eine 
Prozessorfamilie und ihr Drumrum spricht, wenn sich Leute damit so 
schwer tun.

[Conny G. (conny_g)]

Feldstecher schrieb:

> Ich bin aber nach wie vor der Meinung, dass es nicht gerade fuer eine
> Prozessorfamilie und ihr Drumrum spricht, wenn sich Leute damit so
> schwer tun.

Naja, das ist der Unterschied zwischen einem Dremel und einer CNC Fräse:
„Es spricht nicht gerade für eine CNC Maschine, dass sie so kompliziert 
ist“.

[Cyblord -. (cyblord)]

Feldstecher schrieb:
> Ich bin aber nach wie vor der Meinung, dass es nicht gerade fuer eine
> Prozessorfamilie und ihr Drumrum spricht, wenn sich Leute damit so
> schwer tun.

Naja die libs sind optional. Für AVR gibt es sowas z.B. gar nicht. 
Beschwert sich auch niemand. Aber dafür gab es hier schon Leute die das 
für AVR in ähnlicher Art nachgebaut haben. Manche sehen also schon den 
Bedarf. Andere halt nicht.

Notwendig sind sie nicht. Man KANN sie einsetzen, aber sie sind kein 
Indikator für die Qualität der Controllerfamilie. ST macht halt Hardware 
und keine Software.

[W.S. (Gast)]

Feldstecher schrieb:
> Beim (komplexeren) STM32 steht man vor einer
> Bibliothek (StdPeriph,  HAL), die erstmal nichts mit den Datenblaettern
> zu tun hat.

Ja wenn man es partout falsch angeht, dann ist das so, als ob man das 
Stück Fleisch auf dem Teller anschauen will durch eine dicke braune 
Schicht Soße hindurch. Man kann da das Fleisch nur erahnen.

Wenn man hingegen in das zuständige Referenzmanual hineinschaut, dann 
sieht man das, was man sucht, weitaus klarer und besser.

Allerdings ist es bei ST oftmals ein bissel ärgerlich, daß deren 
RefManuals gelten häufigfür eine ganze Reihe von Chips, wobei man dann 
an einigen Stellen im Manual nochmal unterscheiden muß, was für welchen 
Chip dann endgültig gilt.


> Ich vermute der STM32 wird von Hobbyisten so gut wie nicht eingesetzt,
> daher auch die schlechte Informationslage auf deutsch.

ROTFL...
Du bist wirklich lustig.
Bin grad vor Lachen vom Stuhl gerutscht. Ein Glück, daß das Notebook 
nichts abgekriegt hat.

Also, mal im Ernst: ST hat in den letzten Jahren eine extrem aggressive 
Werbung für deren STM32 betrieben. Auf jeder Embedded der letzten Jahre 
wurde gerade an junge Leute ein Riedenhaufen von Eval-Boards verschenkt. 
Und genau diese Leute sind es, die inzwischen bei "ARM" oder "Cortex" an 
nix anderes mehr denken können als "STM32".

In der Industrie wird ST auch benutzt, aber nicht gar so häufig. Der 
Grund dafür ist zum Teil der, daß eine Menge Peripherie bei den STM32 
noch immer 16 bittig ist, während andere ihre Peripherie schlichtweg 32 
bittig machen. Guck dir z.B. malmeinen USB-VCP-Treiber für die 
STM32F103xxx an. Wie dort die Puffer organisiert sind, ist eine mittlere 
Zumutung.

W.S.

[W.S. (Gast)]

Cyblord -. schrieb:
> Sie sollen den Code lesbarer (=sprechender) machen und über die reinen
> Registerbits Abstrahieren.
>
> Sie erfordern trotzdem dass der Benutzer weiß WAS er tun möchte

Also erstens machen sie den Quellcode nicht lesbarer, weil sie 
Treiber-Interna lustig quer über den Rest der Firmware spülen, anstatt 
selbige im treiber zu kapseln. Auch dieses Forum ist voll von
  "BlaBlaInitStruc.xyz = unendlichlangerunleserlicheridentifier;"

Und zweitens, wer weiß, was er tut, benötigt solches Zeugs nicht und 
lebt mit was Eigenem weitaus besser.

Siehe diese hier:

temp schrieb:
> Da ist es um Längen besser man macht sich
> seine eigene abgespeckte HAL in die man nur das reinpackt was man
> wirklich braucht.

Ja, eben. Genau DAS ist auch meine Herangehensweise. Und wenn man sich 
sein Standard-Repertoire erstmal geschaffen hat, dann kriegt man das 
binnen kurzer Zeit auf jedem anderen Chip zum Laufen. Damit ist man 
schneller und besser als jeder, der sich auf Hersteller-Köder einläßt.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Ja, eben. Genau DAS ist auch meine Herangehensweise. Und wenn man sich
> sein Standard-Repertoire erstmal geschaffen hat,

Ist auch irgendwie blöd wenn jeder Entwickler seine eigenen Bibliotheken 
hat. Wenn man mehrere Software-Komponenten kombinieren möchte passen die 
nicht zusammen, und viel Arbeit ist es sowieso. Es verwendet ja auch 
nicht jeder Ing seinen eigenen Schraubentyp...

[W.S. (Gast)]

Conny G. schrieb:
> Daran wäre ich auch interessiert und es kamen schon ein paar Ressourcen
> zur Sprache.
> Aber generell ist das wohl bei STM32 sehr viel dünner gesäht als bei
> Atmel,...

Das sehe ich nicht so. Es ist bloß weniger allgemeiner Traffic 
anzutreffen.

Mein Rat wäre, zuerst mal mit was Einfachem und Billigen anzufangen. 
Sowas kriegst du aus China oder du bastelst es dir selber zurecht. 
Letzteres hilft dir nicht bloß beim Programmieren, sondern auch beim 
Umgang mit der Hardware.

Schau dir z.B. mal das da an, es ist wirklich nur ein kleines 
Projektchen und entsprechend übersichtlich. Aber man kann es als Basis 
für richtige Projekte benutzen. Und das OHNE den Griff zum Debugger, 
weil es eben eine bereits gut funktionale Basis bildet.

https://www.mikrocontroller.net/attachment/316790/STM32F103C8T6.ZIP

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Schau dir z.B. mal das da an, es ist wirklich nur ein kleines
> Projektchen und entsprechend übersichtlich.

Hast du das immer noch nicht korrigiert?

#define  integer   short int
#define  word      unsigned short int
#define  byte      unsigned char
#define  dword     unsigned long
#define  qword     unsigned long long
#define  int64     long long
#define  cardinal  unsigned long
#define  bool      unsigned char

Das gehört sowas von verboten.

#define     MOD   %
#define     XOR   ^
#define     NOT   ~
#define     AND   &
#define     OR    |

komplett unnötig, C kennt bereits "and", "or" usw.

immerzu:
  Talk (toUART1);
  Talk (toUART2);
  Talk (toUSB);
 ...
  goto immerzu;

Ernsthaft? Ein goto wo es auch ein while(1) getan hätte?

#define  stdin    255        /* In vom Standard-Stream       */
#define  stdout   255        /* Out zum Standard-Stream      */

C- Standard Bezeichner als was komplett anderes überschreiben? 
Hoffentlich kommt keiner auf die Idee <stdio.h> zu inkludieren.

Und wenn schon eine eigene "STM32F103all.h" schreiben, dann doch bitte 
nicht alle Fehler von ST übernehmen und besser machen.

Also Kinder: Das bitte nicht als Beispiel nehmen. Da lieber 3x die 
HAL...

[W.S. (Gast)]

Johnny B. schrieb:
> Beispiel um per I2C etwas einzulesen, 1:1 aus der HAL:
> /**
>   * @brief  Read an amount...
> weitere 2..3 Seiten Code...

Und das nennst du EINFACH????

Bei mir sieht sowas ganz anders aus - und das auf verschiedensten 
Controllern:

// UKW-Radio TEA5767 auslesen
bool Do_Readout (void)
{ bool erg;
    
  erg = Do_I2C_Start(TEA, I2CREAD);
  if(!erg) return erg;

  RFF[0] = Do_I2C_Read (true);
  RFF[1] = Do_I2C_Read (true);
  RFF[2] = Do_I2C_Read (true);
  RFF[3] = Do_I2C_Read (true);
  RFF[4] = Do_I2C_Read (false);
  Do_I2C_Stop();
  return true;
}

So ungefähr stelle ich mir vor, wie sowas beispielsweise einfach und 
übersichtlich aussieht.

W.S.

[312313132131 (Gast)]

ich nutze die standardlibs und auch HAL
gerade wenn man auf M4/M7 mit RTOS unterwegs ist...
ist das HAL gedöhns garnicht so doof weil die lib bei read/write/init 
sich selbst locked.
wenn man mehrere threads hat die auf eine peripherie zugreifen wollen 
...

Die HAL ist SICHERLICH keine schönheit.
Aber funktioniert erstmal fast immer auf anhieb.

oft denke ich darüber nach die 0815 globalen structs aufzulösen in 
entsprechende register
zu 90% das (*struct)->Instance nur eine bescheuerte variable für die
Registeradresse  selbst
nur wegen ca 300bytes ist mir das zu blöd umzuschreiben.

Da schreibe ich lieber die anwendung direkt drauf los.

[312313132131 (Gast)]

achso wenn man mal doch den µC wechselt


oft ist es relativ einfach die HAL_xx von ST gegen andere funktionen von 
anderen Herstellern auszutauschen.

[W.S. (Gast)]

Dr. Sommer schrieb:
> C- Standard Bezeichner als was komplett anderes überschreiben?
> Hoffentlich kommt keiner auf die Idee <stdio.h> zu inkludieren.

Ja, sowas wird hier anders gemacht!
Wir sind in diesem Projekt nämlich NICHT auf dem PC mit einem BS und 
verwalteten I/O-Streams, sondern in einer ganz anderen Umgebung, nämlich 
auf einem kleinen Mikrocontroller - aber sowas konntest du ja schon 
früher nicht begreifen.

Und genau deshalb muß da sowas rein, was du nicht begreifen willst.

Weißt du was? Anstelle seit der Lernbetty nix anderes hier abzulassen 
als Herum-Mosern, solltest du mal selber irgendwas Konstruktives 
beitragen. Dieses Forum lebt nämlich von positiven Beiträgen und nicht 
von ubiquitärem Mäkeln und Mokieren. Ich hatte dich ja schon vor Langem 
dazu animieren wollen, aber selbst was leisten zu sollen, hattest du 
vehement abgelehnt.

W.S.

[312313132131 (Gast)]

ich nutze stdio und stdint weil ich auch diverse libs von anderen nutze
die meisten libs nutzen eben ... stdlib und stdio
daher sind diese schon drin.

DAS könnte ich wie oben nicht machen und würde sofort probleme geben.

und nein ich würde die libs deswegen nicht umschreiben
Das wäre zu komplex ( tcpip, sip, ssl ..... )

[Dr. Sommer (Gast)]

W.S. schrieb:
> Wir sind in diesem Projekt nämlich NICHT auf dem PC mit einem BS und
> verwalteten I/O-Streams, sondern in einer ganz anderen Umgebung, nämlich
> auf einem kleinen Mikrocontroller - aber sowas konntest du ja schon
> früher nicht begreifen.
Und das tut was zur Sache? Auch auf Mikrocontrollern, besonders auf den 
dicken STM32, kann man problemlos puts(), printf() und Konsorten aus der 
<stdio.h> verwenden. Außerdem kann es sein dass irgendein System-Header 
die <stdio.h> mit inkludiert. Daher ist es das mindeste , die 
Standard-Bezeichner nicht zu überschreiben. Es tut überhaupt nicht weh, 
das "mystdout" o.ä. zu nennen, und z.B. ein enum statt einem Makro zu 
verwenden.

W.S. schrieb:
> Und genau deshalb muß da sowas rein, was du nicht begreifen willst.
Es muss da nicht rein und es muss auch nicht "stdout" heißen.

W.S. schrieb:
> Weißt du was? Anstelle seit der Lernbetty nix anderes hier abzulassen
> als Herum-Mosern, solltest du mal selber irgendwas Konstruktives
> beitragen.
Hab ich, aber unter anderem Namen.

W.S. schrieb:
> Ich hatte dich ja schon vor Langem
> dazu animieren wollen, aber selbst was leisten zu sollen, hattest du
> vehement abgelehnt.
Du mäkelst doch auch nur an anderen rum und lobst deinen eigenen 
grässlichen C-Code zum Himmel.

[temp (Gast)]

Oha, Dr. Sommer und W.S., lasst mich schnell Popcorn holen....

[Nop (Gast)]

Dr. Sommer schrieb:

> #define  integer   short int

WTF, ein define statt eines typedef, um sich Datentypen zu schnitzen, 
die man in besser und portabel seit C99 sowieso hat? Und derselbe 
Pascal-Unfug bei den Operatoren?

> Also Kinder: Das bitte nicht als Beispiel nehmen.

Jepp.

[Cyblord -. (cyblord)]

W.S. schrieb:
>> Sie erfordern trotzdem dass der Benutzer weiß WAS er tun möchte
>
> Also erstens machen sie den Quellcode nicht lesbarer, weil sie
> Treiber-Interna lustig quer über den Rest der Firmware spülen, anstatt
> selbige im treiber zu kapseln. Auch dieses Forum ist voll von
>   "BlaBlaInitStruc.xyz = unendlichlangerunleserlicheridentifier;"

Das ist deine Privatmeinung. Und niemand wird gezwungen quer durch den 
Code die Aufrufe der StdLib zu verwenden. Welche Abstraktion der Nutzer 
da oben drauf setzt, hat mit der Lib nichts zu tun.

Wenn es euch so wichtig ist, über die StdLib oder HAL abzukotzen, warum 
macht ihr dafür nicht einen eigenen Thread auf? Hier war das nie Thema. 
Aber einige scheinen es für sehr wichtig zu halten, ihre Ablehnung 
dagegen kund tun zu können.

[Conny G. (conny_g)]

312313132131 schrieb:
> achso wenn man mal doch den µC wechselt
>
>
> oft ist es relativ einfach die HAL_xx von ST gegen andere funktionen von
> anderen Herstellern auszutauschen.

Man kann ja die verschiedenen HAL der Hersteller in eine weitere Layer 
einpacken und diese dann HALAL nennen, rofl

[312313132131 (Gast)]

Conny G. schrieb:
> 312313132131 schrieb:
>> achso wenn man mal doch den µC wechselt
>>
>>
>> oft ist es relativ einfach die HAL_xx von ST gegen andere funktionen von
>> anderen Herstellern auszutauschen.
>
> Man kann ja die verschiedenen HAL der Hersteller in eine weitere Layer
> einpacken und diese dann HALAL nennen, rofl

nunja .. ich nutze diverse librarys

diese bringen eine gewisse art BSP mit wo diverse read/write/init/io 
funktionen abstrahiert werden

hier können dann kundenspezifische funktionen eingebaut werden
ob das HAL ist ... oder STDLIB oder noch ein wrapper ist dabei egal

wichtig ist aber eines!!
die libs sind von µC bis CPU verwendbar

ich möchte nicht zig files durchwühlen und überall register neu zuweisen
das kann echt kopfschmerzen bereiten

[312313132131 (Gast)]

dann lieber HALwrapHAL()