Forum: Mikrocontroller und Digitale Elektronik Hochauflösende Zeitmessung/Capture


von Guizmo (Gast)


Lesenswert?

Hallo Forum!
Ich möchte möglichst genau die Zeit zwischen zwei Flanken messen.
Bisher habe ich das mit dem Capture-Modul gemacht: Das Startsignal auf 
INT0 und das Endsignal auf ICP0 eines mit 20MHz laufenden ATmega.
Das klappte auch ganz gut, nur liegt die Granularität nur bei 50ns
Gibt es eine Möglichkeit mit vertretbarem Aufwand die Genauigkeit bis 
auf 10ns zu verbessen?

Alternative:
Mit einem CPLD oder FPGA ist das sicher realisierbar (Takt 100MHz, 32 
oder 64 Bit Counter etc) nur habe ich damit keine Erfahrung. Wenn, dann 
würde ich in die Thematik anhand eines "kleinen" Bausteins einsteigen 
bei dem evtl. auch ein Dev-Kit mit kostenlosen Tools (oder geringen 
Kosten) verfügbar ist.

Bin für jeden Hinweis dankbar.

Beste Grüße,

Guizmo

von Kakadu (Gast)


Lesenswert?

Wie lang sind die Zeiten? 10ns - ???
Unter Umständen kann man die Messung auch mit ein bißchen Logik und 
einem entsprechenden Zähler machen.

von sum (Gast)


Lesenswert?

Hallo Guizmo,

wie wär es, einen Kondensator über einen konstanten Strom zu laden und 
diesen Ladestrom dann abzuschalten, wenn Deine Flanke kommt? Danach die 
Spannung am Kondensator messen und Du kannst die Zeit ausrechnen, die 
verflossen ist. Unter Umständen den Kondensator regelmäßig entladen, 
damit Du auch längere Zeiten messen kannst. Ich weiss nicht, ob diese 
Technik diskret realisierbar ist - sie kommt aus der IC-Technik.

Schöne Grüße,
 Clemens

von Guizmo (Gast)


Lesenswert?

Im AVR habe ich eine geweisse Flexibilität was die Einstellung des 
Vorteilers von Timer1 angeht. Das interne 16-Bit Register kann dann 
verschiedene Szenarien und Auflösungen abbilden.
Diese Flexibilität möchte ich auch in der weiteren, evtl. Hardwarelösung 
realisieren. 32 oder 64-Bit Register mit einstellbarem Takt/Vorteiler.

Im vorhinein kann ich derzeit nicht festlegen welche Auflösungen und 
welche maximalen Erfassungszeiten notwendig werden. Ich suche daher nach 
einer möglichst flexiblen Lösung die man mit kleinen Änderungen 
(Oszillator etc.) an neue Anforderungen anpassen kann.

Grüße,
Guizmo

von Karl H. (kbuchegg)


Lesenswert?

Guizmo schrieb:
> Ich möchte möglichst genau die Zeit zwischen zwei Flanken messen.
> Bisher habe ich das mit dem Capture-Modul gemacht: Das Startsignal auf
> INT0 und das Endsignal auf ICP0 eines mit 20MHz laufenden ATmega.

Hmm. Wie misst du da eigentlich?
Sag jetzt bitte nicht, dass du mit dem INT0 den Timer startest und mit 
dem Capture dann auswertest. Sags bitte nicht.

Sonst muss ich dich auf einen Artikel zum Thema
"Auflösung versus Genauigkeit" verweisen.

(für die anderen: 50ns ist die Taktzeit bei 20Mhz. Jeder Takt zählt. 
Auch die Takte die unter "Interrupt Latenz" zusammengefasst werden. Also 
der Zeit die vergeht, vom Auftreten des Interrupts bis zum Abarbeiten 
des ersten Befehls in der ISR. Und diese Zeit ist nicht konstant, 
sondern hängt davon ab, bei welchem gerade ausgeführten Befehl der 
Interrupt zuschlägt)

von Kakadu (Gast)


Lesenswert?

>Im vorhinein kann ich derzeit nicht festlegen welche Auflösungen und
>welche maximalen Erfassungszeiten notwendig werden.

Toll! Dann laß es einfach bleiben.

von Hagen R. (hagen)


Lesenswert?

Karl heinz Buchegger schrieb:

>(für die anderen: 50ns ist die Taktzeit bei 20Mhz. Jeder Takt zählt.
>Auch die Takte die unter "Interrupt Latenz" zusammengefasst werden. Also
>der Zeit die vergeht, vom Auftreten des Interrupts bis zum Abarbeiten
>des ersten Befehls in der ISR. Und diese Zeit ist nicht konstant,
>sondern hängt davon ab, bei welchem gerade ausgeführten Befehl der
>Interrupt zuschlägt)

Weswegen man auch den ICP-Modus der Timer benutzt, der diese Probleme 
dann zumindest zum Teil hardwarmäßig lösst.

Gruß Hagen

von Karl H. (kbuchegg)


Lesenswert?

Hagen Re schrieb:

> Weswegen man auch den ICP-Modus der Timer benutzt, der diese Probleme
> dann zumindest zum Teil hardwarmäßig lösst.

Eben.
Nur frage ich mich, was dann das Startsignal am INT0 soll.

Mir scheint, da ist wieder mal wer von der Fraktion:
Was interessieren mich Details, hauptsache haufenweise Kommastellen auf 
der Ausgabe. Je mehr desto besser.

Und ich frage mich zb auch, ob er seinen Quarz temperaturstabil betreibt 
und auf jedes einzelne Hz ausgemessen hat.

von Hagen R. (hagen)


Lesenswert?

>Eben.
>Nur frage ich mich, was dann das Startsignal am INT0 soll.

Anders Thema ;) Deine Aussage:

>Jeder Takt zählt.
>Auch die Takte die unter "Interrupt Latenz" zusammengefasst werden. Also
>der Zeit die vergeht, vom Auftreten des Interrupts bis zum Abarbeiten
>des ersten Befehls in der ISR.

suggeriert das dies auch beim ICP Modus der Timer so wäre und die 
Messergebnisse unvorhersehbar verfälscht würden, was natürlich nicht 
stimmt.

Jetzt im Nachhinein und dem geänderten Kontext ist mir schon klar das du 
dich damit auf den INT0 beziehst der hypothetisch betrachtet durch den 
OP per Software ausgewertet wurde.

Gruß Hagen

von Guizmo (Gast)


Lesenswert?

@Karl heinz Buchegger:

Ja, so wäre das im Prototypen geplant gewesen. Die CPU macht eigentlich 
nichts weiter als auf den den INT0 zu warten. Die Zeit in die ISR ist 
damit vorhersehbar und in das Ergebnis einrechenbar.
Das nächste Ereignis ist erst viel später, lang nachdem die CPU das 
Ergebnis über den UART ausgegeben hat.

Danke für den Link auf den anderen Artikel, den habe ich mir mal vor 
einiger Zeit schon durchgelesen.

@Kakadu:

>Toll! Dann laß es einfach bleiben.

Die Hardware möchte ich möglichst nur einmal bauen und dann für 
verschiedene Zwecke nutzen.

@Alle die ein konkretes Beispiel benötigen:

Fall 1: Messung von Intervallen bis 500µs, Ergebnis +- 10ns
Fall 2: Messung von Intervallen bis 500µs, Ergebnis +- 50ns

Bei Messungen > 16bit mit dem AVR muss man ja dann einen Zähler im 
Timer1-Overflow mitlaufen lassen.

Grüße

von Hagen R. (hagen)


Lesenswert?

@Guizmo:

dann benutzt du den ICP Modus der Timer nicht korrekt und wie es Karl 
Heinz schon schreib handelst du dir Messungenauigkeiten die durch 
unverhersehbares Softwaretiming entstehen ein. Auch wenn du meinst das 
das alles vorhersehbar für dich wäre, was es definitiv im Lauf der 
Evolution einer Software nicht ist. Vom Aufwand/Nutzen ist die korrekte 
Benutzung der ICP Hardware besser und sogar einfacher umzusetzen.

Der weitere Einwand mit der Quarzgenauigkeit ist ebenfalls berechtigt.

Gruß Hagen

von Hagen R. (hagen)


Lesenswert?

Eine einfache Möglichkeit deine Auflösung im errechneten Endergebnis zu 
erhöhen ist mehrere Messung nacheinander zu mitteln. Bei 4 Messungen um 
2 Bits zB.

Aber:
- das Signal muß repetiv sein
- das gesamte Messsystem und/oder Signal muß auch leicht zufällig sein

Gruß hagen

von Karl H. (kbuchegg)


Lesenswert?

Guizmo schrieb:

> Ja, so wäre das im Prototypen geplant gewesen. Die CPU macht eigentlich
> nichts weiter als auf den den INT0 zu warten. Die Zeit in die ISR ist
> damit vorhersehbar und in das Ergebnis einrechenbar.

No. Das mindeste ist eine enge Schleife mittels rjmp. Und je nachdem 
wann genau der Interrupt auftaucht, dauert es unterschiedlich lange, bis 
du in die ISR kommst.

Du musst alles über den ICP laufen lassen, wenn du eine Chance haben 
willst auf die Genauigkeit (nicht Auflösung!) zu kommen.

Und du musst deinen Quarz stabilisieren. Der hat nicht exakt 20000000 
Hz. Und die genaue Frequenz ändert sich auch noch mit der Temperatur. Du 
wirst morgens, wenn es kühler ist, andere Eregbisse bekommen als 
Mittags, wenn die Sonne den Raum aufheizt.

Wenn man in diese Zeitbereiche vorstößt, sind die Dinge nicht mehr so 
einfach.

von Peter D. (peda)


Lesenswert?

10ns schaffst Du z.B. mit dem C8051F120:

"High-Speed pipelined 8051-compatible CIP-51 microcontroller core (100 
MIPS or 50 MIPS)*"

Du kannst sogar 6 Eingänge parallel messen:

"The Programmable Counter Array (PCA0) provides enhanced timer 
functionality while requiring less CPU
intervention than the standard 8051 counter/timers. PCA0 consists of a 
dedicated 16-bit counter/timer and
six 16-bit capture/compare modules."


Peter

von Guizmo (Gast)


Lesenswert?

@Karl heinz Buchegger:

Die Quarzheizung hatte ich übersehen, wobei ich mir bei einer meiner 
Anwendung die ursprüngliche Hardware angesehen habe, die diskret 
aufgebaut und nicht beheizt war.
Ich denke die beste Lösung wird erstmal die korrekte Nutzung des ISP 
sein, ein PTC direkt am Quarz zur Temperaturstabilisierung und ein AVR 
mit 20MHz.

Grüße

von U.R. Schmitt (Gast)


Lesenswert?


von Uwe .. (uwegw)


Lesenswert?


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.