Опрос датчика через последовательный интерфейс USB-RS485 застрял на 16 мс, хотя должен быть быстрее

У меня есть установка, в которой сенсорная плата Razor IMU с коммутационной платой RS-485 подключается к последовательному интерфейсу USB-RS485 через USB-кабель к моему ноутбуку. Я запускаю программное обеспечение на ноутбуке (Max/MSP), которое отправляет сообщения опроса на датчик, ждет данных ответа и при получении ответа автоматически запускает новое сообщение опроса. Это постоянный цикл:

  1. отправить сообщение для голосования
  2. ждать ответа
  3. при ответе перейти к 1.

Я хочу, чтобы этот опрос был как можно быстрее, так как мне придется подключить 21 из этих датчиков к одной и той же шине RS485. Прошивка Razor запрограммирована с помощью Arduino IDE , и, согласно коду, между сообщением опроса и записью ответа должна быть задержка всего ~ 2 мс. Прошивка также тратит 12 мс каждые 20 мс на размещение и расчет датчиков. Этот расчет иногда задерживает ответ на опрос. Я знаю об этом, и все результаты соответствуют этому.

Моя проблема сейчас заключается в том, что опрос датчика зависает со средней частотой обновления 15 миллисекунд. Я просмотрел данные с помощью своего маленького USB-осциллографа и сделал диаграмму (> PDF).

введите описание изображения здесь

Мой осциллограф находится непосредственно на интерфейсе USB-RS485 и видит, как идет опрос и приходит ответное сообщение. Задержка между этими двумя составляет от 2 до 13 мс. Эта разница объясняется тем, что иногда бритва занята сенсорно-математическими вычислениями. Странный факт заключается в том, что, несмотря на то, что ответы приходят с разной задержкой, кажется, что опрос всегда происходит с одним и тем же интервалом около 15 мс.

Мы также реализовали ту же настройку с

  • кодирование прошивки на C и программирование Razor с помощью avr-dude
  • выполнение программного опроса в коде Python
  • на Mac OSX и ПК Windows 7

Все возможные комбинации приводили к одному и тому же интервалу в 15 мс. Так что проблема не в Arduino-коде и не в Max/MSP. У меня есть подозрение, что проблема может быть связана с последовательным интерфейсом USB-RS485 и/или необходимым драйвером FTDI.

Эта проблема никому не знакома??

То есть опрос всегда происходит с компьютера под управлением OSX или Windows 7? Задержка на USB может быть довольно большой, независимо от используемого вами языка программирования.
прямо сейчас мы тестируем на Windows 7 и на OSX. в конце концов он будет работать на Windows 7.
Вместо того, чтобы редактировать свой вопрос, вы можете ответить на свой вопрос. Это позволит вам выбрать его в качестве ответа и даже получить одобрение!
через 7 часов буду! :) <.... Пользователи с репутацией менее 100 не могут ответить на свой вопрос в течение 8 часов после вопроса. Вы можете самостоятельно ответить в течение 7 часов. До тех пор, пожалуйста, используйте комментарии или вместо этого отредактируйте свой вопрос.>

Ответы (2)

Это связано с таймером задержки 16 мс драйвера FTDI и тем фактом, что мои ответы на опрос не были достаточно длинными, чтобы заполнить 64-байтовый буфер для автоматического запуска очистки буфера. Прочтите AN232B-04_DataLatencyFlow.pdf , если вам интересно, или просто перейдите в Диспетчер устройств и измените настройки в свойствах USB-Serial-Port.

Не зная многих деталей (которые я действительно не хочу знать), я бы обвинил адаптер USB-RS-485. У нас была аналогичная проблема с процессором Intel Q7 под управлением Linux с одним из этих адаптеров.

Мы использовали адаптер временно, пока наше специальное оборудование не было готово. Наше специализированное оборудование использует соединение PCIe и FPGA для реализации того же интерфейса RS-485 (и многого другого). Программное обеспечение осталось прежним для адаптера и нашего пользовательского оборудования. Когда мы перешли на нестандартное оборудование, проблема исчезла.

да! только что понял, что я могу изменить кучу вещей в настройках USB-Serial-порта (особенно таймер задержки), и тогда все ускоряется ...