Frequenzzähler mit atmega48

Hast Du einen Schaltplan,

dann schreibe ich Dir eine neue Firmware, wenn ich so eine Musterplatine 
hätte.

Hallo Lukas ,

es wird wohl Timer1 mit Input T1, bei 20MHz ext. Takt und ein 1:64 
Vorteiler verwendet.
Dadurch kann man einen schönen reziproken Frequenzzähler programmieren.
Ich würden den einfachen Quarz noch gegen einen 20MHz TCXO oder OCXO 
ersetzen.

Das LCD ist ein ein 8 Zeichen x 2 Zeilen organisiert, wenn es keinen 
exotischen Chip hat, ist die Ansteuerung kein Problem.

Bei Ebay findet man unter "8 x 2 LCD Modul 0802 Zeichen" ein 
vergleichbares Modul.
http://www.ebay.de/itm//252658879655
Betriebsspannung: 5V
Hintergrundbeleuchtung
Anzeige Format: 8 Zeichen x 2 Zeilen
Charakter Groesse: 2,96 x 5,56 mm
Controller-IC: KS0066U

Lukas schrieb:
> gibt es für den Frequenzzähler hier:
>
> Ebay-Artikel Nr. 131693166348
>
> eine alternative Software,

Was soll die neue Software denn anders machen?

Karl M. schrieb:
> es wird wohl Timer1 mit Input T1, bei 20MHz ext. Takt und ein 1:64
> Vorteiler verwendet.
> Dadurch kann man einen schönen reziproken Frequenzzähler programmieren.

Bei der angegebenen Auflösung von (nur) 100 Hz vermute ich eher einen 
torgesteuerten Ereigniszähler, der sich ohne input-capture-Eingang kaum 
zum reziproken Zähler umbauen läßt.

m.n. schrieb:
> Was soll die neue Software denn anders machen?

Immer bis zum Ende des Satzes lesen ...

Lukas schrieb:
> eine alternative Software, _oder die bestehende Software irgendwo?_

Klingt so, als ob er den Zähler nachbauen und den Controller dafür 
(natürlich) mit irgendwas Lauffähigem flashen muss.

Zweifler schrieb:
> m.n. schrieb:
>> Was soll die neue Software denn anders machen?
>
> Immer bis zum Ende des Satzes lesen ...

Das ändert nichts an meiner Frage.

Hallo,

m.n. schrieb:
> Bei der angegebenen Auflösung von (nur) 100 Hz vermute ich eher einen
> torgesteuerten Ereigniszähler, der sich ohne input-capture-Eingang kaum
> zum reziproken Zähler umbauen läßt.

Ich habe mir gestern Abend noch einen Schaltplan von der Baugruppe 
abgeleitet.
Das geteilte (1:64) Zählersignal gelangt über T1 in die Zählregister von 
Timer1. Über Timer0 oder Timer2 kann man dann eine Zeitbasis herleiten.
Die 8x2 LCD-Ansteuerung und die zugehörige Pinbelegung muss man noch 
ausmessen - auch kein Akt.

Falls nun das 8x2 LCD keine negative Konstrastspannung benötigt, die man 
i.a. über einen TimerN mit negativer Ladungspumpe erzeugen kann, werden 
dann auch nur insgesamt 2 Timer belegt.

Die 100Hz Auflösung kommen u.a. durch den normalen Quarz und von der 
begrenzen Stellenanzahl auf dem 8x2 LCD.
Zeile 1: "500.0000"
Zeile 2: "   MHZ  "

Karl M. schrieb:
> Die 100Hz Auflösung kommen u.a. durch den normalen Quarz und von der
> begrenzen Stellenanzahl auf dem 8x2 LCD.
> Zeile 1: "500.0000"
> Zeile 2: "   MHZ  "

Die Auflösung hängt nicht vom Quarz ab und mit dem Display kann ich mir 
auch andere Frequenzen anzeigen lassen wie z.B.:
Zeile 1: "500.1234"
Zeile 2: "   Hz   "

Wenn das Signal über den T1 Eingang rein kommt, ist die HW nicht so gut 
für einen Reziprokzähler geeignet. Ein Receporkzähler würde das Signal 
am ICP Eingang oder ggf. noch Ersatzweise an einem der analogen 
Eingänge, notfalls dem Koparator haben wollen.

Beim klassischen Zähler ist halt die Auflösung begrenzt, vor allem bei 
niedriger Frequenz.

Lurchi schrieb:
> Receporkzähler
...
> Koparator

Wassn das? :-)

Hallo,

nun dann, schreibst Du aus eigener Erfahrung ?
Ich habe schon verschiedenste reziproke Frequenzzähler programmiert und 
den ICP Eingang von Timer1 benötige ich dabei nicht.

Lurchi schrieb:
> Wenn das Signal über den T1 Eingang rein kommt, ist die HW nicht
> so gut
> für einen Reziprokzähler geeignet. Ein Receporkzähler würde das Signal
> am ICP Eingang oder ggf. noch Ersatzweise an einem der analogen
> Eingänge, notfalls dem Koparator haben wollen.
>
> Beim klassischen Zähler ist halt die Auflösung begrenzt, vor allem bei
> niedriger Frequenz.

Karl M. schrieb:
> Ich habe schon verschiedenste reziproke Frequenzzähler programmiert und
> den ICP Eingang von Timer1 benötige ich dabei nicht.

Dann mußt Du allerdings deutliche Abstriche bei der Genauigkeit 
hinnehmen. Elegant ist das nicht.

Hallo m.n.

"viele Wege führen nach Rom": und da du den Ansatz nicht kennst und 
voreilig schon negative Schlüsse zieht, möchte ich Dich auf die 
Implementierung des "Reziproker Frequenzzähler + Optimierte 64 Bit UInt 
Routinen" von Matthias Hopf hinweisen:

Beitrag "Reziproker Frequenzzähler+ Optimierte 64bit uint Routinen"

Und jetzt schreibe bitte nicht, dass man noch einen INTx Eingang o.ä. 
benötigt, ja so ist das. :-)

Stimmt, kenne ich nicht. Ich habe kein Programm installiert und auch 
keinen Bedarf, um .tgz zu öffnen.
In der Beschreibung steht etwas von 10 ppm Auflösung. Das sind gerade 5 
Stellen. Da gibt es eine Schaltung, die das gleich für 4 Kanäle macht: 
http://mino-elektronik.de/fmeter/fm_software.htm#bsp4

Wozu denn irgendwelche 64 Bit Routinen erfinden, wenn man doch einfach 
und schnell - wie zuvor gezeigt - mit float rechnen kann?
Die Referenzfrequenz grundlos ohne Timer-capture zu erfassen, ist 
schlechtes Design, als wenn man die FPU im µC links liegen läßt und 
durch Software emuliert.

Karl M. schrieb:

> "viele Wege führen nach Rom": und da du den Ansatz nicht kennst und
> voreilig schon negative Schlüsse zieht

Das ist NICHT voreilig.

> möchte ich Dich auf die
> Implementierung des "Reziproker Frequenzzähler + Optimierte 64 Bit UInt
> Routinen" von Matthias Hopf hinweisen:

Der gute Mann hat sich zwar sehr bemüht, aber er kann auch nicht 
zaubern. Das ist nix Schlimmes: schließlich kann das niemand.

...

Es gibt beim AVR8 genau zwei Möglichkeiten, die Flanken eines zu 
messenden Signals mit einer (weitaus höheren) Referenzfreqenz zu 
vergleichen, reine Software oder die Verwendung der 
Timer-Capture-Peripherie.

Letztere ist in der Lage, die Flanken mit der Genauigkeit von einer 
Periode der Referenzfrequenz (Systemtakt) zu erfassen, Software ist in 
jedem Fall deutlich ungenauer, weil man in einem Takt kein sinnvolles 
Programmstück abarbeiten kann, was die notwendigen Funktionen leistet. 
Sie braucht schonmal zwei Takte, um überhaupt eine Endlosschleife 
konstruieren zu können, mit drei Takten schafft sie dann eine Schleife 
mit Abbruchmöglichkeit. Das aber ist das absolute Minimum, was diese 
Meßaufgabe an Funktionalität von der Software erfordert.

Woraus sich ganz unmittelbar der Schluss ziehen läßt, das eine reine 
Softwarelösung (maximal) ein Drittel der Genauigkeit haben kann. 
Tatsächlich sieht das in realen Implementierungen noch deutlich 
schlechter aus, zumal in C. Also auch in der des Herrn Hopf...

Wie auch immer, der einziger Ausweg der Software ist: Messungen zu 
mitteln. D.h.: sie muss deutlich öfter messen als die Hardwarelösung, um 
die gleiche Genauigkeit erreichen zu können. Was unmittelbar heißt: sie 
kann nur deutlich seltener einen gleich genauen Meßwert liefern.

Dazu kommt dann noch die Interaktion über das Timing mit dem Rest der 
Software, die eventuell auf dem gleichen Controller laufen muss. Das ist 
oft noch ein viel größeres Problem...

Das einzige, was also Lösungen wie die des Herrn Hopf eine gewisse 
Existenzberechtigung zu verleihen vermag, ist die Tatsache, dass sie 
auch ohne Capture-Hardware funktionieren. Was allerdings spätestens dann 
kein substantieller Vorteil mehr ist, wenn man entsprechende Hardware 
einfach mal hat...

...

Aber klar, wenn es nur darum geht, das Ergebnis über ein Display an 
einen Menschen auszuliefern, ist das alles Pillepalle. Dann hat man 
unzählige Takte zur Verfügung und kann ewig viele Samples mitteln, bevor 
ein Update des Displays irgendeinen Sinn ergibt. Schlicht, weil ein 
Mensch Grenzen bei der Wahrnehmung hat. Öfter als mit 2..4Hz braucht man 
eine mehrstellige Digitalanzeige einfach mal nicht aktualisieren, weil 
es sowieso keiner mehr hinreichend schnell ablesen könnte...

Hallo m.n. und c-hater,

ich lese eure fachlichen Beiträge häufig mit und gerade was die 
Assemblerprogrammierung angeht freue ich mich immer neue Ideen von Dir 
c-hater auf zugreifen.

Nur leider irrt ihr beide in der Funktionsweise des
"Reziproker Frequenzzähler + Optimierte 64 Bit UInt Routinen" von 
Matthias Hopf.

Wir er im ersten Beitrag zeigt, wird gerade nicht nur ein Takt des 
Eingangssignals lang der Systemtakt gezählt, sondern mehrere Perioden.

Er schreibt:
--------------------------------------
Ein reziproker Frequenzzähler zählt sowohl die Zyklen des Systemtakts,
als auch die der 1-0-Übergänge des Eingangssignals.
Der Zählerstart erfolgt an einem 1-0-Übergang, und endet nach einer 
minimalen Samplingzeit (500ms hier) wieder an einem 1-0-Übergang. Da das 
ganze in Software realisiert wird, kann ein Interrupt zu genau dem 
falschen Zeitpunkt die Genauigkeit reduzieren - das README erklärt, wie 
ich auf die 10ppm komme. Die Berechnung ist nicht trivial, da könnten 
also auch noch Fehler enthalten sein.

Nach dem Zählen hat man zwei Zahlen: n_CLK (Taktzahl bei einer 
Taktfrequenz f_CPU) und n_EVT (Anzahl an 1-0-Übergängen).
Die Frequenz ergibt sich dann als:

   f = n_EVT * f_CPU / n_CLK
--------------------------------------

Somit wird der TimerN als Hardwarezähler mit Softwareerweiterung auf 
32Bit benutzt der die 1-0-Übergänge des Messsignal zählt.
Nach Ablauf der Messzeit wird über einen Interrupt Eingang (INTn) der 
Letzte 1-0-Übergang als Stoppzustand gewertet.
Der nächste 1-0-Übergang entsprechen als Startzustand, usw.
Man kann natürlich auch beides miteinander verbinden.

Karl M. schrieb:

> Somit wird der TimerN als Hardwarezähler mit Softwareerweiterung auf
> 32Bit benutzt der die 1-0-Übergänge des Messsignal zählt.

Genau das ist der Knackpunkt, wie ich dir oben zu erklären versuchte.

Man muss über etliche Perioden der Messfrequenz messen, um zu einem 
brauchbaren Ergebnis zu kommen. Benutzt man die Capture-Hardware, 
braucht man nur eine einzige Periode.

Jetzt begriffen?

Karl M. schrieb:
> Nach dem Zählen hat man zwei Zahlen: n_CLK (Taktzahl bei einer
> Taktfrequenz f_CPU) und n_EVT (Anzahl an 1-0-Übergängen).
> Die Frequenz ergibt sich dann als:
>
>    f = n_EVT * f_CPU / n_CLK
> --------------------------------------

Das ist bekannt ;-)
http://mino-elektronik.de/Archiv/Elektronik25_1984.pdf

c-hater schrieb:
> Benutzt man die Capture-Hardware,
> braucht man nur eine einzige Periode.

Nein, nur bei Frequenzen unterhalb der Anzeigerate <= 10 Hz. Erklärung 
siehe zuvor.
Die Capture-Funktion erhöht die Auflösung (und damit die potentielle 
Genauigkeit) und sorgt dafür, die eff. Messzeit unabhängig von 
Programmlaufzeiten zu erfassen. Damit sind genaue Messungen möglich, 
auch wenn die Anzeige im Multiplex betrieben wird oder andere Interrupts 
jederzeit den Programmablauf unterbrechen können.

Hallo Lukas,

jetzt hast Du dich gar nicht mehr gemeldet. Warum nicht?

Meine Platine ist eingetroffen, das Programm (also die Firmware) ist 
geschrieben, die fehlerhafte Hardware wurde überarbeitet und nun ist der 
Frequenzzähler wieder brauchbar.

mino-fm (m.n.) hatte dazu auch schon etwas geschrieben:

https://www.eevblog.com/forum/projects/ten-dollar-pic-100khz-2-4ghz-frequency-counter-thread-2/msg1030544/#msg1030544

Sapperlot W. schrieb:
> float, dh 32 bit float, hat 24 bit Mantisse und bringt daher nur
> vielleicht 6 dezimale Stellen.

Der große Vorteil von float ist es, nicht bei jeder Rechenoperation neu 
skalieren zu müssen, um Über- bzw. Unterläufe abzufangen. Und wenn man 
die "beschränkten"6-7 Stellen Genauigkeit erhalten möchte, braucht man 
schon mindestens einen TCXO-Takt. Für die hiesige Anwendung also völlig 
ausreichend.

> AVR haben ueblicherweise keine 64 bit
> floats. Weil es niemand fuer noetig fand diese zu implementieren.

AVRs können von sich aus auch keine 32 bit float, da ihnen die FPU 
fehlt. Um Deine Unwissenheit ein wenig aufzuhellen: 
http://mino-elektronik.de/fmeter/fm_software.htm#bsp2
Hier wird double mit einem AVR gerechnet, was der verwendete Compiler 
schon seit knapp 20 Jahren direkt unterstützt.

m.n. schrieb:
> Hier wird double mit einem AVR gerechnet

So so ... du glaubst mit double rechnen zu lassen weil
du double hinschreibst?

m.n. schrieb:
> was der verwendete Compiler
> schon seit knapp 20 Jahren direkt unterstützt.

Nicht dass ich wüsste. Es sei denn du hast einen ganz
besonderen Compiler.

Wünschen kann man sich viel. Aber nicht alles was man
glaubt ist auch die Wahrheit.

Guten Morgen,

Ja, dieses Programm wurde von m.n. mit dem IAR-KickStart geschrieben und 
übersetzt, der kann 64 Bit double float.

http://www1.futureelectronics.com/doc/IAR%20SYSTEMS/EWAVR.pdf

Siehe:  64-bit IEEE-compatible floating-point arithmetic

Ich zolle m.n. Respekt er weis von was er schreibt, durch seine vielen 
Jahre Praxis. :-)

Doublechecker schrieb:
> m.n. schrieb:
>> Hier wird double mit einem AVR gerechnet
>
> So so ... du glaubst mit double rechnen zu lassen weil
> du double hinschreibst?
>
> m.n. schrieb:
>> was der verwendete Compiler
>> schon seit knapp 20 Jahren direkt unterstützt.
>
> Nicht dass ich wüsste. Es sei denn du hast einen ganz
> besonderen Compiler.
>
> Wünschen kann man sich viel. Aber nicht alles was man
> glaubt ist auch die Wahrheit.

Doublechecker schrieb:
> m.n. schrieb:
>> was der verwendete Compiler
>> schon seit knapp 20 Jahren direkt unterstützt.
>
> Nicht dass ich wüsste. Es sei denn du hast einen ganz
> besonderen Compiler.
>
> Wünschen kann man sich viel. Aber nicht alles was man
> glaubt ist auch die Wahrheit.

Unter dem obigen Link findet sich der Quellcode nebst Kommentaren 
bezüglich Funktion und verwendetem Compiler. Das zu lesen, wäre recht 
schnell gegangen. Mit etwas mehr Einsatz, hättest Du das alles auf 
eigenem System nachvollziehen können.
Insofern verstehe ich Deine Ignoranz nicht.

Karl M. schrieb:
> Ich zolle m.n. Respekt er weis von was er schreibt, durch seine vielen
> Jahre Praxis. :-)

Ich vermute, Du brauchst noch meine Bankverbindung?
;-)