💇🏾 🐣 💲 Balada Transfer Data 🏁 ✊🏿 👂🏻

Pada baris pertama pendarahan teks saya, saya ingin mengatakan yang berikut: Sudah banyak ditulis tentang ini, saya juga akan menulis visi saya. Antarmuka standar untuk mengirimkan informasi sangat bagus, tetapi untuk kebutuhan saya, mereka tidak memberikan transfer data yang cukup memuaskan (baik, atau hampir). Saya akan mencoba membuat beberapa tambahan untuk membawa ini ke keadaan yang cocok untuk saya.

Ada 2 atau lebih perangkat pada jarak yang cukup besar (1-100 meter) di mana data harus dikirim. Setelah memeriksa beberapa antarmuka (rs232 / 422/485, I2C, Ethernet), saya sampai pada kesimpulan bahwa mereka tidak menjamin transfer data yang jelas, saya tidak suka banyak kabel juga, mereka tidak memberikan jawaban bahwa informasi diterima. Saya memutuskan untuk menggunakan antarmuka RS485 sebagai basis - ia bisa jauh dari kelebihannya, 2 kabel, Anda dapat menghubungkan banyak perangkat pada saat yang sama, sederhana, (UART) ada di hampir semua pengontrol.

Dalam kasus saya, skema klasik 1 yang memimpin para budak lainnya cocok untuk saya. Algoritma olahpesan adalah sebagai berikut: data ditransmisikan dalam siklus pertukaran, satu siklus pertukaran terdiri dari pesan yang ditransmisikan dari master ke slave, sebagai respons master menerima pesan dari slave, semua yang lain diam. Atas dasar yang sama, terapkan permintaan untuk data dari perangkat budak.

gambar

Satu siklus pertukaran.

Untuk memenuhi kebutuhan transfer data saya, saya hanya perlu menyelesaikan dua pertanyaan. Pertanyaan satu: memeriksa byte yang ditransmisikan didasarkan pada antarmuka RS-485 itu sendiri, tetapi itu tidak menjamin byte yang ditransmisikan secara andal - jika byte ditemukan dalam antarmuka itu sendiri, ia dilempar keluar dari data yang diterima, tetapi masih mungkin untuk mentransfer byte yang salah - jika telah berubah (rusak) ) jumlah genap dalam satu byte. yaitu diperlukan pemeriksaan untuk jumlah byte yang dikirimkan dan validitas byte dalam data yang dikirimkan.

Pertanyaan dua: menerima pesan tanggapan dari pesan yang dikirim.

Pada pertanyaan pertama: skema ini diusulkan: byte awal, byte jumlah
karakter yang ditransmisikan dalam seluruh pesan, sesuatu yang lain, byte checksum (BCS), byte terakhir.

gambar

Catatan: byte checksum harus dianggap modulo 2.

Berdasarkan skema yang diusulkan, dapat dinilai bahwa jika jawabannya tidak kembali, maka pengikut tidak tersedia. Dalam hal ini, opsi dimungkinkan ketika pesan yang rusak mencapai pengikut dan dia tidak menanggapi, atau pesan mencapai dia dan dia mengirimkan jawabannya, tetapi jawabannya memburuk dan pemimpin mengabaikannya.

Untuk memperbaiki ini, diterima: jika jawabannya tidak datang (atau datang tetapi tidak dapat diandalkan), maka ulangi (berapa kali tanpa kegilaan) ulangi siklus pertukaran saat ini. Kesalahan berikut dapat terjadi di sini. Misalkan kita mengirim perintah yang memberi tahu perangkat bahwa Anda perlu menaikkan volume dengan +1 unit. Ketika pesan mencapai budak, ia mengeksekusi perintah untuk menaikkan volume dan mengirimkan respons "ok, saya lakukan seperti yang Anda inginkan", tetapi mungkin ternyata jawabannya memburuk dan presenter tidak mengerti bahwa perintah telah dieksekusi, dan mengirim pesan lagi. Akibatnya, setelah menerima perintah di sisi slave, volume sudah akan ditambahkan +2 unit. Untuk menghindari fenomena ini, adalah kebiasaan untuk memperkenalkan pengidentifikasi (nomor pesan NS) dari perbedaan pesan. Jika nomor pesan diulang, maka ini adalah pesan yang diulang dan perintah yang ditentukan tidak perlu dieksekusi,tetapi hanya mengirim pesan balasan sebelumnya.

Saya juga memasukkan 2 parameter lagi di sini - ini adalah nomor (kode) perangkat yang datanya ditransmisikan dan angka (subkode) yang menunjukkan perintah mana yang harus dieksekusi (atau data apa yang ada di dalam pesan).

gambar

Sebagai hasilnya, saya akan menggabungkan semuanya dan menelusuri algoritma, menggunakan contoh meningkatkan ambang relai oleh suhu sebesar 5 derajat Celcius dan mengambil pembacaan suhu saat ini dari budak untuk 1 siklus pertukaran: Saya

menghasilkan data yang ditransmisikan dari master:

gambar

Ketika pesan diterima, budak melihat 2 byte, di mana jumlah byte yang dikirim, jika jumlah byte yang dikirim sama dengan jumlah yang diterima, maka pesannya tidak hilang byte, maka kita melihat byte awal (karakter) jika = '$', dan juga byte akhir (karakter) jika = # '- ini adalah pesan dari bepergian ke budak.

Segera saya akan mempertimbangkan opsi pesan yang mungkin dari master ke slave dengan kesalahan dalam byte awal dan akhir, serta opsi dengan kesalahan dalam jumlah byte dalam pesan. Saya akan melakukan reservasi segera dari 3 nilai parameter yang akan saya pertimbangkan dengan benar 2 dan 3, yaitu jika 2 parameter dari 3 kemungkinan bersamaan, saya anggap pesan tersebut valid.

1. mulai byte = '$', jumlah byte yang diterima = 7 (jumlah byte yang dikirim = 7), byte akhir tidak sama dengan '#';
2. byte awal tidak sama dengan '$', jumlah byte yang diterima = 7 (jumlah byte yang dikirim = 7), byte terakhir = '#';
3. mulai byte = '$', jumlah byte yang diterima = 7 (jumlah byte yang dikirim = 7, jumlah byte yang bukan 7), byte terakhir = '#'.

Selanjutnya, kami menghitung checksum dari 3 byte yang tersisa (byte 3, 4, 5), jika itu bertepatan dengan BCS, kami melanjutkan penguraian data, kami mencari perangkat ini untuk data ini dan apa yang harus dilakukan, dalam kasus kami kode slave adalah 55 dan subcode 2 mengatakan tentang perlunya menambahkan 5 derajat ke ambang relai dan dalam pesan respons untuk mengirim data suhu saat ini. Saya memeriksa NS jika tidak sama dengan nomor pesan sebelumnya maka saya menjalankan perintah dan menambahkan 5 derajat ke nilai saat ini dari ambang relai. Jika mereka sama (NS), maka saya tidak melakukan tindakan yang ditunjukkan, maka saya melanjutkan ke pembentukan pesan respons.

penerapan skema ['$'] [jumlah byte yang dikirim / diterima] [...] ['#'] - dengan jaminan probabilitas tinggi bahwa kombinasi tersebut tidak akan dapat ditemukan dalam data yang dikirimkan, dan memancing pesan palsu.

Saya membentuk data yang dikirimkan dari budak berdasarkan pesan yang diterima:

gambar

Prinsip pemrosesan adalah sebagai berikut: lihat 2 byte di mana jumlah byte yang dikirim terletak, jika jumlah byte yang dikirim sama dengan jumlah byte yang diterima dan juga byte awal = '@' dan byte akhir = '&' - ini adalah pesan dari slave ke master. Jika diperlukan, saya menggunakan mekanisme 2 dari 3, mirip dengan yang dijelaskan di atas hanya untuk pesan respons (untuk karakter '@' dan '&'). Saat menerima pesan ini, tuan rumah menganalisis checksum 9 (dari tanggal 3 ke 11), jika checksum cocok, data dalam pesan dianggap dapat diandalkan dan analisis data lebih lanjut berlanjut. Jika kode, subkode, dan NS dari pesan yang dikirim dan diterima bertepatan, kami terus menganalisis respons terhadap pesan yang dikirim oleh tuan rumah. Berikutnya adalah analisis data yang diterima,dalam kasus saya, pada byte ke-6, nilai 1 berarti bahwa perintah untuk meningkatkan 5 derajat ke ambang relai berhasil, 5 byte sisanya menunjukkan pembacaan suhu saat ini; byte ke-7 adalah bendera yang menunjukkan keandalan suhu yang ditransmisikan (mis. Saya mempertimbangkan opsi yang dihidupkan dan direspons oleh budak, tetapi sensor mungkin tidak berfungsi) dan 4 byte dari tipe nilai suhu float.

Penggunaan 2 karakter uji di awal dan akhir pesan dengan probabilitas tinggi menjamin bahwa jika terjadi kesalahan tidak akan membingungkan pesan dari slave dan master. Juga data acak (bukan acak) di saluran tidak akan merusak pertukaran.

Sedikit tentang transmisi data dari budak ke budak, dan pesan terpusat untuk semua budak dari master.

Pertama, yang terakhir - transmisi dari master oleh slave dilakukan dengan menetapkan kode perangkat 255, yang memberi tahu slave bahwa ini adalah pesan terpusat, kemudian tetap hanya untuk menyelesaikan masalah subkode umum, juga dimungkinkan untuk dikelompokkan berdasarkan kode perangkat yaitu. menetapkan kode perangkat 254 dan 3 atau 4 perangkat akan menerima pesan menggunakan kode ini, sisanya akan mengabaikannya, tentu saja, bagian dari mengirim respons dari budak tidak boleh bekerja di sini, yaitu tidak dijamin bahwa para pengikut dengan jelas menerima pesan-pesan ini!

Pada transmisi data dari budak ke budak, diimplementasikan oleh master mengirimkan pesan ke budak (slave1) dari mana informasi harus dikirim ke budak lain (slave2), slave1 mengirimkan respons ke master sementara slave2 mendengarkan jawaban ini mengambil data ke dirinya sendiri. Sekali lagi, tidak ada jaminan pengiriman pesan yang jelas dari slave1 ke slave2, ini harus diperhitungkan!

Kemampuan antarmuka jumlah perangkat yang terhubung secara teoritis sekitar 250, perintah / tipe data hingga 248 untuk setiap perangkat, panjang informasi yang berguna dalam pesan adalah hingga 250 byte.

Bicara tentang perangkap:

Semua transfer data dirancang untuk bekerja tepat waktu yaitu penundaan tertentu antar pesan harus diperhatikan. Saya juga merekomendasikan Anda untuk membuat penundaan yang tetap antara pesan yang dikirim oleh master dan respons dari slave sehingga slave dapat menghasilkan data dan sepenuhnya mengirimkannya ke saluran.

Momen pengorganisasian respons dari budak juga penting, mungkin saja budak itu sibuk dan memiliki beberapa pesan data di salurannya sekaligus, Anda harus menghindari balasan ke pesan yang sudah usang (karena pemimpin tidak lagi menunggu untuk mereka) mengabaikannya, hanya menjalankan perintah dari yang terbaru pesan dan berikan jawaban untuk itu.

Secara terpisah, saya ingin menyoroti masalah sinkronisasi perangkat berdasarkan waktu - harus diingat bahwa sinkronisasi waktu dari budak ketika menerima pesan memerlukan dengan mempertimbangkan waktu tunda untuk mengirim data ke saluran (pada kecepatan 9600, pesan 10 byte akan dikirimkan sekitar 11 ms) dan saat gangguan terputus pada akhirnya. menerima data di sisi slave, jika tidak ada gangguan, ada baiknya mempertimbangkan waktu memeriksa kedatangan data di buffer perangkat, dll.

Perlu juga dicatat bahwa pengiriman ulang loop pesan juga menambah nuansa, saya sarankan menggunakan pengiriman pesan tanpa pengulangan untuk sinkronisasi waktu, dan menulis pesan dengan NS baru.

PSSaya ragu bahwa saya menemukan sesuatu yang baru di sini, semua ini sampai batas tertentu digunakan di suatu tempat di antarmuka yang berbeda! Dengan sedikit tangan penulis coretan ini dan penerapan protokol ini dalam perkembangan saya, saya ingin memberi nama pada protokol transfer data ini "SRDB2".

Balada Transfer Data

More articles: