Konversi Bit ke Byte untuk Analisis Bingkai Serial

Mengubah Bit di Jalur Menjadi Byte di Buffer Anda

Begitu Anda memasang penganalisis logika pada jalur UART, SPI, I²C, atau CAN, hasil tangkapannya diukur dalam bit. Sementara itu firmware Anda bekerja dalam byte: buffer penerima berisi 64 entri, peta register berisi 12 register, bidang muatan yang dibatasi 8 byte. Setiap kali berpindah antara dua sudut pandang itu Anda sedang membagi delapan, dan mengerjakannya di kepala pukul tiga pagi saat sebuah bingkai gagal checksum adalah cara paling ampuh melahirkan bug meleset satu.

Faktornya: byte = bit ÷ 8 (sama saja dengan bit × 0,125). Bingkai CAN 2.0A sepanjang 108 bit berarti 108 ÷ 8 = 13,5 byte waktu jalur mentah — padahal hanya 8 byte di antaranya yang benar-benar muatan Anda.

Pembagiannya sepele. Yang bikin orang tersandung adalah bit mana yang barusan dihitung. Satu byte data aplikasi nyaris tidak pernah menempati persis delapan waktu-bit di jalur fisik, karena pembingkaian, sinkronisasi, dan deteksi galat sama-sama meminjam ruang di kabel yang sama.

Bit jalur vs bit muatan

Osiloskop menghitung setiap transisi di kabel, termasuk bit awal, bit henti, bit paritas, dan bit sisipan. Bagi semuanya dengan delapan dan yang Anda dapat adalah waktu jalur dalam satuan setara byte, bukan jumlah byte yang akan disimpan MCU Anda.

Lebar register

Lembar data menjelaskan periferal dalam bit — hasil ADC 12 bit, akumulator 24 bit, sampel sensor 40 bit. Mengonversinya ke byte memberi tahu berapa slot buffer dan berapa banyak isian yang sebenarnya dihabiskan setiap pembacaan.

Anggaran waktu

Waktu-bit adalah satuan yang menentukan latensi interupsi dan ukuran DMA. Ubah bit dalam satu ledakan kiriman menjadi byte dan Anda tahu apakah FIFO sempat terkuras sebelum bingkai berikutnya tiba.

Mengonversi Hasil Tangkapan Langkah demi Langkah

Pastikan dulu bit mana yang Anda maksud

Putuskan lebih dulu apakah Anda menghitung bit muatan atau seluruh bit yang terlihat oleh penganalisis. Untuk satu byte UART 8N1, jawabannya masing-masing 8 dan 10 — dua angka berbeda untuk pertanyaan yang sama.

Ketikkan jumlah bitnya

Masukkan angkanya di kolom bit. Nilai byte ikut berubah sambil Anda mengetik, jadi seluruh rincian bingkai bisa ditelusuri tanpa menekan apa pun. Hasil ekspor dekoder yang panjang sering membawa spasi atau koma desimal — keduanya diterima dan spasi diabaikan.

Salin angkanya langsung ke kode

Tombol salin di setiap kolom mengembalikan angka polos tanpa satuan dan tanpa spasi, persis yang Anda butuhkan ketika nilainya akan masuk ke sebuah #define, ukuran buffer, atau pernyataan uji.

Balik arahnya saat kembali ke osiloskop

Tekan tombol tukar satuan untuk bekerja dari byte kembali ke bit — berguna saat Anda tahu muatannya 32 byte dan butuh berapa waktu-bit yang akan dipakainya. Kedua menu satuan bisa dicari, jadi Anda juga bisa melompat ke kilobit atau byte per detik tanpa meninggalkan halaman ini.

Overhead Pembingkaian UART: Laju Baud ke Byte per Detik Efektif

Konfigurasi klasik 8N1 membungkus setiap byte data dengan satu bit awal dan satu bit henti, sehingga sepuluh waktu-bit hanya membawa delapan bit muatan — pajak tetap sebesar 25 %. Itulah sebabnya perkiraan naif "bagi saja laju baud dengan delapan" selalu lebih tinggi daripada yang sanggup diantarkan jalur tersebut.

Laju baud (bit/dtk)	Naif bit ÷ 8	Muatan nyata (8N1, 10 bit/byte)	Waktu untuk satu byte
9.600	1.200 B/dtk	960 B/dtk	1.042 µs
19.200	2.400 B/dtk	1.920 B/dtk	521 µs
38.400	4.800 B/dtk	3.840 B/dtk	260 µs
57.600	7.200 B/dtk	5.760 B/dtk	174 µs
115.200	14.400 B/dtk	11.520 B/dtk	86,8 µs
921.600	115.200 B/dtk	92.160 B/dtk	10,9 µs

Tambahkan satu bit paritas dan bingkainya menjadi sebelas waktu-bit, sehingga 9.600 baud turun menjadi sekitar 873 byte muatan per detik. Dua bit henti memakan satu slot lagi. Semua itu tidak mengubah aritmetika ÷8 — yang berubah adalah berapa bit yang layak Anda masukkan ke dalamnya.

Kedua kolom tetap hidup saat membandingkan bingkai

Ketik di kotak mana pun dan kotak satunya langsung menyusul, jadi Anda bisa memegang angka muatan di satu tangan dan angka waktu jalur di tangan lain tanpa mengetik ulang apa pun.

Keluaran tetap terbaca untuk kiriman panjang

Ribuan dipisahkan dengan spasi dan tangkapan yang sangat besar beralih ke notasi ilmiah, sehingga jejak berjuta-juta bit tetap terbaca alih-alih menjadi dinding angka.

Semua satuan bus dalam satu menu

Menu satuan yang bisa dicari mencakup bit, kilobit, byte, dan satuan laju per detik, sehingga angka dari CAN, SPI, atau UART bisa dinyatakan ulang tanpa berburu halaman lain.

Tidak ada yang keluar dari meja kerja

Seluruh hitungan berjalan di peramban setelah halaman dimuat, jadi angka yang Anda tarik dari hasil tangkapan milik pelanggan tidak pernah dikirim ke mana pun.

Pertanyaan Seputar Protokol Serial

Kenapa jalur 9.600 baud memindahkan 960 byte per detik, bukan 1.200?

Karena baud menghitung simbol di kabel, bukan bit muatan. Pada UART biner standar satu simbol sama dengan satu bit, jadi 9.600 baud berarti 9.600 waktu-bit per detik — tetapi sepuluh di antaranya habis untuk setiap byte data dalam pembingkaian 8N1. Membaginya dengan 8 memberi angka teoretis 1.200 B/dtk yang hanya terjadi kalau jalur itu isinya data semata; membaginya dengan 10 memberi 960 B/dtk yang benar-benar diterima aplikasi Anda.

Apa sumbangan bit awal, bit henti, dan bit paritas terhadap hitungan itu?

Bit awal adalah tepi turun yang menyuruh penerima mulai mencuplik; bit henti menahan jalur tetap diam cukup lama agar tepi awal berikutnya tidak ambigu. Keduanya tidak membawa informasi. Paritas, bila diaktifkan, menambahkan satu bit kesembilan di samping data murni untuk mendeteksi galat satu bit. Jadi bingkai 8E1 berisi 11 waktu-bit — setara 1,375 byte waktu jalur untuk satu byte muatan.

Apakah urutan MSB dulu atau LSB dulu mengubah jumlah byte yang saya dapat?

Tidak — jumlahnya sama saja, yang berbeda hanya nilai yang tersusun. UART menggeser keluar LSB lebih dulu, sedangkan SPI dan I²C lazimnya menggeser MSB lebih dulu. Mencampuradukkan keduanya menghasilkan byte dengan bit terbalik yang tetap menempati jumlah waktu-bit yang persis sama, dan justru karena itulah gejalanya tampak seperti data rusak, bukan seperti panjang yang tidak cocok.

Bagaimana penyisipan bit pada CAN mengubah gambaran bit ke byte?

CAN menyisipkan satu bit berlawanan setelah lima bit identik berturut-turut agar penerima tetap sinkron dengan detak. Bingkai berpengenal 11 bit dengan muatan penuh 8 byte berisi 108 bit sebelum penyisipan dan bisa mencapai sekitar 135 bit pada kondisi terburuk. Bit tambahan itu murni waktu jalur: muatan Anda tetap 8 byte berapa pun bit sisipan yang disuntikkan transceiver.

Dekoder saya mengekspor panjang kiriman dalam bit — bagaimana membandingkannya dengan buffer penerima?

Bagi angka hasil ekspor itu dengan panjang bingkai, bukan dengan delapan, lalu bandingkan jumlah byte tersebut dengan kedalaman buffer. Kiriman 12.000 bit pada 8N1 berisi 1.200 bingkai, jadi butuh ruang 1.200 byte; angka mentah 12.000 ÷ 8 = 1.500 justru menggambarkan pemakaian jalur. Memasukkan angka yang keliru ke perhitungan ukuran FIFO adalah penyebab umum penanda luapan yang muncul entah dari mana.