Существуют ли простые решения для 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-шины и выдающую их в параллельном или последовательном виде, и наоборот. Это для того, чтобы избежать дополнительных иженерных усилий по программированию и технологических операций при изготовлении.
Буду рад совету.

[Седой]

Тут, кстати, хочу сказать, что запрос (от компьютера) - ответ (устройства компьютеру) в одном фрейме (кадре) USB сделать можно без проблем, а вот как сделать наоборот - запрос (от устройства) ответ (компьютера устойству) в одном кадре я не знаю. А в режиме слейва RS485 нужен именно такой вариант. Отсюда и вопросы.

Невозможно, даже на уровне драйвера устройства.
PS. Хотя если делать свой драйвер корневого концентратора с планировщиком, то может быть... Нужно посмотреть документацию на конкретные чипы.

Кстати дайте ссылочку на ваш вариант (можно и в личку) если не жалко. Я не из-за конкуренции, просто любопытно. А если вам интересно, я на свою железку ссылку дам.

Один из вариантов железки - обыкновенный USB-RS485, где вместо CP2103 впаян С8051F326 http://www.slavna.ru/stran/urs485.htm
Драйвер свой, механизм работы - в теме http://electronix.ru/forum/index.php?showt...=37919&st=0

[galjoen]

Невозможно, даже на уровне драйвера устройства.
PS. Хотя если делать свой драйвер корневого концентратора с планировщиком, то может быть... Нужно посмотреть документацию на конкретные чипы.

Согласен.

А вот моя железка:
http://www.antel.info/index.php?option=com...=3&Itemid=4
Хотя это, конечно, побочный продукт. Основной тот, что с CAN, но CAN там не универсальный, а только под нашу технику.

[Гвоздик]

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

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

[Седой]

... драйверы и АПИшные библиотеки для Винды они прилагают.

Очередной костыль.
Библиотекой USB от Microchip рекомендую пользоваться только с целью изучения.

[Гвоздик]

Очередной костыль.
Библиотекой USB от Microchip рекомендую пользоваться только с целью изучения.

Что ж, смелое утверждение на мой взгляд. А не могли бы Вы подробнее сказать почему? И что на Ваш взгляд более предпочтительно Майкрочипу?

[_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

[Седой]

Что ж, смелое утверждение на мой взгляд. А не могли бы Вы подробнее сказать почему? И что на Ваш взгляд более предпочтительно Майкрочипу?

Еще раз повторю - имеется в виду библиотека. К самим чипам претензий нет.

PS. Почему? Скомпилируйте для PIC24 и посмотрите ассемблерный код.

Что-то в вашей консерватори не так.
.....
И не факт что на МК с USB на борту у вас с ходу обмен получится быстрее.

А может быть не нужно "с ходу", а нужно быстрее ( в смысле задержку покороче).