Problem mit der Beendigung des SPI-Busses

Ich habe an einem Projekt gearbeitet, bei dem ein OMAP Linux SPI-Master mit 6 SPI-Slave-Peripheriegeräten (5x A / D-Wandler und Einzelmagnetometer) interagiert.

Ich kann die SPI-Taktfrequenz einstellen und habe mit 50 kHz, 100 kHz und 1 MHz experimentiert.

Ich habe ein Verdrahtungs- / Platinen-Diagramm beigefügt, das die Länge des SPI-Masters und aller Peripheriegeräte zeigt. Die SPI-Buslänge (alle Kabellängen) vom Master entfernt beträgt für meinen Experimentierfall ungefähr 970 mm.

Das Problem, das ich festgestellt habe, ist, dass die Kommunikation mit einem Peripheriegerät fehlschlägt, wenn ich weitere Peripheriegeräte auf dem Bus hinzufüge. Selbst wenn die Kommunikation zum Magnetometer auf der anderen Seite des Busses erfolgt, schlägt die Kommunikation mit den A / D-Wandlern auf der anderen Seite fehl, bis der Magnetometer-Kabelbaumstummel entfernt wird und der A / D-Abschnitt zurückkehrt.

Ich habe hier etwas gelesen: Überlegungen zur Beendigung des SPI-Busses und hier: Kurzstrecken-Kommunikation von Board zu Board

Wo empfohlen wird, einen RC-LPF so nahe wie möglich an einem beliebigen Treiberknoten zu platzieren, also SCLK und MOSI auf der Masterseite und jedes meiner 6x MISO / SOMI-Signale. Ich habe einen ähnlichen Ansatz für USB mit 47pF / 27R RC-Netzwerk gesehen. Meine Absicht ist es, dies auf meiner Schaltung zu versuchen, um den schnellen Kantenübergang mit scharfen Kanten von ~ 100 ns zu reduzieren.

Ist dies das richtige Verfahren, das ich hier beim Hinzufügen eines RC-LPF befolge? Das scheint wirklich wackelig, gibt es eine bessere Praxis? Ich habe eine App-Notiz von TI gesehen, in der über die Erweiterung des SPI für längere Busentfernungen gesprochen wird. Ist dies hier eine geeignete Lösung oder mein Problem einfach eine der Hochfrequenz-Harmonischen aus dem Hochgeschwindigkeits-Kantenübergang? http://www.ti.com/lit/an/slyt441/slyt441.pdf

Danke, Nick

Es ist schwierig, dies ohne alle Details zu beantworten, aber hier ist ein allgemeiner Blick auf das Problem, von dem ich glaube, dass es auch die nützlichere Art der Antwort für diese Site ist.

Multi-Node-Netze sollten immer simuliert werden. Sie sind so schwer vorherzusagen. Und es dauerte ungefähr 3 Minuten, um festzustellen, dass Ihr Design möglicherweise nicht optimal war.

Hier ist der Simulationsaufbau für die Uhr vom Master bis zu allen Slave-Geräten (Werte sind nur grobe Schätzungen, wie dies der Fall wäre, wenn Sie dies vor dem Erstellen von irgendetwas getan hätten):

Und das resultierende Simulationsdiagramm (wir ignorieren, was ist, Einheiten usw., da es offensichtlich nicht wert ist, erstellt zu werden):

Die erste Idee, die mir in den Sinn kommt, ist eine Verkettung aller Eingänge und eine einfache parallele Terminierung. Ein Fly-by-Schema, wenn Sie möchten. Dies sieht im Simulationssetup folgendermaßen aus:

Und das Ergebnisdiagramm sieht viel besser aus:

Wenn Sie mit dem erhöhten Stromverbrauch des Thevenin-Abschlusses und dem verringerten Spannungshub an den Takteingängen der verschiedenen Geräte leben können und ... (nur Sie kennen die tatsächlichen Einschränkungen) ... dann kann eine Variation davon tatsächlich sinnvoll sein Gebäude.

Es gibt andere Lösungen, die funktionieren würden, aber der Schlüssel ist zu verstehen, dass Netze mit mehreren Knoten nicht einfach vorherzusagen sind. Die 5 Minuten Simulation hier, bevor Sie etwas erstellen, können später viel Zeit sparen. Leider sind diese Simulatortypen nicht billig.

Ich verwende hier Cadence SigXplorer. Es gilt der übliche Haftungsausschluss: Ich unterrichte Klassen in Signalintegrität und habe häufig Cadence- oder Mentor-Sponsor-Softwarelizenzen für diese Klassen.