Определение задержки передачи и приема преобразователя USB в EIA-485

Как я могу определить задержку, связанную с передачей данных на конвертере USB в EIA-485?

Преобразователь представляет собой B&B Electronics USOPTL4, использующий чип FTDI, и я знаю, что существует задержка пропускной способности с момента, когда мое приложение Windows вызывает WriteFile и данные фактически передаются.

Тот же вопрос относится и к приемной части вещей. Я знаю, что есть задержка, когда FTDI получает последовательные данные и предоставляет их ОС для чтения.

Кто-нибудь успешно измерил эти задержки?

Ответы (2)

"Как я могу определить задержку"?

Я использую осциллограф для определения типичных задержек.

Я изучаю исходный код и аппаратное обеспечение, чтобы получить консервативную оценку наихудшей задержки.

типичная задержка

Если бы мне нужно было измерить типичную задержку передачи и приема какой-либо конкретной установки, я бы начал с самого простого измерения: типичной задержки приема-передачи. Возможно, что-то вроде этого было бы относительно легко настроить:

  • Программное обеспечение на Arduino включает светодиод, а затем немедленно отправляет сообщение через UART.
  • у вас есть контакты UART, подключенные к соответствующей микросхеме сдвига уровня, подключенной к вашему конвертеру USB в EIA-485.
  • Программное обеспечение на ПК ожидает последовательного ввода, а затем немедленно отправляет короткое ответное сообщение.
  • Программное обеспечение на Arduino ожидает последовательного ввода, а затем немедленно включает другой светодиод.
  • Программное обеспечение на Arduino ожидает некоторое случайное время, выключает все светодиоды, ждет еще некоторое случайное время, затем начинает сначала с включения первого светодиода.

  • вы подключаете о'скоп к 2 светодиодам и измеряете типичную задержку между включением первого светодиода и включением второго светодиода.

  • вы перекомпилируете сообщения с разными размерами; построить график зависимости размера сообщения от типичной задержки.

наихудшая задержка

Система реального времени должна иметь ограниченную задержку в худшем случае. Увы, с Windows это кажется невозможным — даже если бы вы могли получить исходный код для Windows, исправление для драйвера устройства на следующей неделе может добавить еще 2 миллисекунды задержки в худшем случае.

Некоторые операционные системы реального времени поддерживают USB — в частности, EMC, работающая в Linux, работающая на RTAI, поддерживает USB — hidcomp , пользовательское устройство ввода USB с emc и т. д. USB имеет «изохронные передачи» и «передачи с прерываниями», которые выглядят как они могут быть полезны для ограничения задержки в худшем случае. Увы, похоже, никто не доверяет USB для задач в реальном времени: Поддерживаемое оборудование EMC2 , управление USB в реальном времени? , проблемы с USB и т.д.

Таким образом, EMC2 по-прежнему использует параллельные порты, чтобы получить известную наихудшую задержку; другие протоколы связи с малой задержкой используют различное оборудование, включая оборудование Ethernet.

Вероятно, было бы более экономичным и точным получать данные, измеряя их с программного обеспечения ПК через последовательный шлейф обратно к программному обеспечению ПК — вам понадобится не больше оборудования, чем клочок провода, и вы можете собрать все данные для измерения статистических данных . частота выбросов. Если бы у вас был отдельный выходной канал с малой задержкой от ПК, вы могли бы использовать возможности для измерения односторонней задержки относительно этого, но, если не считать взлома низкоуровневого видео или драйверов IDE, такие вещи могут быть недоступны на современных ПК.
@ChrisStratton: отличное предложение. Я не уверен, какой эффект окажет дополнительная процедура «получить временную метку», но я подозреваю, что это незначительно по сравнению с задержкой и дрожанием USB.

Ну, что ты пытаешься сделать?

Вы обнаружите, что каждый уровень в этом стеке добавляет переменную величину, казалось бы, случайной задержки. Хотя обычно оно может быть менее 1 мс, иногда оно может быть намного больше.

Сама ОС будет иметь некоторую случайную задержку планировщика многозадачности. Это может быть 0-50 мс (или больше в специализированных или плохо настроенных системах). Если вы пытаетесь сделать что-то с очень жесткими временными ограничениями, вам, вероятно, потребуется сделать это в пользовательском драйвере устройства в пространстве ядра, чтобы определить время.

После этого USB не очень удобная шина с задержкой. Ожидание отправки данных через USB добавит небольшую случайную задержку. Сторона чтения на самом деле немного хуже ... так как корень USB должен опрашивать подключенные устройства, чтобы узнать, есть ли у них данные. Я не могу рассказать вам, каковы диапазоны этих задержек ... может быть, кто-то еще может помочь здесь. Тем не менее, это, вероятно, будет довольно изменчивым в зависимости от таких вещей, как подключение через концентратор и количество других подключенных устройств. Поэтому, если вы измеряете его самостоятельно, убедитесь, что вы попробовали хотя бы несколько комбинаций USB-устройств. Попробуйте с подключенными и активными веб-камерами и флэш-накопителями, через концентратор, напрямую и т. д.

Я бы усилил точку зрения @ darron: если задержки имеют достаточное значение, чтобы их можно было измерить (скажем, 10 мс), с USB будет больше проблем, чем оно того стоит. Если требуется детерминированное время, ваша архитектура отталкивается от потребительского интерфейса, такого как USB.