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.
okay, okay. Englisch. Berg, Prophet, ich weiß schon. STM32Newbee
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: > Empfehlen kann man die StdPeriphLib - dort wird zwar auch manchmal etwas übertrieben was Nö, kann man nicht.
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 Pete, vielen Dank, ich versuche es nochmal, obwohl es Code für eine andere Lib ist, kann man manches aus HAL Sicht verstehen. STM32Newbee
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!
Diese Vorgehensweise halte ich auch für Sinnvoll. Jede Funktion bzw Schnittstelle einzeln ausprobieren bevor man sie ernsthaft anwendet.
> 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?
Dieses Buch ist eine Pflichtlektüre: http://centaur.sch.bme.hu/~holcsik_t/sem/The%20Definitive%20Guide%20to%20the%20ARM%20Cortex-M3.pdf
Weil die StdPeriphLib laut ST deprecated ist.
Wer sich nicht um Hardware-Kompatibilität und Hardware-Abstraktion sorgt, darf doch StdLib verwenden.
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.
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..
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.
>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
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.
:
Bearbeitet durch User
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 ;)
:
Bearbeitet durch User
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/
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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: > 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
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.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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
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/
> 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 |
8 | * @param pData Pointer to data buffer |
9 | * @param Size Amount of data to be sent |
10 | * @param Timeout Timeout duration |
11 | * @retval HAL status |
12 | */ |
13 | 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) |
14 | { |
15 | uint32_t tickstart = 0x00U; |
16 | |
17 | /* Init tickstart for timeout management*/ |
18 | tickstart = HAL_GetTick(); |
19 | |
20 | /* Check the parameters */ |
21 | assert_param(IS_I2C_MEMADD_SIZE(MemAddSize)); |
22 | |
23 | if(hi2c->State == HAL_I2C_STATE_READY) |
24 | { |
25 | /* Wait until BUSY flag is reset */ |
26 | if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BUSY, SET, I2C_TIMEOUT_BUSY_FLAG, tickstart) != HAL_OK) |
27 | { |
28 | return HAL_BUSY; |
29 | } |
30 | |
31 | /* Process Locked */ |
32 | __HAL_LOCK(hi2c); |
33 | |
34 | /* Check if the I2C is already enabled */ |
35 | if((hi2c->Instance->CR1 & I2C_CR1_PE) != I2C_CR1_PE) |
36 | { |
37 | /* Enable I2C peripheral */ |
38 | __HAL_I2C_ENABLE(hi2c); |
39 | } |
40 | |
41 | /* Disable Pos */ |
42 | hi2c->Instance->CR1 &= ~I2C_CR1_POS; |
43 | |
44 | hi2c->State = HAL_I2C_STATE_BUSY_RX; |
45 | hi2c->Mode = HAL_I2C_MODE_MEM; |
46 | hi2c->ErrorCode = HAL_I2C_ERROR_NONE; |
47 | |
48 | /* Prepare transfer parameters */ |
49 | hi2c->pBuffPtr = pData; |
50 | hi2c->XferCount = Size; |
51 | hi2c->XferOptions = I2C_NO_OPTION_FRAME; |
52 | hi2c->XferSize = hi2c->XferCount; |
53 | |
54 | /* Send Slave Address and Memory Address */ |
55 | if(I2C_RequestMemoryRead(hi2c, DevAddress, MemAddress, MemAddSize, Timeout, tickstart) != HAL_OK) |
56 | { |
57 | if(hi2c->ErrorCode == HAL_I2C_ERROR_AF) |
58 | { |
59 | /* Process Unlocked */ |
60 | __HAL_UNLOCK(hi2c); |
61 | return HAL_ERROR; |
62 | } |
63 | else |
64 | { |
65 | /* Process Unlocked */ |
66 | __HAL_UNLOCK(hi2c); |
67 | return HAL_TIMEOUT; |
68 | } |
69 | } |
70 | |
71 | if(hi2c->XferSize == 0U) |
72 | { |
73 | /* Clear ADDR flag */ |
74 | __HAL_I2C_CLEAR_ADDRFLAG(hi2c); |
75 | |
76 | /* Generate Stop */ |
77 | hi2c->Instance->CR1 |= I2C_CR1_STOP; |
78 | } |
79 | else if(hi2c->XferSize == 1U) |
80 | { |
81 | /* Disable Acknowledge */ |
82 | hi2c->Instance->CR1 &= ~I2C_CR1_ACK; |
83 | |
84 | /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3 |
85 | software sequence must complete before the current byte end of transfer */ |
86 | __disable_irq(); |
87 | |
88 | /* Clear ADDR flag */ |
89 | __HAL_I2C_CLEAR_ADDRFLAG(hi2c); |
90 | |
91 | /* Generate Stop */ |
92 | hi2c->Instance->CR1 |= I2C_CR1_STOP; |
93 | |
94 | /* Re-enable IRQs */ |
95 | __enable_irq(); |
96 | } |
97 | else if(hi2c->XferSize == 2U) |
98 | { |
99 | /* Enable Pos */ |
100 | hi2c->Instance->CR1 |= I2C_CR1_POS; |
101 | |
102 | /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3 |
103 | software sequence must complete before the current byte end of transfer */ |
104 | __disable_irq(); |
105 | |
106 | /* Clear ADDR flag */ |
107 | __HAL_I2C_CLEAR_ADDRFLAG(hi2c); |
108 | |
109 | /* Disable Acknowledge */ |
110 | hi2c->Instance->CR1 &= ~I2C_CR1_ACK; |
111 | |
112 | /* Re-enable IRQs */ |
113 | __enable_irq(); |
114 | } |
115 | else |
116 | { |
117 | /* Enable Acknowledge */ |
118 | SET_BIT(hi2c->Instance->CR1, I2C_CR1_ACK); |
119 | |
120 | /* Clear ADDR flag */ |
121 | __HAL_I2C_CLEAR_ADDRFLAG(hi2c); |
122 | } |
123 | |
124 | while(hi2c->XferSize > 0U) |
125 | { |
126 | if(hi2c->XferSize <= 3U) |
127 | { |
128 | /* One byte */ |
129 | if(hi2c->XferSize== 1U) |
130 | { |
131 | /* Wait until RXNE flag is set */ |
132 | if(I2C_WaitOnRXNEFlagUntilTimeout(hi2c, Timeout, tickstart) != HAL_OK) |
133 | { |
134 | if(hi2c->ErrorCode == HAL_I2C_ERROR_TIMEOUT) |
135 | { |
136 | return HAL_TIMEOUT; |
137 | } |
138 | else |
139 | { |
140 | return HAL_ERROR; |
141 | } |
142 | } |
143 | |
144 | /* Read data from DR */ |
145 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
146 | hi2c->XferSize--; |
147 | hi2c->XferCount--; |
148 | } |
149 | /* Two bytes */ |
150 | else if(hi2c->XferSize == 2U) |
151 | { |
152 | /* Wait until BTF flag is set */ |
153 | if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, Timeout, tickstart) != HAL_OK) |
154 | { |
155 | return HAL_TIMEOUT; |
156 | } |
157 | |
158 | /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3 |
159 | software sequence must complete before the current byte end of transfer */ |
160 | __disable_irq(); |
161 | |
162 | /* Generate Stop */ |
163 | hi2c->Instance->CR1 |= I2C_CR1_STOP; |
164 | |
165 | /* Read data from DR */ |
166 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
167 | hi2c->XferSize--; |
168 | hi2c->XferCount--; |
169 | |
170 | /* Re-enable IRQs */ |
171 | __enable_irq(); |
172 | |
173 | /* Read data from DR */ |
174 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
175 | hi2c->XferSize--; |
176 | hi2c->XferCount--; |
177 | } |
178 | /* 3 Last bytes */ |
179 | else |
180 | { |
181 | /* Wait until BTF flag is set */ |
182 | if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, Timeout, tickstart) != HAL_OK) |
183 | { |
184 | return HAL_TIMEOUT; |
185 | } |
186 | |
187 | /* Disable Acknowledge */ |
188 | hi2c->Instance->CR1 &= ~I2C_CR1_ACK; |
189 | |
190 | /* Disable all active IRQs around ADDR clearing and STOP programming because the EV6_3 |
191 | software sequence must complete before the current byte end of transfer */ |
192 | __disable_irq(); |
193 | |
194 | /* Read data from DR */ |
195 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
196 | hi2c->XferSize--; |
197 | hi2c->XferCount--; |
198 | |
199 | /* Wait until BTF flag is set */ |
200 | if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, Timeout, tickstart) != HAL_OK) |
201 | { |
202 | return HAL_TIMEOUT; |
203 | } |
204 | |
205 | /* Generate Stop */ |
206 | hi2c->Instance->CR1 |= I2C_CR1_STOP; |
207 | |
208 | /* Read data from DR */ |
209 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
210 | hi2c->XferSize--; |
211 | hi2c->XferCount--; |
212 | |
213 | /* Re-enable IRQs */ |
214 | __enable_irq(); |
215 | |
216 | /* Read data from DR */ |
217 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
218 | hi2c->XferSize--; |
219 | hi2c->XferCount--; |
220 | } |
221 | } |
222 | else |
223 | { |
224 | /* Wait until RXNE flag is set */ |
225 | if(I2C_WaitOnRXNEFlagUntilTimeout(hi2c, Timeout, tickstart) != HAL_OK) |
226 | { |
227 | if(hi2c->ErrorCode == HAL_I2C_ERROR_TIMEOUT) |
228 | { |
229 | return HAL_TIMEOUT; |
230 | } |
231 | else |
232 | { |
233 | return HAL_ERROR; |
234 | } |
235 | } |
236 | |
237 | /* Read data from DR */ |
238 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
239 | hi2c->XferSize--; |
240 | hi2c->XferCount--; |
241 | |
242 | if(__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_BTF) == SET) |
243 | { |
244 | /* Read data from DR */ |
245 | (*hi2c->pBuffPtr++) = hi2c->Instance->DR; |
246 | hi2c->XferSize--; |
247 | hi2c->XferCount--; |
248 | } |
249 | } |
250 | } |
251 | |
252 | hi2c->State = HAL_I2C_STATE_READY; |
253 | hi2c->Mode = HAL_I2C_MODE_NONE; |
254 | |
255 | /* Process Unlocked */ |
256 | __HAL_UNLOCK(hi2c); |
257 | |
258 | return HAL_OK; |
259 | } |
260 | else |
261 | { |
262 | return HAL_BUSY; |
263 | } |
264 | } |
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...
Das ist ja ein verschachteltes Monstrum. :-) Und Ifs inflationär eingesetzt. Warum nicht
1 | if(hi2c->State != HAL_I2C_STATE_READY) |
2 | { |
3 | return HAL_BUSY; |
4 | } |
5 | // other stuff here |
Das systematisch angewendet spart man sich jede Menge Blocks und Verschachtelungen.
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".
Dr. Sommer schrieb: > Bei der Software von ST hat man generell den Eindruck, die > sei von Praktikanten geschrieben... Das ist von ST? Krass!!
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?
Conny G. schrieb: > Das ist von ST? Krass!! Schön finde ich auch sowas:
1 | /**
|
2 | * @brief Toggles the specified GPIO pins.
|
3 | * @param GPIOx Where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
|
4 | * x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
|
5 | * @param GPIO_Pin Specifies the pins to be toggled.
|
6 | * @retval None
|
7 | */
|
8 | void HAL_GPIO_TogglePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin) |
9 | {
|
10 | /* Check the parameters */
|
11 | assert_param(IS_GPIO_PIN(GPIO_Pin)); |
12 | |
13 | GPIOx->ODR ^= GPIO_Pin; |
14 | }
|
Das ist nicht atomar, wenn nebenher Interrupts auf GPIOx->ODR arbeiten geht das schief. Man könnte es korrekt machen:
1 | uint32_t msk = 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 | const GPIO_InitTypeDef i { |
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:
1 | HAL_GPIO_WritePin(GPIOA, 7, GPIO_PIN_RESET); |
2 | // und später
|
3 | HAL_GPIO_WritePin(GPIOA, 7, GPIO_PIN_SET); |
sondern eher
1 | LED_ERROR_on(); |
2 | // und später
|
3 | LED_ERROR_off(); |
Dann stimmt nämlich das "A" in HAL auch wieder.
> 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 | goto immerzu; |
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 | bool Do_Readout (void) |
3 | { bool erg; |
4 | |
5 | erg = Do_I2C_Start(TEA, I2CREAD); |
6 | if(!erg) return erg; |
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 | return true; |
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.
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.
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.
Oha, Dr. Sommer und W.S., lasst mich schnell Popcorn holen....
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.
:
Bearbeitet durch User
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.