В этом МК есть USB?

    Не все йогурты одинаково полезны.

    Пока беспроводные технологии не победили окончательно, 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-ные МК с подобной задачей вполне справились, чувствуется, что опыт у разработчиков Ю интерфейса у этой фирмы весьма велик (а может, куплена хорошая лицензия).
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 36

      +13
      USB (Ю)

      Зачем? Это же всего 3 буквы.
        +5
        Чтоб не переключать раскладку? ;)
          +3
          Приз в студию )
            +4
            В текстовых редакторах есть такая вещь, как функция поиска и замены слов с учетом регистра. После замены читаемость текста повысилась бы.
            0
            Переключатель раскладки на CapsLock для этого весьма удобен. Даже очень. Но дело привычки.
              0
              Вообще то я привык работать с клавиатурой, на которой были клавиши РУС и ЛАТ — кто видел, тот поймет о чем речь.
                0
                15-ИЭ-0013?
                  0
                  Еще 1 приз в студию.
                  Я ее как-то в присутствии руководства ПО чинил легким постукиванием о стол, переходящим в тяжелое постукивание. И починил таки.
                  0
                  Видел, но уже не щупал. На современных компах такой вариант тоже вполне можно сделать, если привычней: habrahabr.ru/post/156779
            0
            Очень интересный пост, спасибо.

            Вопрос: где можно почитать о программной реализации Low-speed USB интерфейса на выводах общего назначения (GPIO)?

            Как вы решили для себя вопрос Vendor ID и драйверов? Пишете драйвера под ОС сами? Что насчет Microsoft Driver Signing? Можно ли делать драйвера USB-устройств, используя UMDF, чтобы не нужно было платить за их испытания и сертификацию?
              +1
              Ну в первую очередь на Atmel у них там лежат AppNotes с исходниками. Есть перевод www.gaw.ru/html.cgi/txt/app/micros/avr/AVR309.htm
              У Microchip тоже было и тоже в аппах, но мне AVR ближе.
              Вообще очень увлекательное чтение исходников, после того, как я их понял, вопросов по USB стало намного меньше, так что программную реализацию можно рекомендовать просто для понимания работы интерфейса.

              С VID и PID то же что и все — изготовитель STM номер с демо платы. Конечно же так нельзя а что делать?
              Жду пока кто-нить начнет продавать ПЗУ с уникальными номерами, как сделали с MAC адресами.
                0
                Для open hardware есть ещё довольно новый вариант с pid.codes
                +3
                И тут надо ещё упомянуть V-USB.
                  +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. Всем хорош, но дорогой, зараза.
                    0
                    По сути, ты можешь брать любой VID, без покупки у USB-IF

                    Я бы для коммерческих устройств так не делал. Как-то совсем несерьезно.

                    А вообще, интерфейс USB разрабатывался уже тогда, когда были микросхемы/контроллеры с достаточной памятью, чтобы разместить в ней 128-битное число (UUID). Да и сложность протокола предполагает, что на 155й рассыпухе USB-интерфейс не реализовать в разумных габаритах. Поэтому то, что они зарезервировали только 16 бит на VID — это намеренно с целью впоследствии получать деньги из воздуха за продажу VID.

                    Ну а так, спасибо за вашу информацию и рекоммендации. Должно пригодиться!
                      0
                      Я бы для коммерческих устройств так не делал. Как-то совсем несерьезно.


                      Если я правильно понял, то, у компании, на которую мы сейчас аутсорсим, до недавнего времени и был такой вот «блатной» VID. Официальный купили только недавно. Компания достаточно известная в определённой сфере. Но вообще — да, я с вами полностью согласен.
                        0
                        Одно но, покупая VID, вы так же обязуетесь выполнять определённые требования, что бы вы могли без зазрения совести ставить на девайсе USB-compatible. В частности, устройство должно соответствовать определённым требованиям. Компании, которая заплатила немалые деньги за VID, как-то стрёмно будет его потерять, если они не будут обеспечивать какой-то минимальный уровень соответствия своих девайсов требованиям. Подробности нужно гуглить, меня больше интересовали технические аспекты, но суть, примерно в этом.
                          0
                          Разумеется, стандарты надо соблюдать, и даже если я не хочу платить шальные деньги за сертификационные испытания — мне будет спокойнее, если мое устройство максимально соответствует стандарту. Иначе пойдут рекламации, возвраты, траты времени и средств на техподдержку. Или того хуже — судебные иски.
                      +1
                      есть предопределенные VID и PID, за которые нет нужды платить. К ним точно относится HID, и вероятно какая то версия CDC.
                      Если вы делаете устройство для себя, то нет нужды лицензировать такой интерфейс. Это справедливо и для теста. Если же на продажу, то вопрос уже переползает в коммерческую сторону с вытекающим ответом.
                        0
                        HID-классы и VID-PID не связаны. При одинаковых идентификаторах, HID может быть любым. Но готовьтесь к проблемам, с такими устройствами. Если классы разные, при одновременном подключении, работать будет только одно из них.
                          0
                          Тогда по вашему выражению получается так, что два устройства на одинаковом чипе от FTDI не должны функционировать вместе. В реальности очень даже работают. При этом пары совпадают. Есть еще уникальный идентификатор устройства, привязанный к конкретной шине USB.

                            0
                            Они работают, потому что имеют общий HID и соответственно используют одинаковые драйвера.
                          +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 в какой-то момент начало с этим бороться. Подробностей не скажу. Можно попытаться нагуглить такое, может отголоски ещё существуют.
                      0
                      Никто не будет ставить полноценный USB в МК промназначения, там нужнее CAN.
                        0
                        Эт точно.
                        На Саяно-Шушенской ГЭС стояли датчики вибрации подключенные по USB.
                        Как известно ими не пользовались либо не обращали внимания. Видимо отваливались часто.
                        И что с этой ГЭС стало все знают.

                        В промконтроллерах строго либо RS485, либо CAN, либо последняя мода — EtherCAT

                        А выбирая контроллер с USB еще очень важно планировать заранее от чего он будет тактироваться.
                        Может оказаться, что одни скоростные интерфейсы (тот же Ethernet) по частотам не совместимы с частотами нужными для USB.
                        Лучше когда SoC имеет для USB свой отдельный генератор.
                          +3
                          И что с этой ГЭС стало все знают.

                          Неужели это из-за датчиков? ;)
                            0
                            Правильное замечание насчет тактирования, но во всех контроллерах с PHY USB, которые я видел, был дополнительный резонатор (на 25 МГц), поэтому я и решил, что это как бы безусловно есть.
                              0
                              По поводу ГЭС:
                              Нет плохих судов, нет плохих ветров, есть плохие капитаны.
                            +2
                            Судя по количеству аббревиатур, отсутствию «воды» в тексте и вообще предельно насыщенному изложению, автор явно начинал работать еще во времена i8051.
                              0
                              И, в целом, это правильно. Не хватает, правда, пару примеров железяк, у которых есть USB, но есть узкие места в реализации…
                              Хотя, вспоминаю одну статью с цветомузыкой, где автор схему разбил на блоки функциональные, обозвал их аббревиатурами, и потом ими оперировал… но и это было в тему.
                                +1
                                Более того, автор начинал еще во времена i8048 (1816ВЕ48) и у меня в 4кбайт УФ ПЗУ жила телефонная станция.
                                Так что, когда я приобрел 1816ВЕ51 и к нему электрически!!! стираемое ППЗУ на 16 кбайт, то понял, что теперь то я смогу сделать все, что угодно. И многое делал, хотя и не все.
                                Кстати по поводу отсутствия «воды» — это действительно так или тонкий троллинг? Дело в том, что я пытаюсь писать лаконично, но все время что то постороннее врывается в текст. Это действительно не раздражает, мои легкие лирические отступления? Все-таки стиль типа «Он пошел, она сказал» мне кажется суховатым.
                                Раз уж зашел разговор о сжатости текста, позволю себе процитировать роман Хема в шесть слов
                                «Продается детская обувь, ни разу не надевалась» и что бы там не думали критики, это действительно роман.
                                  0
                                  Кстати по поводу отсутствия «воды» — это действительно так или тонкий троллинг?

                                  Нет, это не троллинг. Я просто обратил внимание, что текст написан, как и программа под 8051 — ничего лишнего, каждое предложение информационное :)
                                    0
                                    Спасибо.
                                0
                                Сокращения правда лишнее… Читать немного напрягает. Очущение, как будто читаешь документацию советского периода. Автозамена есть во всех нормальных wordprocessor'ах. Лирические отступления нужны, чай не документацию и не дожностную инструкцию пишите…
                                Вместо сокращений я бы привёл английское название терминов, чтобы потом, читая даташиты, понимать о чем речь… Ну и кратенький обзор МК c которыми работали (их явно больше чем два) был бы не лишний.
                                А так, да… Очень полезная статья. Такое в мануалах не вычитаешь…
                                  0
                                  А по мне еще надо разбавить какими-нибудь картинками по теме, между абзацами. Для придания популяризационности статье.

                                  Only users with full accounts can post comments. Log in, please.