Cara menemukan jalur UART gratis untuk mengirim data

Saya memiliki beberapa papan yang berkomunikasi bersama dengan Rs485. Mereka memiliki ATMegaseri mikrokontroler seperti atmega168patau atmega8. Setiap papan bebas mengirim data kapan saja dan saya memiliki batasan yang mengarah ke I Cant menggunakan Modbus . Jumlah papan dapat berkisar dari 5 hingga 10.

Masalah saya adalah: Bagaimana papan dapat menemukan jika jalur UART bebas untuk mengirim data, dan jika itu mendeteksi bahwa bus sedang sibuk, tunggu sampai bus gratis dan kemudian kirim data sendiri?

Apakah ada bendera khusus atau daftar yang dapat secara otomatis atau manual mengubahnya dan membiarkan papan lainnya menemukan bahwa Line is Busy ?

Selamat datang di tantangan terbesar dengan sistem komunikasi setengah dupleks.

RS-485 bukan protokol, ini adalah standar yang mendefinisikan properti listrik untuk tautan diferensial setengah dupleks (*). Tidak ada dalam spesifikasi tentang bagaimana data dikirim melalui tautan itu, atau bahkan bagaimana tautan digunakan.

Karena transceiver RS-485 tersebut tidak memiliki sinyal / flag "jalur sibuk" / apa pun, mikrokontroler yang telah membangun driver RS-485, atau yang menggunakan inti UART yang terhubung ke transceiver eksternal tidak akan.

Semua implementasi kontrol aliran dan kontrol arah diserahkan kepada protokol apa pun yang Anda gunakan. Ada beberapa protokol terkenal yang menggunakan driver RS-485, seperti Modbus. Anda juga dapat mengimplementasikan protokol apa pun yang dapat Anda pikirkan.

Untuk membantu Anda, ini adalah beberapa ide untuk protokol:

1. Anda memiliki protokol tipe master-slave. Dalam hal ini terdapat master node yang mengoordinasikan bus, dan slave node yang masing-masing memiliki beberapa pengidentifikasi unik.

   Node slave tidak diizinkan untuk mengirim data apa pun sampai master node secara khusus mengirim perintah yang ditujukan kepada mereka. Setelah seorang budak diatasi, ia kemudian dapat menanggapi perintah apa pun dengan cara yang telah ditentukan sebelumnya - katakanlah paket respons panjang tetap.

   Dalam hal ini Anda menghindari masalah beberapa perangkat yang ingin berbicara pada saat yang sama karena master ada di sana untuk mengoordinasikan semuanya.

2. Anda dapat menggunakan beberapa bentuk penjadwalan di mana setiap perangkat di bus memiliki slot tetap untuk mengirim data ke perangkat lain. Setelah slotnya habis, ia harus berhenti mengirim dan memungkinkan perangkat berikutnya untuk berbicara.

   Penjadwalan dapat dilakukan oleh perangkat itu sendiri tanpa koordinasi eksternal. Perangkat pertama berbicara, dan kemudian mengirim pesan yang mengatakan itu selesai. Perangkat selanjutnya (mis. Yang memiliki ID lebih tinggi berikutnya) akan tahu bahwa itu bisa pergi. Jika suatu perangkat tidak merespons maka Anda dapat memiliki batas waktu di mana setiap perangkat berikutnya dalam jadwal dapat mengatakan - baik saya belum mendengar dari perangkat sebelum saya untuk sementara waktu, jadi itu harus saya giliran.

(*) Saya percaya ini juga mendefinisikan versi full-duplex menggunakan dua tautan diferensial.

Ini sangat mirip dengan komunikasi radio dari militer atau polisi. Diperlukan protokol. Master slave mudah dan bagus untuk sebagian besar kasus. Tetapi pilihan lain adalah melakukannya seperti yang dilakukan manusia:

1. Mendengarkan.
2. Jika seseorang berbicara - tunggu.
3. Jika Anda berpikir tidak ada yang berbicara - Anda dapat berbicara.
4. Tunggu konfirmasi.
5. Jika tidak ada konfirmasi yang diterima - bicara lagi.
6. Jika Anda ingin menyiarkan, minta semua stasiun untuk mengonfirmasi mendengarkan.
7. Jika Anda ingin berbicara dengan seseorang yang tidak dapat mendengar Anda, tanyakan apakah ada orang lain yang dapat menyampaikan.

Dan seterusnya. Mungkin sangat menarik untuk diimplementasikan. Semoga berhasil!

Berikut adalah beberapa kemungkinan untuk menyelesaikan dilema Anda.

1. Menerapkan sistem token passing. Ketika perangkat memiliki token, itu diperbolehkan untuk mengirim untuk jangka waktu terbatas. Kemudian melewati token ke perangkat berikutnya. Ketentuan untuk node yang hilang yang tidak dapat menerima dan melewati token harus dilakukan.
2. Lihatlah garis terima. Jika sibuk, buat penundaan acak dan coba lagi. Penundaan acak membantu memastikan bahwa tidak ada satu node pun yang dapat memonopoli jendela transmisi. Tabrakan masih dapat terjadi tetapi fitur jumlah cek dapat menentukan apakah paket yang diterima masih utuh. Jika tidak utuh, penerima dapat meminta pengiriman ulang.

Bagaimana papan dapat menemukan jika jalur UART bebas mengirim data,

jawaban umum adalah bahwa tanpa semacam protokol, ia tidak dapat melakukannya dengan andal. Anda biasanya mengandalkan pengontrol atau arbiter untuk melihat apakah saluran sedang sibuk atau tidak. Satu yang sederhana adalah pin OD yang menarik garis indikator ke bawah sebelum transmisi dan melepaskannya setelah itu. Dengan membaca garis itu pemancar dapat menentukan apakah bus tersedia atau tidak.

sistem yang kurang dapat diandalkan tetapi lebih sederhana adalah untuk mengintegrasikan tegangan bus (misalnya melalui jaringan ar / c).

dan jika mendeteksi bahwa bus sedang sibuk, tunggu sampai bus gratis dan kemudian kirim datanya sendiri?

pendekatan umum adalah menunggu periode waktu acak dan coba lagi.

Saya mengatasi masalah ini dengan desain saya seperti ini:

alih-alih menggunakan 2 pin untuk komunikasi, saya menggunakan 3 pin. Dalam jarak pendek itu berfungsi. Pin ke-3 adalah indikator garis sibuk. Pin ini ditarik dari sisi master. Ketika seseorang (MCU atau apa pun) ingin berbicara:

• periksa status pin ini (INPUT).
• jika pin TINGGI maka pin rendah (OUTPUT)
• dan pembicaraan.
• Ketika pesan ditransfer melepaskan pin (INPUT) (impedansi tinggi) kemudian pin menjadi tinggi.
• Jika pin rendah maka tunggu beberapa saat kemudian kembali untuk memeriksa siklus pin.

Ini adalah implementasi dari jawaban Gregory Kornblum.

Anda bisa menggunakan stack protokol BACnet open source untuk komunikasi mikrokontroler pada RS485 jika Anda tidak ingin menggunakan modbus. Pada dasarnya, itu hanya melewati token di sekitar yang memberitahu setiap perangkat ketika dapat mengirim, mirip dengan topologi token-ring dan Ethernet. Berikut ini beberapa tautan untuk Anda mulai:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Kontrol aliran perangkat lunak

Kedua perangkat lunak dan kontrol aliran perangkat keras memerlukan perangkat lunak untuk melakukan tugas berjabat tangan. Ini membuat istilah kontrol aliran perangkat lunak agak menyesatkan. Yang dimaksud adalah bahwa dengan kontrol aliran perangkat keras, terdapat saluran tambahan di kabel komunikasi yang menandakan kondisi jabat tangan. Dengan kontrol aliran perangkat lunak, yang juga dikenal dengan nama kontrol aliran XON-XOFF, byte dikirim ke pengirim menggunakan jalur komunikasi standar.

Menggunakan kontrol aliran perangkat keras menyiratkan, bahwa lebih banyak garis harus ada antara pengirim dan penerima, yang mengarah ke kabel yang lebih tebal dan lebih mahal. Oleh karena itu, kontrol aliran perangkat lunak adalah alternatif yang baik jika tidak diperlukan untuk mendapatkan kinerja komunikasi yang maksimal. Kontrol aliran perangkat lunak memanfaatkan datachannel antara dua perangkat yang mengurangi bandwidth. Pengurangan bandwidth dalam banyak kasus namun tidak begitu mengejutkan bahwa itu adalah alasan untuk tidak menggunakannya.

Dua byte telah ditentukan sebelumnya dalam set karakter ASCII untuk digunakan dengan kontrol aliran perangkat lunak. Bytes ini dinamai XOFF dan XON, karena mereka dapat berhenti dan memulai kembali transmisi. Nilai tambah XOFF adalah 19, dapat disimulasikan dengan menekan Ctrl-S pada keyboard. XON memiliki nilai 17 yang ditetapkan yang setara dengan Ctrl-Q.

Menggunakan kontrol aliran perangkat lunak itu mudah. Jika pengiriman karakter harus ditunda, karakter XOFF dikirim di telepon, untuk memulai kembali komunikasi lagi XON digunakan. Mengirim karakter XOFF hanya menghentikan komunikasi ke arah perangkat yang mengeluarkan XOFF.

Metode ini memiliki beberapa kelemahan. Satu sudah dibahas: menggunakan byte pada saluran komunikasi membutuhkan beberapa bandwidth. Satu alasan lain lebih parah.

Jabat tangan sebagian besar digunakan untuk mencegah overrun buffer penerima, buffer dalam memori digunakan untuk menyimpan byte yang baru diterima. Jika overrun terjadi, ini mempengaruhi cara karakter yang akan datang pada saluran komunikasi ditangani. Dalam kasus terburuk di mana perangkat lunak telah dirancang dengan buruk, karakter-karakter ini dibuang tanpa memeriksanya. Jika karakter seperti itu adalah XOFF atau XON, aliran komunikasi dapat sangat rusak. Pengirim akan terus memberikan informasi baru jika XOFF hilang, atau tidak pernah mengirim informasi baru jika tidak ada XON yang diterima.

Ini juga berlaku untuk saluran komunikasi di mana kualitas sinyal buruk. Apa yang terjadi jika pesan XOFF atau XON tidak diterima dengan jelas karena derau di telepon? Tindakan pencegahan khusus juga diperlukan agar informasi yang dikirim tidak mengandung karakter XON atau XOFF sebagai byte informasi.

Oleh karena itu, komunikasi serial menggunakan kontrol aliran perangkat lunak hanya dapat diterima ketika kecepatan komunikasi tidak terlalu tinggi, dan kemungkinan terjadinya buffer overruns atau kerusakan data sangat kecil.

CSMA kecepatan tinggi

Untuk kecepatan tinggi seperti ethernet CSMA pembawa rasa, multiple access, tabrakan mendeteksi / penghindaran, dengan acak timer backoff telah dianalisis untuk probabilitas stokastik thruput untuk optimasi.