Sensor Polling melalui USB-RS485 Serial Interface terjebak di 16ms, meskipun itu harus lebih cepat

Saya memiliki pengaturan, yang menghubungkan papan sensor Razor IMU , dengan papan Breakout RS-485 , ke antarmuka serial USB-RS485 melalui kabel USB ke laptop saya. Saya menjalankan perangkat lunak pada laptop (Max / MSP) yang mengirimkan pesan polling ke sensor, menunggu data respons, dan saat menerima respons memicu secara otomatis pesan polling baru. Ini adalah loop konstan:

mengirim pesan pemungutan suara
tunggu jawaban
pada respons buka 1.

Saya ingin polling ini secepat mungkin, karena saya harus menghubungkan 21 sensor ini ke RS485-bus yang sama. Firmware pada Razor diprogram dengan Arduino IDE , dan menurut kode hanya ada penundaan ~ 2 ms antara pesan polling dan penulisan respon. Firmware juga menghabiskan 12ms setiap 20ms pada sensor-alokasi-dan-perhitungan. Perhitungan ini kadang-kadang menunda respons terhadap pemungutan suara. Saya sadar akan hal itu dan semua hasilnya sesuai.

Masalah saya saat ini adalah bahwa polling sensor macet pada tingkat pembaruan rata-rata 15 milidetik. Saya melihat data dengan usb-osiloskop kecil saya dan membuat diagram (> PDF).

masukkan deskripsi gambar di sini

Osiloskop saya duduk langsung pada antarmuka USB-RS485 dan melihat pemungutan suara keluar, dan pesan respons masuk. Penundaan antara keduanya terletak antara 2 hingga 13 ms. Perbedaan ini dapat dijelaskan dengan fakta bahwa kadang-kadang pisau cukur sibuk melakukan perhitungan sensor-matematika. Fakta anehnya adalah, bahwa meskipun responsnya datang dengan penundaan berbeda, pemungutan suara tampaknya selalu keluar pada interval yang sama sekitar 15 ms.

Kami juga menerapkan pengaturan yang sama dengan

coding firmware dalam C dan pemrograman Razor dengan avr-dude
melakukan polling perangkat lunak dalam kode Python
pada Mac OSX dan PC Windows 7

Semua kemungkinan kombinasi menghasilkan interval 15 ms yang sama. Jadi masalahnya bukan pada kode Arduino, atau dalam Max / MSP. Saya memiliki kecurigaan bahwa masalahnya bisa disebabkan oleh Antarmuka Serial USB-RS485 dan / atau driver FTDI yang diperlukan.

Apakah masalah ini terdengar akrab bagi siapa saja ??

— evsc
sumber

Jadi polling selalu terjadi dari komputer yang menjalankan OSX atau Windows 7? Penundaan pada USB bisa jadi sangat besar terlepas dari bahasa pemrograman yang Anda gunakan.

— Kellenjb

saat ini kami sedang menguji pada Windows 7 dan pada OSX. pada akhirnya itu akan berjalan pada Windows 7.

— evsc

Alih-alih mengedit pertanyaan Anda, Anda dapat menjawab pertanyaan Anda sendiri. Ini akan membiarkan Anda memilihnya sebagai jawaban dan bahkan mendapatkan upvotes!

— Kellenjb

dalam 7 jam saya akan! :) <.... Pengguna dengan reputasi kurang dari 100 tidak dapat menjawab pertanyaan mereka sendiri selama 8 jam setelah bertanya. Anda dapat menjawab sendiri dalam 7 jam. Sampai saat itu silakan gunakan komentar, atau edit pertanyaan Anda.>

— evsc

Ini disebabkan oleh latency timer 16ms dari driver FTDI, dan fakta bahwa respons polling saya tidak cukup lama untuk mengisi buffer 64-byte untuk secara otomatis memicu pengosongan buffer. Baca AN232B-04_DataLatencyFlow.pdf jika Anda tertarik, atau cukup buka Device Manager Anda, dan ubah pengaturan pada properti USB-Serial-Port Anda.

— evsc
sumber

Tanpa mengetahui banyak detail (yang sebenarnya tidak ingin saya ketahui), saya akan menyalahkan adaptor USB to RS-485. Kami memiliki masalah serupa pada prosesor Intel Q7 yang menjalankan Linux dengan salah satu dari adaptor tersebut.

Kami menggunakan adaptor untuk sementara hingga perangkat keras khusus kami siap. Perangkat keras khusus kami menggunakan tautan PCIe dan FPGA untuk melakukan antarmuka RS-485 yang sama (dan lebih banyak lagi). Perangkat lunak tetap sama untuk adaptor dan perangkat keras khusus kami. Ketika kami beralih ke perangkat keras khusus, masalahnya hilang.

Iya! baru tahu bahwa saya dapat mengubah banyak hal dalam pengaturan USB-Serial-port (terutama penghitung waktu latensi) dan kemudian semuanya mempercepat ...

— evsc