Hi, ich würde gerne von AVR´s auf STM32 umsteigen. Da die Standard Lib durch HAL abgelöst wurde, würde ich gerne direkt mit der HAL einsteigen. Leider finde ich kein Tutorial im Netz das die HAL beschreibt - was es mir als Hobby Einsteiger sehr schwer macht. Habt Ihr eine Quelle zum Einstieg parat? Danke und Gruß technikus
technikus schrieb: > würde ich gerne direkt mit der HAL einsteigen. Du gehst nicht mit der Zeit! Du bist hintendran! Bald wird ein neuer Jünger auftreten und dir predigen dass du gefälligst CubeMX nehmen sollst. Und wenn du noch etwas wartest wird man die STMs in Java und Visual Basic programmieren können/dürfen/müssen. Dann aber wird es von Vorteil sein sich wieder mit den alten AVRs aus- einanderzusetzen.
HAL ist keine Library sondern steht für Hardware Abstraction Layer. Für die STM32 gibt es zwei HAL Libraries. Einmal die alte Standard Peripheral Libraries und das neuere STM32Cube. Wenn du danach suchst findest du eventuell was. Arduinoquäler schrieb: > Und wenn du noch etwas wartest wird man die STMs in Java und > Visual Basic programmieren können/dürfen/müssen. Dann aber > wird es von Vorteil sein sich wieder mit den alten AVRs aus- > einanderzusetzen. Genau. Wenn man Mikrocontroller nur noch in Java programmieren kann interessiert sich bestimmt jemand für einen AVR Programmierer...
:
Bearbeitet durch User
Sieh dir mal Folgendes an: https://stm32f4-discovery.net/2014/09/stm32f4-tutorials-one-place/ Das hat für mich für ein paar grundlegende Dinge gereicht, wenn ich mich recht entsinne...
Sebastian V. schrieb: > HAL ist keine Library sondern steht für Hardware Abstraction Layer. Für > die STM32 gibt es zwei HAL Libraries. Einmal die alte Standard > Peripheral Libraries und das neuere STM32Cube. Falsch. ST beschreibt die Library ja selbst als CubeFx/HAL-Library (x = 1,3...), auch wenn die Abkürzung natürlich richtig ist. Die SPL ist auch keine richtige Abstraktion. Und STM32Cube ist keine Library, sondern ein "Ökosystem" für Hardware-Abstraktion, zu dem die STM32CubeFx HAL-Libraries und der STM32CubeMX Startup Code Generator gehören.
:
Bearbeitet durch User
technikus schrieb: > ich würde gerne von AVR´s auf STM32 umsteigen. ... ist am Anfang etwas (untertrieben) "verwirrend". Du benötigst natürlich die Datasheets (man beachte: Mehrzahl) zu dem verwendeten Controller. Hier kannst du schlicht unterscheiden in: - Datasheet .. steht bspw. Pinbelegung, Alternative Pins etc. drin und vor allem die Adressen der Register OHNE deren Beschreibung - Reference Manual .. KEINE Pinbelegung dafür Beschreibung der einzelnen Register Von daher ist also erst einmal angesagt: Sondieren, wo steht was. Die Einstellmöglichkeiten von STM32 bringen dich am Anfang schier um, angefangen mit der Einstellung, welcher Systemtakt herschen soll: HSI für internen Oszillator HSE für externen Oszillator Aber, hier darfst dann gleich ermitteln, wie ein Takt weiter "aufbereitet" wird. Ein interner PLL erzeugt eine Taktvervielfachung so daß oft - wenn verwendet - ein externer Quarz 8MHz verschaltet wird der dann über PLL vervielfacht wird. Dann mußt du dir immer vergegenwärtigen, dass jede interne Einheit grundsätzlich erst einmal den Takt eingeschaltet haben mag. Nicht, wirklich nichts läuft von alleine automatisch an. Unterm Strich wirklich gut, weil so keine Einheiten unnötig Strom verbraten, für den Anfänger allerdings schwierig weil er auch das konfigurieren muß. Auch hier muß man die Taktgeschwindigkeit für bspw. ein SPI oder I2C oder auch nur GPIO - Pins konfigurieren. Sieht man in diverse Sourcen, dann erkennst du auch schnell Unterschiede bspw. im Behandeln von GPIO-Pins (für Bitbanging): Es gibt nicht ein Register, dass die einsen und nullen auf den Hardware-Pins abbildet. Zum setzen und löschen einzelner Bits hast du ein 32-Bit Register mittels derer du (je nach Controller) 16 Port-Pins ein- und ausschalten kannst, wobei ein setzen einer 1 an den oberen 16 Bit den Pegel am Pin löscht !!!! Ein setzen an den unteren setzt diese. Arduinoquäler schrieb: > Bald wird ein neuer Jünger auftreten und dir predigen > dass du gefälligst CubeMX nehmen sollst. Ich bin sicherlich kein CubeMX - Jünger (und ich habe ein Template, das CubeMX erstellen kann nie verwendet), aber für den Anfang ist das schön zu sehen, welche Einheiten innerhalb des STM was beaufschlagen (und du lernst dort die Namen kennen). Sebastian V. schrieb: > Einmal die alte Standard > Peripheral Libraries und das neuere STM32Cube. Die Welt besteht nicht nur aus schwarz und weiss. Wenn man in die Sources von beiden schaut stellt sich oft auch ein "Aha-Erlebnis" ein, eine weitere Möglichkeit wäre jedoch auch: libopencm3 (die ich persönlich verwende). Hier kannst du dann (auch schmerzlich) lernen, an welchen Speicheradressen welche interne Peripherie liegt und du lernst was ein Linkerscript ist (ohne das mit Cortex Mx gar nichts geht). Ich für meinen Teil habe für mich die libopencm3 weiter abstrahiert (mit genau der Namensgebung mit der ich auch mit anderen Controllern arbeite, sodaß ich oft gar nicht mehr merke - leider - mit welchem Controller ich es eigentlich zu tun habe). Bspw. kann ein SPI mit derart vielen Einstellungen betrieben werden, die ich in aller Regel gar nicht benötige, also hab ich mir mit libopencm3 eben die Einheiten weiter für mich vereinfacht und ein auf mich passendes Makefile geschustert. Ein Vorteil von libopencm3 sind die vielen FUNKTIONIERENDEN Beispiele. Die Beschreibung von libopencm3 findest du hier: http://libopencm3.org/docs/latest/html/index.html Schaut man hier in die Sources und "studiert" diese etwas genauer, wirst du in einigen Fällen gar keine HAL verwenden sondern setzt diese selbst auf, dann weißt du auch, wie es funktioniert. Wenn du allerdings einfach nur einen STM32 verwenden magst und mit den Eigenheiten nicht kämpfen magst, kannst du auch ein MBED-fähiges Board nehmen (bspw. die superbilligen STM32F103 BluePill Boards aus China, am besten in Verbindung mit einem ST-Linkv2 Clone ebenfalls aus China) und die Software online in MBED erstellen (was sehr stark nach Arduino anmutet). Viele Wege führen hin zu STM32. Wenn du den Weg über die Datenblätter gehst, in ALLE verfügbaren Sourcen und Libraries reinschaust wirst du am meisten lernen und - so glaube ich - sich der Aha-Effekt am schnellsten einstellen.
>Bald wird ein neuer Jünger auftreten und dir predigen >dass du gefälligst CubeMX nehmen sollst. Amen, ich sage dir, du MUSST CubeMX benutzen, die Silizium Götter wollen es so ! STMicro mit CubeMX, Infineon mit DAVE Microchip mit MPLAB Code Configurator Atmel mit start.atmel.com Alle bieten einen Code Generator an und Ihn nicht zu benutzen wird dich in die Hölle der Bitsetzerei verdammen. Ein Codegenerator in Kombination mit einer IDE ist eine Arbeitserleichterung, so bald man verstanden hat wie es funktioniert. Allerdings ist der Weg dahin kein Zuckerschlecken. Aber alle Dokumentation der Libs ist darin enthalten. Java geht auch: http://www.stm32j.com/ Aber die Code Generatoren sind für C. Es gibt viele Anleitungen im Web, aber die wenigsten sind einsteigerfreundlich. Oder auf deine Wunschkonfiguration zugeschnitten. Fang mal damit an: http://www.st.com/content/st_com/en/about/events/upcoming-events-and-technical-seminars.html Besonders die online MOOC sind interessant und gratis. Und lies mal das PDF https://community.st.com/docs/DOC-1250-hallabspdf Oder das angehängte PDF, habe da gerade keinen Link zur Hand. Gruß, dasrotemopped.
Ralph S. schrieb: > technikus schrieb: > - Datasheet > .. steht bspw. Pinbelegung, Alternative Pins etc. drin und vor allem > die Adressen der Register OHNE deren Beschreibung > - Reference Manual > .. KEINE Pinbelegung dafür Beschreibung der einzelnen Register - und dann gibt es noch das Programming Manual. Da gibt's u.a. das Befehlssatz, Interruptcontroller, Systick und Fließkomma-Einheit. > Von daher ist also erst einmal angesagt: Sondieren, wo steht was. Das ist übrigens AUCH angesagt, wenn man mit HAL arbeitet, weil die HAL gar keine eigentliche Abstraktion bietet, sondern eher Wrapperfunktionen für die Register. Um die HAL-Funktionsparameter zu verstehen, muß man trotzdem die Manuals lesen. > Die Einstellmöglichkeiten von STM32 bringen dich am Anfang schier um, > angefangen mit der Einstellung, welcher Systemtakt herschen soll: Die HAL setzt den Takt normalerweise beim Init auf das spezifizierte Maximum (ohne sinnvolle Fehlerbehandlung bei kaputtem Quarz, fehlt einfach). Runtertakten ist dann nicht vorgesehen. Will man dynamisch je nach Betriebsmodus unterschiedliche Frequenzen, muß man das eh selber implementieren. > Sieht man in diverse Sourcen, dann erkennst du auch schnell Unterschiede > bspw. im Behandeln von GPIO-Pins (für Bitbanging): Es gibt nicht ein > Register, dass die einsen und nullen auf den Hardware-Pins abbildet. Doch, das gibt es zusätzlich auch noch, nämlich das Output Data Register (ODR). Was Du meinst, ist das Bit Set/Reset Register (BSRR). Man kann beide benutzen - mit dem BSRR spart man sich die ansonsten übliche Kette "auslesen, Bit maskieren, zurückschreiben". Dafür kann man das ODR auch auslesen, um den gegenwärtigen Zustand zu lesen, das geht beim BSRR nicht. > libopencm3 Aufgepaßt mit der Lizenz. Das ist LGPL, man muß also zwar nicht seinen eigenen Quelltext offenlegen - aber, und das wird nicht leicht, man muß das so ausliefern, daß es kein statisch gelinktes Image ist. Was das embedded heißt, ist eine riskante Grauzone, weil es IMMER ein Hexfile sein wird. Aber logisch gesehen ist das absolute Minimum, daß man es so ausliefert, daß man libopencm3 modifizieren und ein neues Hexfile linken kann. Das einzurichten wird einiges an Aufwand. Ist natürlich kein Problem, wenn man seinen eigenen Quelltext ohnehin unter irgendeiner Opensource-Lizenz beilegt. Oder wenn man gar nichts ausliefert, sondern das nur im privaten Einsatz hat. Aber man sollte sich von Anfang an überlegen, zu welchen Zwecken man das verwenden will, und ob dort langfristig Lizenzprobleme drohen. Will man sich auch für beruflichen Hintergrund in STM32 einarbeiten, ist libopencm3 wahrscheinlich eine Sackgasse.
dasrotemopped schrieb: > Ein Codegenerator in Kombination mit einer IDE ist eine > Arbeitserleichterung, so bald man verstanden hat wie es funktioniert. Nachteil: man kann dann erstmal den Code anderer Leute debuggen. Sobald man das gemacht hat, ist man auf genau diese Version dann festgenagelt, es sei denn, man will seine Änderungen dann in die nächste Version selber reinporten. Zudem wird sowas u.U. langfristig zu einem Problem, wenn nämlich der alte Codegenerator 10 Jahre danach auf einem neuen PC nicht mehr läuft, aber der Kunde noch eine klitzekleine Änderung will. Ja, sowas gibt es. Aus meiner Praxis würde ich bei längerfristigen Projekten keinerlei externe Abhängigkeiten zulassen außer dem Compiler, und den würde ich auch in genau der benutzten Version archivieren. Sofern auf dem Host beim Build irgendwelche Tools gebraucht werden (Datenkonvertierer, Checksummentools), ist das OK, wenn sie im Quelltext vorliegen, und zwar in irgendeiner etablierten Sprache, zu der es auch einen ISO-Standard gibt sowie Compiler/Interpreter, die den ausdrücklich implementieren (weil der auch 10 Jahre später noch zumindest einzustellen gehen wird). Etwa C und C++ sind da geeignet, z.B. Python hingegen nicht. Und proprietäre IDEs, die Code generieren, schon überhaupt nicht.
CMSIS bietet Makros, um den CPU Core zu konfigurieren, HAL bietet Funktionen, um die CPU Peripherie zu konfigurieren. CubeMX bietet die Möglichkeit, das alles in einer GUI zu machen und erstellt zusätzlich noch ein Projekt für die gewünschte IDE. Wer will kann natürlich das Rad neu erfinden und die Bits selbst kippen. Bei der Menge, die ein Cortex-M bietet eine abendfüllende Aufgabe. Einen 8085 / 8051, oder andere 8-Biter sind noch überschaubar, aber ab einem bestimmten Punkt wird es albern, das alles "im Kopf" zu haben. Und Einsteiger / Anfänger mit der Komplexität eines Cortex-M abzuschrecken um Ihn in die Steinzeit zu schicken ist nicht nett. Mit den bereits erwähnten Werkzeugen ist ein Cortex-M zu programmieren so einfach wie Schnecken fangen. Gruß, dasrotemopped.
>man kann dann erst mal den Code anderer Leute debuggen der selbst programmierte Code ist ja per Definition fehlerfrei >würde ich bei längerfristigen Projekten keinerlei >externe Abhängigkeiten zulassen außer dem Compiler ach komm, den Compiler kannst du doch auch noch selbst schreiben Der TO hat um Hilfe beim Einstieg gebeten, keine Branchenlösung für die Ewigkeit. Also mal kleine Brötchen backen und auf dem Teppich bleiben. Gruß, dasrotemopped.
dasrotemopped schrieb: > Und Einsteiger / Anfänger mit der Komplexität eines Cortex-M > abzuschrecken um Ihn in die Steinzeit zu schicken ist nicht nett. Der OP ist aber kein Anfänger, sondern ein Umsteiger. Ich gehe also davon aus, daß er weiß, wie man die Doku eines µC liest, und daß er auch programmiertechnisch schon fit ist. Wer das alles nicht ist und auch nicht sein will, nimmt sich eh den Arduino. Zudem ist die HAL leider nicht das, was ihr Name suggeriert, sondern es sind Wrapperfunktionen, die sehr direkt die Register abbilden. Mit anderen Worten, um zu verstehen, was die diversen Parameter denn bewirken, muß man ohnehin die o.g. Manuals trotzdem lesen. Dann kann man aber auch gleich die Register ohne den Bloat selber beschreiben. dasrotemopped schrieb: > der selbst programmierte Code ist ja per Definition fehlerfrei Es ist zumindest wesentlich leichter nachzuvollziehen, was passiert. Die HAL ist IMO eher eine HOL - Hardware Obfuscation Layer, mit dem hauptsächlichen Zweck eines vendor-lock-in, deswegen macht ST das. Daß z.B. die Fehlerbehandlung beim Takteinstellen einfach fehlt, habe ich ja schon erwähnt - so programmiert man bei ST halt. Also ich würde mich auf so eine wackelige Quelltextbasis nicht verlassen wollen.
Angehängte Dateien:
-
RCC.png
64 KB
Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores. Und eine Fehlerbehandlung ist auch implementiert. Beschäftige dich doch erst mal mit den HAL Libs, bevor du sie schlecht findest. Gruß, dasrotemopped.
Mit dem Download der HAL Libs bekommt man für so gut wie jede verfügbare Peripherie einen Haufen Demo-Beispiele. Mit Hilfe derer kann man sich eigentlich ganz gut einen Überblick darüber verschaffen, wie man mit der HAL arbeiten kann.
dasrotemopped schrieb: > Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores. ja, aber die STM HAL macht das anders, siehe FAQ im Anhang der HAL Doku http://www.st.com/content/ccc/resource/technical/document/user_manual/2f/71/ba/b8/75/54/47/cf/DM00105879.pdf/files/DM00105879.pdf/jcr:content/translations/en.DM00105879.pdf 'How do I configure the system clock? Unlike the standard library, the system clock configuration is not performed in CMSIS drivers file (system_stm32f4xx.c) but in the main user application by calling the two main functions, HAL_RCC_OscConfig() and HAL_RCC_ClockConfig(). It can be modified in any user application section.' Insgesamt sind die UserManuals eine Lektüre für lange Winterabende, für den F4 knapp 1000 Seiten und für die F0 sogar 1300 Seiten... Diese Seite habe ich in meinen Lesezeichen, da sind einige Tutorials drin: https://stm32f4-discovery.net/2014/09/stm32f4-tutorials-one-place/ und diese ist recht beliebt: http://www.diller-technologies.de/stm32.html weiss aber gerade nicht ob die auf neuere HAL aufbaut.
dasrotemopped schrieb: > Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores. > Und eine Fehlerbehandlung ist auch implementiert. > > Beschäftige dich doch erst mal mit den HAL Libs, bevor du sie schlecht > findest. > > Gruß, > dasrotemopped. Die Aussage ist m.W. nach nicht ganz richtig (sh. auch Yiu Kapitel 14). Der Core kann entweder extern oder intern geclockt werden. Keine von beiden Sources ist von ARM spezifiziert oder vorgegeben, nur was mit dem clock Signal dann im Kernel passiert. Die CMSIS Library schreibt lediglich vor, welche Prototypen die Funktionen haben müssen, die die Chip vendors in ihrer Version der CMSIS Initialisierung zur Verfügung stellen müssen/sollen, und dass als Seiteneffekt davon eine globale Variable gesetzt werden soll (s.u.). Bei den STM Cortex Prozessoren werden dabei Register im RCC Modul im Adreßbereich 0x40000000+ manipuliert, das ist der peripherals bus. Alle vom Cortex Kern verwalteten Register liegen im PPB (Private Peripheral Bus), das ist der Adressbereich 0xe0000000+. Die CMSIS hat mit dem Core nur zum Teil zu tun, deswegen ist die Aussage "ein Teil der CMSIS, da Teil des CPU Cores" falsch (sh. https://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php). Im Submodul CMSIS_CORE (sh. http://www.keil.com/pack/doc/CMSIS/Core/html/index.html) sind die Kernel relevanten Teile dokumentiert, und das einzige, was sich hier über die clock findet, ist dies: "A variable to determine the system clock frequency which simplifies the setup the SysTick timer." Die muss von der konkreten Implementation der Sysclock_Init() Funktion gefüllt werden.
:
Bearbeitet durch User
dasrotemopped schrieb: > Clock ist bei allen Cortex-M ein Teil der CMSIS, da Teil des CPU Cores. > Und eine Fehlerbehandlung ist auch implementiert. Nein, ist sie nicht. Der Interrupt tut ja nichts Sinnvolles. Es wäre vermutlich rocket science für ST, wenn man bei versagendem HSE die PLL-Faktoren passend umskaliert, die PLL dann auf den HSI umschaltet und die Funktion einen entsprechenden Fehlercode zurückgibt.
Leute, bevor ihr euch und ST zerfleischt, bedenkt das der TE nur spielen will. Siehe Beitrag Beitrag "stm32cube darstellungsprobleme"
Nop schrieb: > Aufgepaßt mit der Lizenz. ... - aber, und das wird nicht leicht, man muß > das so ausliefern,... Hm, glaubst Du wirklich, dass das für den TE ein Problem ist? technikus schrieb: > Hobby Einsteiger Vielleicht ist Open Source da geradezu ideal.
:
Bearbeitet durch User
Da wartet wieder jemand um mit dem erhobenen Zeigefinger herein zu grätschen :-) Irgendwas hatte in diesem Thread doch gefehlt...
Hallo? Und wenn das Thema interssant ist, unabhängig davon ob der TE es ernst meinte oder nicht?
W.S. schrieb: > Leute - Hört auf! Der TO hat sich von dannen geschlichen. > > W.S. Ne, ich bin noch da ;) Vielen Dank für die zahlreichen Antworten! Nur Spielen möchte ich nicht. Eher etwas dazu lernen und meine neuen Hobbyprojekte auf STM32 Basis umsetzen. Wie schon richtig bemerkt ist der Einstieg ziemlich hart. Ich habe hier ein STm32F051 Discovery und Cube MX sowie Visual GDB Installiert. LED Anschalten klappt, RS232 auch, allerdings scheitert es hier schon den Empfangspuffer nicht "hintenrum" zu löschen. Jetzt wollte ich mal Timer nutzen, hierzu habe ich folgendes Tutoriel als Grundlage genutzt http://www.diller-technologies.de/stm32.html Ich wollte mich da durch arbeiten und die Beispiele auf die HAL lib portieren - Pustekuchen - ich finde keinen Zugang. Dazu dann diese Dokument http://www.st.com/content/ccc/resource/technical/document/user_manual/2f/77/25/0f/5c/38/48/80/DM00122015.pdf/files/DM00122015.pdf/jcr:content/translations/en.DM00122015.pdf Allerdings fehlt reicht mir dieses PDF nicht um zu verstehen was hier abgeht. Könnt Ihr mir den Einstieg erleichtern und z.B. anhand des Timer PEM Beispiels die herangehensweise und nötige Dokumente nennen ? Danke und Gruß Daniel
Eigentlich ist die HAL recht simpel, wenn man verstanden hat wie sie funktioniert. Es gibt meist drei Möglichkeiten für Kommunikationsinterface: - Blocking/Timeout (kein Interrupt im CubeMX aktivieren) - Interrupt getrieben (Interrupt immer im CubeMX aktivieren, sonst klappt es nicht - DMA Transfer (DMA Interrupt + !Periferie-Interrupt! aktivieren) Dann kanns eigentlich schon los gehen. Alles per CubeMX anschalten. Anschließen mal fix auf eine I2C EEPROM schreiben? HAL_I2C_Mem_Write_DMA(...) Einfach geht es bald nicht. Ich war am Anfang auch sehr negativ eingestellt. Mittlerweile gefällt mir die HAL und die StdPer gehört zum alten Eisen. Achtung: Man kommt NIE damit aus, nicht in den CubeMX Codebereich einzugreifen (z.B. wegen kleiner Bugs). Also versucht erst gar nicht zu wiederstehen. Zwei Optionen: 1. Projekt nur ein mal mit CubeMX generieren -> Erweiterungen notfalls selbst hinzufügen 2. Mit CubeMX (möglchst selten) euer Projekt "überspielen" und eure Anpassungen über ein git reset vor den ungewollten Änderungen des CubeMX schützen. IMO kommt man so sehr schnell recht weit! Ohne Controller- und Programmiererfahrungen natürlich am Anfang (wie immer) ein Kampf... Aber die Leute die für die komplexesten Prozessoren immer alles selbst neu schreiben haben viel Zeit für ihr Hobby oder keinen Chef... Besonders witzig, wenn die dann noch behaupten fehlerfreien Quellcode zu schreiben... nicht wie der Quellcode der durch die gesamte Community getestet wird ;) VG Basti
Basti schrieb: > Aber die Leute die für die komplexesten Prozessoren immer alles selbst > neu schreiben haben viel Zeit für ihr Hobby oder keinen Chef... Deswegen mache ich doch solche Hobby-Projekte, eben weil es keine Deadlines gibt. Da kann ich mich dann auch in der Tiefe und in aller Ruhe mit der Controller-Doku befassen. Der Lerneffekt ist meiner Meinung nach beim harten Weg am höchsten. Ist natürlich etwas anderes, wenn man nicht lernen will, sondern schnell mal eben etwas umsetzen will, aber das wird vom Arduino-Ökosystem schon ganz gut abgedeckt. > Besonders witzig, wenn die dann noch behaupten fehlerfreien Quellcode zu > schreiben... Opensource variiert auch sehr stark zwischen professioneller Entwicklung und "bei mir läuft's doch"-Dreck. Zumal bei Opensource oftmals die Doku grottig ist, weil es mehr Spaß macht, etwas Halbgares zusammenzuhacken, als es zu dokumentieren. Das Ergebnis ist, daß es mich bei kleineren Sachen weniger Zeit kostet, es gleich selber zu machen. > nicht wie der Quellcode der durch die gesamte Community > getestet wird ;) Klar, das vier-Augen-Prinzip. So wie bei Heartbleed. Weil sich alle darauf verlassen, daß irgendwer anders ganz bestimmt einen Blick auf das Gefrickel geworfen haben wird. Oder zumindest getestet haben wird.
technikus schrieb: > Nur Spielen möchte ich nicht. Eher etwas dazu lernen und meine neuen > Hobbyprojekte auf STM32 Basis umsetzen. OK, ist doch ein Wort! Aber zum Dazulernen solltest du dich nicht auf zusätzlichen Krempel wie ST-Lib, HAL, Cube und dergleichen verlassen. Bedenke mal, daß all dies eben NICHT dazu gedacht ist, die ganze Sache zu vereinfachen oder gar den Horizont des angehenden Programmierers zu erweitern, sondern es ist dazu gedacht, die Kunden an das eigene Portfolio zu binden. Vergiß das NIE. Ansonsten ist die Cortex-Welt nicht wirklich schwieriger als das, was du bereits kennst. Es ist etwas mehr an jeder Stelle, jaja, aber dafür gibt's auch ne dickere Dokumentation - und die ist bei ST nicht schlecht. Nebenbei gesagt, sind auch die LPC von NXP und deren Doku nicht schlecht. Du brauchst definitiv KEIN "Tutorial im Netz das die HAL beschreibt", denn das Wesentliche darüber, wie die Hardware funktioniert, steht im Referenzmanual - und die sogenannte HAL ist definitiv eben keine HAL, aber das ist dir weiter oben schon mal gesagt worden. Also konzentriere dich auf einen konkreten Chip und dessen Dokumentation und nicht auf zusätzliches Software-Geschwurbel. Wenn es denn schon ein STM32 sein soll, dann schau dir eher die STM32F30x als alle anderen für den Anfang an. Die STM32F30x haben nämlich eine angenehmere Art, die Funktionalität der Port-Pins einzustellen als z.B. die STM32F1xx und das hilft am Anfang. W.S.
@ W.S. Ist es wirklich Nötig das Du bei so ziemliche jedem Beitrag, in dem HAL auch nur erwähnt wird, deiner HAL Phobie freien Lauf lassen musst? Lass die Leute doch einfach mal machen. Einer mag das Konzept, ein anderer eben nicht!
Abgesehen davon ist es egal ob man die hal verwendet oder nicht. In beiden Fällen ist man von der Peripherie des Herstellers abhängig. Ohne Code Modifikation portiert man das sowieso nicht. Dann bleibe ich lieber bei der fertigen "hal" und mache mir das Leben einfacher. Zudem kann ich zwischen den stm32 Controllern einfacher migrieren. Und wenn man es portabel haben will kommt man in beiden Fällen nicht um eine zusätzliche Abstraktionsschicht herum. Seit lto ist Performance auch kein Argument mehr. Der einzige Nachteil meiner Meinung ist die miese Dokumentation.
W.S. schrieb: > Bedenke mal, daß all dies > eben NICHT dazu gedacht ist, die ganze Sache zu vereinfachen oder gar > den Horizont des angehenden Programmierers zu erweitern, sondern es ist > dazu gedacht, die Kunden an das eigene Portfolio zu binden. Das ist deine Interpretation. Im User Manual gibt es eine FAQ mit der Frage 'Why should I use the HAL drivers?' und einigen schlüssigen Argumenten. Natürlich steht da Kundenbindung nicht mit drin, aber ST hätte ein mieses Marketing wenn sie nichts für Kundenbindung tun würden. Viele haben mit dem AVR Studio angefangen und es lieferte genau das was der Hobbyist für den Einstieg haben wollte, auch wenn es nur für Atmel µC taugte. Da der Wettbewerb bei den Cortex-M sehr groß ist reicht es nicht mehr ein Eval Board in die Menge zu werfen. Was ST da kostenlos anbietet finde ich schon sehr bemerkenswert und andere versuchen auch da etwas ähnliches gegen zu setzen, früher hat man für solche Tools und Libraries locker 5-stellige Beträge bezahlt. Das ST da soviel Druck macht gefällt sich nicht allen, aber der Plan geht doch auf. Dem Hobbyisten ist es egal das die HAL nur für STM32 zu nutzen ist, mit der Riesenauswahl von F0 - F∞ ist für Bastelprojekte doch alles abgedeckt und dazu wesentlich leistungsfähiger als alles was man in der ATtiny/Atmega Schiene hatte. Trotzdem nutze auch ich lieber die LPC von NXP und das mit der mbed lib. Damit ist nämlich die Tür für STM32 genauso offen wie für alle anderen Cortex-M Anbieter. Und ein PWM Ausgang wird zum 3 Zeiler, unabhängig von NXP, ST, Atmel uvm:
1 | PwmOut mypwm(PWM_OUT); |
2 | |
3 | mypwm.period_ms(10); |
4 | mypwm.pulsewidth_ms(1); |
Die HAL abstrahiert schon einiges und man muss nicht jedes Register kennen und z.B. ein I2C/SPI read/write wird auch sehr einfach, aber gerade für PWM muss man GPIO, Timer Clock und Timer Match konfigurieren, das sind schon drei Kapitel die man zusammensuchen muss.
hp-freund schrieb: > Ist es wirklich Nötig das Du bei so ziemliche jedem Beitrag, in dem HAL > auch nur erwähnt wird, deiner HAL Phobie freien Lauf lassen musst? Ja, das ist aus hygienischen Gründen EXTREM notwendig. Du siehst es ja in diesem Forum an jeder Ecke: Da kommen Neulinge von AVR oder von nirgendwo und suchen zu allererst einmal irgend eine Orientierung - und was wird ihnen von allen möglichen Leuten zu allererst empfohlen? Eben genau DAS, was den tatsächlichen Einstieg in die Materie zunächst erstmal gründlichst verschwurbelt. Mir ist schon klar, daß man als Neuling zuerst denkt, "oh, ich weiß ja noch so wenig, da laß ich mir erstmal von Erfahrerenen sagen, wo es lang geht". Bloß die "Erfahrenen", die keinen Fuß auf den Teppich kriegen, sondern allzeit sich in XY_InitStructur.abcdef ergehen, die einen UART nicht selbst benutzen können und nicht mal ein Portpin ohne Hersteller-Bibliothek aufsetzen können, sind wahrlich KEINE echte Hilfe, sondern sie steuern jeden Neuling gnadenlos in eine Ecke, wo er nicht mehr rauskommt. Ich rate deshalb jedem Neuling dazu, sich auf den Chip und dessen Primär-Literatur zu konzentrieren und all den Sekundär- und Tertiär-Kram beiseite zu lassen. Sowas kann man bei Bedarf später mal inspizieren, wenn man selber schon sattelfest ist. Aber eben NICHT zum Anfang. Ein Gleiches gilt übrigens auch für das Thema IDE. Zu allererst sollte ein Jeder lernen, seine Tools selber aufzurufen und zu benutzen. Wenn man das kann und weiß, was ab geht, dann kann man auch ne IDE benutzen - wohlgemerkt dann, wenn man nicht auf selbige angewiesen ist, sondern selber laufen gelernt hat. W.S.
ich kann auch nicht verstehen wie jemand das Gefühl haben kann mit der HAL geht es besser und einfacher. Das können eigentlich nur die behaupten die das ausschließlich machen. Jeder der beides durch hat, weiß dass es außer zusätzlichen Aufwand nichts bringt. Oder man ist wirklich so benebelt im Kopf, dass man z.B. DMA benutzt ohne das Refmanual gelesen zu haben. Und wenn ich das gelesen habe, interpretiere ich das dann auf schlecht kommentierte HAL Routinen? Dümmer gehts nimmer... Spätestens wenn man dann bei der Fehlersuche auf die Registerebene abtauchen muss nützt einem der zusätzliche Brei überhaupt nichts.
Hi kennst du diesen kurs? fand ich sehr hilfreich! https://st-mooc.udemy.com/?next=%2Forganization%2Fdiscovery%2Fbrowse%2Fstmicroelectronics-learning-portal%2F4031580%2F%3Fpage%3D1 technikus schrieb: > Hi, > > ich würde gerne von AVR´s auf STM32 umsteigen. > Da die Standard Lib durch HAL abgelöst wurde, würde ich gerne direkt mit > der HAL einsteigen. > Leider finde ich kein Tutorial im Netz das die HAL beschreibt - was es > mir als Hobby Einsteiger sehr schwer macht. > > Habt Ihr eine Quelle zum Einstieg parat? > > Danke und Gruß > technikus
hp-freund schrieb: > Ist es wirklich Nötig das Du bei so ziemliche jedem Beitrag, in dem HAL > auch nur erwähnt wird, deiner HAL Phobie freien Lauf lassen musst? Komischerweise beschwerst Du Dich nicht über die wiederholten positiven Beiträge zur HAL. > Einer mag das Konzept, ein anderer eben nicht! Eben, und genau das sollten Anfänger auch wissen. Deswegen gehören AUCH Postings wie das von u.a. W.S. in jeden Thread, den ein Anfänger dazu aufmacht. Was Du sichtlich gerne hättest, wäre die Vermittlung des (falschen!) Eindrucks, daß es allgemein üblich sei, mit der HAL zu arbeiten. Du möchtest das erreichen, indem nur die Fans posten sollen und die Kritiker bitteschön irgendwann mal die Klappe halten sollen.
Nop schrieb: > Deswegen gehören AUCH > Postings wie das von u.a. W.S. in jeden Thread, den ein Anfänger Ich hätte auch gerne so eine Kristallkugel wie W.S. Jeden Fremden den man nie gesehen hat und dessen Skills man nicht kennt, gleich als Anfänger der auf dem Holzweg ist zu erkennen, finde ich schon enorm. Der HAL ist low level und da setzen weitere Libs und Middleware auf, das ist auch ein Grund so etwas nutzen zu wollen. Nur um einen IO Pin wackeln zu lassen braucht man das nicht, aber das ist ja schliesslich nicht alles was der HAL bietet. Aufbauend kann man RTOS, Speicherkarten, Grafik uvm nutzen und da fängt es an spannend zu werden. Und freundlicherweise ist das alles Quelloffen und man kann sich ansehen was da abgeht.
Johannes S. schrieb: > Ich hätte auch gerne so eine Kristallkugel wie W.S. Jeden Fremden den > man nie gesehen hat und dessen Skills man nicht kennt, gleich als > Anfänger der auf dem Holzweg ist zu erkennen, finde ich schon enorm. Ich hätte auch gerne so eine Kristallkugel wie die HAL-Fans. Jeden Fremden, den man noch nie gesehen hat und dessen Skills man nicht kennt, gleich als planlosen, lernunfähigen und doku-allergischen Anfänger zu erkennen, finde ich schon enorm. Zumal er dann auch gleich Arduino hätte nehmen können. > Der HAL ist low level und da setzen weitere Libs und Middleware auf, das > ist auch ein Grund so etwas nutzen zu wollen. Klingt nach einem Cluster-Vendor-Lock-In. Es gibt genug RTOS, mit denen man sich das nicht ans Bein bindet, schon weil sie älter als SPL und HAL sind. Das kann ST später dann Möglichkeiten wie die geschickte Abkündigung bestimmter Chips ermöglichen (TI hat sowas schon gemacht), so daß Kunden zähneknirschend auf die teureren Varianten umsteigen müssen. Obwohl, angesichts des Bloats müssen sie das ja im Grunde schon von Anfang an machen. Deswegen ist Software von einem Hardwarehersteller meistens ein Danaergeschenk, weil der Interessenkonflikt zwischen hersteller und Käufer immer zulasten des Käufers gehen wird. Das Problem hat man nicht, wenn man sich eine wirkliche HAL schreibt. Also nicht nur den umständlichen Register-in-structs-Mapper wie bei ST. Dann braucht die Applikationsschicht nämlich gar nicht mehr zu wissen, auf welchem Chip sie läuft. Schnelle Dinge wie IO-Pins realisiert man natürlich per Macro. Als Hobbyist ist STs Ansatz jedenfalls zum Lernen auch nicht so toll, weil man damit nichts Wirkliches lernt, sondern nur irgendwelche Structs zu befüllen. Die resultierenden Anfängerfragen hier sind ja auch dementsprechend. Außerdem ist sowas vollkommen wertlos, wenn man dann irgendwann mal z.B. einen NXP-Chip nutzen will.
Genau das meine ich. Da stellt jemand einen einfache Frage, in diesem Fall zu HAL. Als Folge gibt es Seitenweise Diskussionen darüber ob man das besser lassen sollte oder nicht. Ob man zu dumm sei mal schnell mehrere tausend Seiten Datenblätter und RM zu lesen. Wenn dann noch etwas unklar ist, könne man noch mal nachfragen. In ein paar Monaten oder so. Es gibt sicher viele die alles ganz genau wissen wollen und für die es besser ist auf Registerebene anzufangen, aber vielleicht will ja jemand einfach nur etwas nachbauen oder leicht für seine Bedürfnisse anpassen. Ich denke/hoffe wer Fragen wie diese hier stellt hat nicht beruflich damit zu tun. Zu 8 bit Zeiten war das einfach mal überschaubarer und somit leicht nachvollziehbar. Bei ARM kann man auf verschiedene Arten an die Sache heran gehen. Darum meine Meinung - und damit ist das Thema für mich auch durch: Lasst doch jedem seine Entscheidung, wie er an die Programmierung heran gehen möchte, bzw. ob es überhaupt sein Ding ist. Ende.
H. R. schrieb: > Hi > kennst du diesen kurs? > fand ich sehr hilfreich! > > https://st-mooc.udemy.com/?next=%2Forganization%2Fdiscovery%2Fbrowse%2Fstmicroelectronics-learning-portal%2F4031580%2F%3Fpage%3D1 Danke für den Tipp! Leider kann ich mich dort nicht registrieren weil ich "nicht eingeladen wurde" Wie komme ich da dran?
hp-freund schrieb: > Da stellt jemand einen einfache Frage, in diesem Fall zu HAL. > > Als Folge gibt es Seitenweise Diskussionen darüber ob man das besser > lassen sollte oder nicht. Ob man zu dumm sei mal schnell mehrere tausend > Seiten Datenblätter und RM zu lesen. Wenn dann noch etwas unklar ist, > könne man noch mal nachfragen. In ein paar Monaten oder so. > ... Amen! Ähnlich wie früher, bevor es Arduino gab, die Bascom Diskussionen. Ich suche IMMER NOCH ein gutes HAL basiertes STM32 Tutorial in englischer oder deutscher Sprache ;) Danke
hp-freund schrieb: > Da stellt jemand einen einfache Frage Falls Du es noch nicht mitbekommen hast: das läuft hier immer so, und das ist auch gut so. Beispielsweise bei Programmierfragen wird auch nicht nur genau das geantwortet, was der Fragesteller gefragt hatte, sondern es wird oftmals auch der ganze Ansatz schon auseinandergenommen, wenn er nicht so dolle ist. Das ist ein Feature dieses Forums. Und nur, weil Du in die HAL so verknallt bist, daß es Dir den Tag verdirbt, sobald jemand das nicht so dolle findet, ist das kein Grund, durch Schweigen diesen Mist auch noch zu promoten.
technikus schrieb: > Ich suche IMMER NOCH ein gutes HAL basiertes STM32 Tutorial in > englischer oder deutscher Sprache ;) Lies Dir das reference manual durch, dann wird offensichtlich, welcher Parameter in den structs was bedeutet. Wie, das ist Arbeit? Naja was, es abstrahiert die Hardware (dem Namen zum Trotze) ja eben gerade NICHT. Es wäre auch sinnfrei, dafür nochmal abgeleitete Doku zu schreiben, die man dann parallel pflegen müßte, die aber auch nicht mehr Information enthält. Ansonsten, die Inits für die Clockpfade sollten ja schon automatisch generiert werden, also welche Peripherals und Busse für welchen Zweck geclockt werden müssen.
Habe mir die neuen HAL / STM32F0Cube Sachen mal angeschaut. Also das ganze ist schon sehr umfangreich und ich finde es für einen Anfänger (auch Umsteiger von AVR) relativ verwirrend. Vor lauter includes, defines etc. blickt man kaum noch durch, selbst bei einem einfachen I/O-Toggle Beispiel. Wie auch immer, wenn Du HAL machen willst, findest Du eigentlich alles in: - Latest release of STM32CubeF0 firmware package - Getting started with the STM32CubeF0 firmware package for STM32F0 Series (UM1779) - Description of STM32F0xx HAL drivers (UM1785)
:
Bearbeitet durch User
Nop schrieb: > Lies Dir das reference manual durch, dann wird offensichtlich, welcher > Parameter in den structs was bedeutet. Wie, das ist Arbeit? Das ist geil hier! Wer hat denn gesagt das ich nicht arbeiten will??? Da ich zunächst von der Fülle aller Informationen erschlagen war, habe ich hier den Thread angestoßen. Aber Ihr habt mich überzeugt! Der erste Blick geht jetzt immer über das reference manual. Nichts desto trotz mach ein HAL Tutorial doch Sinn und ich gebe nicht auf. Auch wenn ich mir gerade aus den Erkenntnissen selbst eins schreibe. Mir geht es um die Interpretation der Funktionen. Ein gutes Beispiel ist ein per Cube erstelltes Projekt mit Interrupt gesteuertem UART. Beitrag "Verständnisfrage stm32 uart" HAL_UART_Receive_IT(&UartHandle, rx_data, 10); Füllt fleißig den Puffer bis 10 Bytes empfangen wurden und beginnt dann wieder von vorne - alles Interrupt gesteuert. Was ist aber, wenn ich in der Hauptschleife auslese ob schon was da ist und dann den Startzeiger vom Puffer neu initialisieren möchte? Qick and dirty kriege ich das hin, geht aber irgendwie am HAL Gedanken vorbei... Gruß
Zusammengefasst: Man muss einzelne fertige Funktionen schon "begreifen" um sie sinnvoll nutzen zu können. O.k. ich beschäftige mich erst wenige Stunden mit den STM32. Wie geht Ihr daran und welche Dokus nutzt ihr hierfür?
technikus schrieb: > Mir geht es um die Interpretation der Funktionen. Ein gutes Beispiel ist > ein per Cube erstelltes Projekt mit Interrupt gesteuertem UART. > > Beitrag "Verständnisfrage stm32 uart" eine Antwort habe ich in den genannten Thread geschrieben.
Dieser udemy.com link funktioniert bei mir auch nicht, das ist scheinbar eine Site mit kostenpflichtigen Inhalten oder der Kurs ist nicht mehr verfügbar. Es gibt aber noch ein Dokument (für die F0 Serie z.B.) https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef0.html Da ist als letztes ein Link zum Firmware Package das in UM1779 beschrieben ist. In dem Paket sind eine Menge Beispiele, auch zu PWM und UART. Kann sein das dieser Link nur nach Registrierung bei ST zu öffnen ist.
technikus schrieb: > Nichts desto trotz mach ein HAL Tutorial doch Sinn und ich gebe nicht > auf. > Auch wenn ich mir gerade aus den Erkenntnissen selbst eins schreibe. > > Mir geht es um die Interpretation der Funktionen. Ein gutes Beispiel ist > ein per Cube erstelltes Projekt mit Interrupt gesteuertem UART. > > Beitrag "Verständnisfrage stm32 uart" > > HAL_UART_Receive_IT(&UartHandle, rx_data, 10); > > Füllt fleißig den Puffer bis 10 Bytes empfangen wurden und beginnt dann > wieder von vorne - alles Interrupt gesteuert. > > Was ist aber, wenn ich in der Hauptschleife auslese ob schon was da ist > und dann den Startzeiger vom Puffer neu initialisieren möchte? > Qick and dirty kriege ich das hin, geht aber irgendwie am HAL Gedanken > vorbei... Siehst du, so ist es, wenn man mit Fleiß einem im Grunde falsch angelegtem Konzept nachgeht. Zumindest sind dir schon jetzt die ersten Ungereimtheiten aufgefallen. Ich sag's mal so: Hier kommen immer wieder Leute mit Problemen an, die etwa so lauten: "Ich will mit dem Kopf durch die Wand. Jetzt bin ich schon 100 mal dagegen gesprungen, aber es funktioniert nicht und ich hole mir nur jedesmal ne Beule. Was soll ich bloß tun?" - und da kommt unsereiner und sagt demjenigen: "Laß das Springen gegen die Wand lieber komplett bleiben, das ist definitiv der falsche Weg. Geh lieber einen Schritt zur Seite, dort ist eine Tür, die kannst du aufmachen und einfach durchgehen - ohne dir ne Beule zu holen". Zu deinem UART-Beispiel: Sowas braucht einen Lowlevel-Treiber, der die zugrundeliegende HW kapselt und damit abstrahiert. Das zitierte "HAL_UART_Receive_IT(&UartHandle, rx_data, 10);" sieht mir jedoch überhaupt nicht danach aus. Ich gebe dir mal ein Gegenbeispiel im Anhang. Schau dir zuerst die "serial.h" darin an. Dann weißt du, wie eine tatsächliche HAL funktioniert. Das übergeordnete Programm wird nicht mit irgendwelchen treiberinternen Details belästigt, in der Headerdatei steht nur genau das drin, was zum Benutzen des seriellen Ports vonnöten ist. Der Treiber puffert beide Datenströme und das übergeordnete Programm kann eben ASYNCHRON und zeichenweise (so wie die Bezeichnung "UART" es suggeriert) senden und empfangen und braucht selbstverständlich nicht auf Sendeabschluß zu warten oder vorher bekannte Anzahl von zu empfangenden Zeichen oder sonstwelche schrottige und unüberlegte Beschränkungen zu beachten. W.S.
>Ich gebe dir mal ein Gegenbeispiel im Anhang. >Schau dir zuerst die "serial.h" darin an. Habe ich gemacht. Gefällt mir nicht. Bleibe doch bei CubeMX. Kann aber damit leben, das andere es anders machen als ich. "jedem tierchen sein pläsierchen" sagt man hier. >Siehst du, so ist es, wenn man mit Fleiß einem im Grunde >falsch angelegtem Konzept nachgeht. Ich kann nur feststellen, das ST keinen Alleingang mit der Struktur der HAL macht. Und wenn man das zugrundeliegende Konzept kennt, erkennt man es in anderen herstellerspezifischen Libs wieder. Aber die Wahl der Adjektive bei der Bewertung der verschiedenen Möglichkeiten macht klar, das es hier nicht um eine rationale Diskussion geht. Gruß, dasrotemopped.
Vielleicht kann ich hier ein paar Gedanken beisteuern, wie ich als Hobbyist den Übergang von PSoC zu STM32F7 ziemlich schnell geschafft habe. Es gibt nämlich eine Anleitung nebst Bibliothek und Beispielen von Uwe Becker, die man hier findet: http://mikrocontroller.bplaced.net/wordpress/ Als IDE verwende ich Eclipse in der Version von SW4STM32 von dieser Quelle: http://www.openstm32.org/HomePage Ich habe als konkretes Ziel ein User- Interface für ein Funkgerät mit Red Pitaya als Transceiver und STM32F7Disco als Anzeige- und Bedieneinheit. Der gegenwärtige Stand ist hier zu sehen: http://www.wkiefer.de/x28/Red%20Pitaya.htm Ohne die Vorarbeit von Uwe Becker wäre ich längst noch nicht auf diesem Stand... Deshalb mein Dank an ihn.
technikus schrieb: > Wie geht Ihr daran Stückweise, vom Einfachen zum Schwierigen. Erstmal die jeweilige Toolchain ans Laufen kriegen bis dahin, daß von irgendeinem Simpel-Projekt im Netz, das zu meinem Board paßt, ein Hexfile generiert wird. Dabei prüfe ich dann zumindest Stackpointer und Resetvektor (also den Anfang des Hexfiles) gegen das Mapfile, ob das hinkommt. Kleine Falle - der Resetvektor im Hexfile ist um genau 1 höher als die Adresse aus dem Mapfile, was für den Thumb-Mode der STM32 aber genau richtig ist. Dann das Interface mit dem Programmer, also zumindest ein Verify muß laufen, damit ich sehe, daß er eine Verbindung kriegt. Die Überprüfung scheitert natürlich, weil ich noch nichts eingespielt habe, aber das ist erstmal egal. Dann einspielen des Simpel-Projektes, optimalerweise einfach ein Blinky. Wenn das geht, bin ich schonmal sehr zufrieden, denn die Toolchain funktioniert. > und welche Dokus nutzt ihr hierfür? Danach kommt das Reference Manual (manchmal auch das Programming Manual). Ich lese mir die Beschreibung von den Dingen durch, die ich nutzen will, um erstmal ein Gefühl dafür zu kriegen, wie das funktionieren soll. Da steht oftmals auch drin, was an Randbedingungen zu beachten ist. Beispielsweise die PLL-Einstellung hat noch Anforderungen an die Zwischenfrequenzen, und außerdem spielen Waitstates und Voltage-Scaling auch noch eine Rolle. Da ich Applikationen ohnehin schichtenmäßig baue, habe ich irgendeine Art von logischer Lowlevel-Abstraktion mit definiertem Interface, und nur diese Funktionalitäten hängen überhaupt von der Hardware ab, also muß ich die implementieren. Was genau ich da brauche, hängt von der Funktionalität ab. Aber die üblichen Bausteine wie IO-Debouncing, AD-Glättung, DA-Ausgabe, Datenqueues usw. sind ja Standardmuster, das kennt man. Oftmals muß man Zeugs zwischen Applikationskontext und Interruptkontext tauschen, wo man möglichst wenig Logik in den Interrupt packt, aber soviel wie nötig. Wenn das Lowlevel-Interface zu groß wird, splitte ich das auch nochmal in zwei Schichten, deren untere sich um die Sequenz der physikalischen Registerzugriffe kümmert (nach Reference Manual), und die obere um die Verwaltung der Hardware und die Kreuzeffekte zwischen den Einstellungen (z.B. CPU-Frequenz vs. Systemtimer). Allerdings lasse ich die untere Schicht auch gerne noch Makros exportieren, damit z.B. das IO-Toggling aus der oberen Schicht nicht unnötig lahm wird.
Das hier ist übrigens auch ganz nett für den ersten Einstieg: http://letanphuc.net/2015/06/stm32f0-timer-tutorial-and-counter-tutorial/ Bei mir läuft jetzt, dank euerer Hilfe: - Timer Interrupt - PWM - UART
Also der CUBEMX + STM32 HAL kurs ist kostenlos. UDEMY ist ein kommerzieller anbieter, aber ST stellt es frei zur Verfügung. Kann ich dir sehr empfehlen. Hier kannst du dich wie gesagt for free anmelden: https://my.st.com/content/my_st_com/en/events/registration-for-stm32cube-basics--online-course-with-hands-on-e.html Wenn ich mich anmelde sehe ich 4 verschieden Kurse, Alls ganz interessant
:
Bearbeitet durch User
Ich war damals (2013?) auch bei einem kostenlosen ST-Seminar zur Einführung in die STM32-Reihe in Dortmund. Das war ganz nett, STM32F0-Discovery gab es kostenlos, Essen auch, dazu natürlich etwas Werbung der bekannten Distributoren. Zumindest gewinnt man so einen guten ersten Überblick über die Reihe. Und aus dem Seminar habe ich zwei sehr wertvolle Kontakte mitgenommen, davon einen direkt bei ST, falls es mal brennt. Alleine deswegen hat sich das schon gelohnt. Zur Frage des OP: Ich sehe das alles (HAL oder selbst Register füllen) nicht so kritisch. Ich hab damals mit der STLib begonnen und wirklich schlecht fand ich sie nicht. Man hat schnell ein Erfolgserlebnis, weil im Netz fast überall dieser Code verwendet wird. Sehr hilfreich waren/sind die Kommentare in den einzelnen Quelldateien der Peripheriemodule (bspw. stm32f0xx_dma.c) gewesen, das sollte man sich unbedingt ansehen. Da hat man eine kurze Zusammenfassung dessen, was man zum Einsatz benötigt. Das kann ich jedem Anfänger wärmstens empfehlen. Mittlerweile sind wir von der STLib weg und schreiben direkt in die Register bzw. über eine eigene HAL. Aber zum ersten Reinschnuppern und schauen, was man an konkreten Registern überhaupt benötigt, finde ich den Quellcode nicht schlecht. Das Reference Manual ist ja doch für Einsteiger abschreckend groß.
Hallo, ich buddel den mal wieder aus ..... bisher bin ichn mit meinen StdPeriphLibs ja recht glücklich im Hobbybereich. Das Moped fährt dahin wo es hin soll nachdem ich es zusammen geschraubt habe. Habe da ja auch keinen Zwang auf Teufel komm raus was Neues erfinden zu müssen. Aber mehr und mehr erscheinen Codes mit dieser "HAL" und dieses ominöse Case Tool CubeMX wird erwähnt. Case Tools gab es schon Ende der 90iger, setzten sich nie wirklich durch. EmBitz wird nicht unterstützt, EmWin auch nicht und natürlich auch kein CooCox. Kostet ja nix, verdient keiner was dran. Ist hier jemand mit diesem CubeMX glücklich geworden? Odrer dient das nur dazu den Überblick zu kriegen wie was funktioniert, damit man es später selbst umgeschrieben und angepasst verwendet? Gruss, Christian
Christian J. schrieb: > Ist hier jemand mit diesem CubeMX glücklich geworden? Ja. Zusammen mit SW4STM32 läuft das prima. Ohne Begrenzung und ohne Kosten.
Jaaaa, die Ökosysteme sind sind ca. 3 Jahren das ganz heisse Ding in Herstellerkreisen. Jeder Hersteller bringt sein eigenes Ökosystem auf den Markt oder bundled Drittherstellerkomponenten zu dem "one stop shopping ultrafast time to market don't worry about the details" Entwicklungserlebnis. Faszinierenderweise fast immer umsonst, äh kostenfrei... Aber natürlich gibt es nichts umsonst auf der Welt. Das Geschäftsmodell ist natürlich vendor lock in und die Hoffnung, genügend Leute mit soviel Erfahrung in "meinem" Ökosystem auszustatten, dass die kostenpflichtige Version davon dann auch dort zum Einsatz kommt, wo Geld fliessen darf. Ist auch erstmal nichts dagegen zu sagen. Irgendwie muss sich ja die Arbeit, die man darein gesteckt hat, rentieren. Mit Software Geld zu machen ist heutzutage nicht einfach. Blöd wird's wirklich nur da, wo aus politischen Gründen mehrere dieser Ökosysteme miteinander in Konkurrenz stehen. ARM z.B. pusht sehr aggressiv ihr CMSIS 2 und will es zum universellen Standard erklären - was natürlich kein Chiphersteller gern sieht, weil damit sein Alleinstellungsmerkmal verloren geht und im Super GAU Fall (aus Herstellersicht; von ARM aus gesehen das Paradies) alle ARM Chips sofotwaremässig komplett austauschbar sind. Codebasen, in denen CMSIS und vendorspezifische HALs gemeinsam benutzt werden müssen (weil z.B. die eine genutzte Middleware auf CMSIS aufsetzt und die andere auf ST HAL), sind irgendwann so dermassen mit Abstraktionslayern und wrappers aufgebläht, dass die Les- und Wartbarkeit des Codes enorm darunter leidet, vom Blähfaktor mal ganz zu schweigen. Wer mal versucht hat, irgendein Codebeispiel vom Kinetis SDK auf Minimum zu strippen, wird irgendwann mal die 27 OS wrappers alle in die Tonne schmeissen, dann wird es einfacher, back to the roots zu gehen.
Christian J. schrieb: > EmBitz wird nicht unterstützt, EmWin auch nicht und natürlich auch kein > CooCox. Such mal nach CubeMX2Makefile, das ist ein simples Pythonskript.
Es geht mit EmBitz. Allerdings muss man manuell einige Sachen machen: Erstmal das Projekt im EmBitz anlegen, dann alles bis auf die .ld und .s Files löschen. Dann den von CubeMX generierten Kram in das Projektverzeichnis kopieren und die Files (rekursiv) dem Projekt hinzufügen. Alles sehr unschön leider. EDIT: Evtl. hilft auch das hier, kommt mir aber etwas verworren vor: https://www.embitz.org/forum/thread-670.html
:
Bearbeitet durch User
Hallo, mir geht es da wie beim Arduino 1.0.5 und beim PIC mit CCS. ich habe mir da eine funktionierende Umgebung zusammen gestrickt, etliche Chips per Hand eingefpflegt in die Scripte, kann einen Attiny84 programmieren usw. Und auf einmal kommt was Neues raus, inkompatibel natürlich, andere Config Files. Und man fängt von vorne an oder blibt bei dem was man hat. So ist es mit dem ARM dran oder ARM ab auch: Mit der SPL fahre ich gut, kann sie anwenden und die letzte Version ist auch recht fehlerfrei. Im Hobbybereich wohlgemerkt! EmBitz 1.1 hat alles was man braucht, außer einen Code Analyzer und auch keine Runtime Analyse. Aber Debugger, gelben Balken, Watch Fenster mit Live Updates und alles besser als eine rote LED, die man als Debugger verwendet. Schätze mal ich friere das auch auf dem Stand ein, alter Hase (48) muss keine neuen Tricks mehr lernen..... Christian
Thread beobachten
Seitenaufteilung abschaltenBitte 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.