Седой

Поддержка композитных usb устройств у Microsoft'a появилась в Win2000 и в Win98. В Win2000 и Win98(Me) роль драйвера композитного устройства выполнял драйвер хаба. В WinXP появился отдельный драйвер композитного устройства (USB Common Class Parent Driver). В WinXP SP1(или SP2, нужно посмотреть) этот драйвер стал подерживать энумерацию функциональных устройств, имеющих более 1-го интерфейса ( в том числе CDC), для этого был введен USB Interface Association Descriptor - IAD. В Vista и WinXP SP3 появилась возможность выбора различных конфигураций. Повторю свой вчераший пост: Призываю уважаемых участников данного обсуждения прежде чем высказывать свои "измышлизмы" внимательно прочитать первоисточник по данной теме- http://msdn.microsoft.com/en-us/library/ms793564.aspx PS. Ссылку даю уже в четвертый раз. PS1. Посмотрел - IAD поддерживается начиная с WinXP SP2.

Призываю уважаемых участников данного обсуждения прежде чем высказывать свои "измышлизмы" внимательно прочитать первоисточник по данной теме- http://msdn.microsoft.com/en-us/library/ms793564.aspx PS. Ссылку даю уже в третий раз.

Очень даже стандартным - см. http://msdn.microsoft.com/en-us/library/ms793564.aspx -это раздел описания работы системного драйвера композитного USb устройства (до XP эти функции выполнял драйвер хаба). А применительно к использованию класса СDC (он имеет два интерфейса) в композитном устройстве см. http://msdn.microsoft.com/en-us/library/aa476422.aspx

Да, может. Описание здесь http://msdn.microsoft.com/en-us/library/ms793564.aspx

Еще раз повторю - имеется в виду библиотека. К самим чипам претензий нет. PS. Почему? Скомпилируйте для PIC24 и посмотрите ассемблерный код. А может быть не нужно "с ходу", а нужно быстрее ( в смысле задержку покороче).

Да, правильно. Теперь по поводу FTD2XX.LIB в Microsoft C и Borland C http://www.ftdichip.com/Support/Knowledgebase/index.html т.е. для использования в VC ничего делать не надо, библиотека импорта FTD2XX.LIB в последней редакции как раз для него и сделана.

Там все не так сложно. Сделайте def файл с экспортом по номерам функций и ,не подключая к проекту, из командной строки запустите LIB /DEF :вашфайл.def http://msdn.microsoft.com/en-us/library/aa235502(VS.60).aspx Полученный в результате lib файл подключите к проекту. PS. Если не получится, завтра-послезавтра скину сюда. (Сейчас просто нет времени) PS2. Пока писал ответ, КRS вам уже подсказал.

Зачем тогда беретесь за работу? Еще одна ссылка http://www.progz.ru/articles.php?issue=9

Первоисточник http://msdn.microsoft.com/en-us/library/aa294088(VS.60).aspx

Как обычно: Динамически - LoadLibrary и GetProcAddress. Статически - через создание дополнительной библиотеки статического связывания. PS. Все описано в документации. Дело не в среде, а в особенности декорирования имен в VC.

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

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

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

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

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

Похожая на вашу проблема уже обсуждалась в теме http://electronix.ru/forum/index.php?showt...=37919&st=0 Возможно, что указанное решение подойдет и для FTDI. Естественно при условии настройки timeout, как указал SSerge, и отсутствии кривизны драйверов от FTDI. Но, лучше всего использовать USB-RS485 на микрокотроллере с firmware и драйвером, оптимизированными под вашу задачу. PS. Если не можете сделать сами - пишите в личку, мы такие USB-RS485 производим.

Поменяли. В основном оптимизация по скорости, ну и были небольшие недочеты. Обновить - пишите в личку или [email protected].

Ну так давайте адрес, вышлем, сами и посмотрите, понравится - купите.

Посмотрите http://www.moschip.com/mcs9820.php Покупать в ЭФО

С тех времен, когда выкладывал проект DFU ( http://projects.caxapa.ru/?ID=45 ), он значительно доработан. В основном в плане АPI, т.е. библиотеки пользователя, но и драйвер тоже. Появилась возможность обновления ПО из диспетчера устройств (см. рисунок), т.е. без запуска программы программатора. API включает в себя как функции работы с файлами прошивок, так и функции программирования, в том числе низкоуровневые и высокоуровневые. Также поддерживается возможность динамического определения подключенных устройств и т.д. Сейчас в фоновом режиме готовлю обновление проекта, в том числе примеры реализации со стороны МК и документацию. Где-то через месяц выложу, если будет время.

Нет, и скорее всего не будет из-за специфики устройств, для которых он нужен. Мы сделали свой, но оказалось он и не понадобился, т.к. большей функциональности удается получить используя спец. драйвер и API. PS. VCP больше всего нужен производителям микросхем USB-UART, таким как FTDI, Silabs, Moschip и т.д. PS1. Все требования к драйверу COM порта изложены в DDK

Ну и в чем проблема, возмите другой физ. уровень и используйте LIN протокол. Кстати, я думаю, и штатный LIN приемопередатчик может 300м потянуть, если подобрать нагрузку и емкость линии, вам же не требуется четкое соблюдение требованиям спецификации LIN.

Второй вариант как раз поможет. Автор не уточнил, что у него за девайс, - есть ли смысл и возможность полностью его переделывать. Если серийный - то смысл есть, но и в этом случае такой переходник полезная опция для уже существующих устройств (и клиентам приятно и себестоимость копеечная).

zltigo указал вам на лучшее решение. Но если переделывать девайс для вас не подходит, то действуйте по варианту 2. Конечно программу для PC придется переписать и реализовать в переходнике логику работы протокола обмена. Вариант 1 не подойдет в силу уже указанных zltigo причин.

Насколько я понял, вы считаете основным ограничением по скорости в вашей задаче появление 1 ms межфреймовых интервалов между транзакциями по одной EP, поэтому и решили использовать две EP. Задача синхронизации не тривиальная и требует четко продуманного алгоритма, причем он должен быть реализован как со стороны хоста, так и со стороны устройства. Я согласен с galjoen, в этом нет никакого смысла, скорость действительно существенно не повысится, если вы у вас размер транзакции больше размера пакета по данной ЕP. Если вы не успеваете принимать данные с помощью драйверов Cypress - делайте свой драйвер с организацией постоянного чтения данных с одной ЕP в буфер драйвера и чтением данных приложением из этого буфера.