Frequenzmessung per ICP

[Liquidator]

Das Signal wurde mit einem Oszilloskop untersucht und ist präzise, hier liegt kaum der gesuchte Fehler vor.
Ich schreibe mal die ganze Berechnungsroutine in die main() rein, damit kürzt sich die unsigned long- Variable aus der ISR.

Dann gilt es jetzt die unsigned long Zeit zu analysieren...Was erwartest du da zu sehen? Ich meine, es werden eben größere Sprünge zu sehen sein, doch worauf willst du hinaus?
Bis 2Khz habe ich es mir eigentlich einfacher vorgestellt mit der Messung...

MfG,
Nik

P.S: mal hypothetisch, was könnten für Fehler an einem TTL-Signal +5V auftreten?

[markusj]

Das und den 2^16 Fehler verstehe ich leider nicht ganz. Die Differenz wird ihrer Größe wegen in einer unsigned long-Variable gesichert. Wäre es besser wenn ich es in der main() berechne?

Vergiss den 2^16-Fehler, da lag ich daneben. Danke Stefan, ich hatte die Logik dahinter nicht ganz durchdrungen.

Was die Subtraktion angeht: Start 0xff00 und Ende 0x00ff entspricht eigentlich einer Zeit von 0x1ff. Wenn du die voneinander subtrahierst bekommst du bei einer 16-Bit-Subtraktion dank abgeschnittener Carry-Bits auch tatsächlich 0x1ff heraus, bei einer 32-Bit-Subtration wäre das Ergebnis aber 0xffff01ff. Lösen lässt sich das Problem, indem du die Subtraktion in Klammern setzt und das Ergebnis auf uint16_t castest.

Grüße,
Markus

[sternst]

Was die Subtraktion angeht: Start 0xff00 und Ende 0x00ff entspricht eigentlich einer Zeit von 0x1ff. Wenn du die voneinander subtrahierst bekommst du bei einer 16-Bit-Subtraktion dank abgeschnittener Carry-Bits auch tatsächlich 0x1ff heraus, bei einer 32-Bit-Subtration wäre das Ergebnis aber 0xffff01ff. Lösen lässt sich das Problem, indem du die Subtraktion in Klammern setzt und das Ergebnis auf uint16_t castest.

Sorry Markus, aber du liegst wieder daneben.
Im Prinzip hast du ja Recht mit der 16-Bit-Arithmetik, aber so einfach ist es nur, wenn die Capture-Länge immer unter einer Timer-Periode liegt, man also keine Overflows mitzählen und einrechnen muss. Wenn man aber mitzählt, dann hat man immer bei Start>Ende einen Overflow gezählt, der nicht hinzugerechnet werden darf. Entweder macht man eine zusätzliche Abfrage und korrigiert die gezählten Overflows ggf, oder man beschränkt das Ende-Start eben NICHT auf 16-Bit, dann fällt dieser zusätzliche Overflow nämlich ganz von alleine raus. Nimm doch einfach mal deine eigenen Beispielwerte und rechne damit die Formel im Code komplett aus, und nicht nur teilweise.

[markusj]

Sorry Markus, aber du liegst wieder daneben.

Und du hast schon wieder recht, irgendwie war gestern nicht mein Tag ...

mfG,
Markus