Teknik pembatasan / sinkronisasi protokol serial

Karena komunikasi serial asinkron tersebar luas di antara perangkat elektronik, bahkan saat ini, saya yakin banyak dari kita telah mengalami pertanyaan seperti itu dari waktu ke waktu. Pertimbangkan perangkat elektronik Ddan komputer PCyang terhubung dengan jalur serial (RS-232 atau serupa) dan diperlukan untuk pertukaran informasi secara terus-menerus . Yaitu PCmasing-masing mengirimkan kerangka perintah X ms, dan masing-masing Dmembalas dengan laporan status / bingkai telemetri Y ms(Laporan dapat dikirim sebagai respons terhadap permintaan atau secara mandiri - tidak masalah di sini). Frame komunikasi dapat berisi data biner sembarang . Dengan asumsi frame komunikasi adalah paket dengan panjang tetap.

Masalah:

Karena protokol ini kontinu, sisi penerima mungkin kehilangan sinkronisasi atau hanya "bergabung" di tengah frame yang sedang dikirim, sehingga tidak akan tahu di mana awal frame (SOF) berada. Jika data memiliki arti yang berbeda berdasarkan posisinya relatif terhadap SOF, data yang diterima akan rusak, berpotensi selamanya.

Solusi yang dibutuhkan

Skema pembatas / sinkronisasi yang andal untuk mendeteksi SOF dengan waktu pemulihan yang singkat (artinya tidak perlu lebih dari, katakan 1 frame untuk mensinkronisasi ulang).

Teknik-teknik yang ada saya sadari (dan menggunakan beberapa) dari:

1) Header / checksum - SOF sebagai nilai byte yang telah ditentukan. Checksum di ujung bingkai.

• Pro: Sederhana.
• Cons: Tidak dapat diandalkan. Waktu pemulihan tidak diketahui.

2) Byte isian:

• Kelebihan: Andal, pemulihan cepat, dapat digunakan dengan perangkat keras apa pun
• Cons: Tidak cocok untuk komunikasi berbasis bingkai ukuran tetap

3) Penandaan bit 9 - tambahkan setiap byte dengan bit tambahan, sementara SOF ditandai dengan 1dan byte data ditandai dengan 0:

• Kelebihan: Andal, pemulihan cepat
• Cons: Membutuhkan dukungan perangkat keras. Tidak didukung langsung oleh sebagian besar PCperangkat keras dan perangkat lunak.

4) penandaan bit ke-8 - jenis emulasi di atas, saat menggunakan bit ke-8 dan bukan ke-9, yang hanya menyisakan 7 bit untuk setiap kata data.

• Kelebihan: Andal, pemulihan cepat, dapat digunakan dengan perangkat keras apa pun.
• Cons: Membutuhkan skema pengkodean / decoding dari / ke representasi 8-bit konvensional ke / dari representasi 7-bit. Agak boros.

5) Berbasis waktu habis - menganggap SOF sebagai byte pertama yang datang setelah waktu idle tertentu.

• Pro: Tidak ada data overhead, sederhana.
• Cons: Tidak bisa diandalkan. Tidak akan bekerja dengan baik dengan sistem pengaturan waktu yang buruk seperti, katakanlah, PC Windows. Potensi overhead throughput.

Pertanyaan: Apa teknik / solusi lain yang ada untuk mengatasi masalah? Bisakah Anda menunjukkan kontra di daftar di atas yang dapat dengan mudah ditangani, sehingga menghapusnya? Bagaimana Anda (atau akan) merancang protokol sistem Anda?

Bagaimana Anda (atau akan) merancang protokol sistem Anda?

Dalam pengalaman saya, semua orang menghabiskan lebih banyak waktu untuk debugging sistem komunikasi daripada yang pernah mereka harapkan. Jadi saya sangat menyarankan bahwa setiap kali Anda perlu membuat pilihan untuk protokol komunikasi, Anda memilih opsi mana saja yang membuat sistem lebih mudah untuk di-debug jika memungkinkan.

Saya mendorong Anda untuk bermain dengan merancang beberapa protokol khusus - ini menyenangkan dan sangat mendidik. Namun, saya juga mendorong Anda untuk melihat protokol yang sudah ada sebelumnya. Jika saya perlu mengkomunikasikan data dari satu tempat ke tempat lain, saya akan berusaha sangat keras untuk menggunakan beberapa protokol yang sudah ada sebelumnya bahwa orang lain telah menghabiskan banyak waktu debugging.

Menulis protokol komunikasi Anda sendiri dari awal sangat mungkin membanting banyak masalah umum yang sama yang dimiliki setiap orang ketika mereka menulis protokol baru.

Ada selusin protokol sistem tertanam yang terdaftar di Good RS232 berbasis Protokol untuk Komunikasi Komputer Tertanam - yang mana yang paling dekat dengan kebutuhan Anda?

Bahkan jika beberapa keadaan membuat mustahil untuk menggunakan protokol yang sudah ada sebelumnya, saya lebih cenderung mendapatkan sesuatu yang bekerja lebih cepat dengan memulai dengan beberapa protokol yang hampir sesuai dengan persyaratan, dan kemudian men-tweak-nya.

kabar buruk

Seperti yang saya katakan sebelumnya :

Sayangnya, protokol komunikasi tidak mungkin memiliki semua fitur menyenangkan ini:

• transparansi: komunikasi data transparan dan "8 bit bersih" - (a) file data apa pun yang mungkin dapat dikirim, (b) urutan byte dalam file selalu ditangani sebagai data, dan tidak pernah disalahartikan sebagai sesuatu yang lain, dan (c) ) tujuan menerima seluruh file data tanpa kesalahan, tanpa penambahan atau penghapusan.
• salinan sederhana: membentuk paket paling mudah jika kita hanya secara membabi buta menyalin data dari sumber ke bidang data paket tanpa perubahan.
• awal yang unik: simbol awal paket mudah dikenali, karena itu adalah byte konstan yang diketahui yang tidak pernah terjadi di tempat lain di header, header CRC, payload data, atau data CRC.
• 8-bit: hanya menggunakan byte 8-bit.

Saya akan terkejut dan senang jika ada cara untuk protokol komunikasi untuk memiliki semua fitur ini.

kabar baik

Apa teknik / solusi lain yang mungkin ada untuk mengatasi masalah?

Seringkali itu membuat debugging jauh, lebih mudah jika manusia di terminal teks dapat mengganti perangkat komunikasi apa pun. Ini membutuhkan protokol yang dirancang agar relatif tidak tergantung waktu (tidak berhenti selama jeda yang relatif lama antara penekanan tombol yang diketik oleh manusia). Juga, protokol semacam itu terbatas pada jenis byte yang mudah bagi manusia untuk mengetik dan kemudian membaca di layar.

Beberapa protokol memungkinkan pesan dikirim dalam mode "teks" atau "biner" (dan mengharuskan semua pesan biner yang memungkinkan memiliki beberapa pesan teks "setara" yang memiliki arti sama). Ini dapat membantu mempermudah debugging.

Beberapa orang tampaknya berpikir bahwa membatasi protokol hanya menggunakan karakter yang dapat dicetak adalah "sia-sia", tetapi penghematan dalam waktu debug sering membuatnya berharga.

Seperti yang telah Anda sebutkan, jika Anda mengizinkan bidang data berisi byte sewenang-wenang, termasuk byte awal header dan akhir header, saat penerima pertama kali dihidupkan, kemungkinan penerima salah sinkronisasi. apa yang tampak seperti byte awal-header (SOH) di bidang data di tengah satu paket. Biasanya penerima akan mendapatkan checksum yang tidak cocok pada akhir paket semu (yang biasanya setengah jalan melalui paket nyata kedua). Sangat menggoda untuk membuang seluruh pseudo-message (termasuk bagian pertama dari paket kedua) sebelum mencari SOH berikutnya - dengan konsekuensi penerima dapat tetap tidak sinkron untuk banyak pesan.

Seperti yang ditunjukkan oleh alex.forencich, pendekatan yang jauh lebih baik bagi penerima untuk membuang byte pada awal buffer hingga SOH berikutnya. Ini memungkinkan penerima (setelah bekerja melalui beberapa byte SOH dalam paket data itu) untuk segera melakukan sinkronisasi pada paket kedua.

Bisakah Anda menunjukkan kontra di daftar di atas yang dapat dengan mudah ditangani, sehingga menghapusnya?

Seperti Nicholas Clark tunjukkan, konsisten-overhead byte stuffing (COBS) memiliki overhead tetap yang bekerja dengan baik dengan frame ukuran tetap.

Salah satu teknik yang sering diabaikan adalah byte marker end-of-frame berdedikasi. Ketika penerima dihidupkan di tengah suatu transmisi, byte marker end-of-frame khusus membantu penerima melakukan sinkronisasi lebih cepat.

Ketika penerima dihidupkan di tengah-tengah paket, dan bidang data paket kebetulan berisi byte yang tampaknya merupakan awal-paket (awal paket-pseudo-paket), pemancar dapat memasukkan serangkaian byte penanda frame akhir setelah paket itu sehingga byte pseudo-permulaan paket di bidang data tidak mengganggu segera menyinkronkan dan dengan benar men-decoding paket berikutnya - bahkan ketika Anda sangat sial dan checksum paket pseudo-paket itu tampak benar.

Semoga berhasil.

Skema byte-isian telah bekerja sangat baik untuk saya selama bertahun-tahun. Mereka bagus karena mudah diimplementasikan dalam perangkat lunak atau perangkat keras, Anda dapat menggunakan kabel USB-to-UART standar untuk mengirim paket data, dan Anda dijamin mendapatkan framing berkualitas baik tanpa harus khawatir tentang batas waktu, hot-swapping, atau hal lain seperti itu.

Saya akan menganjurkan metode byte-stuffing dikombinasikan dengan byte panjang (panjang paket modulo 256) dan CRC tingkat paket, dan kemudian menggunakan UART dengan bit paritas. Byte panjang memastikan deteksi byte-drop, yang bekerja dengan baik dengan bit paritas (karena sebagian besar UART akan menjatuhkan byte yang gagal paritas). Kemudian CRC tingkat paket memberi Anda keamanan ekstra.

Sedangkan untuk overhead byte-stuffing, sudahkah Anda melihat protokol COBS? Ini adalah cara jenius untuk melakukan byte-stuffing dengan overhead tetap 1 byte per setiap 254 yang ditransmisikan (ditambah framing Anda, CRC, LEN, dll).

https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing

Opsi Anda # 1, SOH plus checksum, IS reliable, dan pulih pada frame berikutnya yang tidak rusak.

Saya berasumsi Anda sudah mengetahui panjang pesan, atau panjangnya dikodekan dalam byte segera setelah SOH. Byte cek muncul di akhir pesan. Anda juga memerlukan penyangga sisi penerimaan untuk data yang setidaknya selama pesan terlama Anda.

Setiap kali Anda melihat byte SOH di kepala buffer, ini berpotensi sebagai awal pesan. Anda memindai melalui buffer untuk menghitung nilai cek untuk pesan itu, dan melihat apakah cocok dengan cek cek di buffer. Jika demikian, Anda sudah selesai; jika tidak, Anda membuang data dari buffer hingga Anda mencapai byte SOH berikutnya.

Perhatikan bahwa jika sebuah pesan benar-benar MEMILIKI kesalahan data, algoritme ini akan membuangnya - tetapi Anda mungkin akan tetap melakukannya. Jika algoritma pemeriksaan Anda menyertakan koreksi kesalahan maju, Anda dapat memeriksa setiap potensi penyelarasan pesan untuk kesalahan yang dapat diperbaiki.

Jika panjang pesan tetap, Anda dapat membuang byte SOH secara bersamaan - cukup uji SETIAP posisi awal yang memungkinkan untuk nilai cek yang valid.

Anda juga dapat membuang algoritma pemeriksaan dan mempertahankan byte SOH saja, tetapi ini membuat algoritma kurang deterministik. Idenya adalah bahwa untuk penyelarasan pesan yang valid, SOH akan selalu muncul di awal pesan. Jika Anda memiliki keberpihakan yang salah, byte berikutnya dalam aliran data tidak mungkin SOH lain (tergantung pada seberapa sering SOH muncul dalam data pesan). Anda dapat memilih byte SOH yang valid berdasarkan ini saja. (Ini pada dasarnya bagaimana framing pada layanan telekomunikasi sinkron seperti T1 dan E1 bekerja.)

Salah satu opsi yang tidak disebutkan tetapi banyak digunakan (terutama di internet) adalah ASCII / pengkodean teks (sebenarnya, sebagian besar implementasi modern menganggap UTF-8). Dalam pengalaman saya, orang-orang hardware benci untuk melakukan ini tetapi orang-orang perangkat lunak cenderung lebih suka ini daripada hampir semua hal lain (kebanyakan datang untuk tradisi Unix membuat semua hal berdasarkan teks).

Keuntungan pengkodean teks adalah Anda dapat menggunakan karakter yang tidak dapat dicetak untuk membingkai. Sebagai contoh, yang paling sederhana adalah menggunakan sesuatu seperti 0x00untuk menunjukkan awal bingkai dan 0xffuntuk akhir bingkai.

Saya telah melihat dua cara utama data dikodekan sebagai teks:

1. Ketika seorang pria perangkat keras / perakitan diminta untuk melakukan ini maka kemungkinan besar akan diimplementasikan sebagai hex encoding. Ini hanya mengkonversi byte ke nilai hex mereka di ASCII. Overheadnya besar. Pada dasarnya Anda akan mengirimkan dua byte untuk setiap byte data aktual.

2. Ketika seorang pria perangkat lunak diminta untuk melakukan ini maka itu mungkin akan diimplementasikan sebagai pengkodean base64. Ini adalah pengkodean de-facto internet. Digunakan untuk semuanya, mulai dari lampiran email MIME hingga penyandian data URL. Overheadnya persis 33%. Jauh lebih baik daripada pengkodean hex sederhana.

Atau, Anda dapat sepenuhnya meninggalkan data biner dan mengirim teks. Dalam hal ini teknik yang paling umum adalah membatasi data dengan baris baru (baik adil "\n"atau tidak "\r\n"). NMEA (GPS), perintah Modem AT dan sensor Adventech ADAM adalah beberapa contoh yang paling umum dari ini.

Semua protokol / pembingkaian berbasis teks ini memiliki pro dan kontra berikut:

Pro:

• Mudah di-debug
• Mudah diimplementasikan dalam bahasa scripting
• Perangkat keras dapat dengan mudah diuji menggunakan HyperTerminal / minicom
• Mudah diimplementasikan pada perangkat keras (kecuali itu mikro yang sangat kecil seperti PIC)
• Bisa berupa bingkai ukuran tetap atau ukuran bervariasi.
• Membingkai diprediksi dan waktu pemulihan sinkronisasi cepat (pulih di akhir frame saat ini)

Menipu:

• Overhead yang sangat besar dibandingkan dengan transmisi biner murni (sekali lagi, teks I / O juga dapat "mengompres" angka seperti mengirim satu byte "0"(0x30) alih-alih empat byte 0x00000000)
• Tidak begitu bersih untuk diimplementasikan pada mik yang sangat kecil seperti PIC (kecuali perpustakaan Anda menyertakan sprintf()fungsi)

Secara pribadi bagi saya pro lebih berat daripada kontra. Kemudahan debugging sendiri dihitung sebagai 5 poin (sehingga satu titik saja sudah melebihi kedua kontra).

Lalu ada solusi tidak terlalu hati-hati-keluar sering datang dari orang-orang perangkat lunak: mengirim data yang disandikan tanpa berpikir tentang membingkai.

Saya harus berinteraksi dengan perangkat keras yang mengirim XML mentah di masa lalu. XML adalah semua framing yang ada. Untungnya, cukup mudah untuk mengetahui batas bingkai oleh <xml></xml>tag. Kekurangan terbesar bagi saya adalah ia menggunakan lebih dari satu byte untuk membingkai. Selain itu, pembingkaian itu sendiri mungkin tidak diperbaiki karena tag mungkin mengandung atribut: <tag foo="bar"></tag>jadi Anda harus buffer untuk kasus terburuk untuk menemukan awal bingkai.

Baru-baru ini saya melihat orang-orang mulai mengirim JSON dari port serial. Dengan framing JSON yang terbaik adalah menebak. Anda hanya memiliki "{"(atau "[") karakter untuk mendeteksi bingkai tetapi mereka juga terkandung dalam data. Jadi Anda akhirnya membutuhkan parser keturunan rekursif (atau setidaknya counter penjepit) untuk mencari tahu bingkai. Setidaknya sepele untuk mengetahui apakah frame saat ini berakhir sebelum waktunya: "}{"atau "]["ilegal di JSON dan dengan demikian menunjukkan bahwa frame yang lama telah berakhir dan sebuah frame baru telah dimulai.

Apa yang Anda gambarkan sebagai "penandaan bit Xth" dapat digeneralisasi menjadi kode lain yang memiliki sifat memperluas data dengan fraksi konstan, membiarkan beberapa codeword bebas untuk digunakan sebagai pembatas. Seringkali kode ini memberikan manfaat lain juga; CD menggunakan delapan hingga empat belas modulasi , yang menjamin panjang lari maksimum 0 bit antara masing-masing 1. Contoh lain termasuk kode blok Forward Error Correction , yang menggunakan bit tambahan untuk menyandikan informasi kesalahan deteksi dan koreksi, juga.

Sistem lain yang belum Anda sebutkan adalah menggunakan informasi di luar jalur, seperti jalur pilih chip, untuk membatasi transaksi atau paket.

Pilihan lain adalah apa yang dikenal sebagai pengkodean baris . Pengkodean baris memberi sinyal karakteristik listrik tertentu yang membuatnya lebih mudah untuk dikirim (jaminan seimbang dan panjang lari maksimum DC) dan mereka mendukung karakter kontrol untuk pembingkaian dan sinkronisasi jam. Kode jalur digunakan di semua protokol serial modern kecepatan tinggi - 10M, 100M, 1G, dan 10G Ethernet, serial ATA, FireWire, USB 3, PCIe, dll. Kode jalur umum adalah 8b / 10b , 64b / 66b dan 128b / 130b. Ada juga kode garis yang lebih sederhana yang tidak memberikan informasi pembingkaian, hanya keseimbangan DC dan sinkronisasi jam. Contohnya adalah Machester dan NRZ. Anda mungkin ingin menggunakan 8b / 10b jika Anda ingin menyinkronkan dengan cepat; kode baris lainnya tidak dirancang untuk disinkronkan dengan terburu-buru. Menggunakan kode baris seperti penawaran di atas akan memerlukan penggunaan perangkat keras khusus untuk mengirim dan menerima.

Sedangkan untuk opsi Anda 5, serial RS232 standar seharusnya mendukung pengiriman dan penerimaan jeda ketika saluran tidak digunakan selama beberapa byte. Namun, ini mungkin tidak didukung pada semua sistem.

Umumnya metode pembingkaian paling sederhana dan paling dapat diandalkan adalah pilihan Anda 1, dalam kombinasi dengan bidang panjang dan CRC sederhana atau rutin checksum. Rutin decoding sederhana: buang byte sampai Anda mendapatkan byte awal, baca kolom panjang, tunggu seluruh frame, periksa checksum, simpan jika bagus. Jika checksum buruk, mulailah membuang byte dari buffer hingga Anda mendapatkan byte awal dan ulangi. Masalah utama dengan teknik ini adalah menemukan awal dari frame byte yang sebenarnya bukan awal dari frame byte. Untuk mengatasi masalah ini, satu teknik adalah untuk melarikan diri byte dengan nilai yang sama dengan awal frame byte dengan karakter kontrol yang lain, dan kemudian mengubah byte yang diloloskan sehingga memiliki nilai yang berbeda. Dalam hal ini, Anda juga harus melakukan hal yang sama dengan byte kontrol baru.