Anda melihat aliasing dalam tangkapan Anda, bukan jam jitter - kasus alat yang salah untuk pekerjaan itu.
Jam 2Mhz memiliki periode 500ns, jadi tinggi untuk 250ns. Dengan penganalisis logika 16Mhz, Anda mengambil sampel setiap 62,5 detik, jadi idealnya Anda akan melihat 4 sampel tinggi, 4 sampel rendah berulang.
Sekarang pertimbangkan efek dari perbedaan frekuensi yang sangat kecil 0,5% pada osilator CPU, sehingga jaringan pembagi hingga bus SPI sekarang berjalan dengan periode 251,25ns. Catatan:frekuensinya tidak bergeser dari waktu ke waktu, ini masih merupakan kristal yang ideal, tetapi bentuk gelombang yang kami coba tangkap tidak lagi merupakan kelipatan tepat dari jam tangkap 62,5ns. Ini memberi Anda aliasing dengan pola 4/4, 3/5, 4/4, 5/3,... sebagai rasio tinggi/rendah dalam tangkapan Anda saat Anda mengamati hubungan fase antara dua jam yang bergerak masuk dan keluar.
Penganalisis Anda masih bagus untuk menangkap sinyal SPI (di atas Nyquist dll), tetapi tidak cocok untuk menilai stabilitas jam. Untuk itu, gunakan cakupan yang dipicu di satu sisi untuk melihat stabilitas sisi lainnya dan penghitung frekuensi terkalibrasi untuk memeriksa frekuensi absolut.
Karena SPI adalah protokol sinkron, frekuensi yang tepat pada satu titik waktu tidak menjadi masalah. Semuanya dikunci ke tepi jam, jadi waktu yang tepat di antara tepian benar-benar tidak masalah - tentu saja dalam batas perangkat.
Ada sejumlah cara di mana sinyal SPI dapat dihasilkan. Dalam beberapa kasus, perangkat akan perangkat keras yang dapat diinstruksikan untuk mengirimkan isi dari rentang memori tertentu ke port SPI tanpa campur tangan prosesor. Dalam kasus seperti itu, umumnya akan ada urutan pulsa jam yang seragam, meskipun mungkin ada "jeda" setelah setiap kedelapan. Dalam beberapa kasus, prosesor perlu memuat setiap byte ke dalam shifter yang mampu menerima setidaknya satu byte "di muka" dari yang sedang digeser. Output dalam kasus-kasus tersebut akan sering terlihat seperti itu dari kasus perangkat keras murni, kecuali bahwa kadang-kadang ada celah acak setelah kelipatan delapan jam jika perangkat lunak kadang-kadang gagal memuat byte berikutnya sebelum byte saat ini dipindahkan, tetapi tergantung pada waktu prosesor yang mungkin tidak pernah terjadi. Dalam kasus di atas, penggunaan fungsi pemicu tertunda pada cakupan mungkin berguna saat memeriksa data yang diformat secara teratur, karena semuanya akan selalu (atau hampir selalu) terjadi pada waktu yang konsisten relatif terhadap awal bingkai.
Namun, hal-hal tidak selalu menyenangkan. Sangat umum bagi perangkat untuk memiliki perangkat keras yang dapat mengirimkan 8 bit secara otomatis, tetapi memerlukan perangkat lunak untuk menunggu hingga satu grup berisi 8 bit dikirim sebelum mengantrekan berikutnya. Ini menciptakan kelompok 8 pulsa jam dengan jarak teratur, dengan jumlah ruang acak di antaranya. Ini sering menghalangi penggunaan fungsi delay-sweep, tetapi di sisi lain sering kali membuat identifikasi awal dan akhir setiap byte lebih mudah daripada jika semua pulsa seragam. Kemungkinan terakhir adalah bahwa perangkat lunak dapat menghasilkan sinyal SPI dengan menggunakan urutan perintah "set port high" dan "set port low". Itulah yang tampaknya terjadi pada contoh di atas.
Dalam kebanyakan kasus, perangkat master pada bus SPI (RasPi dalam hal ini) bebas untuk menggunakan campuran pulsa panjang dan pendek apa pun yang dianggap sesuai, hanya tunduk pada batasan waktu pulsa minimum tertentu dan, kadang-kadang, waktu pulsa maksimum yang sering urutan besarnya di atas minimum (misalnya perangkat mungkin memiliki lebar pulsa minimum dan pemisahan pulsa masing-masing 250ns, tetapi waktu maksimum antara pulsa 1ms - lebih dari tiga kali lipat perbedaan besarnya). Asalkan waktu pulsa tetap berada dalam batas yang ditarik secara luas (dan dalam banyak kasus tidak akan ada batas maksimum), komunikasi harus dapat diandalkan.
Satu-satunya waktu kehilangan data yang mungkin terjadi dengan SPI adalah ketika perangkat budak adalah sebuah prosesor. Perangkat keras slave SPI yang dibangun ke dalam banyak CPU mengharuskan saat sebuah byte tiba, prosesor harus bertindak sebelum master dimulai untuk mengirim byte berikutnya untuk menghindari kehilangan data, tetapi tidak menyediakan cara yang dapat digunakan oleh budak untuk memberi tahu master bahwa itu sudah siap; akibatnya, budak sering perlu menggunakan lima jalur untuk berkomunikasi dengan master (jam, MOSI, MISO, CS, dan jalur "siap" yang diimplementasikan secara manual) atau mengharuskan master menambahkan penundaan setelah setiap byte cukup untuk mengakomodasi waktu respons terburuk dari budak.