Как сменить pid в драйвере
Здравствуйте. Осваиваю LibUsbDotNet. И сразу возникла куча вопросов.
Есть у них на сайте пример, выводящий список подключенных устройств.
НО что-то не нашёл в свойствах VID & PID. Подскажите, где это можно найти?
Добавлено через 7 минут
Разобрался, спасибо.
Библиотека понравилась. Буду дальше изучать.
Спасибо разработчикам.
Добавлено через 22 секунды
Тему можно считать закрытой.
Добавлено через 46 минут
Теперь вопрос, как эти самые VID/PID программно поменять.
Кто-нибудь работал с LibUsbDotNet? Как работать с HID?
Здравствуйте. Собственно есть HID-устройство (плата Teensy 2 с залитой программой LUFA HID от.
Как программно поменять иконку исполняемого файла приложения?
например у меня есть кнопка загрузить иконку , человек загружает ее , и создает билд , и надо чтобы.
Не читаются данные с RFID через LibUsbDotNet
Суть вопроса вот в чем. Есть RFID reader usb китайский без SDK и без драйверов. В диспетчере.
Как программно поменять иконку файла?
как программно поменять иконку файла?
Да это я на микросхеме ftdi (кстати официально купленной) программой FTProg опрометчиво PID поменял. Пытался direct driver подключить. А теперь назад не получается. С другим PID её FTProg уже не видит.
Она, конечно, стоит 5 рублей, но хочется разобраться. Спасибо.
а) Запускаем FT_Prog.
б) Жмем на “линзу” на панели под меню. Появляется список найденных устройств.
в) Во избежание ошибок отключаем “лишние” устройства (если есть).
г) Для нужного устройства выбираем слева пункт «USB_Device_Descriptor».
д) Затем справа в свойствах «Custom VID/PID» выбираем «FTDI_Default».
е) Ждем на “молнию” на панели под меню. Появляется окно записи.
ж) В окне ставим галочку напротив устройства.
з) Снимаем галочку внизу на «Only Program Blank Device».
и) Жмем «Program».
Отключаем устройство. Теперь оно будет опзнаваться как "FTDI Serial port".
Это основная статья, в которой мы рассмотрим, как классический способ смены данных флешки, так и сравним его с двумя экзотическими, подробно описанными в отдельных статьях.
В них описаны методики смены таких данных, которые нельзя изменить обычным редактированием настроек программы. Короче, применён нестандартный подход к решению задачи.
Чем хороши контроллеры SMI, так тем, что их шить совсем не обязательно, чтобы изменить серийный номер и большинство прочей инфы. Это в свою очередь, снижает риски, получения на выходе мёртвой флешки.
Но расслабляться всё равно не надо, использование любого из методов может повлечь, как необходимость дополнительного форматирования, так и зависания. В основном это связанно с глюками некоторых дистрибутивов утилиты SMI MPTool. Так в одной версии, почему-то идентификационная инфа не хочет обновляться, в другой после перебивки серийника, требует форматирования и т.д. Иногда, просто необходимо нащупать полностью совместимый дистрибутив со своей флешкой и уже смело извращаться по полной.
Ниже я разместил небольшую табличку, в которой сделал наглядное сравнение возможностей различных методов изменения идентификационной информации. Как видно из неё, универсального способа нету и комбинация отдельных элементов — это тот самый выход, который напрашивается самим собой.
СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДИК | |||
---|---|---|---|
СТАНДАРТНЫЙ МЕТОД | SMI DEBUG | РЕДАКТИРОВАНИЕ ФАЙЛОВ | |
VID-PID: | + | + | + |
Vendor-Product: | + | + | + |
Serial Number: | + | + | + |
Revision: | – | + | + |
MP Date: | – | + | – |
ISP Ver: | – | – | + |
PreTest Ver: | – | + | + |
MP Package No: | – | + | + |
FlashSet: | – | + | + |
УРОВЕНЬ СЛОЖНОСТИ: | ЛЕГКО | СРЕДНИЙ | ВЫШЕ СРЕДНЕГО |
Как я уже написал в введении, шить совсем не обязательно для решения задачи смены данных. Достаточно на первой странице настроек в правой части оставить активными галочки Write CID и Download ISP.
И даже больше, для старой модели SM3252C, можно вообще оставить только одну птичку Write CID.
Полная же перепрошивка достигается путём дополнительного включения опций: Pretest и Format(FAT32).
Отдельно рассмотрим Serial Number, т.к. он наиболее сложный, а уже потом все прочие параметры.
При первом знакомстве может показаться что благодаря ручной правке, можно устанавливать длину серийника SMI-флешки ниже 13-символов, заложенных в производственную утилиту SMIMPTool. Но как такового нижнего ограничения в 13 байт не существует в приложении, не смотря на имеющийся параметр SN Length.
Сначала выставляем значение параметра Serial Number, определяющего способ формирования:
– 13-32 Bytes (стандартное значение, из-под которого и следует редактировать его)
– Random SN (случайные символы)
– NO Serial (отсутствует серийник)
– NO Update Serial (оставить прежнее значение)
Если хотите жестко задать определённый серийный номер, то просто укажите его в графе Serial Mask.
SN Length: значение длины, от 13 до 32 символов. Без опции Chk SN Len, жестко контролирующей длину указанного серийника, параметр SN Length ограничивает ваши аппетиты лишь по максимальной длине.
Т.е. символы AA и USBDEVRU остались, остальные произвольно сменились.
Объяснять процедуру изменения VID-PID, REV, VENDOR-PRODUCT нету особого смысла, лишь коротко поясню где что. Будем называть элементы SMI MPTool так, как это принято в приложении ChipGenius.
VID и PID и без меня понятно, вбиваем свои значения, если это того требуется.
(название в SMI MPTool) = (в ChipGenius)
USB Vendor Str = Device Vendor
USB Product Str = Device Name
Inquiry Vendor = Manufacturer
Inquiry Product = Product Model
bcdDevice – это ревизия (Revision), задаётся одно и тоже значение для Device Revision и Product Revision. При использовании других методов, можно менять их отдельно и поэтому в таблице я поставил МИНУС в соответствующей графе.
Является компактным портативным инструментом, который идеально подходит совсем неподготовленным юзерам.
Достаточно активировать снизу птички тех параметров, которые следует изменить и затем перебить их в верхней части программы.
К сожалению утилита устаревшая и несовместима с актуальными чипами. Предположительно работает с моделями не старше SMI SM3257AA, который с конца 2000-ых годов, днём с огнём не сыщешь.
К тому же не позволяет сменить серинный номер устройства, а это вполне существенный недостаток. Позволяет модифицировать следующие параметры: VID, PID, Device Vendor, Device Name, Device Revision, Manufacturer и Product Model.
Имеет куча особенностей и заковырок, советую обходить утилиты Dyna Mass Storage Production Tool стороной по возможности.
Для тех, кто как-то запорол флешку и хочет прошить её уже с нужными данными, покажу на скринах соответствующие пункты настроек программы.
: OpenCard Config :
: Device Config :
Учитывая то, что с DYNA-шитыми флешками вообще много проблем, лучшее для них решение будет ручное редактирование данных через инструмент SMI Debug.
Есть ещё такой вариант как использование утилиты SMI QCTool I1027, но это всё же слишком экзотический вариант.
Точно сказать не могу с какими моделями чипов совместима эта утилита, но уж точно мало с какими и все они старые. Например, совместима с моей флешкой на SMI SM3252C.
Рассматривать в данном материале вопрос применения приложения SMIQCTool мы не будем и вам не советую с ним связываться. Скажу лишь, что в графы Vendor, Product, Label находящиеся в главном окне утилиты, нужно вбить значения вашей флешки, чтобы она не выдавала красным цветом ошибки типа: Label error, SCSI Vendor error и SCSI Product error.
Ну и приведу пару скриншотов настроек утилиты, а дальше уже сами, если захотите.
Для детального рассмотрения вашей проблемы по смене серийника или любого другого параметра, перейдите пожалуйста на – ФОРУМ USBDEV .
Установка оборудования часто сопровождается трудностями. Больше всего времени занимает поиск драйвера для установки оборудования. В этот этап многие пользователи заходят в тупик – казалось бы, драйвер скачан с официального сайта производителя, но нет, они упорно не хотят устанавливаться.
Все дело в том, что одна и та же модель оборудования (например, веб-камера) на самом деле может быть собрана на совершенно разных микрочипах. А производитель иногда предоставляет программное обеспечение только для одного чипа.
В этом случае выручают драйвера от другого производителя схожего вида компьютерной периферии, или драйвера от производителя серии микросхем, на которых собрано оборудование.
Иногда нужно изменить драйвера под конкретное свое оборудование. Изменение драйвера сводится к редактированию файла сведений (это файлы с расширением *.inf) и последующей установки модернизированного драйвера.
Обычно нужно изменить или дописать только тот раздел файла *.inf, в котором перечисляются Коды экземпляров оборудования, поддерживаемые драйвером. Надо вписать ИД оборудования для своего устройства.
Рассмотрим наглядный пример (реальный случай был рассмотрен на Форуме). На ноутбуке eMachines E728 под Windows XP не устанавливается звуковая карта. Ид оборудования звуковой карты имеет вид:
Код:
HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025049B |
Поиск драйверов именно с точно таким же ИД не дал результатов. Но к счастью имеется драйвер звуковой карты Conexant от ноутбука eMachines D725, который поддерживает звуковые карты, у которых следующие Коды экземпляров:
Код:
HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250214 HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250215 HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250219 HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025021A HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025021C HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025021D HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250253 |
В ИД оборудования очень важна именно первая часть кода VEN_14F1&DEV_5051 , которая определяет производителя чипа и точную модель чипа. Как видно у найденного драйвера она совпадает с кодом звуковой карты.
Как изменить драйвер?
Для редактирования драйвера, все файлы должны быть распакованы в любую папку. Среди распакованных папок и файлов находим файл с расширением *.inf. В нашем случае – это файл WAUHER5a.inf.
Откроем его в обычном Блокноте для редактирования.
В начале файла увидим следующие строчки:
Код:
%HdAudioFunctionDriver.Hermosa5051.DeviceDesc% = HdAudModelSJ,HDAUDIO/FUNC_01&VEN_14F1&DEV_5051& SUBSYS_1025049B |
После этого файл WAUHER5a.inf сохраняем и устанавливаем только что измененный драйвер. Звук заработает!
Точно по такому же принципу можно редактировать драйвера для веб-камеры, видеокарты, модема и так далее. Но помните, что оно не гарантирует вам стопроцентного результата.
Установка оборудования часто сопровождается трудностями. Больше всего времени занимает поиск драйвера для установки оборудования. В этот этап многие пользователи заходят в тупик – казалось бы, драйвер скачан с официального сайта производителя, но нет, они упорно не хотят устанавливаться.
Все дело в том, что одна и та же модель оборудования (например, веб-камера) на самом деле может быть собрана на совершенно разных микрочипах. А производитель иногда предоставляет программное обеспечение только для одного чипа.
В этом случае выручают драйвера от другого производителя схожего вида компьютерной периферии, или драйвера от производителя серии микросхем, на которых собрано оборудование.
Иногда нужно изменить драйвера под конкретное свое оборудование. Изменение драйвера сводится к редактированию файла сведений (это файлы с расширением *.inf) и последующей установки модернизированного драйвера.
Обычно нужно изменить или дописать только тот раздел файла *.inf, в котором перечисляются Коды экземпляров оборудования, поддерживаемые драйвером. Надо вписать ИД оборудования для своего устройства.
Рассмотрим наглядный пример (реальный случай был рассмотрен на Форуме). На ноутбуке eMachines E728 под Windows XP не устанавливается звуковая карта. Ид оборудования звуковой карты имеет вид:
Код:
HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025049B |
Поиск драйверов именно с точно таким же ИД не дал результатов. Но к счастью имеется драйвер звуковой карты Conexant от ноутбука eMachines D725, который поддерживает звуковые карты, у которых следующие Коды экземпляров:
Код:
HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250214 HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250215 HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250219 HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025021A HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025021C HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_1025021D HDAUDIO/FUNC_01&VEN_14F1&DEV_5051&SUBSYS_10250253 |
В ИД оборудования очень важна именно первая часть кода VEN_14F1&DEV_5051 , которая определяет производителя чипа и точную модель чипа. Как видно у найденного драйвера она совпадает с кодом звуковой карты.
Как изменить драйвер?
Для редактирования драйвера, все файлы должны быть распакованы в любую папку. Среди распакованных папок и файлов находим файл с расширением *.inf. В нашем случае – это файл WAUHER5a.inf.
Откроем его в обычном Блокноте для редактирования.
В начале файла увидим следующие строчки:
Код:
%HdAudioFunctionDriver.Hermosa5051.DeviceDesc% = HdAudModelSJ,HDAUDIO/FUNC_01&VEN_14F1&DEV_5051& SUBSYS_1025049B |
После этого файл WAUHER5a.inf сохраняем и устанавливаем только что измененный драйвер. Звук заработает!
Точно по такому же принципу можно редактировать драйвера для веб-камеры, видеокарты, модема и так далее. Но помните, что оно не гарантирует вам стопроцентного результата.
Один из аргументов любителей Windows перед любителями Linux – недостаток драйверов для оборудования под эту ОС. С течением времени ситуация выправляется. Сейчас она уже гораздо лучше, чем 10 лет назад. Но иногда можно встретить какое-то устройство, которое не распознаётся вашим любимым дистрибутивом. Обычно это будет какая-нибудь USB-периферия.
Красота свободного софта в том, что эту проблему можно решить самостоятельно (если вы программист). Конечно, всё зависит от сложности оборудования. С трёхмерной веб-камерой у вас может и не получится – зато многие USB-устройства довольно просты, и вам не придётся нырять в глубины ядра или закапываться в С. В этом уроке мы с вами при помощи Python по шагам изготовим драйвер к игрушечной радиоуправляемой машинке.
Процесс по сути будет реверс-инженирингом. Сначала мы подробно изучим устройство, затем сохраним данные, которыми оно обменивается с драйвером в Windows, и попытаемся понять, что они означают. Для нетривиальных протоколов вам может потребоваться как опыт, так и удача.
Знакомство с USB
USB – шина с управлением хостом. Хост (PC) решает, какое устройство отправляет данные по проводам, и когда именно. Даже в случае асинхронного события (нажатие кнопки на клаве) оно не отправляется хосту сейчас же. Поскольку на каждой шине может быть до 127 устройств (и ещё больше, если через хабы), такая схема работы облегчает управление.
В проводах
USB-устройство можно рассматривать как набор конечных точек, или буферов ввода/вывода. У каждого есть направление данных (ввод или вывод) и тип передачи. По типам буферы бывают следующие: прерывания, изохронные, управляющие и пакетные.
Прерывания передают данные по чуть-чуть в реальном времени. Если пользователь нажал клавишу, устройство ждёт, пока хост не спросит «не нажимали ли там кнопочки?». Хост не должен тормозить, и эти события не должны потеряться. Изохронные работают примерно так же, но не настолько жёстко – они разрешают передавать больше данных, при этом допуская их потерю, когда это не критично (например, веб-камеры).
У любого USB-устройства есть буфер номер ноль – это конечная точка туннеля по умолчанию, который используется для управляющих данных. Но как хост узнаёт, сколько у устройства есть ещё буферов и какого они типа? Для этого используются разные дескрипторы, отправляемые по особым запросам по туннелю по умолчанию. Они могут быть стандартными для всех, особыми для конкретных классов устройств, или проприетарными.
Дескрипторы составляют иерархию, которую можно посмотреть утилитами типа lsusb. Наверху сидит дескриптор устройства, где содержится Vendor ID (VID) и Product ID (PID). Эта пара уникальная для каждого устройства, по ней система находит нужный драйвер. У устройства может быть несколько конфигураций, каждое со своим интерфейсом (например, принтер, сканер и факс в МФУ). Но обычно определяется одна конфигурация с одним интерфейсом. Они описываются соответствующими дескрипторами. У каждой конечной точки есть дескриптор, содержащий её адрес (число), направление (ввод или вывод) и тип передачи.
У спецификаций классов есть свои типы дескрипторов. Спецификация USB HID ожидает передачу данных в виде «отчётов», которые отправляются и принимаются по буферу управления или прерываний. Эти дескрипторы определяют формат отчёта (к примеру, «1 поле длиной 8 бит») и то, как его надо использовать («офсет в направлении Х»). Поэтому HID-устройство описывает само себя и его может поддерживать универсальный драйвер (usbhid в Linux). Иначе пришлось бы писать свой драйвер для каждой мыши.
Разбираемся с разрешениями
По умолчанию с USB-устройствами можно работать только из-под рута. Чтобы не запускать таким образом тестовую программу, добавим правило udev:
Под капотом
Машинка – это Device 036 (чтобы быть уверенным, её можно отсоединить и снова запустить lsusb). Поле ID – это пара VID:PID. Для чтения дескрипторов запустите lsusb -v:
Стандартная иерархия. Как и у большинства устройств, у неё только одна конфигурация и интерфейс. Можно заметить одну конечную точку interrupt-in (кроме точки по умолчанию 0, которая есть всегда, и поэтому не выводится в списке). Поле bInterfaceClass сообщает о том, что это устройство HID. Это хорошо – протокол общения с HID открыт. Казалось бы, прочтём дескриптор отчётов, чтобы понять их формат и использование, и дело в шляпе. Однако у него стоит пометочка ** UNAVAILABLE **. ЧЗН? Поскольку машинка – устройство HID, драйвер usbhid присвоил её себе, но не знает, что с ней делать. Надо отвязать его от управления ею.
Для начала надо найти адрес шины. Переподключим её, запустим dmesg | grep usb, и посмотрим в последнюю строчку, начинающуюся с usb X-Y.Z:. X, Y и Z – целые числа, уникальным образом определяющие порты на хосте. Затем запустим
1.0 – это конфигурация и интерфейс, которые должен отпустить драйвер usbhid. Чтобы подвязать всё обратно, запишите то же самое в /sys/bus/usb/drivers/usbhid/bind.
Теперь поле Report descriptor выдаёт информацию:
Задано два отчёта. Один читает с устройства (ввод), второй пишет (вывод). Оба размером в байт. Однако их использование не очевидно. Для сравнения, вот как выглядит дескриптор отчёта для мышки (не весь, но главные строчки):
Тут всё ясно. С машинкой – непонятно, и нам надо догадаться об использовании битов самостоятельно.
Небольшой бонус
Большинство радиоуправляемых игрушек просты и используют стандартные приёмники, работающие на одинаковых частотах. Значит, нашу программу можно будет использовать для управления другими игрушками, кроме этой машинки.
Работа для детектива
При анализе сетевого трафика используют снифер. И в нашем случае такая штука пригодится. Бывают специальные USB-мониторы для коммерческого использования, но для нашей задачи подойдёт и Wireshark.
Настроим перехват USB в Wireshark. Сначала разрешим мониторинг USB в ядре. Загрузим модуль usbmon:
Подмонтируем особую файловую систему debugfs:
Появится директория /sys/kernel/debug/usb/usbmon, которую можно использовать для записи трафика простыми средствами оболочки:
Там лежат файлы с загадочными именами. Целое число – номер шины (первая часть адреса шины USB); 0 означает все шины на хосте. s – statistics, t – transfers, u — URBs (USB Request Blocks логические сущности, представляющие происходящие транзакции). Чтобы сохранить все передачи на шине 2, введите:
Для нетренированного глаза тут ничего непонятно. Хорошо, что Wireshark будет декодировать данные.
Теперь нам нужна Windows, которая будет работать с оригинальным драйвером. Лучше всего установить всё в VirtualBox (с Oracle Extension Pack, поскольку нам необходима поддержка USB). Убедитесь, что VirtualBox может использовать устройство, и запустите KeUsbCar, которая управляет машинкой в Windows. Запустите Wireshark, чтобы посмотреть, какие команды драйвер отправляет на устройство. На первом экране выберите интерфейс usbmonX, где X – это шина, к которой подключена машинка. Если Wireshark запускается не из-под рута, убедитесь, что узлы /dev/usbmon* имеют соответствующие разрешения.
Нажмём в KeUsbCar кнопочку Forward. Wireshark перехватит несколько исходящих управляющих пакетов. На скриншоте отмечен тот, который нужен нам. Судя по параметрам, это запрос SET_REPORT (bmRequestType = 0x21, bRequest = 0x09), который обычно используется, чтобы изменить статус устройства – такого, как лампочки на клавиатуре. Согласно тому Report Descriptor, что мы видели, длина данных составляет 1 байт, и сам отчёт содержит 0x01 (также подсвечено).
Нажатие кнопки Right выливается в похожий запрос. Но отчёт уже содержит 0х02. Можно догадаться, что это означает направление движение. Таким же образом выясняем, что 0х04 – это правый реверс, 0х08 – задний ход, и т.д. Правило простое: код направления – это двоичная единичка, сдвинутая влево на позицию кнопки в интерфейсе KeUsbCar, если считать их по часовой стрелке.
Также можно отметить периодические запросы прерываний от Endpoint 1 (0x81, 0x80 означает, что это точка ввода; 0x01 это её адрес). Что это? Кроме кнопок, у KeUsbCar есть индикатор заряда, так что это, возможно, данные по батарее. Их значение не меняется (0х05), если машина не выезжает из гаража. В противном случае запросов прерываний не происходит, но они возобновляются, если мы ставим её обратно. Тогда, видимо, 0х05 означает «идёт зарядка» (игрушка простая, поэтому уровень зарядки не передаётся). Когда батарея зарядится, прерывание начнёт возвращать 0x85 (0x05 с установленным 7 битом). Видимо, 7 бит означает «заряжено». Что делают биты 0 и 2, которые составляют 0х05, пока неясно.
Пишем почти настоящий драйвер
Если у вас есть USB-сетевуха, можно использовать TUN/TAP для подключения программы PyUSB в сетевой стек Linux. Интерфейсы TUN/TAP работают как обычные сетевые, с именами типа tun0 или tap1, но через них все пакеты становятся доступны в узле /dev/net/tun. Модуль pytun делает работу с TUN/TAP простой. Быстродействие страдает, но можно переписать программу на С с использованием libusb.
Пишем код
Как нам работать в USB под Linux? Это возможно делать из пространства пользователя при помощи библиотеки libusb. Она написана на С и требует хороших знаний USB. Простая альтернатива – PyUSB. Для интерфейса пользователя я использовал PyGame.
Импортируем два главных модуля PyUSB и вставляем значения для управления машинкой, которые мы вычислили при просмотре трафика. VID и PID – это id машинки, взятые из вывода lsusb.
Мы отвязываем драйвер ядра, как мы делали в случае с lsusb. 0 – номер интерфейса. По выходу из программы его надо привязать обратно через release(), если он был активен. Поэтому мы запоминаем начальное состояние в self._had_driver.
Запускаем конфигурацию. Этот код эквивалентен следующему коду, который PyUSB скрывает от программиста:
Этот метод надо вызвать перед завершением программы. Мы отпускаем использовавшийся интерфейс и присоединяем драйвер ядра обратно.
direction – одно из значений, определённых в начале класса. ctrl_transfer() передаёт управляющие команды. Данные передаются как строка или как список. Возвращает метод количество записанных байт. Поскольку у нас всего один байт, мы возвращем True в этом случае, и False в ином.
Метод для статуса батареи:
Класс UI инкапсулирует интерфейс пользователя. Пройдёмся по основным вещам. Главный цикл находится в UI.main_loop(). Мы задаём фон с картинкой, показываем уровень заряда, если машинка в гараже, и рисуем кнопки управления. Затем ждём события – если это клик, то двигаем машинку в заданном направлении через USBCar.move().
Вся программа, включая GUI, занимает чуть больше 200 строк. Неплохо для устройства без документации.
Конечно, мы специально взяли довольно простое устройство. Но в мире есть довольно много схожих с нашим устройств, и многие используют протоколы, не сильно отличающиеся от того, что мы расковыряли. Реверс-инжениринг сложного устройства – задача непростая, но уже сейчас вы можете добавить в Linux поддержку какой-нибудь безделушки вроде устройства, сообщающего о полученном e-mail. Если это и не сильно полезно – то, по крайней мере, это интересно.
Читайте также: