Существуют ли простые решения для USB slave?, FTDI FT232RL делает слишком долгую задержку перед передачей Опции

[Гвоздик]

Здравствуйте, уважаемые форумчане!
Сначала кратко опишу существующее оборудование: преобразователь сигналов из USB в RS-485, созданный на основе микросхемы FTDI RS232RL; внешний аппаратный блок, отвечающий на запросы по шине RS-485; персональный компьютер с интерфейсом USB. Скорость обмена на шине равна 1 Мбит/с, что нас вполне устраивает.
Суть загвоздки в следующем: при замере времени от выдачи команды с ПК до приема ответа на него проходит не менее 15 мс, причем внешний аппаратный контроллер вносит задержку не более 1 мс. В пачке содержится 8 байт запроса и 8 байт ответа. При уменьшении скорости обмена по шине RS-485 время между запросом и ответом увеличивается, но незначительно. Основная задержка остается примерно одинаковой (15 мс).
Мы пробовали сначала использовать виртуальный последовательный порт для работы с компьютера, потом переписали ПО под использование динамических библиотек, пытаясь увеличить скорость обмена, все безрезультатно. Похоже, что микросхема от FTDI упорно вносит эту задержку выдачи первых данных в шину.
Скажите, пожалуйста, уважаемые форумчане, какие еще существуют наиболее простые в исполнении решения для ведомого устройства на шине USB? Скорости в 1 Мбит/с нам вполне достаточно, необходимо лишь уменьшить время отклика хотя бы до 5 мс.
Если использовать микроконтроллер с USB "на борту", какая задержка приемопередачи данных будет в этом случае?
Идеальным решением было бы применение готовой микросхемы, принимающей данные из USB-шины и выдающую их в параллельном или последовательном виде, и наоборот. Это для того, чтобы избежать дополнительных иженерных усилий по программированию и технологических операций при изготовлении.
Буду рад совету.

[SSerge]

Дык, USB передаёт данные пакетами, поэтому то, что приходит с RxD сначала буферизуется внутри микросхемы и потом передаётся по таймауту или при заполнении буфера. Время таймаута можно настраивать.
Вот, прямо на 4-й странице пишут:

Programmable Receive Buffer Timeout - The receive buffer timeout is used to flush remaining data from the receive buffer. This time defaults to 16ms, but is programmable over USB in 1ms increments from 1ms to 255ms, thus allowing the device to be optimised for protocols that require fast response times from short data packets.

Ещё один способ - по окончании передачи пакета "подёргать ножкой" CTS или DSR чтобы спровоцировать передачу буфера. Смотрите AN232B-04 Data Throughput, Latency and Handshaking.

[Гвоздик]

Дык, USB передаёт данные пакетами, поэтому то, что приходит с RxD сначала буферизуется внутри микросхемы и потом передаётся по таймауту или при заполнении буфера. Время таймаута можно настраивать.
Вот, прямо на 4-й странице пишут:

Ещё один способ - по окончании передачи пакета "подёргать ножкой" CTS или DSR чтобы спровоцировать передачу буфера. Смотрите AN232B-04 Data Throughput, Latency and Handshaking.

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

Похожая на вашу проблема уже обсуждалась в теме http://electronix.ru/forum/index.php?showt...=37919&st=0

Возможно, что указанное решение подойдет и для FTDI. Естественно при условии настройки timeout, как указал SSerge, и отсутствии кривизны драйверов от FTDI.

Но, лучше всего использовать USB-RS485 на микрокотроллере с firmware и драйвером, оптимизированными под вашу задачу.

PS. Если не можете сделать сами - пишите в личку, мы такие USB-RS485 производим.

Если не секрет, то какова задержка от отправки до приема пакета с применением микроконтроллера с USB "на борту"?

[Гвоздик]

Спасибо за совет по таймауту. Однако, это мы уже пробовали и неоднократно. На самом деле изменение значения таймаута таймера в драйвере не помогает, квалификации виндового программиста я доверяю.
Подергать ножкой попробуем, может и поможет.
Если не секрет, то какова задержка от отправки до приема пакета с применением микроконтроллера с USB "на борту"?

Ножками "подрыгали", толку нет, задержка таже - 15 мс и более.
Для сведения пробовали мы измерять задержку с использованием аппаратного последовательного порта RS-232C на том же оборудовании с тем же ПО. Задержка от отправки 8 байт запроса до приема 8 байт ответа составила 3..5 мс в зависимости от материнской платы ПК. Т.е. в три раза быстрее, чем по УСБ с микросхемой от FTDI, вот такие вот пирожки печет FTDI.
Придется на микроконтроллере с УСБ "на борту" делать заново, пока смотрю в сторону Майкрочипа, драйверы и АПИшные библиотеки для Винды они прилагают.

[_3m]

Ножками "подрыгали", толку нет, задержка таже - 15 мс и более.
Для сведения пробовали мы измерять задержку с использованием аппаратного последовательного порта RS-232C на том же оборудовании с тем же ПО. Задержка от отправки 8 байт запроса до приема 8 байт ответа составила 3..5 мс в зависимости от материнской платы ПК. Т.е. в три раза быстрее, чем по УСБ с микросхемой от FTDI, вот такие вот пирожки печет FTDI.
Придется на микроконтроллере с УСБ "на борту" делать заново, пока смотрю в сторону Майкрочипа, драйверы и АПИшные библиотеки для Винды они прилагают.

Что-то в вашей консерватори не так.
Использую FT232BM. Изменением значения Latency Timer до 2-4мс получаю задержку запрос-ответ 3-5мс на скорости 1000килобит/с, мое устройство отвечает мгновенно. Коммуникационная часть на писюке крутится в отдельном потоке.
Ваши цифры характерны для дефолтного значения Latency Timer, которое составляет 16мс. Кстати, старые чипы FTDI не позволяют менять задержку, у старых чипов Latency Timer фиксированный на 16мс.
У чипов FTDI конечно есть проблемы, но именно с задержками у них ситуация лучше чем у всех остальных производителей USB-UART.
И не факт что на МК с USB на борту у вас с ходу обмен получится быстрее.

Сообщение отредактировал _3m - Dec 8 2008, 13:12