Не все йогурты одинаково полезны.
Пока беспроводные технологии не победили окончательно, USB (Ю) стал (или вот-вот станет) наиболее часто применяемым интерфейсом в устройствах на микроконтроллерах (МК) и уверено занимает нишу устройства стандартной коммуникации, вытесняя UART. Не забудем и то, что в настоящий момент в наиболее известной и распространенной серии плат на основе МК — Arduino — даже и сам UART реализован через преобразователь из Ю интерфейса, а в некоторых продвинутых вариантах и преобразователь реализован на самом МК. Так что наличие Ю модуля в МК становится одним из критериев выбора конкретного устройства из множества вариантов. К сожалению, невозможно всего лишь посмотреть на таблицу в документации и удостоверится в наличии плюса в соответствующей строке. Рассмотрим некоторые особенности интерфейса с точки зрения функциональных возможностей.
Прежде всего, Ю имеет три варианта исполнения 1, 2 и (кто бы мог подумать) 3, а также версии вариантов.
Вариант 1 поддерживает низкую скорость (LS=1.5 МБ) и полную скорость (FS=12 МБ), причем низкая скорость может быть реализована в железе на любом МК, на котором имеется 2 цифровых порта, тактовая частота на уровне 10 МГц и прерывание по одной из этих ног (последнее требование можно и снять при определенных ограничениях на прикладную программу). Тема более чем избитая и упоминается только с целью подчеркнуть эрудированность автора. Поэтому можно с уверенностью заявить, что практически каждый МК имеет на борту Ю первой версии в режиме LS и тема закрыта (есть одна особенность, но о ней позже).
Вариант 2 поддерживает также и высокую скорость (HS=480 МБ), но реализация подобных устройств в МК пока что весьма не распространена, особенно в части физического (PHY) интерфейса, поэтому пока не актуальна и рассматриваться далее не будет (несогласных прошу в комментарии). Так что мы можем сосредоточится на особенностях реализации режима FS.
Вариант 3 рассматривать не вижу особого смысла, поскольку он все-таки не предназначен для МК, уж слишком высоки требования к производительности, а его аппаратные особенности все равно спрятаны во внешнем приемопередатчике (что справедливо и для большинства реализаций HS).
Итак, какие подводные камни могут быть спрятаны в МК, относительно которого мы уверены, что в нем есть PHY USB FS Device, поскольку так написано в документации, каковые (камни) могут стать препятствием в реализации требований к нашему устройству.
Прежде всего это терминирующие резисторы (вот она особенность). Как известно, наличие резистора на одной из линий данных является признаком поддерживаемых устройством скоростей, но в то же время и признаком подключения устройства к шине. Поэтому, если у выбранного МК отсутствуют внутренние терминирующие резисторы (в современных МК вряд ли, а вот раньше такое бывало, особенно при реализации LS устройства на портах), вы не сможете инициализировать процесс пере-подключения устройства путем отсоединения резистора от линии данных. Разумеется, такая возможность может и не понадобится, но помнить об этом следует.
Требования соблюдения стандартов будем считать выполненными, если на устройстве есть значок Ю концерна, хотя лично я бы на это не надеялся. Имелась вполне конкретная ситуация, когда Ю анализатор сообщал о пакетах-одиночках в середине линии, хотя устройство функционировало нормально и дело было явно в несогласованности уровней. Ну на этот параметр повлиять никак нельзя, ведь в документации никто не напишет о частичном соответствии стандарту.
А вот теперь начинаются действительно интересные вещи, которые мы можем прочитать в документации. Прежде всего это количество оконечных точек (ОТ), поскольку именно этот параметр напрямую определяет реализуемый функционал. Ну, прежде всего, без нулевой ОТ устройство вообще не заработает, поэтому ее наличие не обсуждается. Я не нашел указаний на то, что нулевая ОТ может быть использована для каких-либо иных целей, кроме как конфигурирования устройства при включении, если у кого есть другая информация, то поделитесь.
Поэтому нам потребуется точно более чем одна ОТ, ближайшее целое число 2, но все-таки их делают как минимум 4. Почему — потому что самые простые устройства используют одну ОТ для управления, а вторую (и третью) для передачи данных, вот как раз 4 и получилось. Такого количества вполне достаточно для реализации практически любого Ю устройства, но только до тех пор, пока не потребуется создать комбинированное устройство. Вот здесь и наличествует засада — к сожалению, использовать одну ОТ для реализации разных функций не получается.
Вот создать комбинированное HID устройство — это сколько угодно, все репорты можно передавать к хосту по одной ОТ, а по одной ОТ передавать репорты и данные от массовой памяти уже не получается. Поэтому количество ОТ (а это параметр, определяемый аппаратурой и программно увеличить его не получится, хотя есть варианты) является серьезным ограничением при проектировании комбинированных устройств.
Следующая важная деталь — параметры ОТ, а именно размер буфера под данные, возможность сцепления буферов, и возможность работы на прием и передачу одновременно. Начнем с последнего — для осуществления дуплексной передачи по одной ОТ необходимо иметь раздельные флаги готовности для чтения и для записи (это требование в принципе можно обойти программно при определенных требованиях к хосту) и раздельные буфера на прием и передачу (а вот тут ничего не поделать и они действительно нужны). Если такие требования в данном МК выполнены, то количество ОТ как бы удваивается и это облегчает построение комбинированных устройств.
Следующий важный параметр — размер буфера памяти ОТ, поскольку максимальный размер пакета данных напрямую от него зависит. Опять-таки для HID устройств этот параметр не столь важен, а вот для устройств передачи данных может весьма существенным образом ограничить пропускную способность. Напрямую с пропускной способностью связано и наличие более чем одного буфера для одного направления передачи одной ОТ для организации переключения буферов. Немаловажным параметром для обеспечения максимальной пропускной способности является и возможность работы Ю контроллера с механизмом ПДП МК.
Как видно, вышеприведенные требования к реализации Ю в МК сводятся к двум группам — скорость и функционал. И если со скоростью ничего сделать нельзя, и она жестка ограничена аппаратными возможностями (другой вопрос, что неаккуратное написание драйвера может эти возможности еще более ограничить — смотрите конкретные реализации), то с точки зрения функционала есть один совершенно очаровательный трюк, позволяющий делать устройства неограниченного функционала.
Трюк этот заключается в реализации псевдо-хаба, поскольку в этом случае можно представить комбинированное устройство в виде множества устройств, подключенных к хабу и тем самым убрать все ограничения на количество и тип ОТ. Конечно, это потребует аккуратного программирования и не представляет собой тривиальную задачу, но, тем не менее, вполне реализуемо. Однако, для этого варианта есть категорическое требование к Ю интерфейсу — возможность принимать пакеты с любым адресом, то есть возможность отключения адресного фильтра, что реализовано далеко не в каждом МК.
Резюмирую все вышесказанное, можно заявить, что если планируется создание относительно простого Ю устройства (HID), то плюсика в описании МК в соответствующей строке вполне достаточно, а вот если планируется комбинированное разнородное устройство, либо устройство с интенсивной передачей данных, то следует с особой тщательностью прочитать спецификацию Ю контроллера выбираемого МК, чтобы избежать неприятных разочарований.
Как, наверное, понятно читателю, данный пост является результатом хождения по граблям, поэтому маленькая практическая рекомендация, созданрая в результате вполне конкретного проекта — применение МК фирмы Миландр для реализации устройств, описанных в предыдущем абзаце, не может быть рекомендовано. МК сами по себе очень неплохие, но вот Ю интерфейс в них реализован с весьма ограниченными возможностями. А вот STM-ные МК с подобной задачей вполне справились, чувствуется, что опыт у разработчиков Ю интерфейса у этой фирмы весьма велик (а может, куплена хорошая лицензия).
Комментарии (36)
MichaelBorisov
14.04.2015 13:05Очень интересный пост, спасибо.
Вопрос: где можно почитать о программной реализации Low-speed USB интерфейса на выводах общего назначения (GPIO)?
Как вы решили для себя вопрос Vendor ID и драйверов? Пишете драйвера под ОС сами? Что насчет Microsoft Driver Signing? Можно ли делать драйвера USB-устройств, используя UMDF, чтобы не нужно было платить за их испытания и сертификацию?
GarryC Автор
14.04.2015 16:09+1Ну в первую очередь на Atmel у них там лежат AppNotes с исходниками. Есть перевод www.gaw.ru/html.cgi/txt/app/micros/avr/AVR309.htm
У Microchip тоже было и тоже в аппах, но мне AVR ближе.
Вообще очень увлекательное чтение исходников, после того, как я их понял, вопросов по USB стало намного меньше, так что программную реализацию можно рекомендовать просто для понимания работы интерфейса.
С VID и PID то же что и все — изготовитель STM номер с демо платы. Конечно же так нельзя а что делать?
Жду пока кто-нить начнет продавать ПЗУ с уникальными номерами, как сделали с MAC адресами.
monah_tuk
15.04.2015 02:22+1А смотря какие девайсы. По сути, ты можешь брать любой VID, без покупки у USB-IF, можешь ещё какие допущения делать, но если ты начнешь продавать такие девайсы с наклейкой «USB бла бла», то можно отгрести по шапке. Ну и конфликты на твоей совести. По поводу дров: тут тоже от девайса зависит. Можешь делать стандартные классы: HID, UVC, UAC и т.д., тогда будут использоваться стандартные, либо вообще возиться с устройством при помощи libusb (на винде isochronous передачу не поддерживает), плюс девайсу можно, начиная с Win8 автоматом зарегистрировать WinUSB драйвер (нужен для libusb), либо устанавливать его из приложухи (курить в сторону zadig и libwdi).
Что насчет Microsoft Driver Signing? Можно ли делать драйвера USB-устройств, используя UMDF, чтобы не нужно было платить за их испытания и сертификацию?
Попробую спросить, если не забуду.
Вопрос: где можно почитать о программной реализации Low-speed USB интерфейса на выводах общего назначения (GPIO)?
Выше уже написали про V-USB, добавлю сюда TinyUSB.
Кстати, если вдруг захочется USB 3.0, то можно поглядеть на Cypress EZ-FX3. Всем хорош, но дорогой, зараза.MichaelBorisov
15.04.2015 13:37По сути, ты можешь брать любой VID, без покупки у USB-IF
Я бы для коммерческих устройств так не делал. Как-то совсем несерьезно.
А вообще, интерфейс USB разрабатывался уже тогда, когда были микросхемы/контроллеры с достаточной памятью, чтобы разместить в ней 128-битное число (UUID). Да и сложность протокола предполагает, что на 155й рассыпухе USB-интерфейс не реализовать в разумных габаритах. Поэтому то, что они зарезервировали только 16 бит на VID — это намеренно с целью впоследствии получать деньги из воздуха за продажу VID.
Ну а так, спасибо за вашу информацию и рекоммендации. Должно пригодиться!monah_tuk
15.04.2015 16:57Я бы для коммерческих устройств так не делал. Как-то совсем несерьезно.
Если я правильно понял, то, у компании, на которую мы сейчас аутсорсим, до недавнего времени и был такой вот «блатной» VID. Официальный купили только недавно. Компания достаточно известная в определённой сфере. Но вообще — да, я с вами полностью согласен.
monah_tuk
15.04.2015 17:14Одно но, покупая VID, вы так же обязуетесь выполнять определённые требования, что бы вы могли без зазрения совести ставить на девайсе USB-compatible. В частности, устройство должно соответствовать определённым требованиям. Компании, которая заплатила немалые деньги за VID, как-то стрёмно будет его потерять, если они не будут обеспечивать какой-то минимальный уровень соответствия своих девайсов требованиям. Подробности нужно гуглить, меня больше интересовали технические аспекты, но суть, примерно в этом.
MichaelBorisov
15.04.2015 23:29Разумеется, стандарты надо соблюдать, и даже если я не хочу платить шальные деньги за сертификационные испытания — мне будет спокойнее, если мое устройство максимально соответствует стандарту. Иначе пойдут рекламации, возвраты, траты времени и средств на техподдержку. Или того хуже — судебные иски.
svd71
15.04.2015 15:12+1есть предопределенные VID и PID, за которые нет нужды платить. К ним точно относится HID, и вероятно какая то версия CDC.
Если вы делаете устройство для себя, то нет нужды лицензировать такой интерфейс. Это справедливо и для теста. Если же на продажу, то вопрос уже переползает в коммерческую сторону с вытекающим ответом.
thelongrunsmoke
15.04.2015 16:11HID-классы и VID-PID не связаны. При одинаковых идентификаторах, HID может быть любым. Но готовьтесь к проблемам, с такими устройствами. Если классы разные, при одновременном подключении, работать будет только одно из них.
svd71
15.04.2015 22:44Тогда по вашему выражению получается так, что два устройства на одинаковом чипе от FTDI не должны функционировать вместе. В реальности очень даже работают. При этом пары совпадают. Есть еще уникальный идентификатор устройства, привязанный к конкретной шине USB.
thelongrunsmoke
16.04.2015 05:29Они работают, потому что имеют общий HID и соответственно используют одинаковые драйвера.
monah_tuk
15.04.2015 17:08+2Не мешайте тёплое с мягким: класс устройства — это всего лишь набор дескрипторов, обязательный из которых только один (если не ошибаюсь) — device descriptor, который, собственно, и содержит в себе 2 байта VID и 2 байта PID. Остальные дескрипторы определяют или стандартизированные классы, типа HID, CDC и иже с ними, и тогда с ними может работать какой-то стандартный драйвер (много вы на клаву ставите дров?), или какой-то свой кастом, для работы с которым нужен или свой драйвер или user-space утилита (libusb, но в винде нужен generic драйвер WinUSB, выше писал уже). Кроме того класс устройства определяет протокол общения с ним, который описан и стандартизирован (как и сами дескрипторы): www.usb.org/developers/docs/devclass_docs
По поводу бесплатных VID:PID — есть оные для прототипов. Ещё раньше практиковалось: компания покупает один или несколько VID и продаёт нуждающимся конкретные пары VID:PID, что выходило существенно дешевле и было выгодно для всякой мелкосерийки. Но USB-IF в какой-то момент начало с этим бороться. Подробностей не скажу. Можно попытаться нагуглить такое, может отголоски ещё существуют.monah_tuk
15.04.2015 17:16Ну и по поводу бесплатных VID:PID: www.opennet.ru/opennews/art.shtml?num=41978 либо делать так: bsvi.ru/pismo-v-usb-org (подтверждение через отрицание) :)
thelongrunsmoke
14.04.2015 13:07Никто не будет ставить полноценный USB в МК промназначения, там нужнее CAN.
Indemsys
14.04.2015 13:25Эт точно.
На Саяно-Шушенской ГЭС стояли датчики вибрации подключенные по USB.
Как известно ими не пользовались либо не обращали внимания. Видимо отваливались часто.
И что с этой ГЭС стало все знают.
В промконтроллерах строго либо RS485, либо CAN, либо последняя мода — EtherCAT
А выбирая контроллер с USB еще очень важно планировать заранее от чего он будет тактироваться.
Может оказаться, что одни скоростные интерфейсы (тот же Ethernet) по частотам не совместимы с частотами нужными для USB.
Лучше когда SoC имеет для USB свой отдельный генератор.GarryC Автор
14.04.2015 16:15Правильное замечание насчет тактирования, но во всех контроллерах с PHY USB, которые я видел, был дополнительный резонатор (на 25 МГц), поэтому я и решил, что это как бы безусловно есть.
GarryC Автор
14.04.2015 17:28По поводу ГЭС:
Нет плохих судов, нет плохих ветров, есть плохие капитаны.
DrPass
14.04.2015 14:47+2Судя по количеству аббревиатур, отсутствию «воды» в тексте и вообще предельно насыщенному изложению, автор явно начинал работать еще во времена i8051.
serafims
14.04.2015 16:02И, в целом, это правильно. Не хватает, правда, пару примеров железяк, у которых есть USB, но есть узкие места в реализации…
Хотя, вспоминаю одну статью с цветомузыкой, где автор схему разбил на блоки функциональные, обозвал их аббревиатурами, и потом ими оперировал… но и это было в тему.
GarryC Автор
14.04.2015 16:22+1Более того, автор начинал еще во времена i8048 (1816ВЕ48) и у меня в 4кбайт УФ ПЗУ жила телефонная станция.
Так что, когда я приобрел 1816ВЕ51 и к нему электрически!!! стираемое ППЗУ на 16 кбайт, то понял, что теперь то я смогу сделать все, что угодно. И многое делал, хотя и не все.
Кстати по поводу отсутствия «воды» — это действительно так или тонкий троллинг? Дело в том, что я пытаюсь писать лаконично, но все время что то постороннее врывается в текст. Это действительно не раздражает, мои легкие лирические отступления? Все-таки стиль типа «Он пошел, она сказал» мне кажется суховатым.
Раз уж зашел разговор о сжатости текста, позволю себе процитировать роман Хема в шесть слов
«Продается детская обувь, ни разу не надевалась» и что бы там не думали критики, это действительно роман.
northbear
16.04.2015 05:25Сокращения правда лишнее… Читать немного напрягает. Очущение, как будто читаешь документацию советского периода. Автозамена есть во всех нормальных wordprocessor'ах. Лирические отступления нужны, чай не документацию и не дожностную инструкцию пишите…
Вместо сокращений я бы привёл английское название терминов, чтобы потом, читая даташиты, понимать о чем речь… Ну и кратенький обзор МК c которыми работали (их явно больше чем два) был бы не лишний.
А так, да… Очень полезная статья. Такое в мануалах не вычитаешь…
vitmeat
21.04.2015 01:59А по мне еще надо разбавить какими-нибудь картинками по теме, между абзацами. Для придания популяризационности статье.
hedgehog
Зачем? Это же всего 3 буквы.
nerudo
Чтоб не переключать раскладку? ;)
GarryC Автор
Приз в студию )
iliasam
В текстовых редакторах есть такая вещь, как функция поиска и замены слов с учетом регистра. После замены читаемость текста повысилась бы.
monah_tuk
Переключатель раскладки на CapsLock для этого весьма удобен. Даже очень. Но дело привычки.
GarryC Автор
Вообще то я привык работать с клавиатурой, на которой были клавиши РУС и ЛАТ — кто видел, тот поймет о чем речь.
Yak52
15-ИЭ-0013?
GarryC Автор
Еще 1 приз в студию.
Я ее как-то в присутствии руководства ПО чинил легким постукиванием о стол, переходящим в тяжелое постукивание. И починил таки.
monah_tuk
Видел, но уже не щупал. На современных компах такой вариант тоже вполне можно сделать, если привычней: habrahabr.ru/post/156779