Hello, Leha! You wrote to Sergey Zabelin on Tue, 23 May 2006 12:51:13 +0000 (UTC):
LB> А как из программы на РС ты обмениваешься данными со своим устройством? LB> Обычные ReadFile/WriteFile работают? Не. Обмен с HID устройством вообще по другому выглядит, он заключается в записи и чтении т.н. репортов - структур данных, определяемых в дескрипторе устройства. Репорты бывают FEATURE (запись-чтение), INPUT, OUTPUT. У меня для обмена используются ф-ии HidD_GetHidGuid HidD_GetAttributes HidD_GetSerialNumberString HidD_GetFeature HidD_SetFeature Они из библиотеки hid.dll, она входит в состав Винды, но связана динамически. Ну еще надо енумерацию провести, интерфейс найти, нужное устройство (у меня их может быть несколько на одном компе). Для этого ф-ии SetupDi... используются. В общем, 2-3десятка строк на Це или паскале.
LB> У USB 2.0 вроде бы есть доп. пакеты с интервалом 0.125мс или они для LB> HID-ов не используются? Насколько я понимаю, HID только на LS может быть, даже не FS. А 0.125, скорее всего, только к HS относится. Но я вплотную этот вопрос не изучал, не было надобности.
LB> Похоже, что еще очень мало кто использует контроллеры с USB, чаще LB> пользуются чем-то типа FTDI, что бы получить связь через USB. FTDI хорошие кристалы, спору нет, но мне в них кое-что не нравится. 1) Требуется установка и, соответственно поставка драйверов, а HID воткнул в любой комп, и работает. У этих драйверов надо вручную отслеживать версии, следить за совместимостью, обновлять, а винда со своими делает это сама. Сл-но, надо писать инсталятор, поскольку клиент такой, что драйвер от стайера не отличит :-)
2) Твое, выстраданое потом и кровью устройство видится в диспетчере устройств как банальный COM-порт. Клиент спрашивает, ты пошто с меня такие деньги берешь? Вкусовщина, конечно, но все же...
3) Затруднена работа с несколькими устройствами. Каждое будет своим COM портом, и где какое программно не определишь, прописывать надо вручную. Причем и вручную определить - нетривиальная задача для клиента. А так - у каждого серийный номер, который на нем написан и программно доступен, все просто и понятно
4) Модель COM-порта не совсем удобна для работы с устройством, у которого несколько интерфейсов. Например, у меня 3 - запись/чтение управляющих регистров, канал данных, и управление. Они все работают одновременно и независимо друг от друга. С СOM-портом, конечно, подобное тоже можно организовать, но геморройнее. Например, те же AT-команды у простого модема как сделаны - требуются дополнительные телодвижения чтобы переключится из режима управления в режим передачи данных и обратно, и одновременно работать они не могут. А если хочется к разным интерфейсам из разных потоков обращаться (допустим, управление из основного потока и передача данных в отдельном потоке), то это и вовсе нетривиальной задачей становится.
5) Несколько настораживает глюкавость драйверов. Я не склонен к драматизации, да и сам на FTDI ничего не делал, но зато в свое время ковырялся с переходниками USB-COM разных производителей, в т.ч. FTDI. У меня было 3 разных переходника, и вот что показали исследования: - На TransmitChar (передача в обход буфера) рухают в BSOD все три. - Два из трех (и FTDI) рухают в BSOD, если порт открыть, считать несколько байт, программно остановиться не закрывая, но снаружи продолжать передачу данных на порт. Через некоторое время буфер переполняется (а контоль переполнения там сделать, видимо, забыли), и - пожалуйте бриться - Один (это, правда, был пролифик) не устанавливает нестандартную скорость передачи. Мне надо было 200 б/c, SetCommState возвращает, что все ок, но реально скорость оказывается 300 б/с.
Справедливости ради, надо сказать что это было несколько лет назад, возможно оно уже исправлено, да и глюки обходимые - если их знать, работать можно. Но все равно - осадок остался :-)
With best regards, Sergey Zabelin. E-mail: snipped-for-privacy@telemak.ru