Im Anhang der vorläufige Entwurf für einen reziproken Frequenzzähler auf
Basis des RP2040 Pico-Boards, was für wenige Euro erhältlich ist. Im
einfachsten Fall wird nur ein Eingangssignal an Fin angelegt und die
Ergebnisse an TxD ausgegeben. Als Versorgungsspannung werden 5 V (per
USB oder Powerbank) benötigt.
Optional kann die genaue Frequenzanzeige per Poti um +/- 20 ppm
justiert, eine 10 MHz Referenz verwendet oder der TxD-Pegel so
eingestellt werden, daß er direkt an einen RS232->USB-Converter
angeschlossen werden kann. Diese kommen in der Regel mit 3 V Signalen
klar.
Reicht der Eingangsfrequenzbereich nicht ganz aus, kann er per Option
auf 32 MHz erweitert werden. Diese Funktion ist experimentell und mich
würden Erfahrungswerte bezüglich der Tauglichkeit interessieren.
vorläufige Daten:
• Pico RP2040 Board
• reziproke Frequenzmessung
• Eingangsbereich 0,1 Hz – 16 MHz,
• Option max. Fin = 32 MHz (Turbo)
• Auflösung 7 Stellen / s
• 3 Messungen / s oder eine Periode (bei Fin < 3 Hz)
• ser. Datenausgabe mit 115,2 kBd
• Abgleich der Frequenzanzeige +/- 20 ppm
• Anschluß 2 x 16 LCD (Option)
• invertierte TxD-Pegel (Option)
• 10 MHz Referenzsignal (Option)
Da sich vermutlich noch starke Veränderungen am Programm ergeben, hier
nur die .UF2-Datei zum direkten Kopieren per USB auf das Board.
Das geht wie folgt: Taster auf dem Board gedrückt halten und USB-Kabel
einstecken. Mit Kopierfunktion die Datei "pico_fmeter.uf2" in den
aufklappenden Ordner schieben.
Viel Erfolg!
Mi N. schrieb:> Im Anhang der vorläufige Entwurf für einen reziproken Frequenzzähler
Naja, der Entwurf ist noch gar sehr 'vorläufig'.
Aber wo da das Reziproke herkommt, ist nicht wirklich ersichtlich.
Ich frage mich an solchen Stellen immer, was der eigentliche Zweck
solcher Entwürfe ist. Soll das mal ein Gerät werden, womit jemand
tatsächlich arbeiten soll/kann? Oder ist das nur dazu da, mal eine
Beispielschaltung für diesen RP2040 zu zeigen?
In solchem Zusammenhang wäre es anstelle von vorläufigen Wunschdaten
weitaus wichtiger, entscheidende Konstruktionsdetails vorzustellen -
vorausgesetzt selbige existieren. Da wäre z.B. die Frage, ob der Chip
tatsächlich asynchron betreibbare Counter besitzt und davor noch eine
ebenfalls asynchrone Torschaltung. Sonst ist es nämlich ein bissel Essig
mit einem reziproken Zähler, oder man muß sowas extern machen, was aber
aus deinem Entwurf nicht ersichtlich ist.
Alle anderen Kunststücke im Mikrocontroller laufen darauf hinaus, daß
man übersieht, daß auch die internen Counter und Catch/Compare-Logiken
nicht mit den tatsächlich außen anliegenden Signalen arbeiten, sondern
mit Samples, die vom verwendeten Takt getaktet worden sind. So etwas mag
gehen für Zähler, die ausdrücklich nur langsame Zähler für den
NF-Bereich sind, aber für den universellen Einsatz sind sie nicht
geeignet, weil sowas eine Präzision vorgaukelt, die realiter nicht
existiert. Von wegen 7 Stellen.
Ein anderes, aber ebenfalls wichtiges Thema ist der Meßengang bzw. die
Meßeingänge. Vielen Zähler-Bastlern ist das völlig unwichtig, so daß sie
nur bis zu einem TTL-Pegel-Eingang denken. Aus sowas wird dann nie ein
benutzbares Gerät.
Naja, es ist ja wie geschrieben, nur ein erster Versuch.
W.S.
W.S. schrieb:> Da wäre z.B. die Frage, ob der Chip> tatsächlich asynchron betreibbare Counter besitzt und davor noch eine> ebenfalls asynchrone Torschaltung.
RTFM
Abschnitt 2.15.4. Frequenzy Counter
W.S. schrieb:> Ich frage mich an solchen Stellen immer, was der eigentliche Zweck> solcher Entwürfe ist. Soll das mal ein Gerät werden, womit jemand> tatsächlich arbeiten soll/kann? Oder ist das nur dazu da, mal eine> Beispielschaltung für diesen RP2040 zu zeigen?
Du stellst die falschen Fragen und erwartest die falschen Antworten.
Deine Suche nach Torzeithardware ist wie immer vergebens.
Falls Du ein RP2040 Pico-Board hättest, könntest Du binnen fünf Minuten
feststellen, daß das Teil 1 Hz Signale mit 7-stell. Auflösung bzw.
Genauigkeit liefern kann. Ohne Umschaltung geht der Messbereich bis 30
MHz hoch.
So, wie ich Dich kenne, hast Du kein Pico-Board und wärest Dir auch zu
fein dafür, es auszuprobieren. Zum einen müßtest Du erst einmal ein
eigenes Board designen und zum anderen bereit sein, zu akzeptieren, daß
es andere als Deine alten, verfahrenen Wege gibt, Probleme zu lösen.
Wer ein Pico-Board hat, kann es für kurzfristigen Bedarf umprogrammieren
und danach wieder für andere Aufgaben verwenden. Und das alles zu einem
extrem günstigen Preis.
Noch überlege ich, ob ich noch zwei weitere Eingangskanäle mit gleichen
Eigenschaften implementiere, um automatisch ein Signal nach Vorteiler
(1/256 oder 1/80) automatisch zu erkennen und somit den
Eingangsfrequenzbereich zu erweitern. Ein 3. Kanal könnte
Referenzfrequenzen von 1 Hz (GPS), 10 kHz oder 10 MHz (TCXO bzw.
Systemreferenz) erkennen und als Referenz zum permanenten automatischen
Abgleich zu verwenden.
Und das alles ohne weitere Hardware (ausgenommen Vorteiler IC nach
Wahl), ohne Torzeit und alles schön vollautomatisch, lückenlos und ohne
Umschalterei.
> Ein anderes, aber ebenfalls wichtiges Thema ist der Messeingang bzw. die> Meßeingänge. Vielen Zähler-Bastlern ist das völlig unwichtig,
Du beantwortest Deine Frage ja selber ;-)
Hier geht es erst einmal darum, eine Probierlösung ohne Löterei von
vielpoligen SMD-ICs zu erhalten. Das Pico-Board scheint ferner derzeit
gut lieferbar zu sein.
Ernsthaft Interessierte können sich die Eingangsstufe auch selber
konfigurieren und das ganze in ein Gehäuse packen.
Mi N. schrieb:> Hier geht es erst einmal darum, eine Probierlösung ohne Löterei von> vielpoligen SMD-ICs zu erhalten.
Na dann probiere mal weiter.
Aber tu nicht so, als wäre so ein vorläufiger Vorentwurf bereits etwas,
das bereits in greifbarer Nähe zur Benutzbarkeit ist.
Allerdings ist das Basteln mit Zeugs, wo man nicht löten muß, für so
einige Programmierer weitaus interessanter, als sich Gedanken zur
Anwendung machen zu müssen. Oder gar zur Geräte-Gestaltung. Ieks, da ist
ja sogar Mechanik mit im Spiel. Von da her sehe ich da durchaus
Beschäftigungspotential.
Mi N. schrieb:> Ernsthaft Interessierte können sich die Eingangsstufe auch selber> konfigurieren und das ganze in ein Gehäuse packen.
Da sage ich nur: Banana-Soft. Reift beim Kunden.
W.S.
Mi N. schrieb:> Dumm, frech und neidisch!
Ne, immer noch realistischer als so ein Spezi der hier binär-Code
reinstellt und darauf hofft Lorbeeren zu ernten. Wenn du dich nicht
traust den Quellcode zu zeigen, dann wird das wohl seinen Grund haben.
Allein deshalb ist es völlig sinnfrei das auch nur zu probieren.
temp schrieb:> Wenn du dich nicht> traust den Quellcode zu zeigen, dann wird das wohl seinen Grund haben.
Benutze mal die Suchfunktion und Du wirst eine Menge Quellcode von mir
finden - von anderen und besseren Zählern. Aber ich mache hier nicht den
Affen, wenn jemand nach seinem Hund ruft.
Von "temp" oder "pico" scheint es in der Codesammlung nichts zu geben -
außer die hiesige Meckerei. Erstgemeinter Bedarf ist wohl nicht
vorhanden.
Alles klar!
Mi N. schrieb:> Erstgemeinter Bedarf ist wohl nicht> vorhanden.
Nun ja, die Leser deines Projektes haben vermutlich soviel Fachwissen,
daß sie dein Projekt beurteilen können. Daher wohl die Absenz
ernstgemeinten Bedarfes.
Und nochwas zu deinen flotten Sprüchen weiter oben: Hast du dir
eigentlich jemals klar gemacht, was für eine Dimension die Frequenz hat?
Nee? Ich sag's dir: 1/s oder verbal Ereignisanzahl/Zeitspanne. Dabei
wird besagte Zeitspanne gemeinhin als 'Torzeit' bezeichnet. Und wenn du
dieses Wort nicht magst, dann nenne das meinetwegen 'Ottokar'. Für's
Prinzip ist der Name egal, aber die Torzeit, also die Zeit, wo die
Ereignisse gezählt werden ist genauso wichtig wie das korrekte Zählen
der Ereignisse. Man braucht schlußendlich beides, um die Frequenz eines
Signals zu messen bzw. darzustellen.
Apropos korrektes Zählen: für sowas braucht man einen Zähler, der direkt
auf das Eingangssignal reagiert, genauer: auf dessen Flanken reagiert.
Bei allen üblichen Timer/Counter-Modulen, die in µC stecken, sieht so
ein Modul jedoch nur die vom Systemtakt erzeugten Samples des
Eingangssignals. Folglich schlägt hier das Abtasttheorem zu und wenn man
mit sowas einen Zähler (präziser: einen Zählfrequenzmesser) baut, dann
geht der nur richtig, wenn beide Halbwellen des zu messenden Signals
länger sind als der Zeitabstand der Samples. Für ein reines NF-Meßgerät
ist das OK, aber nicht für einen Universalzähler. Und das hast du nun
schon jahrelang mit Fleiß ignoriert, obwohl ich es dir schon vor langem
erklärt habe.
W.S.
W.S. schrieb:
...
> Und das hast du nun schon jahrelang mit Fleiß ignoriert, obwohl ich es dir >
schon vor langem erklärt habe.
>
Du erklärst hier immer wieder dein Wissen aus dem letzten Jahrhundert
...
aber die Welt dreht sich weiter.
Hans-Georg L. schrieb:> aber die Welt dreht sich weiter.
OK, dann wurde wohl auch das Hebelgesetz gestern außer Kraft gesetzt. Es
war ja schon sooo alt.
W.S.
W.S. schrieb:> Apropos korrektes Zählen: für sowas braucht man einen Zähler, der direkt> auf das Eingangssignal reagiert, genauer: auf dessen Flanken reagiert.> Bei allen üblichen Timer/Counter-Modulen, die in µC stecken, sieht so> ein Modul jedoch nur die vom Systemtakt erzeugten Samples des> Eingangssignals.
Aus dem Grund hat man Früher™ gerne diverse PIC (ohne "O" am Ende!) zum
Frequenzzählen genommen, da konnte ein Timer unabhängig vom IO-Takt
arbeiten, und auch Frequenzen deutlich > CPU-Takt verarbeiten.
https://www.sprut.de/electronic/pic/projekte/frequenz/freq.htm
Εrnst B. schrieb:> Aus dem Grund hat man Früher™ gerne diverse PIC (ohne "O" am Ende!) zum> Frequenzzählen genommen,
Da machst Du W.S. ja eine riesige Freude. Tor auf - zählen, zählen,
zählen - Tor wieder zu. Dann warten, bis der Controller die Zählerwerte
umgerechnet und auf's Display ausgegeben hat. Dann kann schon die
nächste Messung starten.
Schöne alte Technik, mit der man heute nicht einmal die beat-beat
Pulsfrequenz messen kann, weil jeder zweite Schlag fehlt.
> da konnte ein Timer unabhängig vom IO-Takt> arbeiten, und auch Frequenzen deutlich > CPU-Takt verarbeiten.
Du wirst lachen, das geht auch heute noch.
Beitrag "Re: STM32F429-Discovery Recycling: 90 MHz Frequenzzähler mit TFT"
Von 20 mHz - >= 400 MHz, allerdings ohne Umschalterei, ohne Tor zum
Blockieren von Impulsen und immer hochgenau.
Man muß es nur zur Kenntnis nehmen wollen.
Mi N. schrieb:> Schöne alte Technik, mit der man heute nicht einmal die beat-beat> Pulsfrequenz messen kann, weil jeder zweite Schlag fehlt.
Die alten Grundlagen gelten heute immer noch - das ist schlichtweg
Physik bzw. Mathematik.
Allerdings wer meint man müsse 0,1Hz mit 7 Stellen Auflösung anzeigen,
der zeigt das er sich über die Größenordnungen keine Gedanken gemacht
hat, was wiederum den Schluß zuläßt das Du die Grundlagen eben noch
nicht vollständig durchdrungen hat.
Du bringst ja noch nicht mal ein vernünftiges Schematik zu stande oder
besser gesagt Du bist viel zu faul da was Vernünftiges zu machen.
Und wenn man hier schon "ein Projekt" vorstellt und man dazu auch ein
Feedback erwartet, dann gehört eben auch der Sourcecode dazu. Darf man
fragen wo Du den herauskopiert hast?
Ne solange Du da nicht kooperativer bist und dazu noch, mal vorsichtig
formuliert, dem einen oder anderen dumm anmachst, wird es so bleiben wie
es W.S. offensichtlich richtig erkann und formuliert hat:
W.S. schrieb:> Nun ja, die Leser deines Projektes haben vermutlich soviel Fachwissen,> daß sie dein Projekt beurteilen können. Daher wohl die Absenz> ernstgemeinten Bedarfes.
Εrnst B. schrieb:> https://www.sprut.de/...
Das kannst du einfacher haben: Ich hatte mir mal einen kleinen
Taschen-Frequenzähler mit einem PIC16F716 und einem 2 zeiligen LCD (die
95Ct Dinger, die es mal bei Pollin gab) gebaut und hab auch hier im
Forum sowohl Schaltung und Leiterplatte als auch die Firmware gepostet.
Naja, und wer partout 20 Millihertz messen will, der muß sich eben dafür
etwas passenderes bauen als einen Frequenzmesser. Da hat er Zeit bei
einer Periodenlänge von einer knappen Minute. Mir selber ist sowas noch
nicht untergekommen.
W.S.
W.S. schrieb:> Frenzy Countess?> Ach nö, ich bin nicht der Autor dieses Projektes.>> W.S.
Nunja, wer zu Sache keine Argumente mehr hat, zieht sich an Tippfehlern
hoch...
Übrigens ist es nicht meine Schuld, dass die Idioten der Foundation das
Rauskopieren aus dem PDF gesperrt haben und ich das deshalb abtippen
musste...
Andererseits: Ist bei sehr vielen Datenblättern aus unerfindlichen
Gründen so. Idioten gibt's also überall reichlich. Das Einzige, was
tröstet: es werden nicht die Entwickler der Hardware sein, die solche
schwachsinnigen Entscheidungen verantworten...
c-hater schrieb:> Nunja, wer zu Sache keine Argumente mehr hat, zieht sich an Tippfehlern> hoch...
Nö, es war ganz gewiß kein Tippfehler, was du da geschrieben hast:
c-hater schrieb:> RTFM
Also nochmal: Das Lesen des Manuals halte ich für eine Obliegenheit des
Autors des Projektes. Und der bin ich eben nicht. Also wäre dein
umfänglicher Beitrag eher an den TO zu richten als an mich.
Alles jetzt klaro?
W.S.
Nemo schrieb:> Allerdings wer meint man müsse 0,1Hz mit 7 Stellen Auflösung anzeigen,> der zeigt das er sich über die Größenordnungen keine Gedanken gemacht> hat, was wiederum den Schluß zuläßt das Du die Grundlagen eben noch> nicht vollständig durchdrungen hat.
Da sagst Du etwas Wahres!
Gerade gesehen, so einen Billigzähler von einer noname-Firma Keysight.
Die verkaufen Zähler, die 1 mHz mit 12 Stellen anzeigen können.
Mann, sind die bescheuert! Das braucht doch kein Schwein.
Da mußt Du unbedingt hinschreiben, wie blöd die sind.
Nemo schrieb:> vernünftiges Schematik
Ist das ein Teil, was Tik-Tak macht? Oder kann man das essen?
Nemo schrieb:> Darf man fragen wo Du den herauskopiert hast?
Das würde ich auch gerne wissen, ich finde den Link nicht mehr.
Aber danke, daß Du mich darauf hingewiesen hast.
Mi N. schrieb:> Gerade gesehen, so einen Billigzähler von einer noname-Firma Keysight.> Die verkaufen Zähler, die 1 mHz mit 12 Stellen anzeigen können.> Mann, sind die bescheuert!
Gehörst du eventuell auch zu denen, die sich nichts dabei denken, 1000
Sekunden auf ein Ergebnis zu warten?
Abgesehen davon ist ein Ereigniszähler anwendungsmäßig etwas anderes als
ein Frequezzähler. Rein technisch ist sowas natürlich auch ein Zähler.
Was hätten wir da noch? Meßuhren für mehr oder weniger verschiedene
Zeitspannen, von mir auch bis zu einem Jahr, manchmal auch mit separaten
Eingängen für Start und Stop. Sind rein technisch gesehen auch Zähler,
aber keine Frequenzzähler.
Also labere du lieber nicht über allgemeine Zähler oder ändere die
Überschrift über diesen Thread, damit man nicht aneinander vorbeiredet.
W.S.
W.S. schrieb:>> Gerade gesehen, so einen Billigzähler von einer noname-Firma Keysight.>> Die verkaufen Zähler, die 1 mHz mit 12 Stellen anzeigen können.>> Mann, sind die bescheuert!>> Gehörst du eventuell auch zu denen, die sich nichts dabei denken, 1000> Sekunden auf ein Ergebnis zu warten?
Es gibt Leute, die zum Angleich Ihrer Uhrenbausteine (RTCs) einen ganzen
Tag warten, um anschließend eine ungewisse Korrektur vorzunehmen.
Selber messe ich jede Sekunde am Sekundenausgang und gleiche das Teil
binnen einiger Sekunden ab.
Obwohl ich zugeben muß, daß nicht alles so schnell geht und ich immer
ein ganzes Jahr auf Weihnachten warte.
> Abgesehen davon ist ein Ereigniszähler anwendungsmäßig etwas anderes als> ein Frequezzähler. Rein technisch ist sowas natürlich auch ein Zähler.
Aha, zwei neue Begriffe: Ereigniszzähler und Frequezzähler ;-)
Du meinst also, die Keysight Entwickler sind solche Deppen, daß sie die
Ergebnisse von Ereigniszählern mit der Dimension "mHz" versehen?
> Also labere du lieber nicht über allgemeine Zähler oder ändere die> Überschrift über diesen Thread, damit man nicht aneinander vorbeiredet.
Du bist darauf konditioniert, am Thema vorbeizureden. Da kann ich Dir
nicht helfen.
Mi N. schrieb:> Noch überlege ich, ob ich noch zwei weitere Eingangskanäle mit gleichen> Eigenschaften implementiere, um automatisch ein Signal nach Vorteiler> (1/256 oder 1/80) automatisch zu erkennen und somit den> Eingangsfrequenzbereich zu erweitern. Ein 3. Kanal könnte> Referenzfrequenzen von 1 Hz (GPS), 10 kHz oder 10 MHz (TCXO bzw.> Systemreferenz) erkennen und als Referenz zum permanenten automatischen> Abgleich zu verwenden.
Das habe ich mittlerweile umgesetzt. Mit einem MC12080 als Vorteiler
kommt man dann auf einen lückenlosen Eingangsbereich von 0,01 Hz - 1,3
GHz.
Zu überlegen bleibt noch, den RP2040 an ein 4,3" TFT anzuschließen.
Genug internes RAM hat er ja, und mit zwei ADC-Kanälen kann man die
Bedienung komfortabel per touch-screen erledigen.
Und ja, einen Modus als Ereigniszähler füge ich dann auch noch hinzu ;-)
Mi N. schrieb:> Zu überlegen bleibt noch, den RP2040 an ein 4,3" TFT anzuschließen.
Na, dann mach mal. Das Ding wird also letzlich kein Meßgerät zum Zwecke
der tatsächlichen Anwendung, sondern eher eine Demo, was dir grad für so
einen RP2040 eingefallen ist. So ungefähr wie heutige Webseiten, wo die
eigentlich erwartete Information nur einige Prozent ausmacht und der
Rest für bunte Werbung oder Schnüffeln da ist, oder bloß so, damit es
eben bunter aussieht.
Naja, und Gratulation daß du inzwischen auch auf einen MC12080 gekommen
bist. Bevor ich meinen bereits genannten Taschen-Frequenzzähler gebaut
hatte, hatte ich einen normalen Zähler gebaut mit einem SA702, der
allerdings auch bloß bis so etwa 1.1 GHz geht. Ist aber schon lange her.
Du kommst also mit deiner 'neuen' Idee so etwa 20 Jahre zu spät. Aber
mach mal, und wenn du damit fertig bist, dann wäre es die rechte Zeit,
das Ergebnis nebst einer Baumappe o.ä. hier zu posten.
W.S.
W.S. schrieb:> Na, dann mach mal. Das Ding wird also letzlich kein Meßgerät zum Zwecke> der tatsächlichen Anwendung, sondern eher eine Demo, was dir grad für so> einen RP2040 eingefallen ist. So ungefähr wie heutige Webseiten, wo die> eigentlich erwartete Information nur einige Prozent ausmacht und der> Rest für bunte Werbung oder Schnüffeln da ist, oder bloß so, damit es> eben bunter aussieht.
Kannst Du bitte Deine persönlichen Animositäten woanders austoben?
Was soll denn dieser Quark? Dieses Teil ist hier in diesem Unterforum
genau richtig. Es ist weder ein Produkt noch wird es zum Kauf angeboten.
Muss jetzt JEDE technische Lösung genau Deinen verqueren Vorstellungen
entsprechen?
Von Dir bin ich Anderes gewöhnt - irgendwie hat sich das leider
verändert, schade.
Es würde mich freuen wenn sich das legen würde und dem Forum tut es ganz
bestimmt gut. In letzter Zeit hat sich das Klima hier sehr
verschlechtert und Du gibst dem noch "Zucker", als Vorbild. Das muss
nicht sein.
Blackbird
Den Schaltplan habe ich an die aktuelle Version (noch nicht ganz fertig)
angepaßt. Er kann aber auch für die bisherige Version verwendet werden,
sofern auf ext. Vorteiler und separate ext. Referenzfrequenz verzichtet
werden kann.
Die Eingangsstufe kann für sinusförmige Signale verwendet werden. Für
maximale Empfindlichkeit sind entweder R3 oder R4 anzupassen. Der
Umschaltpunkt für IC3 liegt bei ca. 1,4 V.
Der Vorteiler mit IC4 teilt asynchron 4:1 und der zusätzliche interne
Vorteiler 64:1, sodaß intern max. 1 MHz ausgewertet werden müssen. Das
erledigt SM1 von PIO0. Die Übernahmefrequenz vom Vorteiler liegt derzeit
bei 256 kHz, was aber vielleicht noch geändert wird.
SM2 von PIO0 mißt eine weitere Frequenz, die bei hinreichender
Genauigkeit mit 1 Hz, 10 kHz oder 10 MHz zur Korrektur der lokalen
Quarzfrequenz verwendet wird. Der Abgleich per Poti wird dabei
abgeschaltet.
Anschluß von LCD und RS232-Treiber sollten bekannt sein.
Soweit erst einmal vorab. Das abschließende Programm ist noch in Arbeit
bzw. muß noch getestet werden.
Gut Ding hat Weile und so gibt es noch kein "perfektes" Endergebnis aber
einen 95% Zwischenstand.
Anbei eine Übersicht und die notwendigen Dateien, um sich eine fertige
Ausführung selbst unter den Weihnachtsbaum legen zu können.
Aber, wie oben schon gesagt, reicht auch allein eine Pico-Board-Platine
mit RS232 Treibern und/oder LCD, um die Funktion der Schaltung zu
erproben.
Mit 2 x 10 MHz OCXO kann man sich schöne Kurven zeichnen lassen.
Das Signal eines OCXO geht an den Fref-Eingang und nach der
Eingangsstufe über 22 pF auf den Eingang XIN des RP2040. Der Zähler wird
auf ext. 10 MHz eingestellt. Das Signal des anderen OCXO geht an Fin.
Die leichte Abweichung von 0,07 Hz ist in TimeLab passend eingestellt.
Mit einer Messzeit von 10 s über insgesamt eine Stunde Laufzeit, kann
man einen Einblick über die Auflösung des Zählers bekommen.
Bild 1 zeigt die ADEV-Kurve und Bild 2 die Differenzwerte zwischen Fin
und Fref. Gegen Ende der Messung muß ein OCXO Luftzug bekommen haben.
Das ist ja garnicht so "offtopic": https://www.miles.io/timelab/beta.htm
Ein schönes Spielzeug wenn man richtig angeben möchte ;-)
Gerade habe ich noch ein Foto gemacht, wie das Pico-Board modifiziert
werden muß, um eine externe 10 MHz Referenzfrequenz zu verwenden.
Ergänzt werden müssen: Graues Kabel mit 22 pF zum Einspeisen der Fref
und rote Steckbrücke zum Umschalten auf 10 MHz.
Beim Programmieren per USB darf keine ext. Fref anliegen; dann läuft der
RP2040 mit 12 MHz des XOs. Die 22 pF zusätzliche Lastkapazität stören
nicht.
Mi N. schrieb:> Zu überlegen bleibt noch, den RP2040 an ein 4,3" TFT anzuschließen.> Genug internes RAM hat er ja, und mit zwei ADC-Kanälen kann man die> Bedienung komfortabel per touch-screen erledigen.
Einfach um zu sehen, ob es funktionieren kann, eine Demo vom derzeitigen
Entwicklungsstand. Den TFT-Controller hatte ich zwischenzeitlich für
eine andere Anwendung benötigt und mit zwei umfunktionierten Eingängen
läßt sich ein Zähler inkl. internem Vorteiler realisieren. Man beachte
die detailreiche Darstellung selbst bei kleiner Schrift ;-)
Ein fertiges Board dazu ist nicht geplant.
Das Pico-Board hat sich für diese Anwendungen als recht geeignet
gezeigt.
Als dieser Beitrag gestartet wurde, war noch offen, in welche Richtung
sich die Entwicklung bewegen wird. Mittlerweile zeichnet sich ein
stabiles Endergebnis ab. Wer es nicht schon gefunden hat, findet den
Quellcode zum Projekt hier:
http://mino-elektronik.de/progs/Pico-Fmeter2a/pico_fmeter2.zip
Da sich trotz der eingefügten Kommentare nicht unbedingt das Wie und
Warum der reziproken Messfunktion speziell mit dem RP2040 ergeben, habe
ich dies noch einmal gesondert beschrieben:
http://mino-elektronik.de/download/Arbeitsweise_Pico_Fmeter2.pdf
Es können sich immer noch Veränderungen ergeben, die aber eher kleinere
Korrekturen sein werden.
Viel Spaß bei der Lektüre!
http... da muss man den Browser erstmal überreden es zu aktzeptieren.
Ich schaue es mir trotzdem an, würde aber lieber ein TFT mit Speicher
anschliessen.
http... da muss man den Browser erstmal überreden es zu aktzeptieren.
Ja, das sind die superschlauen Browser. Wenn die keine Cookies oder Scripts auf einer Seite finden, gehen die gleich auf höchste Alarmbereitschaft.
Irgendwann wird man seinen elektronischen Ausweis vorzeigen müssen, um sein eigenes Haus betreten zu dürfen.
Ich schaue es mir trotzdem an, würde aber lieber ein TFT mit Speicher
anschliessen.
TFT ist kein Problem. Der Speicher ist ja schon auf dem RP2040 und reicht für eine 480x272 Anzeige mit zwei Seiten, wenn man Pins sparen muß/möchte und mit 64 Farben/Pixel zufrieden ist. (Schwarz, Rot und Gelb sind ja auf jeden Fall dabei ;-)
Da Du wohl eher Softwerker bist, schielst Du vermutlich auf die kleinen Spielzeug-Anzeigen <= 3,5". Die halte ich für touch-Bedienung für völlig ungeeignet, es sei denn, man möchte aus einer Speisekarte, Pommes, Majo, Sosse, Reis und Nudeln mit einem einzigen Daumendruck bestellen.
Die Billigteile von heute können morgen schon nicht mehr beschaffbar sein.
Gut, ohne touch-Bedienug und nur als Zeichenknechte kann man sie nehmen, wenn man die richtige LIB dazu findet ;-)
Da man zumeist sowieso eine Leiterplatte für SMD-Peripherie braucht, kann man die paar Bauteile, die zur Ansteuerung benötigt werden, gleich mit dazu packen.
Auf dem Foto kann man die Teile sehen, die neben dem Pico-Board noch benötigt werden. Zum einen einen Spannungswandler (rund um IC3) für die Hintergrundbeleuchtung VLED und, wenn man mag, eine Ladungspumpe (rund um D1), die ein Signal "DISP" zur Aktivierung des TFT nur dann erzeugt, wenn auch ein DCLK-Signal anliegt.
Ab 4,3" geht touch-Bedienung gut. Bei der Größe gibt es viele Anbieter mit Standard 40-Pin Steckverbinder und bester Ablesbarkeit. (Die überstehenden Laschen auf dem Foto dienen zur Befestigung von 4,3" TFTs mit Abstandshaltern auf der Frontplattenrückseite. Mein TFT hat noch eine alternative Pinbelegung mit separater VLED-Leitung.)
Reduziert man ein typisches 7" TFT auf 400x240 Pixel, hat man eine "schöne", große Anzeige und der PicoPi erzeugt auch dafür die passenden Signale mit 64 Farben/Pixel und zwei Bildspeichern.
Klar, wer mit bunten Bildern spielen möchte, ist hier falsch. Hier geht es um die kontrastreiche Anzeige von Messwerten.
Zu der Software und der Hardware gibt es jeweils eine neue Version.
Bei der Software sind einige Fehler beseitigt und Feinheiten ergänzt worden. Insbesondere wurde das Timeout zum FRef-Eingang nicht beachtet. Beim Betreib ohne EEPROM wurde der Programmstart durch fehlende Pullup-Widerstände am IIC-Bus blockiert.
Dann ist noch ein neuer Befehl 'x' hinzugekommen, mit dem das Verhalten beim Zu-/Abschalten des Vorteilers geändert werden kann: drei Zeitstempel verwerfen oder die aktuelle Messung ganz neu starten.
Die .pdf-Beschreibung dazu wurde entsprechend angepaßt. Siehe Anhang.
Beim Einspeisen von Signalen mit Logikpegeln, kann man sich die Signalaufbereitung sparen und es gibt nichts weiter zu beachten.
Das Rauschen des Schaltreglers auf dem Pico-Board stört jedoch die Signalaufbereitung von Sinussignalen mit kleineren Pegeln. Es empfiehlt sich daher, den Schaltregler abzuschalten und einen externen low-drop 3,3 V Regler zu ergänzen. Mit Reglern im TO92-Gehäuse geht das recht einfach.
Die TFT-Version funktioniert soweit, wobei noch offen ist, ob ich nicht noch einen TDC für konstant hohe Auflösung ergänze.
Mit 11-stelliger Anzeige der formatierten Werte macht das Foto mehr her, als nur die 7 Stellen anzuzeigen, die der ext. Quarzoszillator bestenfalls liefert ;-)
Zur Einschätzung: für die Ausgabe der Messwerte inkl. Statistik auf das TFT braucht der RP2040 rund 40 ms. Wird die Messzeit kürzer gewählt gehen zwar keine Messwerte verloren, können aber auch nicht über die RS232 ausgegeben werden. Testweise habe ich den 2. Kern des Controllers für die TFT-Ausgabe verwendet, womit dann rund 300 Messungen/s (3 ms Intervall) geschafft werden, weil Ausgabe und Messung dann parallel stattfinden können.
Da weiß ich noch nicht, ob das so bleibt. 25 Messungen/s sind ja auch nicht schlecht und hohe Auflösung wird erst >= 1 s erreicht.
Ein externes TFT mit eigenem Controller kann die Messung zwar auch entlasten, braucht aber aufbereitete Pixeldaten um die Zeichen darzustellen. Daher wird die Ausgabe wohl nicht wesentlich schneller werden.
Vielleicht hat J. S. (jojos) einen Vergleichswert zur Hand.
Gut, dann sollte ich etwas genauer sein.
Es sind <= 33 ms für die Ausgabe, wobei zu beachten ist, daß der RP2040 im Hintergrund mit 100 kHz alle notwendigen Daten für die Regressionsberechnung sammelt. Das sind uint64_t und "echte" double-Werte inkl. Vorverarbeitung.
Damit ist der 1. Kern zu rund 50% ausgelastet.
Reduziere ich die Abtastrate auf 50 kHz, was die Auflösung nur wenig schmälert, werden <= 21 ms gebraucht. Bei 10 kHz sind es <= 13 ms.
Aber bevor Du etwas sagst, hast Du natürlich mit Deinem (unausgesprochenen) Einwand recht: man müßte die angezeigten Daten vorverarbeiten und nur geändert Inhalte neu schreiben. Etwas "lästig", aber durchaus machbar ;-)
Ich versuche am WE ein Display anzuschließen. Das UI habe ich schon mal grob im lvgl SquareLine Studio Editor nachgebaut, mal sehen was das kann.
Eine genaue Leistungsmessung ist vermutlich nicht ganz so einfach, die Ausgabe wird je nach Framebuffergröße Häppchenweise berechnet.
Es ist schon effizienter nur das UI zu aktualisieren wenn sich auch tatsächlich Werte geändert haben. Ich baue noch eine LED ein die den Trigger symbolisiert, ist praktisch wenn sich Werte nicht ändern. Aber bei so vielen Stellen wird schon Leben drin sein.
Das UI habe ich für 480 x 320 Pixel und 16 BPP gezeichnet, aber 320 x 240 ist natürlich schneller mit weniger Pixeln. Ob das größere Display brauchbar schnell ist weiß ich nicht, ich hoffe das ich eines in der Sammlung habe.
Dann weiß ich noch nicht wie schnell SPI auf dem RP2040 läuft, für 16 Bit parallel sind vermutlich nicht genug Leitungen frei? Oder 8 Bit parallel, mal sehen. Habe mit dem Pico noch nicht viel gemacht.
Dann weiß ich noch nicht wie schnell SPI auf dem RP2040 läuft, für 16
Bit parallel sind vermutlich nicht genug Leitungen frei? Oder 8 Bit
parallel, mal sehen. Habe mit dem Pico noch nicht viel gemacht.
Lt. Datasheet RP2040:
1
"For example, at the maximum SSPCLK (clk_peri) frequency on RP2040 of 133 MHz, the maximum peak bit rate in
Dann könnte das alles in richtige Arbeit ausarten!
Vermute ich richtig, daß Deine Displays mit eingebautem Controller vielleicht noch Linien und Rechtecke erzeugen, aber ansonsten nur Pixel setzen können?
Dann müßtest Du die Pixeldaten pro Messwertzeile in einen kleinen Puffer ins RAM schreiben und zeilenweise per DMA und SPI o.ä. rausschieben. Die Ausgabe per SPI und DMA kann man zeitlich wohl ignorieren, da das gepuffert im Hintergrund abläuft. Die Hauptarbeit bleibt dann, die Pixel zu den Ziffern/Zeichen zu setzen. Dann sehe ich aber keinen Geschwindigkeitsvorteil bei solchen Displays, ausser daß man mehr Farben darstellen kann und die Displays höhere Auflösungen bieten können.
Elegant wäre ein Display, was wie ein Terminal arbeitet. Startposition, Schriftgröße und ASCII-Zeichen schreiben und das Teil macht die Pixelei selber. Dann müßte der µC, der die Messwerte ausgibt, die Ausgabe nicht mehr abwarten. Nur alle 100 ms einen neuen Datensatz zu schicken, wäre flüssig genug für die Augen.
Selber habe ich jetzt den "lästigen" Punkt (siehe oben) erledigt:
alle 10 ms wird die Ausgaberoutine aufgerufen, wobei nur jeweils ein Wert ausgegeben wird. Bei insgesamt 6 Werten ist die Anzeige alle 60 ms aktualisiert. Eine neue Ausgabe erfolgt nur dann, wenn alter und neuer Wert (jeweils als double) voneinander abweichen. Bei der Zeichenausgabe selber werden dann neuer und alter ASCII-String übergeben und nur die Zeichen geschrieben, die abweichen.
Die Messroutine schafft somit 200 Messungen/s mit ein wenig Jitter im ms-Bereich. Ich weiß, das ist schon alles recht speziell ;-)
Warum ich das alles schreibe? Ich versuche zu verstehen, warum für Dich ein separates TFT verlockend ist, und ob ich das auch mal so angehen sollte.
Dann könnte das alles in richtige Arbeit ausarten!
aber nicht doch, ein mögliches Design habe ich doch schon gezeigt. Das ist nicht in Paint gemalt, sondern schon mit den echten GUI Elementen emuliert. Das macht alles lvgl, eine Lib die einiges an Controls mitbringt. Schöne Schriften können viele, lvgl kann da einiges mehr.
Als Treiber braucht man eine Funktion die einen Speicherbereich in den Displaycontroller schaufelt, das ist überschaubar. Es gibt mittlerweile viele fertige Lösungen, für einige STM32 Boards habe ich auch schon Treiber mit den BSPs gebaut. Der lvgl Editor erzeugt ui files und die sind so portabel das sie im PC Simulator oder im µC funktionieren. Habe ein Disco F746 hier liegen und die da reingeworfen, siehe Bild. Das Display hat 480 x 272, da ist dann der untere Teil abgeschnitten. Man kann das Flag 'scrollable' gesetzt lassen und schon wäre der Screen scrollbar, das Display ist nur ein Fenster in einen 16 k x 16 k Bildbereich. Braucht aber einen schnellen Bildaufbau.
'Mein' Display kann wie viele andere nur das RAM auf dem TFT darstellen und man muss die Daten eben einfach da rein schaufeln, Linien oder andere Primitive können die nicht. Es gibt intelligente, Nextion ist ein bekannter Vertreter. Aber warum wenn die MCU schon zwei Kerne hat? Selbst mit einem Kern + RTOS geht das bequem.
Es geht mir auch nicht um einen Geschwindigkeitsvorteil, sondern den Einsatz von lvgl und wie gut das so in echten Anwendungen funktioniert. Ich finde bei Geräten müssen nicht nur die inneren Werte stimmen, auch ein GUI darf gut aussehen und intuitiv zu bedienen sein.
Ich hatte das GUI schon auf den Pico portiert, erstmal mit ILI9341 320x240 Display weil sich das einfacher auf dem Breadboard unterbringen ließ. Das ist mit den 62,5 MHz SPI schon sehr fix, bei Bildumschaltung ist kein Bildaufbau sichtbar. Dabei habe noch nichtmal DMA benutzt, was in der verwendeten Bodmer/eTFT_SPI Lib aber auch drin ist. Der Name der Lib ist nur historisch zu verstehen, 8 oder 16 Bit Parallel unterstützt die auf dem Pico auch. Auch bessere 3,5“ Displays mit 480x320.
Leider habe ich gerade ein mittelschweres Handicap und kann da gerade nicht weiter machen.
Für DMA mit double Buffering fehlt in der Lib eine Signalisierung per Int, das kann der RP doch sicherlich auch?
Zu der Software und der Hardware gibt es jeweils eine neue Version.
Bei der Software sind einige Fehler beseitigt und Feinheiten ergänzt
worden.
Und es gibt aktuell wieder eine neue Version, die aus besagten Gründen auf jeden Fall verwendet werden sollte.
Dabei ist eine statistische Auswertung hinzugekommen:
Fmean, Fmax, Fmin, Sdev und Anzahl werden kontinuierlich erfaßt und können angezeigt und ausgegeben werden.
Die Version mit TFT-Anzeige stelle ich etwas zurück. Aktuell teste ich eine neue Schaltung mit TDC. Die Zeitmessung übernimmt ein AS6501, der eine Auflösung im ps-Bereich bietet und auch die Kosten deutlich steigert ;-)
An einem GUI hatte ich schon angefangen, kann im Moment leider nicht so
viel am PC arbeiten.
Kein Problem, es eilt ja nichts.
Unsere Vorgehensweise hat sicherlich andere Prioritäten. Dir geht es primär um eine "schicke" Präsentation mit allgemein verfügbarer Hardware, mir eher um eine technische Anzeige, die die verwendete Hardware möglichst weit ausnutzt. Im Vordergrund bei mir steht eher die Messung selbst als eine verspielte, bunte Darstellung. Ebenso die möglichst direkte Bedienung per touch-Auswahl.
Ich hatte mal einen Kunden, der persönlich farbenblind war. Für ihn war eine kontrastreiche Anzeige das Wichtigste.
Aus Erfahrung bevorzuge ich es, keine fertigen Module zu verwenden, die immer mal wieder knapp werden können. 4,3" TFTs gibt es mit weitgehend genormtem 40-pol. FB-Kabel. Da kann man recht einfach den Anbieter wechseln.
Bei 7" TFTs hat man auch größere Auswahl.
Die üblichen TFT-Module <= 3,2", auf deren touch-Bildschirm man Pommes, Majo, Bier und Zichten mit einem einzigen Daumendruck "bestellen" kann, mag ich garnicht ;-)
naja, Pommes mit Majo haben auf dem (seriösen) Basteltisch eh nix verloren. Man kann auch trotzdem Hardware Buttons einbauen, für Dinge die man häufig umschaltet ist das sinnvoll anstatt sich durch Menüs zu hangeln. Andererseits kann man Geräte mit Touchdisplay kompakter bauen.
Deine Messtechnik funktioniert ja schon mit dem RP2040, das sollte sich vereinen lassen. Eine PIO SM wird für das SPI benutzt, die zweite sollte dann frei sein.
Der Charme am RP2040 ist ja das er sehr günstig und trotzdem leistungsfähig ist. Aber wenn man schon soviel Aufwand da rein steckt, dann macht es ja auch den Kohl nicht fett wenn man einen STM32H7 für so ein Gerät nimmt. Nur die Liefersituation ist noch beschissen bei den Teilen.
Und ich möchte kein Geschäft mit den Dingern eröffnen, von daher interessiert mich eine Langzeitverfügbarkeit der Displays weniger. Aber diese einfachen gibt es auch schon viele Jahre und andere Controller zu unterstützen ist nicht viel Arbeit. Einzig der Blickwinkel ist bei den low cost Dingern schlecht, aber da habe ich auch noch IPS Displays die ich mal testen möchte.
Da IAR die Konditionen für seine Demo-Versionen geändert hat, ist sie für unbefristete, kleinere Projekte nicht mehr geeignet.
Ohne auf die kostenlose Arduino-IDE umschwenken zu müssen, habe ich testweise RP2040 Projekte für die Segger IDE
"SEGGER Embedded Studio for ARM Release 7.32 Build 2023081802.53976" angepaßt. Das gelingt mal mehr und mal weniger gut ;-)
Das Projekt zum Eingangsschaltbild findet sich hier:
http://mino-elektronik.de/progs/RP2040/Pico_Fmeter_Segger.zip
Nach Installation des Segger ES kann das Projekt durch Anklicken von 'Pico_Fmeter_Segger.emProject' geöffnet werden.
Spielt man die .UF2-Datei auf das Pico-Board, braucht man keinen RP2040-fähigen J-Link zu benutzen. Für kleinere Anpassungen sollte das ausreichend sein.
Helau!
Mit Pulseview auf Timing Protokoll lassen sich exzellent und schnell Frequenzen messen. Mit einem Waveform Generator (auf Github nach Arbitrary Waveform Generator suchen), kann man schnell schlechte Kabelverbindungen erkennen und verbessern. Die sind naemlich sehr sehr oft der Grund fuer besch. Frequenzmessungen.
Und welchen Vorteil hat das gegenueber dieser Loesung z.B.?
Einfache Frage - einfache Antwort: man kann ein Display anschließen!
Da kann man sich als Begrüßungstext "Helau", "Alaaf" oder auch "Ein Bier" anzeigen lassen.
Und wenn man sich vor Narren schützen möchte: "Nur für Befugte" oder "Ich bin kein Kabeltester".
Das ist doch echt ätzend!?
Du hat wohl noch nie Pulseview ausprobiert? Du, da werden die Ergebnisse auf einem MONITOR schon gross ausgegeben. Du, ich fragte ja nur, wenn du keinen Bock hast zu antworten dann lass'es eben.
Du, ich fragte ja nur, wenn du
keinen Bock hast zu antworten dann lass'es eben.
Dann stelle Fragen, die man als solche wahrnehmen kann und deren Antworten Du auch verstehst.
In diesem Beitrag geht es weder um Logikanalysator, Pulseview oder Kabeltester. Und wenn Du den Unterschied zu einem reziproken Frequenzzähler geklärt haben möchtest, erstelle dazu einen eigenen Beitrag.
Du, ich fragte ja nur, wenn du
keinen Bock hast zu antworten dann lass'es eben.
Dann stelle Fragen, die man als solche wahrnehmen kann und deren
Antworten Du auch verstehst.
In diesem Beitrag geht es weder um Logikanalysator, Pulseview oder
Kabeltester. Und wenn Du den Unterschied zu einem reziproken
Frequenzzähler geklärt haben möchtest, erstelle dazu einen eigenen
Beitrag.
Na denn vielen Dank fuer die freundlichen und ueberaus hilfreichen Hinweise zu deiner tollen, ach was deiner besten, Entwicklung. Sorry, das ich ich auf dem Schlauch stehe, aber dank deiner ueberaus grosszuegigen Hilfe werde ich schon weiterkommen. Mache dir keine Sorgen du hilfreicher Ritter. Danke, danke, danke.
pico_fmeter.png
(20 KB)
