Forum: Mikrocontroller und Digitale Elektronik Zeit messen zwischen zwei Punkten im Programmfluß (STM32F103)


von Christoph K. (chriskuku)


Lesenswert?

Ich will einem Ereignis, das in einer Timer-Interruptroutine markiert 
wird (ein Array von 32 Ereignissen) einen Zeitstempel zuordnen. Im 
Hauptprogramm soll das jüngste Ereignis herausgefunden werden, indem das 
Maximum der Zeitstempel ermittelt wird.

Um zwei Ereignisse unterscheiden zu können, müßte ich die Zeit kennen, 
die minimal zwischen den Ereignissen liegen kann.

Die kenne ich per Programmfluß. Ich müßte sie aber irgendwie ermitteln 
können. Instruktionen zählen wäre eine Möglichkeit. Programm ist aber in 
C. Gibt es im Debugger (STM32CubeIDE) eine Möglichkeit, die Zeit 
zwischen 2 Breakpoints zu messen?

Oder ich müßte ein Timerregister auslesen, das mit 72MHz läuft und die 
Werte irgendwo hinschreiben. Hätte dann ein Vielfaches von ca. 14ns 
zwischen den Punkten.

Ideen?

von J. S. (jojos)


Lesenswert?


von jo mei (Gast)


Lesenswert?

Warum in die Schwerne feiefen, das Gute ligt so nah:

Beitrag "Re: stm32f103 1 us Systick-timer delay"

Einfach den DWT Cylce Counter zum beliebigen Zeitpunkt lesen
und daraus seine Auswertung kreieren.

von Stefan F. (Gast)


Lesenswert?

ARM Controller haben dafür den Systick Timer. Er löst üblicherweise jede 
ms einen Interrupt aus und die ISR erhöht dann überlicherweise eine 
Integer Variable. In dem Fall brauchst du einfach nur den Wert dieser 
Variable in dein Array kopieren.

Auch die HAL benutzt den Systick Timer auf diese Weise.

http://stefanfrings.de/stm32/stm32f3.html#systick

von jo mei (Gast)


Lesenswert?

Stefan F. schrieb:
> ARM Controller haben dafür den Systick Timer.

Der TO will es aber ein bisschen genauer wissen. Er will nicht
wissen dass ein Ablauf 1 oder 2 ms braucht.

von J. S. (jojos)


Lesenswert?

1 ms ist aber sehr grob und ein Interrupt jede ms nervt auch. Dann schon 
lieber einen Timer auf 1 µs frei laufen lassen und für Start/Stoppzeit 
auslesen. So einen Timer hat mein Lieblings OS als Standard drin und ein 
Softwaretimer ist mit 'Timer t;' schnell erzeugt :)

von Christoph K. (chriskuku)


Lesenswert?

jo mei schrieb:
> Stefan F. schrieb:
>> ARM Controller haben dafür den Systick Timer.
>
> Der TO will es aber ein bisschen genauer wissen. Er will _nicht_
> wissen dass ein Ablauf 1 oder 2 ms braucht.

Dem ist vom TO nichts hinzuzufügen.

von Stefan F. (Gast)


Lesenswert?

jo mei schrieb:
> Der TO will es aber ein bisschen genauer wissen. Er will nicht
> wissen dass ein Ablauf 1 oder 2 ms braucht.

Mit dem Systick kann man auch in kleiner Intervallen zählen. Aber es um 
einstellige µs oder gar ns Intervalle geht, ist der DWT wohl die bessere 
Wahl.

von jo mei (Gast)


Lesenswert?

Stefan F. schrieb:
> Mit dem Systick kann man auch in kleiner Intervallen zählen.

Klar! Du stellst den Systick-Interrupt auf 1 usec, dann
braucht dein Prozessor wenigstens nichts mehr Anderes tun
als Interrupts abarbeiten. Spart jede Menge Programmierarbeit.

von foobar (Gast)


Lesenswert?

> Im Hauptprogramm soll das jüngste Ereignis herausgefunden werden,
> indem das Maximum der Zeitstempel ermittelt wird.

Zwei Punkte:
 1) bzgl Maximum: mach dir Gedanken um Überläufe des Zählers.
 2) bzgl jüngste: in einer Variable die Nummer des letzten Ereignisses 
speichern?

von Stefan F. (Gast)


Lesenswert?

Stefan F. schrieb:
> Mit dem Systick kann man auch in kleineren Intervallen zählen. Aber
> wenn es um einstellige µs oder gar ns Intervalle geht, ist der DWT
> wohl die bessere Wahl.

jo mei schrieb:
> Klar! Du stellst den Systick-Interrupt auf 1 usec, dann
> braucht dein Prozessor wenigstens nichts mehr Anderes tun
> als Interrupts abarbeiten. Spart jede Menge Programmierarbeit.

Versuche es mal mit einer passenden Antwort. 10 µs Intervalle sind 
durchaus machbar. Darunter würde ich wie gesagt nicht gehen.

von Maxe (Gast)


Lesenswert?

Christoph K. schrieb:
> Gibt es im Debugger (STM32CubeIDE) eine Möglichkeit, die Zeit
> zwischen 2 Breakpoints zu messen?
Ich könnte mir vorstellen, dass der Debugger die Zeitspanne (negativ) 
beeinflusst. Also lieber direkt mit Registerzugriff arbeiten und nach 
der Messung erst die Dauer berechnen.

von J. S. (jojos)


Lesenswert?

Maxe schrieb:
> Ich könnte mir vorstellen, dass der Debugger die Zeitspanne (negativ)
> beeinflusst.

nein, das ist ja das Gute bei den Cortex-M: der CoreSight ist eine 
Architektur die die Ausführung eben nicht beeinflusst. Ausser vielleicht 
bei Software BP, aber die kommen ja nicht zum Einsatz solange noch HW BP 
vorhanden sind.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Christoph K. schrieb:
>> Der TO will es aber ein bisschen genauer wissen. Er will _nicht_
>> wissen dass ein Ablauf 1 oder 2 ms braucht.

> Dem ist vom TO nichts hinzuzufügen.

Ist angekommen. Als ich meine Antwort (mit dem Systick) schrieb, war mir 
das noch nicht klar.

von Christoph K. (chriskuku)


Lesenswert?

foobar schrieb:
>> Im Hauptprogramm soll das jüngste Ereignis herausgefunden werden,
>> indem das Maximum der Zeitstempel ermittelt wird.
>
> Zwei Punkte:
>  1) bzgl Maximum: mach dir Gedanken um Überläufe des Zählers.

Ja, Überlauf ist natürlich zu beachten. Selbst bei einer 2µs 
Granularität komme ich immer noch auf eine Lebensdauer von 72h.
Das wäre zwar noch zu tolerieren, aber auch nicht schön.

>  2) bzgl jüngste: in einer Variable die Nummer des letzten Ereignisses
> speichern?

Du meinst, eine Variable einführen, die das letzte Ereignis zusätzlich 
speichert? Das jüngste Ereignis wird ja ermittelt und es wird abgelöst 
durch immer wieder jüngere. Aber es gibt in der Tat sowas wie 
"last_event".

von H. Eggert (Gast)


Lesenswert?

Wenn ich's wissen will, programmiere ich einfach einen IO Pin zum 
Anzeigen wie lange ein Zeitabschnitt dauert. Mit dem Oszi kann man das 
für die Praxis in den meisten Fällen genau genug ermitteln. Bei 
Architekturen wie beim F103 ist es allerdings wegen der internen 
Peripherie etwas ungenauer.

von H. Eggert (Gast)


Lesenswert?

Irgendwo hat irgendwer erwähnt, daß er den DAC an interessanten Stellen 
im Programm so programmiert, daß man dann am Oszi genau verfolgen kann 
wo und wie lang sich der Prozessor im Programm aufhält. Ist eine Geniale 
Idee.

von Maxe (Gast)


Lesenswert?

J. S. schrieb:
> Maxe schrieb:
>> Ich könnte mir vorstellen, dass der Debugger die Zeitspanne (negativ)
>> beeinflusst.
>
> nein, das ist ja das Gute bei den Cortex-M: der CoreSight ist eine
> Architektur die die Ausführung eben nicht beeinflusst. Ausser vielleicht
> bei Software BP, aber die kommen ja nicht zum Einsatz solange noch HW BP
> vorhanden sind.

In deinem Link wird der DWT ja per Code gesteuert (und damit auch die 
Messung). Ueber den Debugger wird dann nur noch der Zahlerstand 
ausgelesen. Die Frage ist, ob es auch eine Loesung mit Breakpoints gibt.

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
Noch kein Account? Hier anmelden.