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
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
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
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)
>Im vorhinein kann ich derzeit nicht festlegen welche Auflösungen und>welche maximalen Erfassungszeiten notwendig werden.
Toll! Dann laß es einfach bleiben.
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
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.
>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
@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
@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
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
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.
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
@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
