Vedi aliasing nella tua cattura, non clock jitter - un caso dello strumento sbagliato per il lavoro.
Un clock da 2 Mhz ha un periodo di 500 ns, quindi è alto per 250 ns. Con un analizzatore logico a 16 Mhz stai prelevando campioni ogni 62,5 ns, quindi idealmente vedresti 4 campioni alti e 4 campioni bassi che si ripetono.
Ora considera l'effetto di una minuscola differenza di frequenza dello 0,5% sull'oscillatore della CPU, quindi la rete di divisione fino al bus SPI ora funziona con un periodo di 251,25 ns. Nota:la frequenza non si sposta nel tempo, è ancora un cristallo ideale, ma la forma d'onda che stiamo cercando di catturare non è più un multiplo esatto del clock di acquisizione 62.5ns. Questo ti dà aliasing con pattern di 4/4, 3/5, 4/4, 5/3,... come il rapporto alto/basso nella tua cattura mentre osservi la relazione di fase tra i due clock che vanno alla deriva dentro e fuori.
Il tuo analizzatore è ancora buono per catturare i segnali SPI (sopra Nyquist ecc.), ma non è adatto per giudicare la stabilità del clock. Per questo, usa un oscilloscopio attivato su un bordo per vedere la stabilità dell'altro bordo e un contatore di frequenza calibrato per controllare la frequenza assoluta.
Poiché SPI è un protocollo sincrono, la frequenza esatta in qualsiasi momento non ha molta importanza. Tutto è adattato ai bordi dell'orologio, quindi il tempo esatto tra i bordi non ha molta importanza, ovviamente entro i limiti del dispositivo.
Esistono diversi modi in cui i segnali SPI possono essere generati. In alcuni casi, un dispositivo avrà un hardware che può essere istruito per inviare il contenuto di un certo intervallo di memoria alla porta SPI senza l'intervento del processore. In tali casi, ci sarà generalmente una sequenza uniforme di impulsi di clock, sebbene sia possibile che ci sia una "pausa" dopo ogni ottavo. In alcuni casi, un processore dovrà caricare ogni byte in uno shifter che sia in grado di accettare almeno un byte "in anticipo" rispetto a quello che viene spostato. L'output in questi casi sarà spesso simile a quello del caso hardware puro, tranne per il fatto che occasionalmente potrebbero esserci intervalli casuali dopo multipli di otto clock se il software occasionalmente non riesce a caricare il byte successivo prima che il byte attuale venga spostato, ma a seconda i tempi del processore che potrebbero non verificarsi mai. Nei casi precedenti, l'uso di funzioni di trigger ritardato su un ambito può essere utile quando si esaminano dati formattati regolarmente, perché tutto avverrà sempre (o quasi sempre) in un momento coerente rispetto all'inizio di un frame.
Le cose non sono sempre così belle, però. È abbastanza comune che i dispositivi dispongano di hardware in grado di inviare automaticamente 8 bit, ma richiedono che il software attenda fino a quando un gruppo di 8 viene inviato prima di accodare il successivo. Questo crea gruppi di 8 impulsi di clock regolarmente distanziati, con quantità casuali di spazio tra di loro. Ciò spesso preclude l'uso di funzioni di scansione ritardata, ma d'altra parte spesso rende più facile l'identificazione dell'inizio e dell'arresto di ciascun byte rispetto a quanto sarebbe se tutti gli impulsi fossero uniformi. L'ultima possibilità è che il software stia generando un segnale SPI utilizzando una sequenza di comandi "set port high" e "set port low". Questo è ciò che sembra accadere nell'esempio qui sopra.
Nella maggior parte dei casi, il dispositivo master su un bus SPI (il RasPi in questo caso) è libero di utilizzare qualsiasi combinazione di impulsi lunghi e brevi ritenga opportuno, soggetto solo a limitazioni su determinate temporizzazioni minime degli impulsi e, occasionalmente, tempistiche massime degli impulsi che sono spesso ordini di grandezza superiori ai minimi (ad es. un dispositivo può avere un'ampiezza minima dell'impulso e una separazione degli impulsi di 250 ns ciascuno, ma un tempo massimo tra gli impulsi di 1 ms, più di tre ordini di differenza di grandezza). A condizione che i tempi di impulso rimangano entro limiti molto ampi (e in molti casi non ci sarebbe alcun limite massimo), la comunicazione dovrebbe essere affidabile.
L'unico momento in cui è probabile la perdita di dati con SPI è quando il dispositivo slave è un processore. L'hardware SPI slave integrato in molte CPU richiede che quando arriva un byte, il processore deve agire prima che si avvii il master inviare il byte successivo per evitare la perdita di dati, ma non fornisce alcun mezzo con cui lo slave possa dire al master che è pronto; di conseguenza, gli slave spesso devono utilizzare cinque linee per comunicare con il master (orologio, MOSI, MISO, CS e una linea "pronta" implementata manualmente) oppure richiedono che il master aggiunga un ritardo dopo ogni byte sufficiente per accogliere il tempo di risposta nel caso peggiore dello slave.