Moin,
ich habe einen STM32f103 und stehe gerade etwas auf dem Schlauch, was
die Taktfrequenz angeht: Ich benutzte die Funktion SystemInit() von
CMSIS am Anfang und dort ist auch (SYSCLK_FREQ_72MHZ) definiert.
Danach tue ich nichts anderes, als ein Port Bit zu toggeln. Allerdings
ändert sich der Ausgang mit ziemlich genau 8MHz, obwohl ich dachte, mein
Takt wäre bei 72MHz.
Fehlt mir bei der Initialisierung noch etwas?
Hier mein Code:
1
SystemInit();//CMSIS Funktion (SYSCLK_FREQ_72MHz ist definiert)
Hi.
Danke für den Tipp mit dem MCO. Allerdings komme ich hier wieder nur auf
die 8MHz, egal ob ich
RCC_MCOConfig(RCC_MCO_PLLCLK_Div2);
oder auch
RCC_MCOConfig(RCC_MCO_SYSCLK);
anschaue. Ich bleibe bei 8MHz.
Habe auch schon im Debugger geschaut. Bei der Initialisierungsroutine
läuft der code durch die Funktion SetSysClockTo72() in der
"system_stm32f10x.c" Datei.
Was könnte ich noch vergessen haben?
Grüße
Du wirst nicht drum herum kommen, dir das Reference Manual
herunterzuladen zu müssen und den Clock-Tree verstehen zu müssen. Sonst
bleibt das ein Herumstochern im Dunkeln.
Die Funktionen gehen glaub ich von einem vorhandenen Quarz aus. Ist das
der Fall? Mit internem RC Oszillator können nämlich nur 64 MHz erreicht
werden. Dafür muss auch die PLL an sein. Google Mal in die Richtung.
Es gibt auch von CMSIS eine Variable SystemCoreClock, Google danach.
Dann brauchst du nix mehr togglen.
Der Spannende Teil ist der Inhalt der SystemInit() Funktion. Ich würde
die gerne mal sehen, bevor ich Scheiße laber.
Normalerweise wird die SystemInit() funktion übrigens vor der main() von
der Initialisierungsroutine aufgerufen, die in Assembler geschrieben
wurde. Man ruft sie normalerweise nicht selber auf.
Wenn "GPIOD->BRR = GPIO_Pin_5"; und "GPIOD->BSRR = GPIO_Pin_5;" jeweils
4 Takte benötigen, dann passt es doch: 72MHz/(4+4) = 9 MHz.
Wo ist denn denn das Problem?
Häh? schrieb:> Wenn "GPIOD->BRR = GPIO_Pin_5"; und "GPIOD->BSRR = GPIO_Pin_5;"> jeweils> 4 Takte benötigen, dann passt es doch: 72MHz/(4+4) = 9 MHz.> Wo ist denn denn das Problem?
Daher: toggeln mit einem Hardware Timer! Ohne CubeMX sind das < 10
Zeilen Code.
Es ist aber schon (zumindest für mich) eine wichtige Erkenntnis, dass
STM32 ihre I/O Pins per Software verhältnismäßig wesentlich langsamer
toggeln, als AVR Mikrocontroller.
Ein 8 MHz AVR schafft 4 MHz, weil jeder I/O Zugriff nur einen Takt
dauert.
Stefanus F. schrieb:> Ein 8 MHz AVR schafft 4 MHz, weil jeder I/O Zugriff nur einen Takt> dauert.
Aber nur, wenn du alle Befehle hintereinander im Speicher hältst.
Bei einer Schleife mit Sprung sieht das auch anders aus.
Häh? schrieb:> Wenn "GPIOD->BRR = GPIO_Pin_5"; und "GPIOD->BSRR = GPIO_Pin_5;" jeweils> 4 Takte benötigen, dann passt es doch: 72MHz/(4+4) = 9 MHz.
Ja dann haben wir ja alles gelöst. Danke.
Wo könnte ich denn eine Übersicht über alle Funktionen bekommen, wie
viele Takte sie jeweils benötigen?
@heiko
SYSCLK_FREQ_72MHz nützt dir nichts wenn das Clocksystem nicht
entsprechend initialisiert ist. Wo wird das in deinem Programm gemacht
?
Default ist der interne 8Mhz Oszillator als Sysclock eingestellt.
SystemInit() initialisiert kein Clocksystem.
Das ruftst du auch nicht auf, das macht der StartupCode den du dazu
linken musst.
Nimm cube MX und stelle es wie im Bild ein ... lass dir den Code
generieren und schau ihn dir an.
Bimbo. schrieb im Beitrag #5814237:
> Kein Bedarf, denn ich mache keine Pin Wackeldackel, wenn ich das in> Hardware erledigen kann ;).
Du hättest aber auch keine Wahl: Wenn taktgenau, dann Hardware. Jetzt
begriffen?
Häh? schrieb im Beitrag #5814224:
>> ...taktgenauen (!) CPU-Befehle...>> Diese Eigenschaft hat der STM32 nämlich nicht.
Die STM32 sind wie alle anderen MCs synchrone Designs und laufen
selbstverständlich Taktsynchron und genau.
Hans-Georg L. schrieb:> Häh? schrieb:>>> ...taktgenauen (!) CPU-Befehle...>>>> Diese Eigenschaft hat der STM32 nämlich nicht.>> Die STM32 sind wie alle anderen MCs synchrone Designs und laufen> selbstverständlich Taktsynchron und genau.
Nein!
WaitStates, Prefetch, gleichzeitige Speicherzugriffe (Debugger, DMA,
USART, ...), ... haben Einfluss. Beim STM32 kann man mit CPU-Befehlen
keine taktgenauen Abläufe machen. Tut mir leid, ich weiss wovon ich
schreibe.
Bimbo. schrieb:> Häh? schrieb:>> Du hättest aber auch keine Wahl: Wenn taktgenau, dann Hardware. Jetzt>> begriffen?>> So macht man das auch Professionell.
Ja. Das ändert aber nichts an meiner Aussage.
Häh? schrieb:> WaitStates, Prefetch, gleichzeitige Speicherzugriffe (Debugger, DMA,> USART, ...), ... haben Einfluss.
Kannst du alles ausschalten. Dann verzichtest du aber auf die
Möglichkeiten, dein Programm schneller zu machen. Dann ist aber ein Add
auch 1 Cycle und du bist wieder in der Atmega-Welt.
Bimbo. schrieb:> Dann ist aber ein Add> auch 1 Cycle und du bist wieder in der Atmega-Welt.
Wobei dann so ein STM32 letztendlich langsamer wird, als ein AVR mit 20
oder 32 MHz.
Der Flash von ST kann nämlich nur maximal 24 Mhz und für viele Befehle
(insbesondere I/O) sind mehr Takzyklen nötig, als bei AVR.
Das ist gut möglich, weiß ich jetzt nicht. Aber wenn man im MHz Bereich
taktgenau mit Pins wackeln möchte ohne die Hardware zu benutzen - dann
läuft sowieso etwas gewaltig schief ;)..
Bimbo. schrieb:> Das ist gut möglich, weiß ich jetzt nicht. Aber wenn man im MHz Bereich> taktgenau mit Pins wackeln möchte ohne die Hardware zu benutzen - dann> läuft sowieso etwas gewaltig schief ;)..
Die STM haben doch dafür genau die vielen Timer und die interconnect
matrix.
Die sind doch hauptsächlich für Timing von Motorsteuerungen und
Schaltregler designt. Damit lassen sich doch viele Probleme ohne
Cpuzyklen und Port gefummel und sogar ohne CPU komplett in Hardware
erledigen. Die Hardware ist doch da benutze sie.
Und es gibt ja nicht nur den F103 ;-)
ps. dein Cpu zyklen genau != taktgenau
Thread beobachten
Seitenaufteilung abschalten