Hallo Ich habe einen STM32H7 welcher die inerne RC clockquelle nutzt. Die countfrequenz wird auf 240MHz hochgesetzt, timer3 soll interrupts alle 10us generieren. Soweit sogut: Prescale 0 Count auf (2400-1) autoladen ein Wenn ichs nun jedoch mit der stoppuhr vergleiche läufts auf dem STM etwa 5% langsamer. Dachte erst liegt am RC und habe daraufhin den 4mhz RC versucht: gleiches ergebnis. gem. darenblatt sollte due RC abweichung nur 0.5% sein. Habe ich irgendowo etwas falsch gemacht?
Meinst du nicht, dass da ein bisschen mehr Infos erforderlich sind? Zum Beispiel der Quelltext, Infos zur Hardware und die Mess-Methode?
Diode schrieb: > clockquelle > countfrequenz > autoladen > 4mhz Gib dir bloß nicht zu viel Mühe. Wenn du so programmierst, wie du schreibst, dann wird das nichts.
Die meisten Informationen hat er doch geschrieben. Der interne HSI ist mit 47.5(min) 48(typ) 48.5(max) [MHz] angegeben. Von daher würde ich auch das Problem eher im Code vermuten. Zumal ich nicht weiß wie man 10us mit einer Stoppuhr stoppt :D
> [..] 240MHz [..] interrupts alle 10us generieren.
Du willst ernsthaft alle 2400 Takte einen Interrupt generieren? Wofür
braucht man das? Da ist der arme Core ja nur noch mit Rein- und
Rausspringen beschäftigt.
g457 schrieb: > Da ist der arme Core ja nur noch mit Rein- und > Rausspringen beschäftigt. Sag doch gleich, dass du den H7 nicht kennst. 100 kHz sind bei 480 MHz CPU-Takt schon recht langsam oder anders ausgedrückt < 1% Auslastung.
Danke für die Antworten, und bitte verzeiht meine schreibweise (am tel). Wie ichs gemessen habe: isr counter und nach ca. 1h mit stopuhr verglichen. Core läuft natürlich mit 480mhz (mit I und D cache wegen dem lahmen Flash), Timer3 begrenzt mit 240 Nun was soll ich dann noch weiter beschreiben damits klar wird? Die einstellubgen sind alle im cube, und mehr als die beschriebenen: count frequenz prescale zählerwert Auto laden gibts meines wissens nicht. Benötigt das autolanden noch zeit?
Diode schrieb: > Nun was soll ich dann noch weiter beschreiben damits klar wird? Benutze die Quelle HSE. Die ist auf jedem Nucleo Board verfügbar, auch wenn kein Quarz zu sehen ist (kommt vom draufgeklatschten ST-Link). Wenn du kein Nucleo Board hast dann mach selbst einen Quarz oder Quarzosillator an deinen STM32H7. Mit den internen Oszillatoren kommst du nie auf einen grünen Genauigkeits-Zweig.
jo mei schrieb: > Diode schrieb: > >> Nun was soll ich dann noch weiter beschreiben damits klar wird? > > Benutze die Quelle HSE. Die ist auf jedem Nucleo Board verfügbar, > auch wenn kein Quarz zu sehen ist (kommt vom draufgeklatschten > ST-Link). Wenn du kein Nucleo Board hast dann mach selbst einen > Quarz oder Quarzosillator an deinen STM32H7. > Mit den internen Oszillatoren kommst du nie auf einen grünen > Genauigkeits-Zweig. Ok Danke; nun habe keinen, habe es nun ca passend mit prescale 0 und count 2389. Die Genauigkeit ist eigentlich genügend für die Anwendung es geht mir mehr darum, ob ST ihre präzisionsspec um faktor 10 verfehlt oder ich etwas falsch gemacht habe. OT: hat jemand Erfahrung im zusammenhang mit DMA und D-Cache; ich habe dies bis jetzt vermieden, da ich Probleme erwarte. (bei meiner Anwendung ist D cache wichtiger als DMA, weshalb aktuell ohne DMA)
Diode schrieb: > Die Genauigkeit ist eigentlich genügend für die Anwendung es > geht mir mehr darum, ob ST ihre präzisionsspec um faktor 10 verfehlt > oder ich etwas falsch gemacht habe. Dann kann man das Thema hier ja zumachen. Ich finde es jedenfalls "schrecklich" wenn man so einen geilen Controller hat und dann nicht mal genau weiss in welchen Zeitrahmen man arbeitet weil der Takt so ungenau ist und dieser mit der Temperatur sogar hin- und herwabert. Irgendwann kommt's dann und man braucht doch die Quarzgenauigkeit. Controller-Takte ohne Quarz sind einfach nur Mist. SCNR.
Also sry aber selbst bei einer Stunde ist die Messungenauigkeit mit einer Stopuhr wohl kaum aussagekräftig. Toggel im ISR einen Pin und mess mit dem Oszi......
Die sicherste Möglichkeit um zu testen ob es der eigene Programmcode oder der interne Oszillator ist, wäre Dir den Systemtakt auf einem MCO-Pin ausgeben zu lassen. Das dann z.B. mit einem Oszi, Spekki oder Frequenzzähler zu messen. 5% Abweichung vom Sollwert sollten sich da gut erkennen lassen. Ansonsten gibt es noch den Kalibrier-Wert und das Trim-Register für den HSI. Hab grad nicht mehr im Kopf wie das im Detail war, wann und wie der geladen/gesetzt wird bzw. von Dir behandelt werden muss. Das würde ich mir an Deiner Stelle im Referenzhandbuch nochmal genau durchlesen. ST wird den Sollwert aus dem Datenblatt angeben wenn man das optimal behandelt. Das muss nicht unbedingt die Standardkonfiguration sein. Was auch noch eine Rolle spielen kann ist unsaubere Spannung und/oder fehlende Kondensatoren am VDDA-Rail. Die wird nämlich benötigt um den Oszillator und die PLL zu versorgen und wirkt sich daher auch auf die Performance von denen aus.
Kevin M. schrieb: > Also sry aber selbst bei einer Stunde ist die Messungenauigkeit > mit einer Stopuhr wohl kaum aussagekräftig. > Toggel im ISR einen Pin und mess mit dem Oszi...... nun meine IST ist ein counter hochzählen, alle paar sek schreibe ich den über usb vcp aufs terminal Inwiefern sollte dies gegenüber dem oszi unterlegen sein? Nun abweichungen von wenigen sek sind vieleicht nicht aussagekräftig mit stoppuhr, wenns aber um etliche 10sec oder mehr geht dann schon. Bez DMA und Cache werde ich vermutlich einen neuen T eröffnen (habs getestet und gibt wie erwartet Probleme)
Diode schrieb: > nun meine IST ist ein counter hochzählen, alle paar sek schreibe ich den > über usb vcp aufs terminal Diode schrieb: > Bez DMA und Cache werde ich vermutlich einen neuen T eröffnen (habs > getestet und gibt wie erwartet Probleme) Wenn du in diesem schlapprigen Stil weiterschreibst kann das hier noch recht lustig werden.
Gerd E. schrieb: > Die sicherste Möglichkeit um zu testen ob es der eigene > Programmcode oder der interne Oszillator ist, wäre Dir den Systemtakt > auf einem MCO-Pin ausgeben zu lassen. Das dann z.B. mit einem Oszi, > Spekki oder Frequenzzähler zu messen. 5% Abweichung vom Sollwert sollten > sich da gut erkennen lassen. > Ansonsten gibt es noch den Kalibrier-Wert und das Trim-Register für den > HSI. Hab grad nicht mehr im Kopf wie das im Detail war, wann und wie der > geladen/gesetzt wird bzw. von Dir behandelt werden muss. Das würde ich > mir an Deiner Stelle im Referenzhandbuch nochmal genau durchlesen. ST > wird den Sollwert aus dem Datenblatt angeben wenn man das optimal > behandelt. Das muss nicht unbedingt die Standardkonfiguration sein. > Was auch noch eine Rolle spielen kann ist unsaubere Spannung und/oder > fehlende Kondensatoren am VDDA-Rail. Die wird nämlich benötigt um den > Oszillator und die PLL zu versorgen und wirkt sich daher auch auf die > Performance von denen aus. Danke ja, damit wärs dann eindeutig. Danke für den tipp mit VDDA; nun habe so ein chinaboard bei welchem aller wahrsch nach Spannungsatabilisierung/Layout mangelhaft sind... Nun habe auch den effekt, dass alle 3 ADC single ended bei eingang kurzgeschlossen mit GND werte von: 1000, 950, 1030 ausgeben (16bit modus, 20mhz adc clk) denke kaum das der STM diesbezüglich das problem ist.
au weia schrieb: > Diode schrieb: > >> nun meine IST ist ein counter hochzählen, alle paar sek schreibe ich den >> über usb vcp aufs terminal > > Diode schrieb: > >> Bez DMA und Cache werde ich vermutlich einen neuen T eröffnen (habs >> getestet und gibt wie erwartet Probleme) > > Wenn du in diesem schlapprigen Stil weiterschreibst kann das > hier noch recht lustig werden. Nun auf dem mobiltel schreiben ist nicht immer einfach. Und R ist neben T auf der Tastatur, das mit IST ISR gemeint ist sollte naheliegend sein.
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.