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"
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.
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.
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.
...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.
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.
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.
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
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
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
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.
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.
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.
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!
> Die Anforderung "Literatur in Deutsch" sollte man allerdings schnell> vergessen.
Das ist das eigentliche kapitale Problem in fast allen technischen und
nichttechnischen Bereichen.
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?
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.
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.
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.
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
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.
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.
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.
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 ;)
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
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/
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.
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.
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.
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
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.
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.
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..
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.
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.
> 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.
> 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
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.
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.
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.
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.
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ß).
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.
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.
> 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
> 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!
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.
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.
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:
1
/**
2
* @brief Read an amount of data in blocking mode from a specific memory address
3
* @param hi2c Pointer to a I2C_HandleTypeDef structure that contains
4
* the configuration information for the specified I2C.
5
* @param DevAddress Target device address
6
* @param MemAddress Internal memory address
7
* @param MemAddSize Size of internal memory address
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...
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".
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?
Das ist nicht atomar, wenn nebenher Interrupts auf GPIOx->ODR arbeiten
geht das schief. Man könnte es korrekt machen:
1
uint32_tmsk=GPIOx->ODR&GPIO_Pin;
2
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:
1
constGPIO_InitTypeDefi{
2
.Pin=(1<<24),
3
.Mode=GPIO_NOPULL,
4
.Pull=GPIO_MODE_INPUT,
5
.Speed=GPIO_MODE_EVT_RISING};
6
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.
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:
> 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.
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.
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“.
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.
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.
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.
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...
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.
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?
1
#define integer short int
2
#define word unsigned short int
3
#define byte unsigned char
4
#define dword unsigned long
5
#define qword unsigned long long
6
#define int64 long long
7
#define cardinal unsigned long
8
#define bool unsigned char
Das gehört sowas von verboten.
1
#define MOD %
2
#define XOR ^
3
#define NOT ~
4
#define AND &
5
#define OR |
komplett unnötig, C kennt bereits "and", "or" usw.
1
immerzu:
2
Talk(toUART1);
3
Talk(toUART2);
4
Talk(toUSB);
5
...
6
gotoimmerzu;
Ernsthaft? Ein goto wo es auch ein while(1) getan hätte?
1
#define stdin 255 /* In vom Standard-Stream */
2
#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...
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:
1
// UKW-Radio TEA5767 auslesen
2
boolDo_Readout(void)
3
{boolerg;
4
5
erg=Do_I2C_Start(TEA,I2CREAD);
6
if(!erg)returnerg;
7
8
RFF[0]=Do_I2C_Read(true);
9
RFF[1]=Do_I2C_Read(true);
10
RFF[2]=Do_I2C_Read(true);
11
RFF[3]=Do_I2C_Read(true);
12
RFF[4]=Do_I2C_Read(false);
13
Do_I2C_Stop();
14
returntrue;
15
}
So ungefähr stelle ich mir vor, wie sowas beispielsweise einfach und
übersichtlich aussieht.
W.S.
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.
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.
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 ..... )
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.
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.
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.
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
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
Thread beobachten
Seitenaufteilung abschalten