Die SPI-Verbindungen vom Pico zum MCP4922 sind nur 8mm lang. Und trotzdem brauchen alle Signalflanken >500ns. Der Pico sollte doch min. 7ns schaffen. Am SPICLK-pin habe versucht mehr Ausgangsstrom und SlewRate zu steigern. Das hatte jedoch keine Wirkung.
Mein Picoscope läuft mit 2ns Abtastrate.
Die Daten werden jedoch korrekt übertragen.
So könnte es mir ja reichen.
Aber ich wüßte gerne eine Erklärung warum das so ist.
Aber ich wüßte gerne eine Erklärung warum das so ist.
Die Darstellung des Signals an deinem Messgerät entspricht in
keiner Weise der physikalischen Realität. Die Bandbreite ist
an irgendeiner Stelle viel zu gering um die Flankensteilheit
korrekt darzustellen.
Es gibt ja nur ein Picoscope und eine Konfiguration dazu, also
brauchst du keine weiteren Angaben machen bzw. Details angeben.
Es erklärt sich alles von selbst.
Die SPI-Verbindungen vom Pico zum MCP4922 sind nur 8mm lang. Und
trotzdem brauchen alle Signalflanken >500ns. Der Pico sollte doch min.
7ns schaffen. Am SPICLK-pin habe versucht mehr Ausgangsstrom und
SlewRate zu steigern. Das hatte jedoch keine Wirkung.
Das ist schon seltsam. Ich habe schon des Öfteren mit gut zwanzig Zentimeter freischwebender Verdrahtung ein Display mit > 25MHz angesteuert. Pure Magie!
Da ist gar nichts seltsam wenn man sich nicht auskennt und
nicht weiss was man tut.
Da kann ich dir nicht widersprechen. ;-)
Es scheint, dass Datenblätter mittlerweile eine ähnlich Wirkung entfachen wie Knoblauch auf Vampire.
Ad1: Die Flanke sind ja wie mit dem Lineal gezogen.
Wenn sie wenigstens ein Segment einer einsminusehochminustdurchtau Funktion darstellten, wäre der Ratschlag dass die dicken Puffer-ElKos an die Versorgungsspannung und nicht an die GPIO Pins gehören.
Man kann ja sowohl Drive Strengh(2-12mA) als auch Slew rate für jeden Pin einstellen.
Wird das eigentlich automatisch bei der Aktivierung der SPI hoch gedreht? Vermutlich nicht. Will man ja vermutlich selbst in der Hand haben wegen EMV.
Ansonsten vllt mal da etwas hochstellen?
Wenn der Pin an der eingestellten Stromgrenze hängt, also den Strom auf einen konstanten Wert begrenzt und der Kondensator groß genug ist, müsste dann nicht eine Gerade normal sein?
Was bleibt der Software anderes übrig als zwei Stützpunkte
eines Datensatzes zu verbinden? Soll sie eine geschlängelte
Kurve hinzufügen?
Laut Aussage des TE liegen da mehr als 250 Punkte (2ns vs. >500ns)
Ich habe gerade mal 75MHz aus einem GPIO Pin gejagt, durch eine vierzig Zentimeter Messschnur, durch den 2mA Strommessbereich eines alten DMM, noch einmal durch eine vierzig Zentimeter Messschnur wieder zurück zu einem zweiten GPIO.
Keine Problem, auch ohne /drive strength/ zu erhöhen (weshalb sollte es auch).
100MHz geht auch problemlos, bei 125MHz wird's mit der wilden Verdrahtung etwas wackelig.
Laut Aussage des TE liegen da mehr als 250 Punkte (2ns vs. >500ns)
Das sind Werte die sein Picoscope kann , aber nicht die Werte
die tatsächlich eingestellt sind. Merke: mit verringerter
Abtastrate hat man mehr Speichertiefe.
Wieder einmal bestätigt sich:
Es reicht nicht einen Lötkolben zu besitzen, man muss auch wissen auf
welcher Seite er heiß wird! ;-
Diese ganzen SO witzigen Bemerkungen könnt ihr euch sparen. Ich hab auch nur gefragt, weil ich die Fehler, die hier mir unterstellt werden, nicht gemacht habe. Die SPI-Leitung kommen geradelinig aus dem Pico heraus. Sonst ist nichts dran. Und bisher hatte ich auch keine Probleme mit dem Picoscope.
Aber vielleicht hab ich die Drähte mit der Spitze des Bügeleisens angelötet?
Aber vielleicht hab ich die Drähte mit der Spitze des Bügeleisens
angelötet?
Daran wirds wohl kaum liegen.
Die gezeigte Kurvenform ist jedenfalls äusserst suspekt. Miss mal mit der gleichen Einstellung die Sekundärspannung eines Trafos.
Da scheint eine Mittelwertbildung oder ähnliches eingestellt zu sein, denn der Triggermarker liegt nicht auf der Kurve.
Bitte prüfe, ob Du eine Auflösungserhöhrung von 8 Bit auf 9 oder mehr Bit eingestelt hast.
Ein komplettes Bildschirmfoto der PicoScope-Software wäre hilfreich.
Viele Erfolg.
Diese ganzen SO witzigen Bemerkungen könnt ihr euch sparen. Ich hab auch
nur gefragt, weil ich die Fehler, die hier mir unterstellt werden, nicht
gemacht habe. Die SPI-Leitung kommen geradelinig aus dem Pico heraus.
Sonst ist nichts dran.
Bis zu einer Taktrate von 330MHz kann man Rechteck Signale aus einem Pin jagen und mit einem zweiten Pin korrekt lesen. Und zwar mit lediglich 2mA /drive strength/. Mit 12mA gehen sogar 340MHz (Grenzwert).
Und du willst uns nun erzählen, dass ~1MHz (also 2*500ns) Probleme macht?
Hmmm, wo mag da der Fehler liegen …
Ich hab auch
nur gefragt, weil ich die Fehler, die hier mir unterstellt werden, nicht
gemacht habe.
Mit dieser Antwort (und den immer noch fehlenden, ausführlichen
Angaben) zeigst du (wieder mal) dass du nichts verstanden hast
bzw. nicht weisst was du wirklich machst.
weil ich die Fehler, die hier mir unterstellt werden, nicht
gemacht habe.
Du hast also alles richtig gemacht, und die Darstellung deines
Signals ist also so richtig?
Das nenne ich doch mal Beratungsresistenz. Ist aber - wenn man
richtig überlegt - nicht anders zu erwarten, wenn man deinen
vorangegangenen Thread anschaut.
Am SPICLK-pin habe versucht mehr Ausgangsstrom und SlewRate zu steigern.
Das hatte jedoch keine Wirkung.
Ich würde nachforschen, warum das nicht gebracht hat. Du könntest den Pin zum Gegentest mal als einfachen Ausgang konfigurieren und per Software toggeln. Wenn das klappt, hängt das Problem mit dem SPI spezifischen Code zusammen.
Belaste die CLK Leitung mit einen zusätzlichen Kondensator im Bereich um 1nF. Zeige uns dann nochmal den Spannungsverlauf deraillierter, egal wie gering die Spannung ist.
Es gibt ja nur ein Picoscope und eine Konfiguration dazu, also
brauchst du keine weiteren Angaben machen bzw. Details angeben.
Es erklärt sich alles von selbst.
Genau so ist es. Baujahr 1961!
Ein deutsches Userinterface ist etwa so huelfreich, wie deutsche
Fehlermeldungen von einem UNIX®.
Belastet man einen CMOS Ausgang kapazitiv, entsteht ein dreieckiges Signal, weil MOSFET ganz natürlich einen begrenzten Strom abhängig von der Steuerpannung (UGS) liefern.
Ich habe nun den Pico ausgebaut und nackt am USB hängen. Das Programm macht auf einen anderen PIN PWM. Dieser PIN hat die selben langsamen Flanken. Der nackte 2.Pico machte es auch so.
Dann sollte es am Picoscope liegen. Win11 neu gestartet, Picoscope auch. Keine Änderung. Was kann man falsch machen beim Anklemmen vom Tastkopf und Masse?
Ich erkenne im Bild vom TO hingegen den Verlauf, der sich aus einem
kobstanten Strom ergibt.
Ah ja, klar, der µC hat einen Konstantstromausgang. High ist 20 mA, Low ist 4 mA. Irgendwas mit Prozessor, also Signale aus der Prozesstechnik.
Man kann hier wirklich unendlich viel lernen.
Und nun mißt das Ding wie es soll. Keine Ahnung warum. Vermutlich im Zusammenhang mit dem heutigen Update. Jetzt reagiert auch die Änderungs der Abtastrate wieder.
Bleibt die Frage: Warum hat die neue Version zunächst das gleiche Verhalten wie die Alte gezeigt?
Fazit: Da hat sich wohl die Software verschluckt.
Danke für Eure Bemühungen.
Bitte prüfe, ob Du eine Auflösungserhöhrung von 8 Bit auf 9 oder mehr
Bit eingestelt hast.
Hatte er, und das um die maximal möglichen 4 Bit. Das sieht man in seinem vorletzten Bild oben links. Bei beiden Kanälen steht da "8+4, also 8 Bit Hardware-Auflösung plus 4 Bit berechnete. Und genau das war die Ursache für die flachen Flanken.
Und genau das war
die Ursache für die flachen Flanken.
Da kommen noch die anfaenglichen 5MS/s Abtastrate dazu. Diese 4 Bit
machen aus den 5MS/s effektive 5/256 MS/s
Die Abtastrate war bei allen gezeigten Bildern 500MS/s. Dargestellt wurde der gleitende Mittelwert über je 256 Messungen was zu den rund 500ns langen Flanken führte.
Dargestellt
wurde der gleitende Mittelwert über je 256 Messungen
Ein gleitender Mittelwert würde aber die Kanten verrunden.
Kommt drauf an. Es gibt etliche Varianten der Berechnung eines gleitenden Durchschnitts.
Die naheliegendste Form liefert bei eine Sprung eine Gerade, deren Steigung durch die Zahl der Speicherstellen für den gleitenden Mittelwert bestimmt wird.
Picotech beschreibt es so:
"The resolution enhancement feature is a flat moving-average filter.
This acts as a low-pass filter with good step response characteristics
and a very slow roll-off from the pass band to the stop band."
Die hätten Politiker werden sollen. Mit vielen Worten bloß nix konkretes sagen, auf das man festgenagelt werden könnte...
Mein Schlusswort:
Wie ich es nun sehe, ist mit den aktuellen Oszi-Variationen einiges zu beachten, das mit mit der analogen Technologie kein Problem war.
Gerne erinnere ich mich an 1974. Da hatte ich die Aufgabe Mainframe-CPUs in TTL-Logik nur mit einem Oszi (ein 1/4qm Kasten) zu reparieren. Ein Logig-Analicer wäre ein Traum gewesen. Aber es war möglich. Und in all der komplexität wäre es mir nie in den Sinn gekommen, der Oszi könne mir was vorgaugeln.
Ich habe damals nie die Bedienungsanweisung gelesen, es war einfach logisch, was die Knöpfe bewirkten.
Da ich nun Elektronik nur noch als Hobby betreibe, nostalgischer Weise, habe ich PicoScope erst bei zwei Projekten benutzt. Aber ich bin ja lernfähig.
Kommt drauf an. Es gibt etliche Varianten der Berechnung eines
gleitenden Durchschnitts.
Die naheliegendste Form liefert bei eine Sprung eine Gerade, deren
Steigung durch die Zahl der Speicherstellen für den gleitenden
Mittelwert bestimmt wird.
Das ist genau das, was hier zu sehen ist.
Wird auch als FIR Filtercharkteristik bezeichnet. Es gibt einen (Ring-)Speicher in dem die Werte von n zurückliegenden Messungen gespeichert sind. Jeder neue Messwert überschreibt den Ältesten und dann wird über alle Werte gemittelt.
Das "F" für finite sagt aus, dass immer nur die Werte der letzten n Messungen im Mittelwert enthalten sind.
Anders sieht es bei IIR Filtern aus. Da wird nur die Summe von n Messungen gespeichert und daraus der Mittelwert durch Division durch n gebildet. Sobald ein neuer Messwert vorliegt wird von der Summe der gegenwärtige Mittelwert abgezogen, der neue Messwert addiert und wieder gemittelt.
Wenn ich das noch richtig in Erinnerung habe, ergibt sich eine e-Funktion als Sprungantwort.
Ja, das sind die beiden Grundformen. Aber auch die gibt es noch in 'zig verschiedenen Varianten.
Wobei schon die Bezeichnungen der Grundformen schon nicht konsistent verwendet werden, noch weniger die Variantenbezeichnungen.
Sprich: entweder macht man es so, wie Picotech und labert einfach nur positiv klingenden, aber letztlich nichtssagenden Bullshit oder man gibt das Bildungsgesetz in Form einer Formel an. Das räumt dann alle Zweifel darüber aus, was da genau passiert.
Aber ich wüßte gerne eine Erklärung warum das so ist.
Bevor du die Schuld auf den PiPico schiebst, zeig erstmal ein Signal aus einer anderen Quelle, das nachweislich steiler ist, gemessen mit gleichen Einstellungen.
Sehe ich nicht so, hier trifft den Bediener höchstens der Vorwurf das falsche Messgerät ausgewählt zu haben, resp. ne "suboptimale" Firmware erwischt zu haben. Beitrag "Re: PiPico zu langsame Flanken SPI-CLK"
Für den Verdacht auf "lügendes Scope" kann man mit einem Analogscope gegenmessen, wie auch der TO selbstreflektierend erkannt hat.
Oder man misst mit dem selben Einstellungen an einem bekannten Signalgenerator als simple Funktionsprobe.
Abschliessend könnte man über den Austausch des scopes durch ein "Bedienrobustes" nachdenken.
Sprich: entweder macht man es so, wie Picotech und labert einfach nur
positiv klingenden, aber letztlich nichtssagenden Bullshit oder man gibt
das Bildungsgesetz in Form einer Formel an.
Wo hast du Probleme, die Angaben in eine Formel umzusetzen - Schwierigkeit mit Textaufgaben?
"Flat moving average" sagt doch alles. Alle Werte innerhalb des Mittelungsfenster gehen mit gleicher Gewichtung ein ("flat"), also geht es um eine Summenbildung innerhalb eines Fenster über eine konstante Anzahl n der letzten Messwerte ("moving") mit Gewichtung 1/n der Werte ("Average"). Der Frequenzgang ist eine Folge davon.
"Progressiver Modus 100 ms".
Was könnte das bedeuten?
Das ist der Schwellwert ab dem eine "Live-Vorschau" übetragen wird wenn der Trigger auslöst und nicht erst am ende der Messung. den Effekt sieht man bei ner mehrsekündigen messung dann sehr gut. Da baut sich die Kurve dann live auf anstatt erst nach ablauf der gesamten Dauer angezeigt zu werden
Komplett irrelevant, aber weil hier so lieb gefragt wird, sei auf die
Suchfunktion (Ctrl+F) verwiesen. (siehe Anhang).
Die Technik des Internets scheint dich kurz nach der Steinzeit abgehängt zu haben.
An Stelle von Zitaten mit Quellenangabe in Form von Screenshots mit markierten Textstellen ist es mittlerweile möglich und üblich, die Quelle zu verlinken.
Deinen hyperschlauen Verweis auf die Suchfunktion kannst du dir sonstwohin stecken.
An Stelle von Zitaten mit Quellenangabe in Form von Screenshots mit
markierten Textstellen ist es mittlerweile möglich und üblich, die
Quelle zu verlinken.
Lass dir mal den Unterschied zwischen möglich und nötig erklären. Und den Unterschied zwischen Referenz (Link) und Entität (Tatsache).
Deinen hyperschlauen Verweis auf die Suchfunktion kannst du dir
sonstwohin stecken.
SPI-Timing.jpg
(120 KB)
#/media/Datei:Ladevorgang.svg){kind=link}