Problema di terminazione del bus SPI

Ho lavorato a un progetto in cui un master OMI Linux SPI interagisce con 6 periferiche slave SPI (5 convertitori A / D e singolo magnetometro).

Posso impostare la frequenza di clock SPI e ho sperimentato 50 kHz, 100 kHz e 1MHz.

Ho allegato uno schema di cablaggio / scheda che mostra la lunghezza del master SPI e di tutte le periferiche. La lunghezza del bus SPI (tutte le lunghezze dei fili) dal master è di circa 970 mm per il mio caso di esperimento.

Il problema che ho riscontrato è che la comunicazione con 1 periferica non riesce poiché aggiungo più altre periferiche sul bus. Anche se la comunicazione arriva al magnetometro sul lato opposto del bus, la comunicazione con i convertitori A / D sull'altro lato fallisce fino a quando lo stub del cablaggio del magnetometro viene rimosso e quindi la sezione A / D ritorna.

Ho fatto alcune letture qui: Considerazioni sulla terminazione del bus SPI e qui: Comunicazione Board to Board a breve distanza

dove si consiglia di posizionare un LPF RC il più vicino possibile a qualsiasi nodo guida, quindi SCLK e MOSI sul lato master e ciascuno dei miei 6 segnali MISO / SOMI. Ho visto un approccio simile fatto per USB con rete 47pF / 27R RC. La mia intenzione è quella di provare questo sul mio circuito nel tentativo di ridurre la transizione del bordo tagliente ~ ~ 100nsec.

È questa la procedura giusta che sto seguendo qui con l'aggiunta di un LPF RC? Sembra davvero shakey, c'è pratica migliore? Ho visto una nota dell'app di TI in cui si parla di estendere SPI per distanze bus più lunghe, questa è una soluzione appropriata qui o il mio problema è semplicemente una delle armoniche ad alta frequenza dalla transizione del bordo ad alta velocità? http://www.ti.com/lit/an/slyt441/slyt441.pdf

Grazie Nick

È difficile rispondere a questa domanda senza tutti i dettagli, ma ecco uno sguardo generico al problema che credo possa essere anche il tipo di risposta più utile per questo sito.

Le reti multi-nodo devono sempre essere simulate. Sono così difficili da prevedere. E ci sono voluti circa 3 minuti per vedere che il tuo design forse non era ottimale.

Ecco l'impostazione di simulazione per l'orologio dal master a tutti i dispositivi slave (i valori sono solo stime approssimative, come sarebbe il caso se lo facessi prima di costruire qualcosa):

E il diagramma di simulazione risultante (ignoriamo ciò che è cosa, unità ecc. In quanto ovviamente non vale la pena costruire):

La prima idea che mi viene in mente è un collegamento a margherita di tutti gli input e una semplice terminazione parallela. Uno schema fly-by se lo desideri. Sembra così nell'impostazione della simulazione:

E la trama del risultato sembra molto più bella:

Se riesci a convivere con il maggiore consumo di energia della terminazione thevenin e la ridotta oscillazione della tensione sugli ingressi del clock dei vari dispositivi e ... (solo tu conosci i vincoli effettivi) ... allora alcune variazioni di questo potrebbero effettivamente valere costruzione.

Esistono altre soluzioni che potrebbero funzionare, ma la chiave è capire che le reti multi-nodo non sono facili da prevedere. I 5 minuti di simulazione qui prima di creare qualcosa possono farti risparmiare molto tempo dopo. Sfortunatamente questo tipo di simulatori non è economico.

Sto usando Cadence SigXplorer qui. Si applica il solito disclaimer: insegno lezioni sull'integrità del segnale e spesso ho licenze software per sponsor Cadence o Mentor per quelle classi.