usb-адаптер для передатчика
Так внятного обяснения состояния дел с лицензированием я не получил. Авторы сами понимают, что с этим дела у них обстоят не очень и тему эту задвигают (Говорят все Ок и не трогайте нас). Я так понимаю они собираются еще это использовать в коммерческих целях - вообще ужас. После этого как можно нормально продавать у нас ПО непонятно.
Я так понимаю они собираются еще это использовать в коммерческих целях - вообще ужас.
И вновь неправильно понимаете. Для коммерческого прибора данная реализация USB не годится ни с технической, ни с юридической точки зрения. Коммерческая версия была бы сделана по-другому.
И вновь неправильно понимаете. Для коммерческого прибора данная реализация USB не годится ни с технической, ни с юридической точки зрения. Коммерческая версия была бы сделана по-другому.
Так Вы все же признаете, что с лицензированием у Вас не все чисто?
Так Вы все же признаете, что с лицензированием у Вас не все чисто?
Извините, но это у Вас в голове не все чисто. Не надо путать авторские права и GPL. GPL и коммерческое использование не связаны НИКАК.
Все права на прототипы принадлежат их авторам и коммерческое использование запрещено авторами. Коммерческое использование нашего устройства также запрещено. Решение о публикации исходников мы вправе принимать любое, т.к. прототипы не подпадают под условия GPL. Если Вы с этим не согласны - жалуйтесь в FSF, но рекомендую предварительно еще раз изучить документ, на к-рый я ранее указал.
В последний раз прошу Вас прекратить крючкотворство. Лучше сделайте что-нибудь сами и опубликуйте.
Извините, но это у Вас в голове не все чисто
…
Не надо путать авторские права и GPL.
Можно узнать где я спутал два этих понятия?
прототипы не подпадают под условия GPL
Как раз в условия попадают, а значит и на все, что созданно на их основе.
“0. Настоящее Соглашение распространияет свое действие на любую программу или другое произведение, которое содержит данное правообладателем уведомление о том, что ее (его) использование осуществляется на основании Открытого лицензионного соглашения GNU.”
жалуйтесь в FSF
Может еще в спортлото отошлете - там уж я точно правду найду.
В последний раз прошу Вас прекратить крючкотворство
“Крючкотворством” занимаетесь Вы - выдумывая способы обойти Лицензию.
Я очень симпатизирую сообществу OpenSource и поэтому Ваши “шаманства” с лицензированием вызывают во мне искренее недовольство.
alkot, его вы добиваетесь-то? текстов программ вы все равно не получите. 😃 скорее vad64 спишется с автором и получит от него “эксклюзивные права”, а именно разрешение не давать вам лично никаких своих исходников. 😃 а позаимствованный из оригинального проекта код - да сколько угодно! 😁
Я очень симпатизирую сообществу OpenSource и поэтому Ваши “шаманства” с лицензированием вызывают во мне искренее недовольство.
Бесплатный сыр только в мышеловке. И достается он _второй_ мышке. Вы тянете пока тоьлко на первую. На ту самую, которой вместо сыра достанется по горбушке.
Умейте ценить чужую собственность и права на неё. Будьте благодарны за представленный готовый продукт. Хочется большего - родите свое. Захотите поделится плодами своего труда - честь вам и хвала. Кстати, тот-же Миндаугас не торопится выкладывать исходники на MJoy16. готовую прошивку, схему - велком, а вот исходники - увольте. Может, сначала там покачаете сомнительные права?
Все, заканчиваем флуд и оффтопик. Хочется потрещать неочем - есть для этого официальная сральня - www.udaff.com
Мы по-моему все здесь собрались для того чтобы эксперементировать, не так ли?.. А Вы к сожалению лишаете такой возможности. 😕
В данном случае, как мне кажется, копирайт есть лишь повод поднять разговор о недоступности исходников для эксперимента.
Увидев на этом сайте превосходную идею реализации конвертора в виде стандартного HID-устройства, я был очень рад, так как самому хотелось сделать что-то такое, но ход всё никак не доходил. А использовать самописанные драйвера для виндов мне не очень нравится, если можно обойтись стандартными. Приятель собрал это устройство, и оно реально работает. Исходников - да, их нет. Но зато есть ссылки, по которым легко попадаешь на страницы Игоря (написавшего базовый USB стек для меги), на чешский проект, реализующий конвертер со специальными драйверами для виндов, на литовский проект MeanDog’а, реализующий поддержку HID.
Исходник версии на меге8 последнего доступен и открыт (хотя проект получил развитие на меге16 с уже закрытыми исходниками в сторону расширения числа линий ввода-вывода - используется пилотами “взрослых” самолетных симуляторов). Текст прекрасно прокомментирован, поддержка USB и HID вынесена отдельно и сопровождается инструкциями автора по модификации дескрипторов (для изменения параметров обнаруживаемого устройства по части кнопок, хаток и ручек). Заменить фрагмент чтения АЦП на чтение значений таймера через Input Capture - элементарная задача пары часов для того, кто способен заняться более-менее серьезными экспериментами с кодом (не считаю таковыми правку имени устройства или Vendor ID).
Так что я лично не пойму предмета разговора. Если это - вопросы сугубо копирайта - то их стоит обсуждать не в этом форуме. Если это - невозможность провести эксперименты, то это не так. Все ссылки есть, и дописано в конкретной прошивке по отношению к первоисточникам, в принципе, совсем немного: маппинг каналов в NVRAM. Так что никто не мешает экспериментировать. Например, перенести код в небольшой 8-ножный чип (2 ноги - питание, 2 кварц, 2 USB, 1 вход PPM/PCM, 1 выход на светодиод, например, как индикатор наличия сигнала с передатчика при подключенном устройстве.
Это было бы более рациональным применением усилий, IMHO 😃
PS. Сам вчера завел литовский джойстик, сегодня займусь модификациями прошивки для своих задач.
(не считаю таковыми правку имени устройства или Vendor ID).
Подскажите чайнику где в Atmega8 эти самые имя и Vendor ID?
Подскажите чайнику где в Atmega8 эти самые имя и Vendor ID?
Они не в атмеге, а в исходных текстах USB-драйвера. Сообщаются виндам при подключении, и те уже потом ищут в своей базе подходящий драйвер. Если не находят, то или ставят стандартный для HID (если устройство сделано под HID), или просят указать, где брать драйвер.
Они не в атмеге, а в исходных текстах USB-драйвера.
Что-то вы путаете. Все эти параметры сообщает само устройство в дескрипторах. Драйвер USB лишь расшифровывает дескрипторы. Если мы говорим о джойстиках (тем более о том, про который статья), то все это - устройства HID, которые сами о себе все сообщают. С другими USB девайсами ситуация может быть другой.
В самой атмеге никаких (“аппаратных”) usb причиндал нет, вся реализация программная. Следовательно и все что к usb относится находится в прошивке, начиная от самого низкого уровня взаимодействия с usb хостом и более высокие уровни, включая самый верхний - hid.
Если не находят, то или ставят стандартный для HID (если устройство сделано под HID), или просят указать, где брать драйвер.
Уточню. Чтобы устройство опозналось как HID оно обязано сообщить о себе “я устройство HID”, передав соответствующие HID-дескрипторы. В HID-дескрипторах содержится название устройства которое выводится в менеджере устройств. Просто абстрактное USB устройство никогда не опознается драйвером HID. С другой стороны, на то оно и HID устройство, чтобы работать без специального драйвера.
Что-то вы путаете. Все эти параметры сообщает само устройство в дескрипторах. Драйвер USB лишь расшифровывает дескрипторы.
Уточню на всякий случай, что я рассматриваю устройство, собранное на ATmegaXX не как черный ящик, а как микроконтроллер, работающий по своей программе. Соответственно, с этой стороны тоже имеет место USB драйвер (программно реализующий поддержку интерфейса, так как аппаратного там на самом деле нет), и приложение, управляющее работой этого драйвера. И дескрипторы (см. ниже).
Следовательно и все что к usb относится находится в прошивке, включая самый низкий уровень взаимодействия с usb хостом и более высокие уровни, включая самый верхний - hid.
Собственно, я это почти дословно и сказал: что VID находится не в меге (как железке), а в “исходных текстах USB-драйвера”, который после компиляции, конечно же, находится внутри меги, но более конкретно - это часть ее прошивки, а не принадлежность кристалла.
Можно спорить, следует ли считать USB дескрипторы частью драйвера или нет. С одной стороны, драйвер - это собственно код, а дескрипторы - часть приложения (работающего в меге) и использующего драйвер для обмена этими дескрипторами с хостом. С другой - можно условно отнести дескрипторы к тому же драйверу, поскольку с точки зрения того, кто кодом приложения считывает и обрабатывает PPM сигнал, формат выдачи его один раз забит и больше не меняется. Потому иногда просто удобнее логически отнести дескрипторы в кучу к драйверу (как физического уровня - bit-banging, так и логического - поддержка протокола обмена). Первый вариант интерпретации корректнее, второй - удобнее в данном конкретном случае.
Чтобы устройство опозналось как HID оно обязано сообщить о себе “я устройство HID”, передав соответствующие HID-дескрипторы. Просто абстрактное USB устройство никогда не опознается драйвером HID.
Похоже, моя фраза была прочитана не очень внимательно. Читаем еще раз вместе:
vid/pid… сообщаются виндам при подключении, и те уже потом ищут в своей базе подходящий драйвер. Если не находят, то или ставят стандартный для HID (если устройство сделано под HID), или просят указать, где брать драйвер.
Имелось в виду следующее:
- при подключении устройство определяется как USB устройство, сообщает свои vid/pid и прочую информацию (это написано).
- по vid/pid Windows ищут в базе драйвер конкретного устройства, если таковой присутствует в системе. Если он найден, то он будет использован (это тоже написано).
- если специфического драйвера для конкретного устройства с заданным vid/pid в системе нет, то Windows пытается установить универсальный драйвер для класса устройств, к которому отнесло себя устройство в своем дескрипторе. Это может быть HID (Human Interface Devices), это может быть MSD (Mass Storage Device - пресловутые USB-диски, например), и т.п.
- Если устройство не относится к стандартным классам, то тогда будет востребован драйвер производителя.
Если прочитать выделенное мною сейчас, то понятно, что речи не шло об абстрактном устройстве с драйверами Windows под HID. Речь шла о HID устройстве (о чем говорит замечание в скобках). А еще о том, что при наличии драйвера конкретного (vid/pid) устройства он всегда имеет более высокий приоритет, чем драйвер универсальный. Приходилось получать от Windwos сообщение типа “Найден более подходящий драйвер для данного устройства”? Вот это оно и есть.
Говоря же о приоритете установки драйверов, приведу пример адаптера из Reflex. Это HID устройство, которое ставится в Windows и работает прекрасно, как стандартный HID, и пишется про него как HID-совместимый USB девайс. Но если поставить драйвер из состава симулятора (правда, в частном случае это всего лишь способ переименовать устройство в панели управления), то стандартное устройство будет использовать в данном случае название - REFLEX RC USB Device, а в общем оно может использовать свой специфический драйвер вместо предоставленного Windows. А может работать поверх предоставленного Windows, подставляя свои фильтры. И т.п. Вариантов множество.
Отвечая, я не ставил задачи излагать взаимодействие устройств максимально подробно и максимально формально - это не форум разработчиков USB девайсов, потому такие беседы лучше вести в другом месте. Но поверьте: я прекрасно представляю взаимодействие всех уровней обмена со всех сторон, так как электроникой и системным программированием под embedded системы занимаюсь уже лет 20. И прежде, чем получить свой работоспособный вариант подобного устройства, кстати, на 70% написанный на C (ассемблерные только time-critical участки, весь application layer, включая десприпторы - C), я перечитал не одну спецификацию c usb.org, включая HID1_11.pdf, Hut1_12.pdf, hidpar.pdf, pid1_01.pdf (не считая популярных книжек типа usb-in-a-nutshell.pdf). А потому представляю, для чего нужен каждый байт кода (исключая только самый нижний уровень, так как это уже отлаженная часть, которая поменяется только вместе со стандартом). Просто нужно ли все это тут? Место ли этому здесь?
В общем, спорить не стану (особенно с членом группы модераторов 😃 ). Мой девайс прекрасно работает, и делался он не с наскока, а с пониманием. Править байтики и гадать, от чего не работает - я так не умею. Да и никому не советую. RTFM полезен. Да и не то место тут - обсуждать особенности реализации USB. Тут народ летает большей частью, чем firmware пишет 😉
Соответственно, с этой стороны тоже имеет место USB драйвер (программно реализующий поддержку интерфейса, так как аппаратного там на самом деле нет), и приложение, управляющее работой этого драйвера.
Путаница в терминологии. Вы называете это “драйвером”, хотя это по сути библиотека. Вот и все непонимание. Я так понял, что вы говорите о драйверах со стороны хоста.
А еще о том, что при наличии драйвера конкретного (vid/pid) устройства он всегда имеет более высокий приоритет, чем драйвер универсальный.
Да, это так. Но только если они, по мнению windows, оба подходят.
Это HID устройство, которое ставится в Windows и работает прекрасно, как стандартный HID, и пишется про него как HID-совместимый USB девайс.
Название самого устройства (в частности, если это именно HID) тоже присутствует. Следовательно, если мы говорим о HID, то все что надо там есть. Впрочем, ничто не мешает нам написать свой драйвер, который будет сообщать другое имя (или подставлять его, вместо пустого). Равно как и драйвер, который будет вообще полностью эмулировать девайс.
В общем, спорить не стану (особенно с членом группы модераторов 😃
Я не спорил, я лишь попытался уточнить.
Путаница в терминологии. Вы называете это “драйвером”, хотя это по сути библиотека.
Тогда путаница есть, поскольку под драйвером обычно (в классическом понимании со времен зарождения компьютеров) понимается часть программного кода, непосредственно взаимодействующая с неким аппаратным устройством с одной стороны, и определяющая некий программный интерфейс для прикладной программы - с другой. То есть, назначение данного кода.
Драйверы Windows к этому отношение имеют лишь косвенное. Там понятие драйвера трактуется слишком широко. Драйвером называют даже простейший inf файл, который не является таковым, а служит для управления работой некоего системного драйвера.
А библиотека - это метод организации кода в многократно используемую единицу в разных проектах. Тем более, что то, в каком виде оно присутствует, библиотекой назвать язык не поворачивается. Не структурировано, не документировано, практически, не подлежит сопровождению. Но, правда, работает 😃
Я так понял, что вы говорите о драйверах со стороны хоста.
Я тоже так понял, что вы так поняли 😃 Отсюда и оговорка первой строчкой ответа о том, что имелись в виду драйверы со стороны контроллера.
Да, это так. Но только если они, по мнению windows, оба подходят.
Именно так.
Название самого устройства (в частности, если это именно HID) тоже присутствует. Следовательно, если мы говорим о HID, то все что надо там есть.
Но не все так просто. HID устройство (да и не HID тоже) при первом подключении говорит о себе, как оно называется, может сообщить производителя, серийный номер и т.п. Но после установки стандартного драйвера HID со стороны Windows эта информация скрывается, и ее можно увидеть лишь в свойствах. Например, размещение - Remote Controller. Но в панели стоит не Remote Controller, а HID-совместимое устройство. Если это джойстик, то будет вторая строка - стандартный игровой манипулятор (или что-то в том духе - точно не помню, под рукой нет). В панели игровых манипуляторов при этом будет или MJoy (на Windows Server 2003), или просто “игровой джойстик с X осями и Y кнопками” (на XP). Более того, Windows кеширует эту фигню. Найдя один раз джойстик с 8 осями и 24 кнопками, винда запоминает это (показывая в панели игровых манипуляторов), и потом без смены vid/pid поменять это не удается. Делаешь 2 оси, включаешь - в панели джойстиков по прежнему будет 8, хотя нажатие на него для проверки или калибровки показывает фактическое количество осей. Удалить его из панели джойстиков невозможно (используйте Device Manager). Удалить из последнего можно, потом устройство будет находиться заново. Но в панели игровых устройств оно по прежнему предстанет как 8-осевое. Удалить кэш из реестра тоже не получается - эта область защищена.
В общем, есть где повеселиться. При всем этом предоставление inf-файла, подобного рефлексовскому, реально переименовывает устройство в Device Manager. Теперь это уже не HID-совместимое устройство, а конкретно названное. Вот цитата на эту тему из еще одной статьи:
Менеджер устройств ОС Windows использует .inf файлы, чтобы решить, какой драйвер назначить найденному устройству. HID устройство может использовать встроенный в OS .inf файл для HID (hiddev.inf для Windfows 98 и input.inf для Windows 2000), альтернативно, Вы можете использовать свой собственный .inf файл, в котором находятся ваши VID и PID. Преимущество собственного .inf файла состоит в том, что Вы можете включить в файл описание устройства и имя изготовителя, которые появятся на Панели Управления вместо общего термина “Стандартное Устройство”.
Впрочем, ничто не мешает нам написать свой драйвер, который будет сообщать другое имя (или подставлять его, вместо пустого). Равно как и драйвер, который будет вообще полностью эмулировать девайс.
Написать-то можно (и тогда достаточно инф-файла для первого случая - сообщить просто имя). Но вот сообщить имя HID-устройства самим устройством, увы, не получится (это будет только в информации о размещении устройства в его свойствах). Об этом пишется в каждом документе по разработке HID-устройств. Почему так сделали - не знаю.
Я не спорил, я лишь попытался уточнить.
Да я, собственно, тоже 😛
Удалить его из панели джойстиков невозможно (используйте Device Manager). Удалить из последнего можно, потом устройство будет находиться заново. Но в панели игровых устройств оно по прежнему предстанет как 8-осевое. Удалить кэш из реестра тоже не получается - эта область защищена.
Достаточно в регедите удалить ключ HKLM\SYSTEM\CurrentControlSet\Enum\USB\Vid_xxxx&Pid_xxxx
Если ругается, то нужно просто в меню “Разрешения” задать полный доступ к разделу USB и его подразделам. А то при отладке замучаешься VIDы PIDы менять.
Да, я тоже так подумал, что надо просто вместо regedit пользовать regedt32 для установки разрешений, но сильно не доставало, и пока оставил эту тему.
Обычно когда я что-то пишу, или отлаживаю, или изучаю чужой код в познавательных целях 😃, я делаю это внутри виртуальных машин VMware, где можно за пару секунд откатить состояние системы назад. Для USB это тоже работает, но не очень удобно. Потому плюнул на это и стал ставить на основную машину. Менять пиды-виды для устновки - не только задолбает, но и систему загадит 😊
А с виртуалками стало совсем удобно после того, как NuMega SoftICE стал поддерживать экранный драйвер виртуальной машины. Можно делать двухмашинные конфигурации с программой в одном месте, интерфейсом отладчика в другом. И все это - не затрагивая хоста. Очень неплохо. Связь между машинами - или по tcp/ip, или через виртуальные комы. Но это уже совсем другая тема.
Тогда путаница есть, поскольку под драйвером обычно (в классическом понимании со времен зарождения компьютеров) понимается часть программного кода, непосредственно взаимодействующая с неким аппаратным устройством с одной стороны, и определяющая некий программный интерфейс для прикладной программы - с другой. То есть, назначение данного кода.
Суть драйвера - модульность. То есть возможность работы с разными устройствами по стандартному интерфейсу без перекомпиляции самого приложения. В нашем конкретном случае все компилируется в единый и неделимый модуль. С таким же успехом можно называть функции вывода на экран “драйвером ЖКИ”, функции генерации писков разной тональности пищалки “звуковым драйвером” и так далее. 😃
Написать-то можно (и тогда достаточно инф-файла для первого случая - сообщить просто имя). Но вот сообщить имя HID-устройства самим устройством, увы, не получится (это будет только в информации о размещении устройства в его свойствах). Об этом пишется в каждом документе по разработке HID-устройств.
Не имеет значения как это показывается в виндах. Важно лишь то, что получает приложение которое работает с этим устройством через setupapi и hidapi. Через hidapi оно получает именно то, что сообщает о себе само устройство.
Суть драйвера - модульность. То есть возможность работы с разными устройствами по стандартному интерфейсу без перекомпиляции самого приложения.
Слова “без перекомпиляции самого приложения”, пожалуй, лишние, хотя часто это именно так. Возможно, это многим не авторитет, но смотрим в Wiki:
Операционная система управляет некоторым «виртуальным устройством», которое понимает стандартный набор команд. Драйвер переводит эти команды в команды, которые понимает непосредственно устройство. Эта идеология называется «абстрагирование от аппаратного обеспечения».
В данном случае мы имеем то самое абстрагирование. Нас не интересует, через какие порты и биты происходит обмен, какие временные диаграммы там формируются, и т.п. Интересует факт: через некий определенный интерфейс мы общаемся с хостом. Если мы заменим порты, биты, скорость обмена (low-speed на full-speed, к примеру) и т.п., взаимодействие основной части приложения с этой частью не изменится. Потому этот кусок вполне можно считать драйвером.
В данном варианте абстрагирование реализовано плохо. Есть много зависимостей, которые надо учитывать. Но это же не единственный вариант, есть и альтернативные.
Да, у нас нет семейства USB (хотя при наличии аппаратной поддержки в какой-нибудь меге можно представить себе драйвер для нее, сохраняющий тот же интерфейс). Но нет - не значит, что не может быть.
В нашем конкретном случае все компилируется в единый и неделимый модуль.
Увы, но драйвер не обязан быть подгружаемым динамически. Это может быть и часть единого неделимого модуля, в частном случае.
С таким же успехом можно называть функции вывода на экран “драйвером ЖКИ”
Можно посмеяться, но ведь так это и называется у разработчиков embedded устройств. Стоит взять любую библиотечку функций, например, бесплатную avrlib, в которой смотрим:
/*! \file ata.c \brief IDE-ATA hard disk interface driver. */
Это же не значит, что там обязательно будет 10 вариантов дисковых накопителей? Кстати, файл действительно содержит несколько функций, и не более того. А из чего еще обычно состоят драйверы, как не из набора функций?
/*! \file lcd.c \brief Character LCD driver for HD44780/SED1278 displays. */
/*! \file ks0108.c \brief Graphic LCD driver for HD61202/KS0108 displays. */
А в коммерческой аналогичной библиотеке исходники строятся по принципу: один файл с интерфейсом, и десяток файлов с конкретными (да-да) драйверами разных типов контроллеров LCD.
Самое интересное: неужели действительно кто-то полагает, что файлы lcd.c и ks0108.c буду присутствовать в одной системе? Скорее, там будет или символьный дисплей, или графический. И это будет единым неделимым модулем в составе прошивки. Лишает ли это права называть набор функций управления конкретным типом дисплея, абстрагирующим основной код от аппаратуры, драйвером? Вероятно, нет.
функции генерации писков разной тональности пищалки “звуковым драйвером” и так далее. 😃
/*! \file uart.c \brief UART driver with buffer support. */
Тут также может быть вариант без буфера с тем же интерфейсом. И в коде будет или тот, или иной, но не оба вместе.
Если это не разбросанные по всему коду приложения функции, а собранные в одном месте, связанные друг с другом по смыслу, управляющие одним аппаратным устройством, то почему бы и не назвать? Тем более, что все так и называют 😃
Заблуждение в том, что если похожих по назначению устройств и работающих с ними кусков кода много, то это будут драйверы (особенно, если они загружаются, а не собраны в единую неделимую прошивку). А вот если такое же устройство (пока?) всего одно, то точно тому же куску почему-то отказано в праве называться драйвером. Как-то не очень логично.
Разговор перешел на идеологическую тему 😃. Это, может, и интересно, только времени отнимает немеряно. Так что я согласен, пусть я даже буду неправ 😃. В конце концов, как не назови этот кусок кода - он все равно будет выполнять свои функции.
Не имеет значения как это показывается в виндах. Важно лишь то, что получает приложение которое работает с этим устройством через setupapi и hidapi. Через hidapi оно получает именно то, что сообщает о себе само устройство.
Смотря к чему. Если это сказано к вопросу о том, можно ли в принципе приложению прочитать название устройства - то да, можно. Если к тому, о чем шла речь - как это устройство показывается в Windows для обычного пользователя, а не девелопера, со стандартными HID драйверами - то тогда нельзя. Может, стандартный драйвер не использует какие-либо доступные функции - не знаю. Но вот некоторым известным симуляторам, к примеру, использующим стандартный HID-драйвер Windows для своих адаптеров, и не использующих никаких DirectInput API или HID API, совершенно пофигу, какие там функции стандартный виндовый драйвер использует. Они видят устройство по VID/PID, и работают с ними на уровне ReadFile, читая байты репорта, но даже не заглядывая в ReportDescriptor (зная, что там заведомо лежит). Ну, а пользователь без установки inf-файла про это даже не подозревает, но видит “стандартное устройство”. А для красоты можно поставить .inf и увидеть, что это супер-пупер-мега-девайс 😃
Спасибо за участие в обсуждении. Пожалуй, дальше нет смысла обсуждать. Пусть каждый сам себе решает, что называть драйвером 😜
Они видят устройство по VID/PID, и работают с ними на уровне ReadFile, читая байты репорта, но даже не заглядывая в ReportDescriptor (зная, что там заведомо лежит).
Так или иначе, но без SetupApi все равно не обойдешься. Хотя бы для получения имени файла устройства. А уж проверять имя или нет - дело софта.
ps: Хотите называть драйвером - называйте. Но тогда поясняйте какой “драйвер USB” вы имеете в виду, их как минимум два по вашей терминологии. Я лично предпочитаю называть драйвером компоненты какой бы то ни было операционной стстемы. Считаете прошивку операционной системой? Ваше право.
Так или иначе, но без SetupApi все равно не обойдешься. Хотя бы для получения имени файла устройства. А уж проверять имя или нет - дело софта.
Говорим о разном. Я о том, что видно в Windows без драйверов про HID-устройство, и можно ли как-то добиться отображения собственного названия без написания .inf. Ну а Вы - о чем-то ином.
ps: Хотите называть драйвером - называйте. Но тогда поясняйте какой “драйвер USB” вы имеете в виду, их как минимум два по вашей терминологии.
Драйвер - это фрагмент кода, предоставляющий прикладной программе или операционной системе набор функций по работе с неким аппаратным (или даже не аппаратным а, к примеру, симулируемым) устройством и ограждающий прикладную программу от знания конкретных особенностей взаимодействия с конкретной аппаратурой.
Драйвер может быть загружаемым как динамически, так и статически слинкованным в единый исполняемый модуль. Драйвером, как совокупностью связанных функций, он является с точки зрения программиста, а не того, где в итоге он размещается.
Какие-либо табличные данные, драйвером используемые, могут быть не связаны с конкретным приложением, использующим интерфейсы драйвера. В этом случае логично отнести эти внутренние данные и таблицы к самому драйверу. Альтернативно некая часть данных или таблиц может быть доступна приложению или предоставляться приложением для вызова функций драйвера. В этом случае логично отнести эту часть данных к самому приложению.
В конкретном случае device descriptor - это, скорее, часть драйвера, так как раз написанная, уже не меняется (с точностью до названия устройства и видов-пидов). Report descriptor - это, скорее, часть приложения, поскольку драйверу все равно, что в нем находится, а приложение форматирует свои данные в соответствии с этой таблицей.
Я лично предпочитаю называть драйвером компоненты какой бы то ни было операционной стстемы.
Если Вы работаете с операционными системами типа Windows, Unix или т.п., то это вполне понятная причина такого представления, поскольку в них это обстоит почти так. Почти - поскольку в том же Unix классически драйверы необходимых в конкретной аппаратной конифгурации устройств входили в состав скомпилированного ядра, а сборка ядра была первой процедурой, производимой после начальной установки стандартного ядра. И то, что они были слинкованными, не мешает называть их во всей литературе драйверами внутри собранного ядра. И только позже во всяких линуксах появилась возможность загружать драйверы на лету, как и выгружать их.
Если бы Вы были ембеддерщиком, то Ваше понимание драйверов бы соответстовало моему. У меня же оно таково, поскольку я начинал работать с компьютерами, которые занимали целый зал, и там была очень тесная связь с аппаратным обеспечением. По сути, это было близко к современным embedded системам. О динамическом подключении устройств типа нынешнего USB тогда даже и не мечтали. Это просто классическое понимаение драйвера.
Считаете прошивку операционной системой? Ваше право.
Я всего лишь привел цитату из онлайновой энциклопедии, которую не имел права править или дополнять. Не всякую прошивку можно считать операционной системой. Но неоспоримым фактом является то, что во многих прошивках используются т.н. RTOS - Real-Time Operating Systems, операционные системы реального времени. В том числе и на AVR таких существует больше десятка. То, что данные RTOS работают в составе единого неделимого кода прошивки, опять же не лишает их права называться RTOS. Или Вы и в этом готовы усомниться (утверждая, что операционных систем внутри прошивок не существует, поскольку это неделимый код)? Ссылки приводить, или не нужно? Впрочем, вот первый же поиск дал такую ссылку. На деле их крайне много, несколько десятков. Вот еще одна… Я использую в своих устройствах третью… И т.д.
PS. Вы - не embedded system programmer, не так ли?
Господа!
Я конечно сильно извиняюсь, но с обсуждением статьи о USB-Aдаптере Ваше мерянье у кого кунфу круче и партбилет краснее имхо ничего общего уже не имеет.
С уважением 