Существуют ли простые решения для 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 "на борту"?

В пределах одного фрейма (т.е меньше 1 миллисекунды).