ATMEGA 328P Frequenzzähler Jittert

[Gnom67]

Die Schwankung liegt um die 400 Prozessortakte - das erscheint mir auch nicht akzeptabel.
Ich würde mal die gesamte Verarbeitung der Daten aus der ISR rausnehmen - die ISR sollte so kurz wie möglich sein. Dort gehört eigentlich nur die Abfrage des Timers rein. Newcount würde ich ebenfalls als globale Variable definieren. Evtl. ein Flag setzen, damit du weißt, dass ein neuer Wert gelesen wurde. Die Verarbeitung kommt dann in den Hauptteil. Allerdings müsste man mal genauer schauen, welche Variante ggf. schneller ist. Direkter Zugriff auf eine globale Variable oder erst irgendeine Zwischenspeicherung in einem Register zwecks Übergabe an eine lokale Variable... das geht dann doch sehr ins Detail.
Du rechnest newcount-oldcount. Was passiert, wenn der Timer übergelaufen ist und newcount kleiner ist als oldcount? Du hast measure als uint32 und oldcount und newcount als uint16 definiert - kann das probleme geben? Ich denke eigentlich nicht.
Die Lösung mit Loopcount finde ich auch nicht besonders elegant. Ich würde im Hauptteil eine Zeitgesteuerte Ausgabe basierend auf millis machen.
Trotzdem, abgesehen davon, das der größte Teil deiner Programmlogik in der ISR steht, wo er nicht hin gehört, finde ich keinen Grund, warum das nicht halbwegs ordentlich laufen soll.
Probier mal die 8 ms zu erhöhen. 10 x 20ms oder 4 * 50 ms - ob sich dann was ändert.
Übringens - was soll das eigentlich bringen, wenn du 25 Messungen in 8 ms Abstand machst? Dadurch wird es doch nicht genauer... (im Gegenteil) stell den Timer auf 200 ms, messe den Wert und gib ihn aus...

[wkrug]

Ich würde mal die gesamte Verarbeitung der Daten aus der ISR rausnehmen - die ISR sollte so kurz wie möglich sein. Dort gehört eigentlich nur die Abfrage des Timers rein.

Im Prinzip hast Du recht - Ich seh da aber keinen Weg hin.
Im Prinzip frag ich eigentlich nur den Timer ab und zieh den letzten gemessenen Wert ab und summiere dann die Werte 25 mal.
Erst bei 25 Durchlauf wird das Ergebnis übertragen.
Die komplette Interupt Routine ohne Registerrettung dauert übrigens 44 Prozessortakte = 2,75µs ohne Aufruf und Registerrettung ( Die ohnehin immer stattfindet ).
Die Berechnung in der Hauptroutine zu machen funktioniert leider nicht, weil allein die Displayausgabe 11ms dauert und somit mindestens eine Messung verloren ginge!

Du rechnest newcount-oldcount. Was passiert, wenn der Timer übergelaufen ist und newcount kleiner ist als oldcount? Du hast measure als uint32 und oldcount und newcount als uint16 definiert - kann das probleme geben? Ich denke eigentlich nicht.

Da alle Variablen als Unsigned definiert sind, sollte das kein Problem geben.
Hab Ich auch des Öfteren schon so gemacht.

Die Lösung mit Loopcount finde ich auch nicht besonders elegant. Ich würde im Hauptteil eine Zeitgesteuerte Ausgabe basierend auf millis machen.
Trotzdem, abgesehen davon, das der größte Teil deiner Programmlogik in der ISR steht, wo er nicht hin gehört, finde ich keinen Grund, warum das nicht halbwegs ordentlich laufen soll.

Die Lösung mit den kurzen 8ms hab ich so gewählt, weil nach 25 Durchläufen 200ms erreicht sind und somit das Ergebnis für die Ausgabe nur noch mit 5 multipliziert werden muß um die reale Frequenz zu erhalten.
Zudem kann TCNT1 bis maximal 65635 Zählen. Damit sind theoretisch Frequenzen bis 8MHz messbar, was auch gewollt ist ( Ich brauch mindesten 1,2MHz ).

Ich hab auch schon versucht 2 Timer hintereinander zu schalten und somit den kompletten Zählvorgang in Hardware zu erledigen.
Da die Timer aber dann wieder auf 0 gesetzt werden müssen, was ja nicht absolut gleichzeitig geschehen kann gab hier noch mehr Probleme.

Übringens - was soll das eigentlich bringen, wenn du 25 Messungen in 8 ms Abstand machst? Dadurch wird es doch nicht genauer... (im Gegenteil) stell den Timer auf 200 ms, messe den Wert und gib ihn aus...

Genau 200ms zu generieren ist mit den gegebenen 16Mhz Quarz und einem 8 Bit Timer nicht möglich.
Ausserdem würde man so die max mögliche messbare Frequenz auf 327KHz beschränken.

[Siro]

sorry, Problem missverstanden.

[wkrug]

Das Rätsel scheint gelöst!
Ich hab nun anstatt der internen 8MHz Quelle einen externen 16MHz Oszillator angeschlossen.
Nun liegen die gemessenen Werte im erwarteten Bereich von +/- 5Hz ( = 1 Count bei 200ms Torzeit ).
Die Messung läuft jetzt bis 7MHz stabil!

Das hat meine alte Meinung bestätigt einen AVR Controller nur mit genauer Taktquelle zu verwenden, sonst gibts nur Ärger.

Trotzdem Danke für die Tipps - Ich werde die soweit als möglich anwenden.

Das Ganze soll übrigens ein Frequenzzähler für UKW und MW werden ( Mit Vorteiler natürlich ).
Als zusätzliche Aufgabe soll auch noch RDS decodiert werden.
Ich möchte damit meinen alten Radiotuner aufmotzen! - Mal gucken, was daraus wird...

[Holomino]

Mal interessehalber (auch wenn der Jitter "nur" im Promillebereich liegt): Die Fehler des RC-Oszillators im DB beziehen sich ja nicht nur auf die Temperatur, sondern insbesondere auch auf die Betriebsspannung. Entsprechend die Frage: Hast Du mal mit dem Oszi gemessen, ob die Versorgung am Controller sauber ist?

[wkrug]

Es ist ne kleine Störspannung mit 60mVpp drauf.
Das Ganze ist noch auf einem Steckboard mit nem Labornetzteil.

Ich hab jetzt noch einen zusätzlichen Elko in die Versorgungsspannung gelegt.
Die Störspannung ist jetzt auf 5mVpp runter.
Trotzdem Jittert die Schaltung mit dem internen Oszillator immer noch ( ohne Änderung am Hauptprogramm );