Announcement: there is an English version of this forum on 
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!
Angehängte Dateien:
-
pico_fmeter.png
20 KB
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
c-hater schrieb: > Frequenzy Counter Frenzy Countess? Ach nö, ich bin nicht der Autor dieses Projektes. W.S.
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.
Hier ein Frequenzgenerator + Zähler mit GUI. Läuft auf allen Arduinos. Auf dem PiPico auch ;-) Beitrag "Re: Python <-> MC serial"
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.
hier scheint das Projekt zu sein: http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp_RP2040 etwas älter: https://github.com/ingbird64/Pi-Pico_FrequencyCounter https://forums.raspberrypi.com/viewtopic.php?t=306250
Ε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
:
Bearbeitet durch User
Angehängte Dateien:
-
pico_fmeter-3.png
48 KB
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.
Angehängte Dateien:
-
pico-fmeter2a.png
61 KB -
pico-Fmeter2a_top.jpg
240 KB -
Pico-Fmeter2a_bot.jpg
240 KB
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.
Angehängte Dateien:
-
2_x_OCXO_10s_Adev.png
12 KB -
2_x_OCXO_10s_Fdiff.png
33 KB
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.
Kurz Offtopic: Mit welchem Programm machst Du denn die Graphiken?
Angehängte Dateien:
-
RP2040_Fref_extern.jpg
400 KB
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Pico-Fmeter-TFT_1.jpg
210 KB -
Pico-Fmeter-TFT.png
38 KB
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.
Angehängte Dateien:
-
TFT-480x272-pico.jpg
240 KB
J. S. schrieb: > 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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
Pico-Fmeter_TFT_Demo.jpg
240 KB -
Pico-Fmeter-TFT.png
74 KB
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.
Mi N. schrieb: > Vielleicht hat J. S. (jojos) einen Vergleichswert zur Hand. am RP2040 hatte ich jetzt noch kein TFT dran, aber der hat ja genug Ressourcen für lvgl. Kann ich mal ausprobieren.
J. S. schrieb: > Kann ich mal ausprobieren. 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 ;-)
Angehängte Dateien:
-
F-Meter_Screens.png
33 KB
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.
:
Bearbeitet durch User
J. S. schrieb: > 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 |
2 | master mode is 62.5 Mbps." |
J. S. schrieb: > Habe mit dem Pico noch nicht viel gemacht. 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_1960.jpg
240 KB -
IMG_1961s.jpg
170 KB
Mi N. schrieb: > 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?
Mi N. schrieb: > 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. Bild und kurzes Video hatte ich gepostet: Beitrag "Re: Display 4,3" oder 5" für einfache Aufgaben"
J. S. schrieb: > 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.
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.