Comments 67
В исходнике также сказано, что USB-IF выдает VIDы для использования в прототипах (но не сказано, на каких условиях).
Давно уже эта тема. Один парень, занимающийся встраиваемыми системы и имеющий на то время популярный блог/сайт, продавал по 5$ PID. После распространения этой практики, USB.org изменила правила использования, которые теперь запрещают продавать или сдавать в аренду PID/VID. Кто-то, если не изменяет память, сумел отстоять свое право использования купленного PID, так как правила изменили после того, как была совершена покупка.
Нашел страничку, но она уже устаревшая www.voti.nl/pids/pidfaq.html
Тут вроде как по прежнему продают.
Интересный момент — USB.org отозвал VID у магазина, однако, дать его кому-то другому уже не может, т.к. это создаст возможность коллизии.
Интересный момент — USB.org отозвал VID у магазина, однако, дать его кому-то другому уже не может, т.к. это создаст возможность коллизии.
КО считает необходимым пояснить, что значение 0xF055 обозначает FOSS на литспике.
В принципе для энтузиастов с десятком-сотней приборов есть FTDI чип с единым VID&PID
На первом прототипе устройства использовали FT232H, также время от времени пользую хвосты USB-RS485 и USB-RS232, оба также с этим чипом. Неудобство «единого» VID&PID почувствовал в полной мере.
У FTDI есть возможность изменить VID/PID и серийный номер, подключив внешнюю EEPROM-ку.
Как-то мы нарвались на покупное устройство сделанное на какой-то FTDI-ке, где разработчики додумались разработать свой драйвер и оставить стандартные VID/PID. Если бы не возможность изменить его PID — на рабочем компе использовать сие поделие было бы невозможно.
Как-то мы нарвались на покупное устройство сделанное на какой-то FTDI-ке, где разработчики додумались разработать свой драйвер и оставить стандартные VID/PID. Если бы не возможность изменить его PID — на рабочем компе использовать сие поделие было бы невозможно.
USB это не только CDC класс
Как их ещё земля носит
Автор, привидите, пожалуйста, хотя бы одного производителя микроконтроллеров/процессоров с интерфейсом USB, который не раздает PIDы по запросу всем нуждающимся?
Если посмотреть на любые китайские поделки с USB и индивидуальными драйверами, то можно увидеть выдуманные VID/PID типа 0xFFFF, 0x0001, 0x2013 и так далее. А так, вероятность коллизии очень маленькая с учетом того, что USB устройств не так уж и много на одном компьютере.
А как Вы представляете себе возможность автодетекта устройства тогда? Снова probing делать, да? Вручную устанавливать драйверы?
Разве я к этому призываю? Я просто констатирую факт, что многие (китайские) производители экономят на вступлении в секту USB.org. Но, например, для HID может подойти и стандартный драйвер и какой там VID/PID уже не так важно.
Кроме кодов производителя и продукта есть еще текстовые поля. По ним вполне можно идентифицировать устройство.
По крайней мере usb_modeswitch так и делает для usb- модемов, имея у себя в базе дублирующиеся коды устройств:
По крайней мере usb_modeswitch так и делает для usb- модемов, имея у себя в базе дублирующиеся коды устройств:
05c6:1000:sVe=GT
05c6:1000:sVe=Option
05c6:1000:uMa=AnyDATA
05c6:1000:uMa=CELOT
05c6:1000:uMa=DGT
05c6:1000:uMa=Option
05c6:1000:uMa=Qualcomm
05c6:1000:uMa=SAMSUNG
05c6:1000:uMa=SSE
05c6:1000:uMa=Vertex
Подробный обзор проблемы (англ):
www.youtube.com/watch?v=1pegVYODsn4
www.youtube.com/watch?v=1pegVYODsn4
поскольку отдельные производители USB-устройств (вроде Microchip или FTDI) раздают некоторое количество своих USB PID бесплатно...
Только сегодня возникла проблема присвоения VID/PID для разрабатываемого устройства, и тут как тут данная информация. Спасибо большое!
Поддержка FTDI ответила оперативно:
Dear Sir,
We have allocated 8 PIDs to you from 7D70 to 7D77 (hex).
The PIDs must be used with VID 0403.
www.lpcware.com/content/project/usb-vid-pid-program у NXP Semicondutor есть похожая програма. Встречал ещё других производителей, но сейчас не вспомню.
Просто интересно, а есть реальная необходимость в VID/PID, если даже зная их, не всегда получается идентифицировать устройство и найти софт к нему? Ну и у многих устройств типа флэшек VID/PID легко меняются и мало чего дают.
Я где-то раньше читал статью об аналогичной истории с продажей блоков MAC-адресов соответствующим комитетом. Некая фирма купила блок и стала продавать на сторону его части — в результате у этой фирмы блок отозвали, и она была вынуждена уйти из бизнеса.
Подобные схемы продажи номеров создаются специально. Зарезервировали всего 16 бит на USB VID — и в результате для избежания коллизий приходится поддерживать глобальную базу данных. Если бы зарезервировали 128 бит — получился бы GUID, вероятность коллизии которых настолько мала (2^-128), что использование какого-то комитета для раздачи номеров не требуется.
Но если бы USB-IF зарезервировал для VID 128 бит — то не было бы возможности зарабатывать деньги из воздуха.
Подобные схемы продажи номеров создаются специально. Зарезервировали всего 16 бит на USB VID — и в результате для избежания коллизий приходится поддерживать глобальную базу данных. Если бы зарезервировали 128 бит — получился бы GUID, вероятность коллизии которых настолько мала (2^-128), что использование какого-то комитета для раздачи номеров не требуется.
Но если бы USB-IF зарезервировал для VID 128 бит — то не было бы возможности зарабатывать деньги из воздуха.
А зачем вообще нужны VID/PID? Разве USB-устройство не само сообщает то, что оно умеет? Или просто «исторически сложилось, что драйвера привязываются к VID/PID»?
Если коротко — то есть так называемые «class devices» или «class-compliant devices», которые делают какую-то более-менее общеупотребительную вещь и работают по стандартизированным на уровне USB протоколам (например, hub, mass storage, HID, CDC и т.п.). Для поддержки такого устройства, вообще говоря, годится стандартизированный же драйвер и все хорошо.
А еще есть туча более специфичных устройств (например, управления каким-нибудь двигателем), который, может быть, с точки зрения низкого уровня и работают по примерно тому же принципу — скажем, последовательно передают байты — но на верхнем уровне требуют различать — какое из подключенных устройств «просто принимающих/передающих байты» именно «то самое», которые отвечает за двигатель. В этом случае в 99% используют именно привязку к VID/PID.
А еще есть туча более специфичных устройств (например, управления каким-нибудь двигателем), который, может быть, с точки зрения низкого уровня и работают по примерно тому же принципу — скажем, последовательно передают байты — но на верхнем уровне требуют различать — какое из подключенных устройств «просто принимающих/передающих байты» именно «то самое», которые отвечает за двигатель. В этом случае в 99% используют именно привязку к VID/PID.
А разве нет какого нить «Custom USB Class device», которая говорит что использует «кастом протокол» и вместе с тем предоставляют некий свой собственный идентификатор? Что-то типа обёртки для любых других протоколов. Примерно как по TCP можно пускать и HTTP, и HTTPS, и SMTP, и XMPP, и вообще что-то своё. Устройство подключается, говорит что у него класс «custom protocol», сообщает некий GUID — или даже текстовое название — своего «протокола» (зашито в спеке класса, например, поле для этого GUID-а) и по этому GUID-у подбирается правильный драйвер (который вовсе может быть User Space Appliation, каким-то образом зарегистрированный в системе, а драйвер устройства «стандартный» — для отработки этого custom protocol class).
Для подобной хрени достаточно же ведь всего одного VID&PID. Неужели подобного до сих пор никто не сделал? Или я не понимаю какого-то базового принципа USB?
Для подобной хрени достаточно же ведь всего одного VID&PID. Неужели подобного до сих пор никто не сделал? Или я не понимаю какого-то базового принципа USB?
Вообще-то USB функционирует примерно так, как вы и описали. Замените в первом абзаце вашего комментария GUID на VID/PID и получите USB как оно есть.
А если GUID уже есть, из которого уникальность первой части контролируется USB.org, а второй — вендором, зачем плодить еще сущности?
Когда стандарт USB только разрабатывался никто и не задумывался об армии умельцев (даже и сейчас среди разработчиков стандарта о них никто не думает), которые через десяток лет станут делать свои штучные/мелкосерийные устройства. Поэтому идентификация по VID/PID перетекла со старых стандартов, например, в PCI та же схема: 3 килобакса за членство и VID в кармане. Так что насчет «исторически сложилось» вы в чем-то правы.
А если GUID уже есть, из которого уникальность первой части контролируется USB.org, а второй — вендором, зачем плодить еще сущности?
Когда стандарт USB только разрабатывался никто и не задумывался об армии умельцев (даже и сейчас среди разработчиков стандарта о них никто не думает), которые через десяток лет станут делать свои штучные/мелкосерийные устройства. Поэтому идентификация по VID/PID перетекла со старых стандартов, например, в PCI та же схема: 3 килобакса за членство и VID в кармане. Так что насчет «исторически сложилось» вы в чем-то правы.
Но ведь теперь такая необходимость очевидна. Тот же GUID позволяет вообще не заботиться о пересечении — вероятность совпадения стремится чуть ли не к нулю, а если сделать вовсе текстовым полем с любой длинной — так вообще почти невозможно совпадение — только если кто-то намеренно такой же воткнёт. Ведь протокол USB позволяет сделать ещё одну «прослойку», не правда ли? Почему, для решения назревшей беды, не использовать этот путь?
Выбить один единственный VID+PID проще, чем целый VID, который рано или поздно всё равно исчерпается, не правда ли?
Выбить один единственный VID+PID проще, чем целый VID, который рано или поздно всё равно исчерпается, не правда ли?
Вообще-то, насколько я понимаю, официальная позиция подобных организаций в том, что «вероятность совпадения» должна быть равна нулю, а не стремиться к нему. И предложенная ими схема централизованного выделения эту задачу решает. Зачем же они будут менять ее на априори худшую схему?
Выбить единственный VID+PID ровно настолько сложно, как и целый VID — ни то, ни другое невозможно.
Выбить единственный VID+PID ровно настолько сложно, как и целый VID — ни то, ни другое невозможно.
«Custom USB Class device» есть, даже больше одного, например:
По поводу «сообщает GUID» — KOLANICH вчера предложил примерно то же самое — мы с ним довольно подробно пообсуждали, правда, уже в личной переписке. Если коротко — то:
1. Есть аппаратная часть, поддерживающая работу шины. Она должна как минимум уметь отличать разные устройства на шине друг от друга, и делает она это по VID, PID и серийному номеру. Эта часть, как правило, совсем аппаратная и зашита в хабе USB-контроллера — призывать это менять можно, но это будет как минимум весьма долго. Тот же USB по сути внедряли лет 10 — соответственно, ждите еще столько же.
2. Драйверы устройств с классами типа тех, что я показал выше, ищут «свои» устройства именно по VID/PID. Первоначально при опросе шины и энумерации от устройства приходит 2 дескриптора — 9 и 18 байт — «дескриптор устройства» и «дескриптор конфигурации». Дальше обычно драйверы, опознавая «свое» устройства по VID/PID, могут начать слать ему более подробные запросы и запрашивать какие-то class-specific или device-specific дескрипторы. Можно по идее сделать на некоем системном уровне хак, который будет для каких-то особенных устройств, не зная, что это именно за устройство, посылать запрос дополнительного дескриптора (скажем, с UUID), а затем в системе находит зарегистрированный драйвер, поддерживающий устройства с таким UUID — но при этом:
3. В любом случае любое подобное действие явно вызовет ответную реакцию к «нарушающему» со стороны USB-IF, прекращение членства в USB-IF и автоматические иски по поводу нарушения торговых марок, патентов, фирменных наименований и т.д.
- 0xEF — Miscellaneous Class (Device or Interface Descriptor)
- 0xFE — Application Specific Class (Interface Descriptor)
- 0xFF — Vendor Specific Class (Device or Interface Descriptor)
По поводу «сообщает GUID» — KOLANICH вчера предложил примерно то же самое — мы с ним довольно подробно пообсуждали, правда, уже в личной переписке. Если коротко — то:
1. Есть аппаратная часть, поддерживающая работу шины. Она должна как минимум уметь отличать разные устройства на шине друг от друга, и делает она это по VID, PID и серийному номеру. Эта часть, как правило, совсем аппаратная и зашита в хабе USB-контроллера — призывать это менять можно, но это будет как минимум весьма долго. Тот же USB по сути внедряли лет 10 — соответственно, ждите еще столько же.
2. Драйверы устройств с классами типа тех, что я показал выше, ищут «свои» устройства именно по VID/PID. Первоначально при опросе шины и энумерации от устройства приходит 2 дескриптора — 9 и 18 байт — «дескриптор устройства» и «дескриптор конфигурации». Дальше обычно драйверы, опознавая «свое» устройства по VID/PID, могут начать слать ему более подробные запросы и запрашивать какие-то class-specific или device-specific дескрипторы. Можно по идее сделать на некоем системном уровне хак, который будет для каких-то особенных устройств, не зная, что это именно за устройство, посылать запрос дополнительного дескриптора (скажем, с UUID), а затем в системе находит зарегистрированный драйвер, поддерживающий устройства с таким UUID — но при этом:
- Этому хаку нужно будет за что-то зацепиться — за какой-то признак в оригинальных дескрипторах => это означает использование дескрипторов не по назначению => конфронтация с USB-IF и неприятие такого подхода с их стороны
- Если этот признак — специфичный VID/PID — то см. с чего начали — USB-IF как раз против такого и явно это запретила
- Ни одна из проприетарных операционных систем скорее всего никогда не будет поддерживать такой способ опроса USB что, как следствие, сильно урезает перспективы выхода на рынок специфичных устройств с небольшими тиражами
- Даже в какие-нибудь Linux или BSD такой патч сильно не факт, что получится протащить — я сильно не уверен, что Linux Foundation или FreeBSD Foundation отважится на открытую конфротанцию с USB-IF
3. В любом случае любое подобное действие явно вызовет ответную реакцию к «нарушающему» со стороны USB-IF, прекращение членства в USB-IF и автоматические иски по поводу нарушения торговых марок, патентов, фирменных наименований и т.д.
Я ненавижу патентную систему. :(
Но если по сути — формально, насколько я понимаю, достаточно выбить один единственный FOSS VID+PID у USB-IF для создания подобного класса устройства, я верно понял?
Но ведь просто вендоры продают свои VID+PID налево, насколько я понял. Почему нельзя просто купить подобный VID+PID у организации, уже состоящей членом в USB-IF и уже получившей свой VID (и пул соответствующих PID-ов)? Именно запрет делать это от USB-IF, которые хотят срубить побольше денег и не хотят появления класса, который позволит положить кое что на их систему регистрации устройств?
Но если по сути — формально, насколько я понимаю, достаточно выбить один единственный FOSS VID+PID у USB-IF для создания подобного класса устройства, я верно понял?
Но ведь просто вендоры продают свои VID+PID налево, насколько я понял. Почему нельзя просто купить подобный VID+PID у организации, уже состоящей членом в USB-IF и уже получившей свой VID (и пул соответствующих PID-ов)? Именно запрет делать это от USB-IF, которые хотят срубить побольше денег и не хотят появления класса, который позволит положить кое что на их систему регистрации устройств?
Нельзя купить ни «один единственный» VID+PID, ни VID, ни вообще какое-либо другое количество идентификаторов с целью перепродажи / субаренды / передачи кому-то еще — и все, точка. USB-IF вполне явно обозначил свою позицию. Для них — основное — принцип, а не конкретное количество номеров. И да, они вполне явно сказали, что будут против любых попыток обхода их системы регистрации.
Кроме того, на самом деле одна пара VID+PID — это неправильно. Если все «умельцы», понагенерившие себе UUIDы, начнут своим изделиям присваивать серийный номер «1», скажем, то шина будет аппаратно не в состоянии отличить один (VID, PID, «1») от другого — она-то ничего не про какие UUIDы не знает.
Кроме того, на самом деле одна пара VID+PID — это неправильно. Если все «умельцы», понагенерившие себе UUIDы, начнут своим изделиям присваивать серийный номер «1», скажем, то шина будет аппаратно не в состоянии отличить один (VID, PID, «1») от другого — она-то ничего не про какие UUIDы не знает.
А какая разница аппаратной шине какой VID и PID и серийный номер у конкретного устройства? Разве она не оперирует понятием «портов»? Или я опять где-то заблуждаюсь?
Приходит новое устройство, шлет приветствия шине. Хаб должен получить эти приветствия и понять, это какое-то из уже существующих устройств или новое. Как он это поймет? Хаб запрашивает стандартные дескрипторы и на их основании выдает адрес на шине.
А хаб не знает, в какой порт воткнуто устройство? Не может по портам различать?
В хаб может быть воткнут другой хаб, а в него — десятки устройств (или еще хабы). В том числе — пассивные.
Хм. Скажем, я купил две одинаковые вебкамеры. Они путаться будут в итоге?
Похоже на изъян самого протокола, в таком случае. При подключении шина какой-то хендшейк чтоли делать должна, присваивая каждому устройству уникальный номер…
Похоже на изъян самого протокола, в таком случае. При подключении шина какой-то хендшейк чтоли делать должна, присваивая каждому устройству уникальный номер…
Еще раз — у двух одинаковых вебкамер будут разные серийные номера. Шина (вернее, root hub) и делает «хендшейк» через энумерацию — присваивает всем устройствам номера. После того, как номера уже присвоены — да, можно обращаться к ним по номерам устройств, и уже без разницы, какие там у кого атрибуты.
А почему он не может «проэнумерить» два устройства с одинаковым серийником?
Представьте, что вы — root hub. У вас есть 2 провода с питанием, 2 провода с rx и tx — всё. К вам подключена большое дерево USB-устройств, физическую часть соединения и начальный token сделал за вас какой-то оконечный порт. Что происходит дальше? Устройство шлет «привет, я тут, вот мой device descriptor, вот мой configuration descriptor (или несколько), дай мне номер на шине». Мы проверяем, есть ли у нас уже такое устройство с такими VID-PID-серийником. Если еще нет — то даем новый номер. Если есть — то говорим, что мы тебя уже знаем под старым номером, напоминаем старый номер. Все хорошо, до тех пор пока не приходят два неотличимых устройства, и тогда второму мы даем первый номер и вся шина превращается в тыкву.
Это, конечно, очень грубое и приблизительное описание — в реальности все несколько сложнее, но общая схема на верхнем уровне примерно такая.
Это, конечно, очень грубое и приблизительное описание — в реальности все несколько сложнее, но общая схема на верхнем уровне примерно такая.
Похоже таки на изъян протокола, если честно. :( Грустно…
Почему изъян-то? Есть в целом задача реализация 1-2 уровня телеком-протоколов. Человечество придумало весьма небольшое количество способов ее решения, если разобраться — «все сразу» никак не получится, чем-то приходится жертвовать.
Да, на мой взгляд, USB — относительно бредовая спецификация, когда изначально задумывали одно простое и надежное решение, а в итоге (в угоду требованиям, которые сгоряча понаобещали маркетологи) сделали весьма монструозное нечто с непомерно высокой сложностью реализации конкретной ноды, страшно ненадежно работающее на более-менее длинных кабелях, зачем-то с очень дешевыми хабами (которые, как оказалось, толком никому не нужны) и идиотскими базовыми спецификациями классов, уже на момент ввода в действие серьезно проигрывавшие альтернативным интерфейсам (вспомнить хоть тот же PS/2), что исправили, да и то частично, только эдак лет через 10-15 после ввода первого стандарта…
Да, на мой взгляд, USB — относительно бредовая спецификация, когда изначально задумывали одно простое и надежное решение, а в итоге (в угоду требованиям, которые сгоряча понаобещали маркетологи) сделали весьма монструозное нечто с непомерно высокой сложностью реализации конкретной ноды, страшно ненадежно работающее на более-менее длинных кабелях, зачем-то с очень дешевыми хабами (которые, как оказалось, толком никому не нужны) и идиотскими базовыми спецификациями классов, уже на момент ввода в действие серьезно проигрывавшие альтернативным интерфейсам (вспомнить хоть тот же PS/2), что исправили, да и то частично, только эдак лет через 10-15 после ввода первого стандарта…
Ну, я бы сделал так:
Шина опрашивает «вышестоящий хаб» по очереди. Ему приходит VID+PID+Serial number. Ну отлично, шине пофиг. Он отсылает его «номер порта». Затем говорит вышестоящему хабу — «мне следующее устройство». Даже если придёт такой же VID+PID+Serial ему ничто не помешает присвоить ему другой номер. Ибо вышестоящий хаб (или хабы) не должен повторяться.
И так постепенно всем номера присвоит.
Шина опрашивает «вышестоящий хаб» по очереди. Ему приходит VID+PID+Serial number. Ну отлично, шине пофиг. Он отсылает его «номер порта». Затем говорит вышестоящему хабу — «мне следующее устройство». Даже если придёт такой же VID+PID+Serial ему ничто не помешает присвоить ему другой номер. Ибо вышестоящий хаб (или хабы) не должен повторяться.
И так постепенно всем номера присвоит.
Ничего не понял почти с самого начала. Кто такая «шина», кто такой «вышестоящий хаб» и как они соотносятся? Судя по «мне следующее устройство» — вы предлагаете еще какой-то более stateful протокол, где кто-то (все?) должен еще иметь память и помнить, какое устройство «следующее». И если помнить должны все, то у них какой-то механизм синхронизации этого знания должен быть…
Как бы хабы должны быть чуть поумней, да.
Корневой хаб направляет запрос «Initialize Next» в один из своих портов. Оттуда приходит ответ:
VID+PID+Serial+(device left/no devices left)+чего там ещё от USB устройств приходит.
Устройству присваивается номер.
Затем корневой хаб кидает в тот же порт Initialize Next если пришёл ответ что есть ещё device left. И пока будут device left он будет слать Initialize Next в тот же порт.
Если в тот порт воткнуто напрямую устройство, то устройство ответит no device next. Если же там хаб и у него есть несколько воткнутых в него устройств (предположим, 2 устройства и ещё один хаб), он ответит на первый запрос device left. На второй тоже device left. А на третий — там где хаб — он будет перенаправлять всё в тот самый хаб. Тот третий хаб будет снова отбивать device next или no device next, который будет просто проксироваться вторым хабом…
Так можно развернуть цепочку хабов с любой длинной.
Надеюсь понятно.
Корневой хаб направляет запрос «Initialize Next» в один из своих портов. Оттуда приходит ответ:
VID+PID+Serial+(device left/no devices left)+чего там ещё от USB устройств приходит.
Устройству присваивается номер.
Затем корневой хаб кидает в тот же порт Initialize Next если пришёл ответ что есть ещё device left. И пока будут device left он будет слать Initialize Next в тот же порт.
Если в тот порт воткнуто напрямую устройство, то устройство ответит no device next. Если же там хаб и у него есть несколько воткнутых в него устройств (предположим, 2 устройства и ещё один хаб), он ответит на первый запрос device left. На второй тоже device left. А на третий — там где хаб — он будет перенаправлять всё в тот самый хаб. Тот третий хаб будет снова отбивать device next или no device next, который будет просто проксироваться вторым хабом…
Так можно развернуть цепочку хабов с любой длинной.
Надеюсь понятно.
Вы правы. В начале инициализации достаточно номера порта, потом устройству назначается свой адрес.
Есть аппаратная часть, поддерживающая работу шины. Она должна как минимум уметь отличать разные устройства на шине друг от друга, и делает она это по VID, PID и серийному номеру. Эта часть, как правило, совсем аппаратная и зашита в хабе USB-контроллера — призывать это менять можно, но это будет как минимум весьма долго
Простите, что?
В USB1 хост-контроллер при отправке данных просто broadcast'ит пакет с данными на шину USB, вообще не задумываясь, кому этот пакет предназначен — пакет сформировал софт. Все хабы broadcast'ят пакет «вниз» по топологии. В пакете нет никаких VID/PID, не говоря уже о серийном номере, но есть 7 бит адреса на шине. Каждое устройство после инициализации знает свой адрес, видит пакет, сравнивает адрес из пакета со своим, игнорирует «чужие» пакеты и отвечает на «свои». Адрес — произвольное ненулевое число, назначается софтом на одной из стадий инициализации устройства, меняется от подключения к подключению, обычно минимальное из ещё не назначенных — первое устройство получает адрес 1, второе — 2 и так далее.
В USB2 всё почти так же, за исключением расщеплённых транзакций к USB1-устройствам. В случае USB1-устройств есть две шины и нужны два набора координат — адрес связывающего хаба и адрес на USB1-шине «ниже» хаба. По-прежнему никаких VID/PID.
В USB3 broadcast для обычных пакетов отменили, к пакету добавили 20-битную Route String, по 4 бита на каждый хаб, определяющую номер порта, которому нужно переслать пакет. Route String заполняется — сюрприз, сюрприз! — софтом при указании данных для передачи. Опять-таки никаких VID/PID.
Софту для конфигурации устройства и назначению адреса VID/PID тоже не нужны. Нужно только выбрать незанятый адрес. Как о нём узнает устройство? Одна из стадий инициализации устройства — назначение адреса, пакет SET_ADDRESS. Сразу после сброса устройство откликается на нулевой адрес, пакет SET_ADDRESS, отправленный на нулевой адрес, установит адрес в устройстве. Нельзя сбрасывать два устройства одновременно. Подключить два устройства одновременно можно, между подключением и сбросом устройство не видит трафика шины — фильтрация на уровне хаба — а момент сброса выбирает софт.
VID/PID/серийный номер не нужны для функционирования шины.
Аппаратная часть хост-контроллера не умеет отличать разные устройства на шине друг от друга.
Можно по идее сделать на некоем системном уровне хак, который будет для каких-то особенных устройств, не зная, что это именно за устройство, посылать запрос дополнительного дескриптора (скажем, с UUID), а затем в системе находит зарегистрированный драйвер, поддерживающий устройства с таким UUID — но при этом:
Этому хаку нужно будет за что-то зацепиться — за какой-то признак в оригинальных дескрипторах => это означает использование дескрипторов не по назначению
В USB3 устройство может содержать один или несколько Platform Descriptors, каждый из которых — вы не поверите — содержит 128-битный UUID платформы, назначаемый создателем платформы, и может ассоциировать с платформой вплоть до 255-20 байт данных. Теоретически вполне возможно объявить, что UUID 47726579-43617400-00000000-00000000, если таковой есть в дескрипторах устройства, задаёт данные такой-то структуры, в которые входит — чего вы там хотите — UUID класса устройств? Производителя? Драйвера?
Разговор с чиновниками из VTM Group и USB-IF бесполезен (как и с любыми другими чиновниками). Если парни из Arachnid Labs действительно хотят честную регистрацию для сообщества, то нужно совместно с фондами Open Hardware, FOSS, Linux Foundation, OSI и OpenCores публично объявить:
а) диапазон vendor, например 0xE000-0xFFFF, принадлежит сообществу открытого железа и открытого софта
б) регистрация открытых спецификаций на этот диапазон отныне ведется на сайте, находящимся под контролем этих фондов.
Всё. Никого спрашивать не надо. Почему это сработает?
Потому что VTM Group и USB-IF после публичного объявления от сообщества о занятии диапазона не смогут выдавать эти диапазоны, т.к. никто из их покупателей не согласится брать vendor id из «свободного» диапазона. Вторая причина — покупатель просто пойдет и зарегистрирует свою спецификацию на сайте сообщества, чем будет кидать деньги мутным толстопузам. При этом он будет понимать, что отныне его спецификацию могут использовать другие производители железа.
Отбраковку «левых» спецификаций можно вести по принципу статей Хабра. Т.е. если спецификация набрала +10 голосов, то автоматически получает номер. Специалисты открытого железа будут просматривать новые спецификации-кандидаты и голосовать за них. Так свободная регистрация упорядочится.
а) диапазон vendor, например 0xE000-0xFFFF, принадлежит сообществу открытого железа и открытого софта
б) регистрация открытых спецификаций на этот диапазон отныне ведется на сайте, находящимся под контролем этих фондов.
Всё. Никого спрашивать не надо. Почему это сработает?
Потому что VTM Group и USB-IF после публичного объявления от сообщества о занятии диапазона не смогут выдавать эти диапазоны, т.к. никто из их покупателей не согласится брать vendor id из «свободного» диапазона. Вторая причина — покупатель просто пойдет и зарегистрирует свою спецификацию на сайте сообщества, чем будет кидать деньги мутным толстопузам. При этом он будет понимать, что отныне его спецификацию могут использовать другие производители железа.
Отбраковку «левых» спецификаций можно вести по принципу статей Хабра. Т.е. если спецификация набрала +10 голосов, то автоматически получает номер. Специалисты открытого железа будут просматривать новые спецификации-кандидаты и голосовать за них. Так свободная регистрация упорядочится.
После попытки такого акта любая организация (FSF, OSI, Open Hardware, whatever), которая заявит о своей поддержке такого registry, получит lawsuit от VTM и, что самое печальное, VTM легко это дело выиграет, принудив в судебном порядке прекратить заниматься раздачей идентификаторов, распространением ложной информации и т.д. и т.п., да еще и стрясет весьма нехилую денежную компенсацию за опороченную деловую честь и имидж. Поэтому ни одна более-менее официально зарегистрированная в штатах или Европе организация на такое не пойдет.
Поясните, пожалуйста, на основании чего именно будет подан иск к организациям, поддерживающим такой вот неофициальный принцип делегирования. Ибо, если судить по остальным комментариям к посту, зачастую поменять VID/PID у своего экземпляра устройства не представляется проблемой — и вроде как за это даже не судят.
А насчёт распространения ложной информации: ну так нет проблем. Пускай сущность, ведущая такой альтернативный реестр, будет вне американской юрисдикции — или вообще не являться юридическим лицом. Тогда иски предъявлять будет некому. А сводная информация будет, тем не менее, доступна всем желающим.
А насчёт распространения ложной информации: ну так нет проблем. Пускай сущность, ведущая такой альтернативный реестр, будет вне американской юрисдикции — или вообще не являться юридическим лицом. Тогда иски предъявлять будет некому. А сводная информация будет, тем не менее, доступна всем желающим.
Иск в таком случае будет подан с десятком разных обвинений — начиная от защиты деловой репутации, кончая потерянными доходами, мошенничества путем введение в заблуждение и выдачи себя за другое юрлицо, обладающее какими-то правами и полномочиями и т.п. — скорее всего еще и trademark, patent & copyright infringement приплетут.
Сделать сущность не юрлицом или где-нибудь в сугубо нейтральной юрисдикции в теории можно, но на практике
(1) Это означает, что всем существующим общественным организациям типа того же FSF / OSI / Apache / Open Hardware / etc) надо от такой сущности откреститься и всячески делать вид, что они к ней никакого отношения не имеют; если рано или поздно выяснится, что таки имеют — их тут же возьмут в соучастники преступления и в соответчики по иску.
(2) На самом деле _не_ сделать ответственную организацию в рамках права в штатах уже весьма сложно — почитайте хотя бы как банды графитчиков (дела «City of Los Angeles v. The Bloods» или «City of Los Angeles v. The Crips») в свое время ловили. Там есть такое понятие, как «unincorporated associations» — достаточно добыть свидетельство, что существует группа людей, называющая себя X, плюс одного человека, который причисляет себя к этой группе — и все. После этого можно судиться с этим физлицом, как представителем организации X напрямую — и совершенно не обязательно формально искать концы и официальную регистрацию организации. Физлицо при этом, как правило, само быстро и проворно переводит стрелки и сдает всю организацию X, т.к. отвечать одно за всех обычно не хочет.
Грубо говоря, это означает, что не найдя организацию, с которой судиться, иск подадут к первому попавшемуся разработчику, посмевшему использовать такие «нелегальные» идентификаторы.
Сделать сущность не юрлицом или где-нибудь в сугубо нейтральной юрисдикции в теории можно, но на практике
(1) Это означает, что всем существующим общественным организациям типа того же FSF / OSI / Apache / Open Hardware / etc) надо от такой сущности откреститься и всячески делать вид, что они к ней никакого отношения не имеют; если рано или поздно выяснится, что таки имеют — их тут же возьмут в соучастники преступления и в соответчики по иску.
(2) На самом деле _не_ сделать ответственную организацию в рамках права в штатах уже весьма сложно — почитайте хотя бы как банды графитчиков (дела «City of Los Angeles v. The Bloods» или «City of Los Angeles v. The Crips») в свое время ловили. Там есть такое понятие, как «unincorporated associations» — достаточно добыть свидетельство, что существует группа людей, называющая себя X, плюс одного человека, который причисляет себя к этой группе — и все. После этого можно судиться с этим физлицом, как представителем организации X напрямую — и совершенно не обязательно формально искать концы и официальную регистрацию организации. Физлицо при этом, как правило, само быстро и проворно переводит стрелки и сдает всю организацию X, т.к. отвечать одно за всех обычно не хочет.
Грубо говоря, это означает, что не найдя организацию, с которой судиться, иск подадут к первому попавшемуся разработчику, посмевшему использовать такие «нелегальные» идентификаторы.
> потерянными доходами
Регистрация вендора должна стоить немногим больше регистрации домена (440 руб.), но никак не 150 000 руб. Это всего лишь регистраторы, их функция — сделать запись в электронной базе данных. О каких «потерянных» доходах идёт речь? У толстопузов отбирают монопольную кормушку? Ну дак это проблема толстопузов, а не общества.
> мошенничества путем введение в заблуждение
Вот эта монопольная обдираловка и есть мошенничество: а именно, паразитирование некоей структуры на открытом международном аппаратном стандарте USB.
> и выдачи себя за другое юрлицо,… обладающее какими-то правами и полномочиями и т.п. — скорее всего еще и trademark, patent & copyright infringement приплетут.
Легтимность какой-либо структуры определяет общество. Разумеется, это война репутаций и доверия. И она идёт уже вовсю несколько лет, с нарастающей мощью открытого сообщества.
В этой войне на одной стороне стоят чиновники, обдирающие народы, со своими филькиными грамотами и с неба взятыми полномочиями, а с другой — сообщество созидательных граждан (в данном примере, разработчиков свободных аппаратных платформ).
Сообщество с каждым годом всё больше и больше борзеет. А чинуши стухают.
Понятно, что это будет демарш со стороны свободных фондов, который ТНК постараются деактивировать. Но время для этого уже пришло, любая агрессия со стороны ТНК и их чиновников только усугубит их же положение и пошатнёт их же репутацию.
Любую конструктивную технологию, которая отбирает кормушку у чинушей и облегчает жизнь трудового народа, нужно немедленно использовать.
Регистрация вендора должна стоить немногим больше регистрации домена (440 руб.), но никак не 150 000 руб. Это всего лишь регистраторы, их функция — сделать запись в электронной базе данных. О каких «потерянных» доходах идёт речь? У толстопузов отбирают монопольную кормушку? Ну дак это проблема толстопузов, а не общества.
> мошенничества путем введение в заблуждение
Вот эта монопольная обдираловка и есть мошенничество: а именно, паразитирование некоей структуры на открытом международном аппаратном стандарте USB.
> и выдачи себя за другое юрлицо,… обладающее какими-то правами и полномочиями и т.п. — скорее всего еще и trademark, patent & copyright infringement приплетут.
Легтимность какой-либо структуры определяет общество. Разумеется, это война репутаций и доверия. И она идёт уже вовсю несколько лет, с нарастающей мощью открытого сообщества.
В этой войне на одной стороне стоят чиновники, обдирающие народы, со своими филькиными грамотами и с неба взятыми полномочиями, а с другой — сообщество созидательных граждан (в данном примере, разработчиков свободных аппаратных платформ).
Сообщество с каждым годом всё больше и больше борзеет. А чинуши стухают.
Понятно, что это будет демарш со стороны свободных фондов, который ТНК постараются деактивировать. Но время для этого уже пришло, любая агрессия со стороны ТНК и их чиновников только усугубит их же положение и пошатнёт их же репутацию.
Любую конструктивную технологию, которая отбирает кормушку у чинушей и облегчает жизнь трудового народа, нужно немедленно использовать.
Я всецело поддерживаю ваш дух, но, боюсь, большинство обвинений несколько мимо кассы. USB IF — это не какое-то назначенное кем-то свыше на законодательном уровне сообщество чиновников, а все те же всем известные крупные корпорации типа IBM, HP, Microsoft и т.п., которые установили такую вот «власть транснациональных корпораций» в своем отдельно взятом королевстве USB и активно ее защищают, насколько могут. Поэтому и деньги у них будут, чтобы судиться, и средства, и, как ни странно, куча народа будет на их стороне.
Вообще, некоторое количество лет назад все подобные вопросы как раз выносились на уровень госрегулирования и решались некоей третьей стороной — государством, которое взвешивало интересы и тех, и других, и пыталось найти компромисс. Для доменов такой компромисс нашли, для железок — пока нет. Надеюсь, найдут. Время покажет.
Вообще, некоторое количество лет назад все подобные вопросы как раз выносились на уровень госрегулирования и решались некоей третьей стороной — государством, которое взвешивало интересы и тех, и других, и пыталось найти компромисс. Для доменов такой компромисс нашли, для железок — пока нет. Надеюсь, найдут. Время покажет.
Послать всю эту организацию на хер и расширить стандарт, реалиpовав поддержку uuid наравне с vid и pid.
То есть пусть устройство с VID 67F0 и случайным PID по хорошему должно иметь строковый дескриптор с индексом последний занятый + 1 с его uuid.
То есть пусть устройство с VID 67F0 и случайным PID по хорошему должно иметь строковый дескриптор с индексом последний занятый + 1 с его uuid.
Тоже не получится. В условиях вступления в foundation в 99% прописывается, что ты обязуешься строго следовать стандарту и не делать какой-то отсебятины и расширений — и это, в целом, разумно и понятно. Соответственно, как только какой-нибудь производитель материнок, скажем, типа ASUS, попробует ввести какое-нибудь расширение стандарта — он тут же будет исключен из foundation и лишен прав продавать какие-либо продукты с торговыми марками «USB», «USB compliant», «USB certified» и т.п. — т.е. по сути все текущие продукты. Таким образом, один производитель на такое никогда не пойдет.
Может быть пойдет какая-то группа производителей, но тогда они создадут скорее всего просто новый foundation и новый стандарт, скорее всего не совместимый с USB. Мы этих попыток уже в количестве наблюдаем за последние лет 10-15 — Firewire, Lightning, DisplayPort, что там еще такого ренегатного придумывали?
Может быть пойдет какая-то группа производителей, но тогда они создадут скорее всего просто новый foundation и новый стандарт, скорее всего не совместимый с USB. Мы этих попыток уже в количестве наблюдаем за последние лет 10-15 — Firewire, Lightning, DisplayPort, что там еще такого ренегатного придумывали?
Thunderbolt.
Любой кабель к которому от «сертифицированного партнера» (тм) стоит от десятки (за 0,5м) мертвых президентов.
Любой кабель к которому от «сертифицированного партнера» (тм) стоит от десятки (за 0,5м) мертвых президентов.
У Тандерболта много выше скорость, а значит и требования к кабелям — индуктивность, емкость, сопротивления. Создатели и владельцы технологии не хоnят, чтобы вы жаловались на то, что тандерболт лажа и не выдает заявленную скорость, когда на деле у вас лажовый китайский кабель с огромной межпроводной емкостью, которая валит фронты.
Почему кусок 4х2х0,7Э кабеля (в просторечье витая пара экранированная) стоит меньше 80 центов за метр? И обеспечивает гигабитную пропускную способность.
Ну да, гигабитную. А TB — 20-гигабитную. Для 10G Ethernet нужны уже cat6a/cat7 кабели, которые стоят ровно столько же (первые попавшиеся ссылки, вероятно есть дешевле)
cat7 2m — 44$ www.blackbox.com/Store/Detail.aspx/CAT7-S-FTP-Patch-Cable-LS0H-PVC-Stranded-White-4-Pair-2-m-6-5-ft/EVNSL74%C4%8280%C4%82002M
thunderbolt 2m — 39$ www.amazon.com/Apple-MD861ZM-Thunderbolt-Cable-VERSION/dp/B00B3Y4FAS
вот кстати еще интересное про thunderbolt habrahabr.ru/post/123156/
cat7 2m — 44$ www.blackbox.com/Store/Detail.aspx/CAT7-S-FTP-Patch-Cable-LS0H-PVC-Stranded-White-4-Pair-2-m-6-5-ft/EVNSL74%C4%8280%C4%82002M
thunderbolt 2m — 39$ www.amazon.com/Apple-MD861ZM-Thunderbolt-Cable-VERSION/dp/B00B3Y4FAS
вот кстати еще интересное про thunderbolt habrahabr.ru/post/123156/
www.ulmart.ru/goods/351492 34 рубля за метр cat6a, хотя это, конечно, у них дороговато, если говорить о барабанах.
www.1-cable.ru/cat/891_913 цены от 60 рублей (~2 баксов за метр) за cat7.
Наконец вопрос: для чего нужна такая пропускная способность в пользовательских системах, где пропускная способность сегодня пока что не превышает 1 Гбит/с?
www.1-cable.ru/cat/891_913 цены от 60 рублей (~2 баксов за метр) за cat7.
Наконец вопрос: для чего нужна такая пропускная способность в пользовательских системах, где пропускная способность сегодня пока что не превышает 1 Гбит/с?
Вы привели бухты, я — кроссы. Коннекторы в таких кабелях — самое дорогое, а у TB там вообще трансивер стоит прямо в коннекторе (см последнюю ссылку в пред. комментарии)
Что до назначения, то в первую очередь он для профессиональных рабочих станций предназначен, не для простых пользователей, и упор там идет на чейнинг. Одно устройство такую полосу реально сейчас забить вряд ли сможет, а вот пяток разных — уже проще.
Вы берете ноутбук и одним кабелем подключаете всю периферию — монитор или пару, внешние накопители, сеть, звук, внешнюю видеокарту, какие-нибудь видео-аудио-пульты и прочее. Вынул один кабель, ушел с ноутбуком работать в другое место. Вернулся, подключил единственный кабель и работаешь дальше со всей периферией
Что до назначения, то в первую очередь он для профессиональных рабочих станций предназначен, не для простых пользователей, и упор там идет на чейнинг. Одно устройство такую полосу реально сейчас забить вряд ли сможет, а вот пяток разных — уже проще.
Вы берете ноутбук и одним кабелем подключаете всю периферию — монитор или пару, внешние накопители, сеть, звук, внешнюю видеокарту, какие-нибудь видео-аудио-пульты и прочее. Вынул один кабель, ушел с ноутбуком работать в другое место. Вернулся, подключил единственный кабель и работаешь дальше со всей периферией
Так почти по любому расспространённому стандарту, Zigbee, KNX.
Only those users with full accounts are able to leave comments. Log in, please.
Организация по стандартизации USB против Open Source