Forum: Projekte & Code Pico Frequenzzähler mit RP2040


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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!

von pico (Gast)


Lesenswert?

und warum nur die uf2, und nicht der source code?

von W.S. (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

c-hater schrieb:
> Frequenzy Counter

Frenzy Countess?
Ach nö, ich bin nicht der Autor dieses Projektes.

W.S.

von Mi N. (msx)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

W.S. schrieb:
> Da sage ich nur: Banana-Soft. Reift beim Kunden.

Dumm, frech und neidisch!

von temp (Gast)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

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!

von W.S. (Gast)


Lesenswert?

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.

von chris_ (Gast)


Lesenswert?


von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Norbert (Gast)


Lesenswert?


von Christoph M. (mchris)


Lesenswert?

Hier ein Frequenzgenerator + Zähler mit GUI. Läuft auf allen Arduinos. 
Auf dem PiPico auch ;-)

Beitrag "Re: Python <-> MC serial"

von Εrnst B. (ernst)


Lesenswert?

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

von Mi N. (msx)


Lesenswert?

Ε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.

von Zeno (Gast)


Lesenswert?

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.

von bitsy (Gast)


Lesenswert?


von W.S. (Gast)


Lesenswert?

Ε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.

von c-hater (Gast)


Lesenswert?

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...

von W.S. (Gast)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

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 ;-)

von W.S. (Gast)


Lesenswert?

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.

von Lothar J. (black-bird)


Lesenswert?

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
von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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.

von Mi N. (msx)



Lesenswert?

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.

von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

Kurz Offtopic: Mit welchem Programm machst Du denn die Graphiken?

von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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
von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

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!

von J. S. (jojos)


Lesenswert?

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.

von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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
von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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.

von Mi N. (msx)


Angehängte Dateien:

Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

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 ;-)

von J. S. (jojos)


Angehängte Dateien:

Lesenswert?

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
von Karsten (Gast)


Lesenswert?

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."

von Mi N. (msx)


Lesenswert?

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
von J. S. (jojos)


Angehängte Dateien:

Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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?

von Mi N. (msx)


Lesenswert?

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 ;-)

von J. S. (jojos)


Lesenswert?

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"

von Mi N. (msx)


Lesenswert?

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 ;-)

von J. S. (jojos)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

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!

von Joe (Firma: Wessibisser) (joe_l794)


Lesenswert?

Und welchen Vorteil hat das gegenueber dieser Loesung z.B.?

https://github.com/dgatf/logic_analyzer_rp2040
Nur(!) 200 MHz sample rate, aber reicht allemal hier ;-)

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.

: Bearbeitet durch User
von Mi N. (msx)


Lesenswert?

Joe schrieb:
> 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!?

von Joe (Firma: Wessibisser) (joe_l794)


Lesenswert?

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.

von Mi N. (msx)


Lesenswert?

Joe schrieb:
> 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.

von Joe (Firma: Wessibisser) (joe_l794)


Lesenswert?

Mi N. schrieb:
> Joe schrieb:
>> 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.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.