Pulsweite messen

[Besserwessi]

Für eine genaue Messung der Zeiten sollte man den Timer durch laufen lassen, und die Differenzen zwischen den Zeiten für die fallende und steigende Flanke bilden.

Das CLI und SEI in der ISR ist überflüssig, bzw, sogar fehlerträchtig. Das Interrupt-Bit ist in der ISR ohnehin schon gelöscht - CLI macht also nicht. Und am Ende wird das Bit wieder gesetzt - das SEI ist überflüssig und in aller Regel eher schädlich.

[Chypsylon]

@BMS: Sowas habe ich mir auch schon überlegt aber dabei wird das Programm ziemlich verlangsamt da er in der zähler-whileschleife "hängen bleibt". Außerdem sind einige delays von ein paar ms im Hauptloop eingebaut (z.b. displayausgabe, Tasterentprellung usw..)
[OT]

PS: Die Zeiten kommen mir bekannt vor Robocupjunior neuer Ball (RCJ-05) - Auswertung mit einem TSOP?

Exakt Bist du eigentlich noch dabei? [/OT]

Für eine genaue Messung der Zeiten sollte man den Timer durch laufen lassen, und die Differenzen zwischen den Zeiten für die fallende und steigende Flanke bilden.

Aber was ist wenn der Timer während der Messung überlauft und wieder bei 0 beginnt? Dann habe ich ja ein falsches negatives Ergebnis?
EDIT: Bin selber draufgekommen - if(erste_messung>zweite messung) zeit= 65536-erste_messung + zweite_messung;

Werde ich dann mal probieren...

Das CLI und SEI in der ISR ist überflüssig, bzw., sogar fehlerträchtig. Das Interrupt-Bit ist in der ISR ohnehin schon gelöscht - CLI macht also nicht. Und am Ende wird das Bit wieder gesetzt - das SEI ist überflüssig und in aller Regel eher schädlich.

Danke für den Hinweis, ich habe irgendwo gelesen das vor Zugriff auf dieses Register alle Interrupts deaktiviert sein sollen - hab wohl im "Eifer des Gefechts" vergessen das diese in der ISR sowieso in die "Warteschlange" gereiht werden

[sternst]

Aber was ist wenn der Timer während der Messung überlauft und wieder bei 0 beginnt? Dann habe ich ja ein falsches negatives Ergebnis?

Du nimmst die passenden Datentypen (uint16_t) und schon regelt sich das von alleine.

EDIT: Bin selber draufgekommen - if(erste_messung>zweite messung) zeit= 65536-erste_messung + zweite_messung;

Einfaches Abziehen reicht, wenn erste_messung und zweite_messung uint16_t sind.

[wkrug]

Ich würde es schon mit dem Input Capture Interrupt machen, weil das praktisch im Hintergrund läuft.

Der Trick dabei ist, das Sensing, also ob der Interrupt auf steigende oder fallende Flanke reagiert in der Interruptroutine umgeschaltet wird.

Das Sensing wird also zunächst auf fallende Flanke eingestellt.
Tritt dieser Interrupt dann auf wird das Input Capture Register ausgelesen und in einer Variable zwischengespeichert.
Zusätzlich wird das Interrupt Sensing auf steigende Flanke umgestellt.

Wird nun irgendwann durch die steigende Flanke der ICP Interrupt ausgelöst, wird das Input Capture Register ausgelesen und der vorher abgespeicherte Wert abgezogen.
Der Unterschied ist das Mass für die gemessene Pausenlänge, also Dein gewünschtes Ergebnis.
Sogleich wird das Interrupt Sensing wieder auf fallende Flanke für die nächste Messung eingestellt.

Ob es dabei zu Überläufen bzw. Fehlberechnungen bei der Subtraktion, kommt wird vom Compiler abhängig sein.
Üblicherweise kommt es bei der reinen Subtraktion von 2 16Bit Unsigned Int Variablen zu keinen Rechenfehlern.
Ich nehm da immer gerne einen 8MHz Quarz und einen Vorteiler von 8, weil dann das errechnete Ergebnis direkt in µs rauskommt.
Die maximal mögliche Messlänge ist dabei 65535µs. Sonst ist ja der Timer ( 16Bit ) bereits einmal komplett durchgelaufen.

Günstig ist es auch, wenn in der Interruptroutine ein Flag ( Bit Variable ) nach einer neuen Berechnung gesetzt wird, damit das Hauptprogramm weiß, das es wieder was zu tun hat.
Wenn das Hauptprogramm den gemessenen Wert verarbeitet hat, wird dieses Flag einfach wieder gelöscht.

[sternst]

Ob es dabei zu Überläufen bzw. Fehlberechnungen bei der Subtraktion, kommt wird vom Compiler abhängig sein.

Nein, es sei denn der Compiler ist fehlerhaft. Über-/Unterläufe bei Unsigned-Integer-Arithmetik sind im C Standard eindeutig definiert.

[BMS]

[OT]PS: Die Zeiten kommen mir bekannt vor Robocupjunior neuer Ball (RCJ-05) - Auswertung mit einem TSOP?
Exakt Bist du eigentlich noch dabei? [/OT]

Bin nicht mehr dabei, studiere jetzt Elektrotechnik, 2.Semester

Wie viele TSOP wertest du denn aus? Weil es gibt nur relativ wenige Pins, an denen du mit Input Capture arbeiten kannst.

Grüße, Bernhard

[wkrug]

Wie viele TSOP wertest du denn aus? Weil es gibt nur relativ wenige Pins, an denen du mit Input Capture arbeiten kannst.

Man kann auch noch die Interrupt Quellen INTx verwenden, da sich da auch das Sensing einstellen lässt.
Allerdings produziert man da einen kleinen Fehler, weil man dabei ja nur das TCNT Register auslesen kann, das ja immer weiter hochzählt.