STM32 Zeit messen?

Schnapp dir einen der Timer, lass den schnellstmöglich laufen, pack dein 
Signal an einen dazu passenden Input-Capture Pin, konfiguriere den auf 
die Flanke, die dich interessiert...

Spacer schrieb:
> gerne, welches ist es denn?

Eines der Timer-Zählerregister, mit Prescaler=1, und natürlich die Clock 
Configuration so einstellen, dass der Timer auch die volle Frequenz 
abbekommt.

Tu dir einen Gefallen und nimm einen der 32-Bit-Timer. Sonst ist die CPU 
ständig am Overflow-Mitzählen.

Stefan ⛄ F. schrieb:
> Das geht gar nicht, so schnell ist die Peripherie nicht.

Mag sein, hatte da wohl einen anderen F4 im CubeMX offen.
Wird mit halbem Clock, also 90MHz am Timer trotzdem noch 
genauer/jitterärmer laufen als in der ISR den Cyclecounter zu Fuß 
auszulesen.

Ich habs so gemacht: ein Timer konfiguriert mit zwei Input capture 
direct mode Kanälen, reset mode und als Trigger source TI1FP1 ausgewählt 
(siehe Bild).

Dann brauchst Du nur im Programm

diff = TIM2->CCR3;

abfragen und bekommst direkt die Take ausgegeben.
Habs ohne Interrupt, aber du kannst natürlich auch ein Interrupt 
starten, wenn die Messung abgeschossen ist, oder das Ganze über DMA 
laufen lassen.

Gruß

Hermann S. schrieb:
> und bekommst direkt die Take ausgegeben.

sh. oben, den Fehler hatte ich auch. bei 180MHz Sysclk und max. 100 MHz 
Timer-clock muss man die nochmal auf 90MHz halbieren, kriegt also nur 
"Doppeltakte" aus dem Timer ausgelesen.

Mit ein paar kleinen Einschränkungen kann man mit dem DWT->CYCCNT 
ziemlich genau messen:
 - der Pin-Interrupt muss der einzige Interrupt sein
 - das Hauptprogramm darf keine Divisions-, FP- und LDM/STM-Befehle 
benutzen
 - der Stack muss immer aligned-8 sein
 - das gesamte Programm muss in den Cache passen oder Cache und Prefetch 
müssen abgeschaltet werden
 - der Counter muss zu Beginn der ISR gelesen werden

Von der Flanke am Pin bis zum Lesen des Counters vergehen viele 
Taktzyklen, aber das bei jeder Flanke, also egal -- solange es immer 
gleich viele sind. Ein wenig Jitter entsteht durch unterschiedlich lange 
Befehle im Hauptprogramm, daher die Einschränkungen. Normalerweise 
hängen die Pins am AHB oder noch direkter an der CPU. Solange AHB-Clock 
= HCLK ist, dürfte da kein weiterer Jitter dazu kommen.

Ja gut, ich hab "nur" nen F103, hab also keine 180 MHz, Clock und Timer 
sind auf der gleichen Frequenz, bei mir passt das auch, wenn ich die 
Takte dann auf die Frequenz umrechne.
Wenn man das aber weiß mit den "Doppeltakten", kann man das ja 
entsprechend gegenrechnen?!

Erich schrieb:
> Spacer schrieb:
>> Den Systemtakt kann ich ja wohl kaum selber zählen ohne dass der Zähler
>> bei jedem Interrupt unterbrochen werden würde.
>
> Du solltest erstmal mit deutlich kleineren uC anfangen,
> PIC10, PIC12, sowas,
> damit Grundlagen erlernen.
> Und erst später in die Astronautentechnik einsteigen.

Ich find die STM32´s sind in Kombination mit der CubeIDE doch recht gut 
auch für "Einsteiger" geeignet. Man muss sich allerdings doch etwas 
einlesen, aber ich denke das muss man bei anderen Mikrocontrollern auch.
Finds halt recht einfach dass man die Hardware nicht selbst 
programmieren muss.

Wühlhase schrieb:
> Dafür braucht er jedenfalls keinen extra Timer zu opfern

Mit dem Timer bekommt man halt Auflösung = Genauigkeit = 1/90Mhz hin.

Mit dem händischen Auslesen des Cyclecounters in der ISR ist die 
Auflösung doppelt so gut, aber die Genauigkeit schlechter bis 
katastrophal schlecht.
Je nachdem ob gerade aus dem Flash oder aus dem Ram/cache gearbeitet 
wird, ob es andere ISRs mit evtl. sogar höherer Priorität gibt, ob das 
Hauptprogramm "böse", langlaufende Befehle enthält usw. dauert es 
unterschiedlich lange, bis die ISR überhaupt angesprungen wird...

Wühlhase schrieb:
> SysClock, SysTick,

die sind m.W. nochmal runtergeteilt, und hätten ansonsten dasselbe 
Problem.