В этом МК есть 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-ные МК с подобной задачей вполне справились, чувствуется, что опыт у разработчиков Ю интерфейса у этой фирмы весьма велик (а может, куплена хорошая лицензия).
