Perché alcuni dei miei segnali "tremano" (hanno jitter)?

Ho un bus SPI a 2 MHz ma una cosa che ho notato è che alcuni dei miei segnali spesso "tremano". Sì, il mio trigger è configurato correttamente, quindi non credo che il problema sia lì.

Puoi vedere cosa intendo qui: (questo è con la modalità di persistenza attiva). Questo è l'orologio del mio bus SPI.

La SPI funziona bene. Ho trasferito centinaia di megabyte su più schede e finora non ho riscontrato alcun problema. Ma sono ancora interessato a sapere quale potrebbe essere il problema qui. Inoltre, dovrei preoccuparmi di risolverlo anche se funziona?

Le misurazioni sono state prese direttamente alla fonte con una clip MOLTO piccola.

Questo è uno schema semplificato del mio circuito. Naturalmente la scheda ha più dispositivi SPI ma ai fini di questa domanda questo è accurato perché la scheda non ha ancora saldato nulla tranne l'uC e la scheda SD.

Il master (AVR Mega 128) sta esaurendo il suo oscillatore RC interno - non so se questo sarebbe rilevante, ma poiché i segnali si spostano nel tempo è possibile che anche il jitter dell'oscillatore RC finisca nel bus SPI. Ho pensato di menzionarlo. Mi è anche venuto in mente che durante queste misurazioni ho fatto funzionare il controller in un ciclo infinito. Ecco il codice:

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

Il jitter / brivido potrebbe verificarsi quando l'interno funziona per 72 volte e poi si chiude. Poiché è necessario un tempo aggiuntivo per eseguire le prime tre righe, è possibile che ogni 73a forma d'onda arrivi in ​​un momento leggermente diverso a causa del tempo di elaborazione aggiuntivo. Se dovessi scommettere, immagino che questa sia la causa del mio problema (se potessi, lo confermerei in questo istante ma le mie schede sono al lavoro e la settimana successiva è fuori!) Ma mi piacerebbe comunque avere opinioni / risposte di SE su questo argomento.

Ma considerando che l'uC funziona a 8 Mhz, non faccio jitter a causa del software, perché in nanosecondi ma piuttosto microsecondi. Ma nella seconda figura è visibile una linea piatta. Ciò si verifica per un brevissimo secondo in cui l'intera forma d'onda si sposta nel tempo ed è invisibile sullo schermo. Immagino che ciò sia dovuto al loop e il jitter nella prima immagine sia dovuto all'oscillatore RC.

Ciò che mostra il tuo ambito è un classico esempio di jitter , che significa un errore nella tempistica di un evento (fronte di salita o di discesa), indipendentemente dal fatto che ci sia del rumore di tensione sul segnale.

Ma cosa può causare il jitter nel tuo sistema?

• Mentre speculi, se l'orologio principale uC è nervoso, molto probabilmente il jitter si trasferirà direttamente all'uscita del clock dalla periferica SPI.

  Un bypass inadeguato (dovresti avere un bypass di massa aggiuntivo sulla tua scheda oltre ai due condensatori da 100 nF che hai disegnato) potrebbe portare a jitter nel circuito di clock uC.

  Anche il rumore dell'alimentazione introdotto da altri circuiti sulla scheda potrebbe avere questo effetto (ma sarebbe ridotto da un ulteriore bypass).

• Il jitter potrebbe essere inerente alle prestazioni della periferica SPI dell'UC. Deve generare l'orologio SPI con riferimento all'orologio di sistema. Se utilizza un semplice divisore (da 4 a 1 nel caso del clock di sistema a 8 MHz e del clock SPI a 2 MHz) non ti aspetteresti di vedere molto jitter aggiunto (anche se il jitter del clock di sistema passerebbe attraverso). Ma se utilizza uno schema più complesso, come un PLL, quel circuito potrebbe variare l'ampiezza dell'impulso del clock SPI per rimanere sincronizzato con il clock di sistema, e lo vedresti come jitter. Un circuito PLL potrebbe anche essere particolarmente sensibile al rumore dell'alimentazione.

Se l'ampiezza del jitter è limitata a una piccola frazione del periodo di clock, come sembra essere qui, non c'è motivo per cui questo jitter causerà errori sul bus SPI (in accordo con l'osservazione che il bus SPI sembra funzionare come previsto) .

Mi sembra che il jitter del segnale. Il periodo di clock varia minuziosamente, tanto che la persistenza del cannocchiale fa sembrare il bordo "macchiato".

Non so se il tuo ambito Rigol abbia la capacità di calcolare le statistiche quando misura. In tal caso, è possibile regolare il punto di trigger in modo che il bordo di trigger venga visualizzato sul bordo sinistro dello schermo, regolare la base dei tempi per mostrare un periodo completo e misurare la variazione di frequenza nel tempo per avere un'idea della variazione. (Il jitter può avere un aspetto peggiore rispetto a quando il bordo del trigger è fuori schermo.)

Se vuoi restringere le fonti di jitter, inizierei con l'oscillatore RC. Vedi se hai un'opzione per usare un diverso metodo di clock (come un cristallo), implementalo e rimisura il jitter.

Le immagini dell'ambito possono essere fuorvianti e devi guardare tutti i parametri per interpretare correttamente i dati. La prima immagine mostra un jitter di 10 ns, e non sarebbe così bello se il trigger fosse solo sullo schermo a sinistra. Ma in basso a destra dice trigger + 1,78 µs, quindi 10 ns è in realtà solo lo 0,5% dell'intervallo di tempo. Tale livello di jitter potrebbe essere dovuto all'oscillatore RC. Aspettatevi che il jitter venga ridotto di almeno un ordine di grandezza con un oscillatore a cristallo.

Dici di non aver ancora riscontrato alcun problema nel trasferimento dei dati SPI. Questo grazie alla relatività dello 0,5%. Se MOSI 1 µs prima dell'impulso CLK il jitter 0,5% provocherà un jitter 5 ns, ciò non violerà i tempi di configurazione e di attesa.

Se hai bisogno di rassicurazione, imposta la base dei tempi in modo tale da poter vedere un tempo di bit completo, sia il canale MOSI che CLK. Noterai che il jitter sarà difficilmente visibile e che i bordi successivi rimarranno ben separati.

Il jitter è una forma di rumore. Se consideri i tempi di inter-arrivo tra i bordi degli impulsi un tipo di segnale, allora se quei bordi non tremano, significa che il tuo sistema mostra un segnale privo di rumore!

Le onde quadrate sono spesso generate dalla soglia su un'onda più continua, con alcuni circuiti di tipo trigger di Schmidt che hanno un comportamento di isteresi. Gli oscillatori Crystal o RC non emettono "nativamente" onde quadrate.

Quindi, se quell'onda in ingresso ha del rumore di tensione, quel rumore si tradurrà in lievi cambiamenti nell'innesco, poiché la tensione raggiunge a volte raggiunge una delle soglie prima e talvolta dopo.

E così, il rumore di un tipo (rumore di tensione) si trasforma in rumore di un altro tipo (rumore di temporizzazione).