Servus, ich bin, was uC anbelangt, ein absoluter noob, die Frage könnte daher auch unsinnig/lächerlich/falsch_gestellt oder dergl. sein. Ich bitte das im Voraus zu entschuldigen. Ich hab ein nucleo64-f411re board und möchte damit einen Modellbau-Servo ansteuern. Ich hab gelernt, dass man das mittels PWM macht. Entscheidend ist offenbar, dass man dazu kommt, period und duty-cycle korrekt einzustellen. Voraussetzung dafür ist offenbar, dass man weiß, mit welcher Frequenz die verschiedenen Timer im Ausgangszustand takten, damit mann dann den prescaler setzen kann usw. Ich hab schon im Reference_Manual nachgeschaut und auch sonst schon ein wenig „gegoogelt“, hab aber nirgends eine Stelle gefunden, der ich den „Basistakt“ entnehmen kann. Es gibt einen externen Quarz, der wohl 8 MHz hat, der CoreSystem-Takt hat offenbar 84 MHz und die CPU scheint 100 MHz zu haben. Leider ist es mir bislang nicht gelungen, diese drei Zahlen irgendwie in ne konkrete Verbindung zu Timern und PWM zu bringen. Ich hab mir auch schon ein paar Youtube-Videos angeschaut, aber dort wird mit unterschiedlichen Werten gearbeitet und nicht erklärt, woher diese Zahlen kommen. Auch CubeMX hab ich mir schon installiert und auch drin rumgeklickt, das hat aber eher zur Verwirrung als zur Aufklärung beigetragen. Ich benutze Eclipse mit dem „mcu-plugin“. Kann mir hier bitte evtl. jemand auf die Sprünge helfen, hat jemand einen Link oder die Angabe einer Spec, in der das aufgeführt ist, oder dergl.?
Moin, du wirst deine PWM vermutlich mit einem Timer erzeugen. Dem Refercene Manual kannst du entnehmen welcher Timer an welcher Taktquelle hängt. Daraus lässt sich dann auch ableiten wie schnell dein Timer läuft. Erzeugst du dir dein Projekt mit CubeMx? Da kannst du das ein bischen leichter ablesen.
@PaSi: Nein, ich benutze kein CubeMX. Ich hab schon ein bischen drin rumgeklickt, aber es hat mehr Fragen als Antworten hinterlassen. Ausserdem hat es (zumindest) in meiner alten Version, keinen Export für meine Art von Eclipse-Installation (und ne neue Version lässt sich nichht installieren) Abgesehen davon würde ich auch lieber selber verstehen wie man den stm32f411re programmiert und nicht nur herausfinden, wie man ein tool bedient .... Ok, danke, dann werd ich im Ref-Manual mal nach Taktquellen suchen.
Hallo Wolfgang, CubeMx tut ja nichts anderes als dir den Initialisierungscode zu erzeugen. Das kann man natürlich auch selbst machen, ist am Anfang vielleicht auch ganz sinnvoll. Du könntest damit aber vielleicht nachvollziehen was für ein Takt an APBxx für deinen Timer ankommt. Verwendest du denn die HAL überhaupt oder beschränkst du dich auf Register? Gruß
Standardmäßig wird alles mit 8Mhz getaktet. Aber du kannst die Konfiguration ändern, zum Beispiel um die Kern mit 84Mhz zu takten. Ich bin zwar kein Freund von CubeMx, aber das ganze Clock System wurde dort sehr schön visualisiert. Damit kannst du herum spielen und ausprobieren, was geht. Die ganzen einstellbaren Register benennt CubeMx auch, so dass du dies danach in eigenen Code überführen kannst. Eventuell helfen Dir dabei meine Erklärungen zum STM32F1, der STM32F4 ist ja ähnlich: http://stefanfrings.de/stm32/index.html#takt
@PaSi Ich möchte mich auf Register beschränken. Ich include zwar stm32f4xx.h um die vordefinierten Konstanten(namen) verwenden zu können, aber diese Init-Structures und was es da sonst noch so gibt, benutze ich nicht. Allein die Tatsache, dass ich CubeMX nur in der Version laufen lassen kann, die ich vor zwei Jahren mal installiert habe, bestätigt mich in meinem Vorurteil, dass ich lieber selber lerne, wie es geht, anstatt mich auf tools zu verlassen. Daher benutze ich auch mbed nicht. Ich verdiene meine Brötchen seit Jahrzehnten mit Softwareentwicklung und wenn ich eines gelernt habe, ist es, dass „Frameworks“ auf den ersten Blick und kurzfristig sehr attraktiv sind, dass man sich damit aber in Abhängigkeiten begibt, die schon mittelfristg mehr Aufwand erzeugen, als den, den man gehabt hätte, wenn man sich die Grundlagen gleich selbst erarbeitet hätte. Meiner Erfahrung nach lohnt es sich durchaus, das ein oder andere Rad auch selbst nochmal zu erfinden ...... ;-)
@Stefanus F, danke für Deinen Link, das ist ja ne Menge Information. Werd ich gleich mal durchlesen und schaun, ob ich das auf mein Nucleo-Board gematched bekomme. Wenn ich bei mir in Eclipse ein leeres Projekt für nen STM32F4 anlegen lasse und mir nur die SystemCoreClock anzeigen lasse, dann sind das 84MHz. Ist das dann auch die Basis, mit der ich den Preescaler für den PWM-Timer berechne, oder geh ich da dann von den 8MHz aus (die in nem Eclipse-Dialog als externe frequenz voreingestellt ist und von der ich auch im STM32F4-Datasheet gelesen hab)?
Stefanus F. schrieb: > Standardmäßig wird alles mit 8Mhz getaktet. Das ist beim F103 so aber beim F411 läuft der interne RC-Oszi mit 16MHz. Die Cortex-M haben immer einen AHB (Advanced High-Performance Bus) und einen APB (Advanced Peripheral Bus), deren Takt generell mit HCLK (für AHB) und PCLK (für APB) bezeichnet werden. Eine grobe Übersicht findest du als "Clock Tree" auf S.90 in RM0383 aber ich gebe Stefan recht, dass das im CubeMX wirklich schön visualisiert ist. Der STM32F411 unterscheidet nochmal zwischen APB1 (low-speed) und APB2 (high-speed), wobei deren Takte jeweils aus dem HCLK über einen Teiler abgeleitet werden. APB1 ist der langsamere und beim F411 50MHz max., d.h. bei HCLK 100MHz (ebenso max. für den F411) muss der Teiler mindestens zwei sein. Ist der Teiler wiederum mindestens zwei, so werden die Timer, die am APB1 hängen doppelt so schnell wie der APB1 getaktet, d.h. für den Fall, dass der Teiler exakt zwei ist, so schnell wie die Timer des APB2. Das klingt zwar ein bisschen kompliziert ist aber in der Praxis relativ einfach, weil die Timer für gewöhnlich immer gleich schnell, nämlich mit HCLK getaktet werden. Zur Veranschaulichung hab ich dir mal zwei Screenshots angehängt. Einmal mit 96MHz mit konfigurierter PLL und einmal mit 16MHz mit HSI, d.h. wie das Teil aus dem Resetzustand kommt. Wie du siehst ist es eigentlich gar nicht wichtig ob ein Timer jetzt an APB1 oder APB2 hängt aber die meiner Meinung nach einfachste Methode ist, in den RCC_APBxENR, also den "clock enable" Registern des jeweiligen APB nachzuschauen (RM0383, S.115ff).
Im Reference Manual der STM32F4 Serie sind die relevanten Register mit ihren Default Werten aufgelistet. Dieser Angabe würde ich mehr trauen, als dem Eclipse Plugin. Auch CubeMX zeigt beim Start NICHT die Default-Konfiguration an. Ich finde das sehr irritierend.
Dein Ehrgeiz ih Ehren, aber mit CubeMX bindest du dich eben nicht an ein Framework, sondern erleichterst dir enorm den Einstieg in die doch recht komplexe Welt der ARM-CPUs. Ich emtwickel auch seit mehreren Jahrzehnten Firmware und hab vor ca. 3J den Umstieg von den 8bit MCUs zu ARM gewagt. CubeMX hat diesen (erforderlichen) Lernprozess enorm beschleunigt, da man direkt am Anfang damit sehr schnell zu einer grundlegenden Initialisierung kommt, die man dann analysieren und verstehen kann. Das entbindet natürlich nicht davon, die Datenblätter und Referenz-Manuals zu lesen und zu verstehen, aber es erleichtert w.g. den Einstieg. Wenn du allerdings nicht einmal in der Lage ist, die aktuelle CubeMX-Version zu installieren, glaube ich, daß du derzeit noch ganz andere Probleme hast.
Stefanus F. schrieb: > Im Reference Manual der STM32F4 Serie sind die relevanten Register mit > ihren Default Werten aufgelistet. Dieser Angabe würde ich mehr trauen, > als dem Eclipse Plugin. Jepp, genauso ist es aber die 84MHz werden schon stimmen, denn auch das Eclipse-Plugin ist gewissermaßen ein Framework, was eben gewisse Dinge hinter deinem Rücken konfiguriert. Stefanus F. schrieb: > Auch CubeMX zeigt beim Start NICHT die Default-Konfiguration an. Ich > finde das sehr irritierend. Sehe ich auch so. Meines Wissens nach ist die Default-Konfiguration immer HSI und alle Prescaler auf 1x bzw. bei den STM32Lx eben MSI statt HSI. Kann man sich schnell zurechtklicken wenn man möchte aber Leute die CubeMX nutzen, wollen sich ja gerade den PLL-Kram generieren lassen. Wolfgang E. schrieb: > Allein die Tatsache, dass ich CubeMX nur in der Version laufen lassen > kann, die ich vor zwei Jahren mal installiert habe, bestätigt mich in > meinem Vorurteil, dass ich lieber selber lerne, wie es geht, anstatt > mich auf tools zu verlassen. Daher benutze ich auch mbed nicht. Kann es sein, dass du eine sehr alte Java-Version installiert hast? Ich erinnere mich, dass ich da auch mal Probleme mit hatte.
> aber mit CubeMX bindest du dich eben nicht an ein Framework
Cube MX generiert Code, der von Cube HAL abhängt, welches ein Framework
ist.
Stefanus F. schrieb: >> aber mit CubeMX bindest du dich eben nicht an ein Framework > > Cube MX generiert Code, der von Cube HAL abhängt, welches ein Framework > ist. HAL ist eine simple Abstraktionsschicht, die sich nahezu nach Belieben mit nativem Code mischen läßt.
:
Bearbeitet durch User
Stefanus F. schrieb: > Cube MX generiert Code, der von Cube HAL abhängt, welches ein Framework > ist. Und trotzdem hilft es am Anfang enorm zu verstehen wie die Clocks etc. alle konfiguriert werden und was wie zusammen hängt. Und nur weil ein paar Zeilen HAL im Projekt sind heißt es ja nicht da man nicht alles weitere mit Registern programmieren kann. HAL abstahiert ja auch nur (mehr oder weniger gut) die Registerzugriffe.
> HAL ist eine simple Abstraktionsschicht, > die sich nach Belieben mit nativem Code mischen lässt. Ja, zum Glück.
Ich finds sowieso lächerlich, wenn Leute HAL mit Hinweis auf enthaltene Fehler (die es natürlich gibt) kategorisch ablehnen, und glauben sie würden "mal eben from Scratch" fehlerfreieren Code produzieren können. Das ist wohl eher der These "man soll keine anderen Götter neben sich dulden" geschuldet....
:
Bearbeitet durch User
> wenn Leute HAL mit Hinweis auf enthaltene > Fehler (die es natürlich gibt) kategorisch ablehnen Hat das jemand in diesem Thread getan? > glauben sie würden "mal eben from Scratch" fehlerfreieren > Code produzieren können. Hat das jemand in diesem Thread behauptet?
Christopher J. schrieb: >> Kann es sein, dass du eine sehr alte Java-Version installiert hast? Ich > erinnere mich, dass ich da auch mal Probleme mit hatte. Hm, ich benutze mac os und ein java -version zeigt: java version "1.8.0_92" Keine Ahnung, ob das alt oder neu ist ;-) Ich hab mir vor zwei Jahren oder so, CubeMX schon mal angeschaut gehabt und wollte jetzt ne neue Version installieren. Wenn ich die neu heruntergeladene SetupSTM32CubeMX-4.26.1.app starte, zuckt es nur kurz auf und schließt sich sofort wieder. Wenn ich im bereits installierten CubeMX (4.8.1) auf check for updates und install gehe, dann bekomm ich den Fehler, dass die "MD5 file checksum not good" sei. Was die grundsätzliche Benutzung von CubeMX anbelangt, so hab ich da vor zwei Jahren, bei einem ersten Kurzzeitexperiment festgestellt, dass ich mich 2 Wochen lang ausschließlich damit beschäftigt hab, wie man das Teil bedient und was man mit dem erzeugten Code dann macht, bzw. wie man den ggf. anpasst. Das war alles mehr oder weniger try and error. Das hat dazu geführt, dass ich bei allem, was über blinkende LEDs hinausging, sehr schnell in ner Sackgasse gelandet bin und kein bischen verstanden hab, was da eigentlich passiert. Folglich hab ich nun, wo ich einen neuen Anlauf in Sachen STM32 unternehme, die Lehre gezogen, dass das für mich persönlich nicht der richtige Weg ist.
@ Wolfgang Gurndsätzlich hat sich da in den letzten 2 Jahren enorm viel getan. Aber wenn du 2 Wochen brauchst um die Bedienung einer Software zu durchblicken....
@all: Ich habe nicht die Absicht, an einem HAL-Glaubensstreit teilzunehmen ;) Ich persönlich bin der Ansicht, dass Vi besser ist, als der Emacs und dass alle Menschen, die Emacs benutzen, doof sind und nach Lulu riechen ;) Ich hab für mich persönlich mit CubeMX eien bestimmte Erfahrung gemacht und hab daraus für mich persönlich den Beschluss gefasst, es erst mal ohne CubeMX zu versuchen. Punkt. Dass die Mehrzahl aller Menschen mit CubeMX super klar kommen und dass CubeMX für diese Menschen eine enorme Erleichterung ist, glaub ich sofort. Und dass es andere Menschen gibt, die alles außer Assembler für Teufelszeug halten, hat auch seine Berechtigung. Ich will eigentlich nur wissen, was ich als Berechnungsgrundlage für meinen PWM-Servo-Presacaler ansetzen muss und wo ich das nachschauen kann ...... Ich denk mal, diesbezüglich hab ich schon ein paar nützliche Anworten bekommen und dafür bedanke mich ausdrücklich und vielmals!
@PaSi, das zeigt einfach, dass ich für dieses tool zu doof bin ... und daher benutz ich es eben auch nicht ....
@Christopher J.: Danke, das liest sich verständlich und hilft mir, denk ich, sehr.
> das zeigt einfach, dass ich für dieses tool zu doof bin ... > und daher benutz ich es eben auch nicht .... Klingt vernünftig, geht mir übrigens ebenso. Und wenn jetzt jemand meint, dass ich für den Job zu doof sei: Es ist gar nicht mein Job, haha! Es ist nur mein Hobby.
Hallo Wolfgang, um mal auf deine eigentlich Frage zurück zu kommen...der Takt mit dem dein Timer und damit deine PWM läuft hängt vor allem von deiner Taktkonfiguration ab....die kann hier aber niemand sehen wenn du keinen Code postest. In sofern...was hast du denn in den Registern eingestellt? Gruß
@PaSi: Die Frage war eigentlich andersrum gemeint. Ich will/wollte ja wissen, was die Ausgangslage ist. Damit ich mir dann Gedanken machen kann, was ich für nen konkreten Code schreiben muss. Denn so weit ich es bislang verstanden hab, hängt das Timing-Ergebnis der PWM ja davon ab, wie schnell meine Timer ohne Prescaler sind. Ich geh jetzt mal davon aus, dass das 84Mhz sind. Das zeigt mir ein "printf" der SystemCoreClock an und wenn ich mir in CubeMX den Clock Tree anschau, dann steht da auch 84MHz. Diverse Beispiele im Internet geben auch 84MHz an. Mein Problem war und ist, dass diese "Clock-Cascade" ziemlich verwirrend ist. Man wird mit allen möglichen Zahlen konfrontiert. Auf der "Schachtel" des Nucleo-Boards steht was von 100Mhz, in der initialen Konfiguration des Eclipse-Projektes ist voreingestellt , dass es eine externe Clock mit 8Mhz gibt, davon ist auch in der RefManuals die Rede. In den RefManuals steht dann aber auch nochmal was von 16MHz. Usw usf. Und da macht es mir die Tatsache, dass mir das Eclipse-Plugin schon mal ales mögliche initialisiert, von dem ich erst mal nix weiß (so lange ich mir nicht die Mühe mache, den Quellcode zu lesen), nicht einfacher. Und wenn ich mir dann dazu nochmal nen Schwung Code von CubeMX generieren lasse (was ich natürlich testweise schon gemacht hab ;) ), hab ich bedauerlicherweise nicht viel mehr verstanden und erreicht. (Abgesehen davon, dass es ja "out of the box" auch nicht läuft.) Ich hab seinerzeit auch nicht zwei Wochen gebraucht, um herauszufinden, wie man mit CubeMX einen Pin als Timer konfigurieren kann oder dergl., das schaff selbst ich nach dem dritten Klick. Das Problem ist, zu verstehen, was man dann da in welche der vielen Felder eintragen muss, was das dann für Auswirkungen auf den generierten Code hat und was man über den generierten Code hinaus noch alles machen muss, damit am Ende das passiert, was man haben will. Und genau da seh ich den Vorteil von CubeMX für mich noch nicht so wirklich. Wenn ich bereits wüsste, wie man einen ARM uC programmiert und was die HAL-lib alles kann, dann wärs sicherlich ganz praktisch. Zu versuchen, das alles mittels der Benutzung von CubeMX zu lernen, hat sich für mich bislang aber nicht bewährt. Was den Code anbelangt, wühle ich mich gerade "durchs Internet". Der Großteil der Menschheit scheint sich auf die HAL-Strukturen eingeschworen zu haben .... ;) Und um auf Deine Frage zu antworten, bislang hab ich den Code, den Eclipse initial für mich generiert ...... und mittlerweile "Berechnungen", von denen ich annehme, dass sie für meine Servo-Steuerung passen könnten PSC 419 ARR 3999 TIMx_CCRx 200 ..... 400 Und jetzt überleg ich mir, ob ich es machen soll, wie alle anderen Menschen "im Internet", indem ich TIM_HandleTypeDef, GPIO_InitTypeDef und Konsorten befülle und versuche herauszufinden welche der 1.000.000 HAL-Funktionen ich in welcher Reihenfolge aufrufen muss, oder ob ich anfange bits zu schiften, zu verunden und zu verodern ... ;)
Wolfgang E. schrieb: > Auf der "Schachtel" > des Nucleo-Boards steht was von 100Mhz Das ist der maximale Takt (vom Hersteller freigegebene Takt) des Controllers. Wolfgang E. schrieb: > in der initialen Konfiguration > des Eclipse-Projektes ist voreingestellt , dass es eine externe Clock > mit 8Mhz gibt Aus dieser Information bastelt sich dann das gnu-mcu-eclipse-plugin deine PLL-Konfiguration und erstellt dir eine SystemInit-Funktion, in der dann die PLL konfiguriert wird Wolfgang E. schrieb: > Ich geh jetzt mal davon aus, dass das 84Mhz sind. Davon würde ich in deinem Fall auch mal ausgehen. Wolfgang E. schrieb: > In den > RefManuals steht dann aber auch nochmal was von 16MHz Das ist die Geschwindigkeit des internen RC-Oszillators, im RefManual als HSI abgekürzt (High Speed Internal (Clock)). Damit startet der Controller grundsätzlich aus dem Reset-Zustand und ist damit auch voll funktionsfähig. Alles andere muss danach konfiguriert werden (externer Quarz, PLL, etc.). Wolfgang E. schrieb: > PSC 419 > ARR 3999 > TIMx_CCRx 200 ..... 400 Jo, das passt auf jeden Fall für die 84MHz, also du bekommst eine 50Hz-PWM (20ms Periode) und mit einem Tastverhältnis von 1/10 bis 1/20 sind das dann 1-2ms. Ich meine aber für die CCRx-Werte gilt das gleiche wie für ARR, d.h. es müsste genau genommen 199..399 sein, weil ja bei null angefangen wird zu zählen.
Wolfgang E. schrieb: > Denn so weit ich es bislang verstanden hab, hängt das Timing-Ergebnis > der PWM ja davon ab, wie schnell meine Timer ohne Prescaler sind. Das ist schon mal falsch! Es hängt davon ab, welcher Takt am Ende rauskommt und darauf haben auch die Prescaler einen nicht unerheblichen Einfluss. Wolfgang E. schrieb: > Ich geh jetzt mal davon aus, dass das 84Mhz sind. Das zeigt mir ein > "printf" der SystemCoreClock an und wenn ich mir in CubeMX den Clock > Tree anschau, dann steht da auch 84MHz. Diverse Beispiele im Internet > geben auch 84MHz an. das ist aber nur 1 mögliche Konfiguration, nämlich die, die CubeMX als default vorschlägt, und die auch in vielen Fällen sinnvoll ist. Besonders für Einsteiger, die das Clock-System noch gar nicht verstanden haben. Wolfgang E. schrieb: > Und wenn ich mir dann dazu nochmal nen Schwung Code von CubeMX > generieren lasse (was ich natürlich testweise schon gemacht hab ;) ), > hab ich bedauerlicherweise nicht viel mehr verstanden und erreicht. > (Abgesehen davon, dass es ja "out of the box" auch nicht läuft.) Komisch! Bei mir läuft das out-off-the-box... Da ist wohl deine IDE noch nicht korrekt aufgesetzt, oder du hast den Vorgang des Import des CubeMX-Projekt in deine IDE nicht verstanden. Warum nutzt du nicht AtollicStudio? Das ist auch Eclipse, allerdings bereits nach der Installation so vorkonfiguriert und eingestellt, daß das unmittelbar mit CubeMX zusammen arbeitet. Das wird nicht umsonst von ST selbst gepflegt und empfohlen. Zum Einstieg gibts auch gut verständliche Tutorials, die dich locker innerhalb weniger Stunden zum 1. Erfolgserlebnis bringen: https://www.youtube.com/channel/UCZ5tf8T8odmacEAOpw68guA Wolfgang E. schrieb: > Und genau da seh ich den Vorteil von CubeMX für mich noch nicht so > wirklich. Wenn ich bereits wüsste, wie man einen ARM uC programmiert und > was die HAL-lib alles kann, dann wärs sicherlich ganz praktisch. Zu > versuchen, das alles mittels der Benutzung von CubeMX zu lernen, hat > sich für mich bislang aber nicht bewährt. Klassisches Henne-Ei-Problem.
@Harry L: Harry L. schrieb: > Komisch! > Bei mir läuft das out-off-the-box... > Da ist wohl deine IDE noch nicht korrekt aufgesetzt, oder du hast den > Vorgang des Import des CubeMX-Projekt in deine IDE nicht verstanden. > Meine IDE (eclipse mit der ARM - Toolchain) wird von der Version von CubeMX , die ich habe, nicht direkt unterstützt. Ich kann dann also anfangen, Eclipse so umzukonfigurieren, dass es mit dem Exportergebnis von CubeMX klar kommt (hab ich vor zwei Jahren so gemacht), oder ich kopier mir den Code, den CubeMX generiert in mein Eclipse-Projekt, (das machen ne Menge Youtuber so), oder ich benutze ein Script dafür oder oder oder ..... Ein Punkt, der mir an der CubeMX-Version, die ich hab, z.B. nicht gefällt, ist, dass sie nur C-Code generiert, ich möchte aber C++ benutzen. Also nicht einfach nur C-Syntax vom C++-Compiler compilieren lassen, sondern mit Klassen und Templates und so. > Warum nutzt du nicht AtollicStudio? > Das ist auch Eclipse, allerdings bereits nach der Installation so > vorkonfiguriert und eingestellt, daß das unmittelbar mit CubeMX zusammen > arbeitet. > Das wird nicht umsonst von ST selbst gepflegt und empfohlen. Weil es AtollicStudio nicht für Mac OSX gibt. Ich steh eben auf dem elitären Standpunkt, dass ich mir selber aussuchen will, unter welchem BS ich mit welcher IDE arbeiten möchte. Und wenn dann ein Tool diese Anforderungen nicht erfüllt, dann benutze ich es nicht. Ich kauf mir jetzt sicher kein Windows, weil ST eine bestimmte IDE pflegt. Und mit CubeMX hab ich ein ähnliches Problem. Ich hab das - wie schon geschrieben - vor nem Jahr oder zwei schon mal ausprobiert. Ich hab es auf einem Ubuntu-System und auf einem Mac OSX-System installiert. Es gibt in dem Tool eine Update-Funktion. Auf beiden Systemen funktioniert sie nicht. Es kommt exakt die gleiche MD5-Checksum-Fehlermeldung. Tja und da sich das Tool vor zwei Jahren für mich persönlich als nicht besonders hilfreich erwiesen hat, bin ich auch jetzt nicht gewillt Forschungsarbeiten zu betreiben, was ich alles tun muss, um es upzudeaten. Ich hab ein bischen danach gegoogelt, nix gefunden und das wars. In ein Tool, von dem ich eh nicht überzeugt bin, weil sich mit dessen Ansatz für mich diverse Nachteile verbinden, investiere ich einfach nicht so viel Zeit. Es sei denn mir ist irgendwan mal langweilig und ich hab Lust darauf. Da ich den Ansatz mit den ganzen HAL-Konstanten zudem nicht für besonders generisch und/oder wiederverwendbar halte, ist mein momentan favorisiertes Vorgehen eben, dem Trend zum Trotz, lieber Register zu von Hand zu befüllen ....
@ Christopher J: Danke für die Bestätigung und den Hinweis.
Wolfgang E. schrieb: > Meine IDE (eclipse mit der ARM - Toolchain) wird von der Version von > CubeMX , die ich habe, nicht direkt unterstützt. Genau das ist dein Problem. Du könntest z.B. die SW4STM-Plugins nachinstallieren. So lange du die Grundlagen nicht wirklich verstanden hast, mach es absolut keinen Sinn für dich, das Rad neu zu erfinden. Wolfgang E. schrieb: > Ich steh eben auf dem elitären Standpunkt, dass ich mir selber aussuchen > will, unter welchem BS ich mit welcher IDE arbeiten möchte. Tja...keine Arme - keine Kekse Für deinen Mac gibt es m.W. auch Bootcamp, womit dan auch Win-Software laufen sollte, oder eben VMWare, und damit ginge dann auch Ubuntu. Wenn du auf deinem MacOS beharrst - bittesehr, aber erwarte keine allzugroße Hilfe hier im Forum. Wolfgang E. schrieb: > Tja und da sich das Tool vor zwei Jahren für mich persönlich als nicht > besonders hilfreich erwiesen hat, bin ich auch jetzt nicht gewillt > Forschungsarbeiten zu betreiben, was ich alles tun muss, um es > upzudeaten. > Ich hab ein bischen danach gegoogelt, nix gefunden und das wars. Wie bereits an anderer Stelle erwähnt, hat sich 2J viel getan, und sich auf eine 2J alte Version zu beziehen und daraus so ein Urteil abzuleiten grenzt an Starrsinn. Wolfgang E. schrieb: > Da ich den Ansatz mit den ganzen HAL-Konstanten zudem nicht für > besonders generisch und/oder wiederverwendbar halte Und du glaubst wirklich, das beurteilen zu können? - ich nicht! Ok, da du offenbar unbedingt mit dem Kopf durch die Wand willst, bin ich hier raus. Es dürfte wohl noch eine ganze Weile dauern, bevor du deine ersten funktionierendes STM32-Programme schreibst....
@Harry L. zwei ganz einfache Fragen: Unterstützt CubeMX in der aktuellen Version Eclipse mit dem gnu-mcu-plugin? Kann man mit CubeMX C++ Code erzeugen? Das ist das, was ich haben wollen würde. Wenn es das nicht kann, dann beschäftige ich mich eben 2 Jahre lang damit, Register zu befüllen oder HAL-Funktionalitäten von Hand aufzurufen. Wenn ich mal das Bedürfnis nach schnellen Erfolgserlebnissen hab, benutze ich einfach meinen mbed-account. Abgesehen davon, hab ich in diesem Thread ja auch durchaus große Hilfe bekommen. Nicht jeder versucht, mich von seiner eigenen Ideologie zu überzeugen. Es gibt durchaus auch Menschen, die einfach meine Fragen beantworten, mir Verweise auf konkrete Quellen (Dokument und Seitenangabe) geben und meine technischen Annahmen bestätigen oder widerlegen. Die beschäftigen sich weder damit, ob ich das richtige Eclipse-Plugin benutze oder das richtige Betriebssystem oder das richtige Tool, die fragen sich nicht, ob meine Vorstellung von Generik und Wiederverwendbarkeit akzeptabel ist oder nicht, die helfen einfach nur. Dafür bin ich diesen Menschen sehr dankbar!
Wolfgang E. schrieb: > Kann man mit CubeMX C++ Code erzeugen? Ich benutze CubeMX zwar auch, aber nicht, um damit Code zu erzeugen. Ich stelle lediglich damit den Ausgangstakt und die nachgeschalteten Prescaler ein, um zu sehen, was dann hinten für Timer-Clocks rauskommen. Diese tippe ich dann ab, um die Datei system_stm32f4xx.c an den entsprechenden STM32 anzupassen. Du findest diese im Anhang. Unterstützt werden damit:
1 | STM32F103C8 Mini-Dev-Board |
2 | STM32F401RE Nucleo Board |
3 | STM32F411RE Nucleo Board |
4 | STM32F446RE Nucleo Board |
5 | STM32F407VG Discovery Board |
6 | STM32F407VE BlackBoard |
Du musst lediglich im Projekt die entsprechende Konstante definieren, z.B. "STM32F411RE". Es wird prinzipiell von 8MHz Quarz-Betrieb ausgegegangen, also HSE-Mode. Bei den Nucleos kann man den 8MHz-Quarz und die beiden zugehörigen Kondensatoren bequem nachrüsten. Die resultierenden Clocks findest Du im Code, z.B. für STM32F411RE:
1 | /*----------------------------------------------------------------------------
|
2 | * STM32F411RE Nucleo Board with 8 MHz crystal (100 MHz)
|
3 | *
|
4 | * Input frequency 8MHz
|
5 | * PLL M 4
|
6 | * PLL N 100
|
7 | * PLL P 2
|
8 | * AHB prescaler 1
|
9 | * APB1 prescaler 2
|
10 | * APB2 prescaler 1
|
11 | *----------------------------------------------------------------------------
|
12 | */
|
13 | #elif defined (STM32F411RE) // STM32F411RE Nucleo Board with 8 MHz crystal (100 MHz)
|
14 | #define HCLK 100 // 100 MHz
|
15 | #define PLL_M 4
|
16 | #define PLL_N 100
|
17 | #define PLL_P 2
|
18 | #define AHB_PRESCALER RCC_CFGR_HPRE_DIV1 // 100 MHz
|
19 | #define APB1_PRESCALER RCC_CFGR_PPRE1_DIV2 // 50 MHz
|
20 | #define APB2_PRESCALER RCC_CFGR_PPRE2_DIV1 // 100 MHz
|
Ebenso stellt der Code die für die jeweiligen Takte nötigen Waitstates ein. Nach Aufruf von
1 | SystemInit (); |
2 | SystemCoreClockUpdate(); // needed for Nucleo board |
direkt oben in der main()-Funktion ist dann der Drops gelutscht.
:
Bearbeitet durch Moderator
@Wolfgang Anfgreifen wollte dich hier sicher niemand. Du solltest das eher als Hinweise zum Einstieg in die durchaus sehr komplexe STM32-Welt verstehen. Zu deinem Clock: Solange wir nicht wissen wie dein Systemclock (Pll etc.) konfiguriert ist können wir auch nur raten was am Ende bei deinem verwendeten Timer rauskommt. Da ich das nicht das Eclipse-Plugin nutze, sondern SW4STM32 (auch Eclipsebasieren und zumindest für Win und Linux verfügbar, bei Mac bin ich mir nicht sicher) weiß ich nicht was für ein Code da default genutzt wird. Gruß
Hab mal kurz ein lauffähiges Beispiel zusammengetippt. Es nutzt PA5, also den LED-Pin, wobei daran wiederum Timer2 Ch1 hängt. Für den Anfang ist es sicher ganz nützlich, weil man dann nämlich genau die Stellen kennt an denen man nachlesen muss. Mehr braucht es nicht zwingend aber natürlich hat man nahezu endlose weitere Einstellmöglichkeiten. Gerade die Timer sind schon sehr mächtig bei den STM32.
1 | void gpio_init(void) |
2 | {
|
3 | // GPIO-Takt anschalten (Kapitel 6: RCC)
|
4 | RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; |
5 | |
6 | // GPIO auf "alternate function" stellen (Kapitel 8: GPIO)
|
7 | GPIOA-> MODER |= GPIO_MODER_MODER5_1; |
8 | |
9 | // Alternate Function für PA5 auf TIM2 CH1
|
10 | // Wert stammt aus Datenblatt, Tabelle 9 (nicht RefMan!)
|
11 | GPIOA->AFR[0] |= 1UL << (5*4); |
12 | |
13 | }
|
14 | |
15 | void timer_init(void) |
16 | {
|
17 | // Takt anschalten
|
18 | RCC->APB1ENR |= RCC_APB1ENR_TIM2EN; |
19 | |
20 | // Konfigurieren von Prescaler, ARR und CCR1
|
21 | TIM2->PSC = 419; |
22 | TIM2->ARR = 3999; |
23 | TIM2->CCR1 = 199; |
24 | |
25 | // PWM-Modus 1, d.h. OC1M = 0b110 (S. 353), heißt soviel wie Signal high wenn CNT<ARR, sonst low
|
26 | TIM2->CCMR1 |= TIM_CCMR1_OC1M_2 | TIM_CCMR1_OC1M_1; |
27 | |
28 | // Timer anschalten
|
29 | TIM2->CR1 |= TIM_CR1_CEN; |
30 | |
31 | // Ausgang einschalten
|
32 | TIM2->CCER |= TIM_CCER_CC1E; |
33 | |
34 | // Timer während des Debuggens anhalten, siehe Kapitel 23.16 auf S.817
|
35 | DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM2_STOP; |
36 | |
37 | }
|
38 | |
39 | int main(void) |
40 | {
|
41 | gpio_init(); |
42 | timer_init(); |
43 | while(1); |
44 | }
|
Wolfgang E. schrieb: > @Christopher J. > Es lebt!!! ;) > > Vielen 1000 Dank! Das freut mich. Gern geschehen ;)
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.