Thăm dò cảm biến qua Giao diện nối tiếp USB-RS485 bị kẹt ở 16ms, mặc dù nó phải nhanh hơn

Tôi có một thiết lập, kết nối bảng cảm biến dao cạo IMU , với bảng đột phá RS-485 , với Giao diện nối tiếp USB-RS485 qua cáp USB vào máy tính xách tay của tôi. Tôi chạy một phần mềm trên máy tính xách tay (Max / MSP) để gửi tin nhắn bỏ phiếu đến cảm biến, chờ dữ liệu phản hồi và khi nhận được phản hồi kích hoạt tự động một tin nhắn bỏ phiếu mới. Đó là một vòng lặp không đổi:

1. gửi tin nhắn bỏ phiếu
2. chờ hồi âm
3. khi trả lời, hãy chuyển đến 1.

Tôi muốn cuộc bỏ phiếu này càng nhanh càng tốt, vì tôi sẽ phải kết nối 21 trong số các cảm biến này vào cùng một xe buýt RS485. Phần sụn trên Dao cạo được lập trình với Arduino IDE và theo mã, chỉ nên có độ trễ ~ 2ms giữa thông báo bỏ phiếu và viết phản hồi. Phần sụn cũng dành 12ms cứ sau 20ms cho việc phân bổ và tính toán cảm biến. Tính toán này đôi khi làm chậm phản ứng bỏ phiếu. Tôi nhận thức được điều đó và tất cả các kết quả phù hợp.

Vấn đề của tôi bây giờ là việc bỏ phiếu của cảm biến bị kẹt ở tốc độ cập nhật trung bình 15 mili giây. Tôi đã xem xét dữ liệu với bộ dao động nhỏ USB của mình và tạo một sơ đồ (> PDF).

Máy hiện sóng của tôi nằm trực tiếp trên giao diện USB-RS485 và thấy bỏ phiếu đi ra và thông báo phản hồi đến. Độ trễ giữa hai lần này nằm trong khoảng từ 2 đến 13 ms. Sự khác biệt này có thể giải thích được với thực tế là đôi khi dao cạo đang bận thực hiện các phép tính toán-cảm biến. Một sự thật kỳ lạ là, mặc dù các phản hồi xuất hiện với độ trễ khác nhau, nhưng việc bỏ phiếu dường như luôn diễn ra ở cùng một khoảng 15ms.

Chúng tôi cũng đã thực hiện thiết lập tương tự với

• mã hóa phần sụn trong C và lập trình dao cạo với avr-dude
• thực hiện việc bỏ phiếu phần mềm trong mã Python
• trên Mac OSX và PC Windows 7

Tất cả các kết hợp có thể dẫn đến khoảng 15ms giống nhau. Vì vậy, vấn đề không nằm ở mã Arduino, cũng không nằm trong Max / MSP. Tôi có nghi ngờ rằng vấn đề có thể là do Giao diện nối tiếp USB-RS485 và / hoặc trình điều khiển FTDI cần thiết.

Vấn đề này nghe có vẻ quen thuộc với bất cứ ai ??

Đó là do bộ đếm thời gian trễ 16ms của trình điều khiển FTDI và thực tế là các phản hồi bỏ phiếu của tôi không đủ dài để lấp đầy bộ đệm 64 byte để tự động kích hoạt làm trống bộ đệm. Đọc AN232B-04_DataLatencyFlow.pdf nếu bạn quan tâm hoặc chỉ cần truy cập Trình quản lý thiết bị của bạn và thay đổi cài đặt trong các thuộc tính Cổng nối tiếp USB của bạn.

Nếu không biết nhiều chi tiết (mà tôi không thực sự muốn biết), tôi sẽ đổ lỗi cho bộ chuyển đổi USB sang RS-485. Chúng tôi đã gặp sự cố tương tự trên bộ xử lý Intel Q7 chạy Linux với một trong những bộ điều hợp đó.

Chúng tôi đã tạm thời sử dụng bộ chuyển đổi cho đến khi phần cứng tùy chỉnh của chúng tôi sẵn sàng. Phần cứng tùy chỉnh của chúng tôi sử dụng liên kết PCIe và một FPGA để thực hiện cùng giao diện RS-485 (và nhiều hơn nữa). Phần mềm vẫn giữ nguyên cho bộ điều hợp và phần cứng tùy chỉnh của chúng tôi. Khi chúng tôi chuyển sang phần cứng tùy chỉnh, vấn đề đã biến mất.