Hallo, gibt es für den Frequenzzähler hier: http://www.ebay.de/itm/Profi-1-500MHz-Hohe-Genauigkeit-Frequenzzahler-Prufvorrichtung-Mess-Meter-Zahler-/131693166348?hash=item1ea9863f0c:g:cB4AAOSwaA5Wi4A5 eine alternative Software, oder die bestehende Software irgendwo? Der Controller ist ein Atmega48
:
Verschoben durch Moderator
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: > Klingt so, als ob er den Zähler nachbauen und den Controller dafür > (natürlich) mit irgendwas Lauffähigem flashen muss. Beispiele für Frequenzzähler mit ATmega findet man z.B. im AVR Softwarepool https://www.mikrocontroller.net/articles/AVR_Softwarepool#Frequenzmesser
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.
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
> m.n. > Wozu denn irgendwelche 64 Bit Routinen erfinden, wenn man doch einfach und schnell - wie zuvor gezeigt - mit float rechnen kann? float, dh 32 bit float, hat 24 bit Mantisse und bringt daher nur vielleicht 6 dezimale Stellen. AVR haben ueblicherweise keine 64 bit floats. Weil es niemand fuer noetig fand diese zu implementieren.
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? ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.