Интересно, может ли кто-нибудь вообще помочь, немного проблема специалиста в этом.
У меня есть приложение, которое должно читать и анализировать несколько USB-устройств (не одновременно, каждое из них запускается в отдельных тестах и теоретически может запускаться на разных машинах).
Каждое из USB-устройств основано на классе USB HID и производится разными компаниями, ни одно из этих USB-устройств не предназначено для работы на ПК, но предназначены для другой платформы, однако в целях тестирования устройств клиент запросил запуск тестового приложения с ПК.
Некоторые из устройств запускаются, распознаются окнами, которые инициализируют и запускают их правильно с помощью встроенного в Windows драйвера универсального класса HID, после чего устройства начнут отправлять правильные пакеты данных с тестируемыми данными.
Некоторые из устройств запускаются, распознаются окнами, которые будут пытаться запустить их, но не смогут полностью инициализировать их, оставив их в полуинициализированном состоянии. Это нормально, так как я могу использовать свой анализатор протокола Beagle для захвата пакетов инициализации с подлинной платформы, а затем использовать библиотеку LibUSBDotNet для репликации оставшихся пакетов в последовательности инициализации и заставить их начать отправку пакетов правильно.
У меня проблема с одним конкретным устройством (хотя есть еще несколько, которые я еще не тестировал, поэтому вполне возможно, что одно из них также может демонстрировать ту же проблему). Проблема в том, что драйвер класса HID Windows распознает устройство и пытается инициализировать и запустить его, это работает по-своему, и устройство начинает отправлять данные.
Проблема в том, что отправляемые данные отличаются от данных, отправляемых на подлинную платформу (содержащую только подмножество полных данных). Как будто Windows инициализировала устройство в другом режиме.
Когда я захватываю пакеты инициализации как с ПК, так и с подлинной платформы с помощью анализатора протокола USB, я вижу, что Windows отправляет несколько разные пакеты инициализации. Использование LibUSBDotNet для повторной отправки правильных пакетов после того, как Windows уже запустила устройство, похоже, не дает никакого эффекта.
Моя проблема в том, что мне нужно остановить попытки Windows инициализировать устройство с помощью стандартного драйвера класса HID, я попытался удалить драйвер в диспетчере устройств, но он все еще инициализирует его (и драйвер волшебным образом переназначается в диспетчере устройств). Я провел небольшое расследование, и есть возможные альтернативы:
Создайте конкретный драйвер, который Windows будет назначать конкретному VID / PID устройства, но ничего не делает, тогда я могу использовать LibUSBDotNet для отправки правильной последовательности инициализации на устройство из моего собственного кода.
Используйте что-то вроде WinUSB для создания подходящего драйвера для устройства (или, возможно, для создания «мертвого» драйвера, такого как 1.
Будет ли драйвер с определенным VID / PID использоваться Windows вместо встроенного драйвера класса USB HID? Если нет, то я бы зря тратил время, идя по этому маршруту?
Обратите внимание, мой Mac правильно инициализирует проблемное устройство, и я задал вопрос клиенту, можно ли разработать приложение для Mac, и их ответ разочаровал только Windows.
У меня нет опыта написания правильных драйверов для Windows, хотя у меня есть опыт общения с USB на относительно низком уровне (так что эта часть не слишком беспокоит). Может ли кто-нибудь предложить хороший план действий (прежде чем я потенциально потрачу несколько недель на изучение того, как писать драйверы для ПК, только чтобы обнаружить, что выбранный мной курс действий не может обеспечить то, что мне нужно).
Любая помощь или предложение очень ценится.
Спасибо, Рич
Добавлено после попытки предложения ниже:
Я попытался использовать мастер LibUsbDotNet inf для создания необходимых файлов и их установки, и это, похоже, сработало - определенно устройство теперь отображалось в диспетчере устройств как устройство libusb-win32, а не устройство HID, и связанный драйвер был драйвером libusb. Даже после этого устройство по-прежнему инициализируется и начинает отправлять пакеты данных неправильного типа, хотя теперь эти пакеты больше не обрабатываются драйвером класса и просто теряются.
Я также наткнулся на Zadig, у которого есть аналогичный мастер создания информации для WinUSB, и он дал точно такой же результат.
Коллега предположил, что это могут быть не сами окна, которые переключают устройство в этот режим, а устройство, определяющее, что оно подключено к машине с Windows, и переключается в этот режим. Я подозреваю, что дело обстоит именно так, и в этом случае я застрял - пора еще раз поговорить с клиентом.
Большое спасибо за помощь.
