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

Сообщение отредактировал barabek - Nov 15 2008, 13:57

Дык, 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 не затачивалась под реалтайм.

Сообщение отредактировал AndreyS - Nov 17 2008, 07:19

В пределах одного фрейма (т.е меньше 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 устройства и устройством работает еще драйвер корневого хаба и драйвер шины, к которой этот хаб подключен.

Сообщение отредактировал Седой - Nov 17 2008, 11:22

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

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

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

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

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