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
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.
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
Vieleicht so etwas: http://www.home.agilent.com/agilent/product.jspx?nid=-33609.959904.00&cc=DE&lc=ger
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.