[Гвоздик 0]

Здравствуйте, уважаемые форумчане!

Сначала кратко опишу существующее оборудование: преобразователь сигналов из USB в RS-485, созданный на основе микросхемы FTDI RS232RL; внешний аппаратный блок, отвечающий на запросы по шине RS-485; персональный компьютер с интерфейсом USB. Скорость обмена на шине равна 1 Мбит/с, что нас вполне устраивает.

Суть загвоздки в следующем: при замере времени от выдачи команды с ПК до приема ответа на него проходит не менее 15 мс, причем внешний аппаратный контроллер вносит задержку не более 1 мс. В пачке содержится 8 байт запроса и 8 байт ответа. При уменьшении скорости обмена по шине RS-485 время между запросом и ответом увеличивается, но незначительно. Основная задержка остается примерно одинаковой (15 мс).

Мы пробовали сначала использовать виртуальный последовательный порт для работы с компьютера, потом переписали ПО под использование динамических библиотек, пытаясь увеличить скорость обмена, все безрезультатно. Похоже, что микросхема от FTDI упорно вносит эту задержку выдачи первых данных в шину.

Скажите, пожалуйста, уважаемые форумчане, какие еще существуют наиболее простые в исполнении решения для ведомого устройства на шине USB? Скорости в 1 Мбит/с нам вполне достаточно, необходимо лишь уменьшить время отклика хотя бы до 5 мс.

Если использовать микроконтроллер с USB "на борту", какая задержка приемопередачи данных будет в этом случае?

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

Буду рад совету.

[aag 0]

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

[barabek 0]

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

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

Изменено 15 ноября, 2008 пользователем barabek

[SSerge 4]

Дык, 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.

[Седой 0]

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

 

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

 

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

 

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

[Гвоздик 0]

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

[AndreyS 0]

Седой Дата Nov 15 2008, 20:08:

 

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

 

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

 

Тут имелось ввиду (я думаю), что применение МК даст вам возможность нивелировать задержку операционной системы.

Сделать это можно соответствующим образом:

Увеличить поток данных и использовать асинхронный режим передачи пакетов.

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

 

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

Изменено 17 ноября, 2008 пользователем AndreyS

[Седой 0]

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

 

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

[galjoen 0]

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

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

[Седой 0]

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

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

[VCucumber 0]

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

Isochronous ?

[galjoen 0]

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

Тут я запутался. Давайте по порядку.

1. Я так понял, что мы говорим об устройстве со стороны RS-485, работающем в режиме slave.

2. Проблема в том, что пока запрос от мастера со стороны RS-485 дойдет по USB до компьютера, компьютер ответит, его ответ передастся по USB в устройство, а устройство начнёт передавать в RS-485 - проходит недопустимо много времени.

3. Эту проблемы можно решить 2 путями:

3.1 Устройство должно знать, что ответить мастеру RS-485 на момент запроса. Это кардинальное решение, там всё ясно, там просто требуется буфер на все возможные ответы в устройстве.

3.2 Можно увеличить поток данных по USB как от устройства к компьютеру, так и от компьютера к устройству. Это позволит уменьшить задержку вносимую USB интерфейсом. Если в шине USB будут, постоянно чередуясь, идти пакеты к устройству и от устройства, то в пределах кадра USB можно несколько раз организовать приём и передачу. Но этот способ не устраняет задержки вносимой собственно ОС. А если ОС переключится на другую задачу?

 

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

[Седой 0]

Тут я запутался. Давайте по порядку.

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

Изменено 17 ноября, 2008 пользователем Седой

[galjoen 0]

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

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

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

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

Кстати, детальный алгоритм механизма работы планировщика задач в Windows известен только в Microsoft ( хотя подозреваю они его забыли?!).

 

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

Ещё нужно знать алгоритм планировщика пакетов USB.

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

 

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

[KykyryzzZ 0]

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

 

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