Warum „zittern“ einige meiner Signale (haben Jitter)?

Ich habe einen 2-MHz-SPI-Bus, aber eine Sache, die mir aufgefallen ist, ist, dass einige meiner Signale oft "zittern". Ja, mein Trigger ist richtig eingerichtet, also glaube ich nicht, dass das Problem dort liegt.

Sie können sehen, was ich hier meine: (Dies ist mit aktiviertem Persistenzmodus). Dies ist die Uhr meines SPI-Busses.

Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein

Der SPI funktioniert einwandfrei. Ich habe Hunderte von Megabyte auf mehrere Boards übertragen und bisher kein Problem gesehen. Aber mich würde trotzdem interessieren, woran es hier liegen könnte. Sollte ich mir auch die Mühe machen, es zu reparieren, obwohl es funktioniert?

Die Messungen wurden direkt an der Quelle mit einer SEHR kleinen Masseklemme durchgeführt.

Dies ist ein vereinfachtes Schema meiner Schaltung. Natürlich verfügt die Platine über mehr SPI-Geräte, aber für die Zwecke dieser Frage ist dies korrekt, da auf der Platine außer dem uC und der SD-Karte noch nichts gelötet ist.

Geben Sie hier die Bildbeschreibung ein

Der Master (AVR Mega 128) läuft über seinen internen RC-Oszillator - ich weiß nicht, ob dies relevant wäre, aber da sich die Signale zeitlich verschieben, ist es möglich, dass der Jitter des RC-Oszillators auch im SPI-Bus landet. Ich dachte nur, ich erwähne es. Mir ist auch aufgefallen, dass ich bei diesen Messungen den Regler in einer Endlosschleife laufen ließ. Hier ist der Code:

while(1)
{
    setFirstBitOnDriver(driver); // this sends a 8-bit command on the SPI bus.
    GLCD_SetCursorAddress(40); // Change cursor position on the display.
    GLCD_WriteText("LED: "); 
    for(wire=0;wire<72;wire++)
    {
        itoa(wire+1,str,10);
        GLCD_WriteText(str);
        GLCD_SetCursorAddress(44);
        _delay_ms(10);
        shiftVectorOnDriver(driver); // another command on SPI. 8-bit wide.
    }
}

Das Zittern/Zittern kann auftreten, wenn das interne 72 Mal ausgeführt wird und dann beendet wird. Da die Ausführung der ersten drei Zeilen eine zusätzliche Zeit in Anspruch nimmt, kann es sein, dass jede 73. Wellenform aufgrund der zusätzlichen Verarbeitungszeit zu einer etwas anderen Zeit ankommt. Wenn ich wetten müsste, schätze ich, dass dies die Ursache meines Problems ist (wenn ich könnte, würde ich es sofort bestätigen, aber meine Boards arbeiten und die nächste Woche ist frei!) Aber ich hätte trotzdem gerne Meinungen/ Antworten von SE zu diesem Thema.

Aber wenn man bedenkt, dass das uC mit 8 MHz läuft, zittere ich nicht aufgrund von Software, weil es in Nanosekunden, sondern eher in Mikrosekunden wäre. Aber in der 2. Abbildung ist eine flache Linie sichtbar. Dies geschieht für eine sehr kurze Sekunde, in der sich die gesamten Wellenformen zeitlich verschieben und auf dem Bildschirm unsichtbar sind. Ich vermute, dass dies auf die Schleife zurückzuführen ist und der Jitter im ersten Bild auf den RC-Oszillator zurückzuführen ist.

Was ist dein Auslöser?
@markrages Der Trigger ist auf CH1 auf 1,48 V eingestellt - ansteigende Flanke.
@ThePhoton Ja. Die Frage wurde mit weiteren Informationen aktualisiert. Ich bin neu in Jitter, also weiß ich nicht, ob es relevant wäre.
Eine Vermutung ist, dass der uC (meine Annahme), der das SPI-Taktsignal erzeugt, eine PLL verwendet, die durch Verkürzen oder Verlängern einiger Taktzyklen funktioniert, um sich selbst an die Referenz zu binden. Wenn diese kurzen oder langen Taktzyklen auftreten, erzeugt dies Jitter auf Ihrer Oszilloskopspur, da die Kanten, die Sie betrachten, früher / später im Vergleich zu der Kante kommen, von der Sie ausgelöst haben.
Oder wenn Sie den SPI nur bit-bangen (weil Sie nichts darüber gesagt haben, welche Art von Schaltung die SPI-Signale erzeugt), sehen Sie nur die Unsicherheit des Timings, mit dem Ihr Mikro auf einen Timer reagiert unterbrechen.
@ThePhoton Ich habe Informationen zum uC hinzugefügt. Es läuft über einen internen RC-Oszillator. Könnte der Jitter des RC-Oszillators auf dem Bus landen? Die Frequenz beträgt 8 MHz. Ich schlage nicht ein bisschen - ich verwende die dedizierte SPI-Hardware auf dem uC.
Oder der SPI wird in Ihrer Hauptschleife generiert, aber manchmal gibt es einen Interrupt, der die Ausführung der Hauptschleife verzögert, sodass Sie wieder Unterschiede in der Periode der Schleife sehen.
Ja, jeder Jitter auf dem Hauptoszillator des uC wird wahrscheinlich direkt auf die SPI-Uhr übertragen – schließlich hat das Mikro keine andere Definition dessen, was 0,5 us sind, außer dass es 4 Zyklen seiner Hauptuhr sind.
@ThePhoton Das macht sehr viel Sinn. Meinst du, ich sollte die Frage löschen oder offen lassen? Ich entschuldige mich dafür, dass ich anfangs nicht mehr Informationen geteilt habe - ich wusste nicht einmal, dass dies Jitter genannt wird, und wusste daher nicht, was relevant oder nicht relevant war.
Es ist wahrscheinlich eine gute Frage, ob Sie ein vereinfachtes Schema hinzufügen, das den uC zeigt, der den Bus antreibt, und die RC-Elemente, die seinen Oszillator steuern. Wenn Sie nichts über Jitter wussten, gibt es viele andere Leute da draußen, die es auch nicht wissen ... und sie könnten auch etwas aus Ihrer Frage lernen. Ich werde meine Kommentare löschen, die Sie bereits in der Frage beantwortet haben.
@ThePhoton Zeichnen des (vereinfachten) Schemas, während ich dies schreibe.
Vielleicht möchten Sie auch experimentieren und bestätigen, dass der Jitter vom RC-Osc kommt, bevor Sie wirklich glauben, dass es wahr ist.
Das sieht nicht wirklich nach viel Jitter aus, besonders im Vergleich zu den Scope-Plots hier: avrfreaks.net/…
@dext0rb Wow, das ist eine Menge Jitter.
Das Wort ist "Jitter", aber Sie können "Schock" sagen ;-)
Okay, ich sehe es jetzt. Der Triggerpunkt befindet sich links vom Bildschirm, sodass das Oszilloskop bei einer vorherigen Taktflanke ausgelöst wurde. Dasjenige, das wir auf dem Bildschirm sehen, variiert zeitlich mit demjenigen, das wir nicht sehen können. Wir waren verwirrt, weil etwas am Auslösepunkt per Definition nicht zittern kann.

Antworten (4)

Was Ihr Oszilloskop zeigt, ist ein klassisches Beispiel für Jitter , was einen Fehler im Timing eines Ereignisses (steigende oder fallende Flanke) bedeutet, unabhängig davon, ob das Signal Spannungsrauschen enthält.

Aber was kann den Jitter in Ihrem System verursachen?

  • Wie Sie spekulieren, wird dieser Jitter höchstwahrscheinlich direkt auf den Taktausgang des SPI-Peripheriegeräts übertragen, wenn die uC-Hauptuhr zittert.

    Eine unzureichende Umgehung (zusätzlich zu den beiden 100-nF-Kondensatoren, die Sie gezeichnet haben, sollte auf Ihrer Platine eine zusätzliche Bulk-Umgehung vorhanden sein) könnte zu Jitter in der uC-Taktschaltung führen.

    Netzteilrauschen, das von anderen Schaltungen auf Ihrer Platine eingeführt wird, könnte ebenfalls diesen Effekt haben (würde aber durch mehr Umgehung reduziert).

  • Der Jitter könnte in der Leistung des SPI-Peripheriegeräts des uC liegen. Es muss den SPI-Takt in Bezug auf den Systemtakt erzeugen. Wenn es einen einfachen Teiler verwendet (4-zu-1 im Fall eines 8-MHz-Systemtakts und eines 2-MHz-SPI-Takts), würden Sie nicht erwarten, dass überhaupt viel zusätzlicher Jitter zu sehen ist (obwohl Systemtakt-Jitter direkt durchgehen würde). Wenn jedoch ein komplexeres Schema wie eine PLL verwendet wird, könnte diese Schaltung die SPI-Taktimpulsbreiten variieren, um mit der Systemuhr synchron zu bleiben, und Sie würden dies als Jitter sehen. Eine PLL-Schaltung könnte auch besonders empfindlich auf Stromversorgungsrauschen reagieren.

Wenn die Jitter-Amplitude auf einen kleinen Bruchteil der Taktperiode begrenzt ist, wie es hier scheint, gibt es keinen Grund, warum dieser Jitter Fehler auf dem SPI-Bus verursacht (in Übereinstimmung mit Ihrer Beobachtung, dass der SPI-Bus wie erwartet zu funktionieren scheint). .

Ich habe eine Bypass-Kappe von 100 nF. auf jedem vcc/gnd-Paar auf jedem Chip. Würdest du noch mehr vorschlagen? Wenn ja, zusätzliche 100nF- oder 1uF-Kappen?
Wenn dieser Jitter das schlimmste Leistungsproblem auf Ihrem Board ist, müssen Sie nichts ändern. Je nachdem, wie viele andere Schaltungen sich in Ihrem System befinden und was sie tun, sind einige zusätzliche 1-, 10- und/oder 100-uF-Bypass-Kappen, die über die Platine verteilt sind, eine gängige Designpraxis. Diese sind nicht auf einen bestimmten Chip lokalisiert, sie bieten eine "Massen"-Umgehung für die gesamte Platine.
Ja, ich habe zu diesem Zweck zwei 47u-Tantal auf der Platine. Also sollte ich mit dem Bypass-Teil in Ordnung sein.
SPI ist voll synchron. Kein Jitter wird dazu führen, dass SPI fehlschlägt.
@markrages, in der Situation von OP stimmt das. Prinzipiell könnte aber ein wirklich extremer Perioden-Jitter beispielsweise den Abstand zwischen steigender Flanke und fallender Flanke soweit verkürzen, dass die Setup-Zeit des Slave-Teils verletzt wird und die Schnittstelle ausfällt. Dafür müsste der Jitter jedoch fast der Hälfte der Taktperiode entsprechen.
Ich gehe davon aus, dass Daten an der steigenden Flanke und Daten an der fallenden Flanke eingehen ...

Das sieht für mich nach Signal-Jitter aus. Die Taktperiode variiert geringfügig, genug, dass die Persistenz des Oszilloskops die Kante „verschmiert“ aussehen lässt.

Ich weiß nicht, ob Ihr Rigol-Oszilloskop die Fähigkeit hat, Statistiken zu berechnen, wenn es misst. Wenn dies der Fall ist, können Sie Ihren Triggerpunkt so anpassen, dass Ihre Triggerflanke am linken Rand des Bildschirms erscheint, die Zeitbasis anpassen, um eine vollständige Periode anzuzeigen, und die Frequenzänderung über die Zeit messen, um ein Gefühl für die Änderung zu bekommen. (Jitter kann schlimmer aussehen, als wenn die Triggerflanke außerhalb des Bildschirms liegt.)

Wenn Sie die Jitterquellen eingrenzen möchten, würde ich mit dem RC-Oszillator beginnen. Prüfen Sie, ob Sie die Möglichkeit haben, eine andere Taktmethode (wie einen Kristall) zu verwenden, implementieren Sie sie und messen Sie den Jitter erneut.

Werde es bei Arbeitsbeginn mit einem externen Oszillator versuchen!

Oszilloskopbilder können irreführend sein, und Sie müssen sich alle Parameter ansehen, um die Daten richtig zu interpretieren. Das erste Bild zeigt einen Jitter von 10 ns, und das wäre nicht so schön, wenn der Trigger nur links neben dem Bildschirm wäre. Aber unten rechts steht Trigger + 1,78 µs, also sind 10 ns eigentlich nur 0,5 % des Zeitintervalls. Dieser Jitterpegel kann durchaus auf den RC-Oszillator zurückzuführen sein. Erwarten Sie, dass der Jitter mit einem Quarzoszillator um mindestens eine Größenordnung reduziert wird.

Sie sagen, Sie haben noch keine Probleme bei der SPI-Datenübertragung festgestellt. Das liegt an der Relativität der 0,5 %. Wenn Sie 1 µs vor dem CLK-Impuls MOSI machen würden, würde der Jitter von 0,5 % einen Jitter von 5 ns verursachen, was die Setup- und Hold-Zeiten nicht verletzen würde.

Wenn Sie Sicherheit brauchen, stellen Sie einfach die Zeitbasis so ein, dass Sie eine vollständige Bitzeit sehen können, sowohl den MOSI- als auch den CLK-Kanal. Sie werden feststellen, dass der Jitter kaum sichtbar ist und dass die aufeinanderfolgenden Kanten gut getrennt bleiben.

Steven, kannst du erklären, warum die Position des Abzugs wichtig ist? Wie kommst du auf die 0,5%?
@Saad - Der Auslösepunkt ist Zeit = 0. Was auf dem Display angezeigt wird, passiert 1,78 us = 1780 ns später. Und der 10-ns-Jitter (mehr oder weniger) ist die Variation dieser 1780 ns, also 10 ns/1780 ns = 0,56 %. Es sieht so schlecht aus, weil es auf diese abfallende Flanke gezoomt ist, aber die Referenzkante (der Trigger) befindet sich mehrere zehn Meter links. Wenn Sie also herauszoomen, um den vollen Puls zu sehen, sieht der Jitter viel kleiner aus. Wenn der Triggerpunkt knapp links von der Anzeige wäre, sagen wir bei -100 ns, dann wäre der 10-ns-Jitter 10 %.

Jitter ist eine Form von Rauschen. Wenn Sie die Zwischenankunftszeiten zwischen den Flanken von Impulsen als eine Art Signal betrachten, dann bedeutet dies, dass Ihr System ein rauschfreies Signal aufweist, wenn diese Flanken überhaupt nicht jittern!

Rechteckwellen werden häufig durch Schwellwertbildung auf einer kontinuierlicheren Welle erzeugt, mit einer Schaltung vom Typ Schmidt-Trigger, die ein Hystereseverhalten aufweist. Kristall- oder RC-Oszillatoren geben keine "nativen" Rechteckwellen aus.

Wenn diese Eingangswelle also ein gewisses Spannungsrauschen aufweist, führt dieses Rauschen zu leichten Verschiebungen in der Auslösung, da die Spannung manchmal früher und manchmal später einen der beiden Schwellenwerte erreicht.

Und so wird Rauschen der einen Art (Spannungsrauschen) zu Rauschen einer anderen Art (Timing-Rauschen).