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

Ну тут получается идеальный вариант CY7C68013. Это usb-модуль с простеньким контроллером на борту

Вообще-то таких камней полно. Например у silabs (c2051f320 /f340). Правда это не самый простой путь . Еще у них же есть преобразователи usb-uart, как у FTDI. Это решение гораздо проще, но я сам не пробовал. Поищите кто их пробовал (CP210x), какие у них параметры.

Дык, 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 "на борту"?

Тут имелось ввиду (я думаю), что применение МК даст вам возможность нивелировать задержку операционной системы.
Сделать это можно соответствующим образом:
Увеличить поток данных и использовать асинхронный режим передачи пакетов.
Или если синхронный режим, то с глубоким буфером в МК. Т.е. ваше устройство не должно сразу пытаться отправить отет и при этом ничего не делать. А должно работать по принципу TCP/IP. Необходимо на верхнем уровне просто кидать пакеты, всю синхронную работу необходимо перенести в МК (т.е на нижнйи уровень).

USB не затачивалась под реалтайм.

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

Т.е. на момент опроса устройста по RS-485, оно уже должно знаеть, что нужно ответить?

Нет конечно, но если оно ответит быстро (< 1ms), то ответ уйдет в тот же фрейм, в котором пришел запрос. Если не быстро, то в текущий фрейм ответа.

Isochronous ?

Тут я запутался. Давайте по порядку.
1. Я так понял, что мы говорим об устройстве со стороны RS-485, работающем в режиме slave.
2. Проблема в том, что пока запрос от мастера со стороны RS-485 дойдет по USB до компьютера, компьютер ответит, его ответ передастся по USB в устройство, а устройство начнёт передавать в RS-485 - проходит недопустимо много времени.
3. Эту проблемы можно решить 2 путями:
3.1 Устройство должно знать, что ответить мастеру RS-485 на момент запроса. Это кардинальное решение, там всё ясно, там просто требуется буфер на все возможные ответы в устройстве.
3.2 Можно увеличить поток данных по USB как от устройства к компьютеру, так и от компьютера к устройству. Это позволит уменьшить задержку вносимую USB интерфейсом. Если в шине USB будут, постоянно чередуясь, идти пакеты к устройству и от устройства, то в пределах кадра USB можно несколько раз организовать приём и передачу. Но этот способ не устраняет задержки вносимой собственно ОС. А если ОС переключится на другую задачу?

Вот я и спросил - каким способом вы пользуетесь? Или м.б. вы знаете ещё какой либо способ кроме перечисленных?

Способом организации механизма запрос-ответ в одном фрейме пользуемся постоянно, естественно где это необходимо.

По поводу остального - оптимальным считаем перенос не только протокольного уровня в USB-RS485, но и более высоких, если между USB и RS485 стоит устройство с мозгами, то оно и должно работать по максимуму. Тогда и все проблемы, связанные с OS, частично решаются. Кстати, детальный алгоритм механизма работы планировщика задач в Windows известен только в Microsoft ( хотя подозреваю они его забыли?!).

PS. И еще не следует забывать, что между драйвером USB устройства и устройством работает еще драйвер корневого хаба и драйвер шины, к которой этот хаб подключен.

Теперь дошло, что здесь имеется ввиду фрейм USB.

Полностью согласен. Сам сделал переходник USB-RS485 на таком принципе. Мозгов там больших и не нужно. Но если работа в режиме мастера RS485 не вызывает никаких проблем, то режим слейва требует знания ответов на ВСЕ возможные запросы по RS485. А если этих возможных запросов штук 200, и отвечать на них нужно 256 байтами на каждый, то к мозгам приходится добавлять внешнее ОЗУ.

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

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

Работал с CP2103 на скорости 115200 . Драйвера у них кривоватые (как в общем то у всех микросхем этого типа по отзывам). Задержки есть, но точно сказать не могу сколько. Скорее всего ставить CP210x - шило на мыло. Уж лучше полноценный USB

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



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

Согласен.

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

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

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

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

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

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

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



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