Не все йогурты одинаковы.
Пока беспроводные технологии не победили окончательно, USB(U) стал (или вот-вот станет) наиболее часто используемым интерфейсом в устройствах на базе микроконтроллеров (МК) и уверенно занимает нишу стандартного устройства связи, вытесняя UART. Не будем забывать, что на данный момент в самой известной и распространенной серии плат на базе МК - Arduino - даже сам UART реализован через преобразователь из интерфейса U, а в некоторых продвинутых версиях преобразователь реализован на самом МК.
.
Так что наличие Ю-модуля в МК становится одним из критериев выбора конкретного устройства из множества вариантов.
К сожалению, просто посмотреть таблицу в документации и убедиться, что в соответствующей строке стоит плюс, невозможно.
Давайте рассмотрим некоторые особенности интерфейса с точки зрения функциональности.
Прежде всего, у Ю есть три варианта 1, 2 и (кто бы мог подумать) 3, а также варианты версий.
Вариант 1 поддерживает низкую скорость (LS=1,5 МБ) и полную скорость (FS=12 МБ), а низкая скорость может быть реализована аппаратно на любом микроконтроллере, имеющем 2 цифровых порта, тактовую частоту 10 МГц и прерывание по одному.
время от этих ветвей (последнее требование можно убрать при определенных ограничениях прикладной программы).
Тема более чем избитая и упоминается лишь для того, чтобы подчеркнуть эрудицию автора.
Поэтому можно с уверенностью сказать, что почти каждый МК имеет на борту первую версию Ю в режиме LS и тема закрыта (есть одна особенность, но об этом позже).
Вариант 2 также поддерживает высокую скорость (HS=480 МБ), но реализация таких устройств в МК пока не очень распространена, особенно в части физического (PHY) интерфейса, поэтому пока не актуальна и далее рассматриваться не будет. (Прошу несогласных в комментариях) .
Таким образом, мы можем сосредоточиться на особенностях реализации режима FS. Я не вижу особого смысла рассматривать вариант 3, так как он все равно не предназначен для МК, требования к производительности слишком высоки, а его аппаратные возможности все еще скрыты во внешнем трансивере (что справедливо и для большинства реализаций HS).
Итак, какие подводные камни могут быть скрыты в МК, относительно которого мы уверены, что в нем PHY USB FS Device, так как об этом написано в документации, которые (камни) могут стать препятствием для реализации требований к нашему устройству .
В первую очередь это согласующие резисторы (в этом особенность).
Как известно, наличие резистора на одной из линий передачи данных является признаком поддерживаемых устройством скоростей, но в то же время это также признак того, что устройство подключено к шине.
Поэтому, если выбранный MCU не имеет внутренних согласующих резисторов (вряд ли в современных MCU, но такое случалось и раньше, особенно при реализации LS-устройств на портах), вы не сможете инициировать процесс повторного подключения устройства, отключив резистор от линии передачи данных.
Конечно, эта функция может и не понадобиться, но об этом стоит помнить.
Будем считать требования соответствия стандартам выполненными, если на устройстве имеется значок концерна Ю, хотя лично я бы на это не надеялся.
Была очень специфическая ситуация, когда U-анализатор сообщал об одиночных пакетах в середине линии, хотя устройство функционировало нормально и проблема была явно в несогласованности уровней.
Ну а на этот параметр повлиять никак нельзя, потому что никто в документации не напишет о частичном соответствии стандарту.
Но теперь начинается самое интересное, о чем мы можем прочитать в документации.
Прежде всего, это количество конечных точек (ОТ), поскольку именно этот параметр напрямую определяет реализуемый функционал.
Ну во-первых, без нулевого ОТ устройство работать вообще не будет, поэтому его наличие не обсуждается.
Никаких указаний на то, что нулевой ОТ можно использовать для каких-либо иных целей, кроме настройки устройства при включении, я не нашел, если у кого-то есть другая информация, поделитесь.
Поэтому нам обязательно понадобится больше одного ОТ, ближайшее целое число - 2, но все равно их получается не меньше 4. Почему - потому что самые простые устройства используют один ОТ для управления, а второй (и третий) для передачи данных, вот именно 4 и это сработало.
Этого количества вполне достаточно для реализации практически любого устройства, но только до тех пор, пока не возникнет необходимость создания комбинированного устройства.
Вот в этом и проблема — к сожалению, невозможно использовать один ОТ для реализации разных функций.
Создать комбинированное HID-устройство — это сколько угодно; все отчеты могут передаваться на хост через один ОТ, но передавать отчеты и данные из массовой памяти через один ОТ уже невозможно.
Поэтому количество ОТ (а это параметр, определяемый аппаратно и программно не увеличиваемый, хотя варианты есть) является серьёзным ограничением при проектировании комбинированных устройств.
Следующая важная деталь — это параметры ОТ, а именно размер буфера для данных, возможность объединения буферов в цепочку и возможность одновременной работы на прием и передачу.
Начнем с последнего — для реализации дуплексной передачи по одному ОТ необходимо иметь отдельные флаги готовности на чтение и запись (это требование в принципе можно обойти программно при определенных требованиях к хосту) и отдельные буферы на прием и запись.
передающие (но тут ничего не поделаешь и они очень нужны).
Если в данном МК соблюдены такие требования, то количество ОТ увеличивается вдвое и это облегчает построение комбинированных устройств.
Следующий важный параметр — размер буфера памяти ОТ, поскольку от него напрямую зависит максимальный размер пакета данных.
Опять же, для HID-устройств этот параметр не столь важен, но для устройств передачи данных он может существенно ограничивать пропускную способность.
Непосредственно с пропускной способностью связано наличие более одного буфера для одного направления передачи одного ОТ для организации переключения буферов.
Важным параметром для обеспечения максимальной пропускной способности является способность контроллера Y работать с механизмом DDP МК.
Как видите, вышеперечисленные требования к реализации Ю в МК сводятся к двум группам - скорости и функциональности.
И если со скоростью ничего не поделаешь, и она жестко ограничена аппаратными возможностями (другой вопрос, небрежное написание драйверов может еще больше ограничить эти возможности - см.
конкретные реализации), то с функциональной точки зрения есть одно совершенно очаровательное трюк, позволяющий создавать устройства с неограниченной функциональностью.
Эта хитрость заключается в реализации псевдохаба, так как в этом случае можно представить объединенное устройство в виде множества подключенных к хабу устройств и тем самым снять все ограничения на количество и тип ОТ.
Конечно, это потребует тщательного программирования и является нетривиальной задачей, но, тем не менее, вполне осуществимой.
Однако для этого варианта есть категорическое требование к интерфейсу Y - возможность приема пакетов с любым адресом, то есть возможность отключения фильтра адресов, что реализовано не в каждом МК.
Подводя итог всему вышесказанному, можно сказать, что если вы планируете создать относительно простое устройство Y (HID), то плюсика в описании МК в соответствующей строке вполне достаточно, но если вы планируете комбинированное гетерогенное устройство, или устройство с интенсивной передачей данных, то следует быть особенно внимательным.
Прочтите спецификацию контроллера Ю выбранного МК, чтобы избежать неприятных разочарований.
Как читатель, наверное, понимает, этот пост — результат проделывания ходов, поэтому небольшая практическая рекомендация, созданная в результате вполне конкретного проекта — использования МК от Миландера для реализации устройств, описанных в предыдущем пункте, — не может быть рекомендуемые.
Сами по себе МК очень хорошие, но интерфейс Y в них реализован с очень ограниченными возможностями.
А вот с этой задачей МК на базе STM справились вполне хорошо, чувствуется, что разработчики интерфейса Y из этой компании имеют большой опыт (а может, купили хорошую лицензию).
Теги: #микроконтроллеры #Программирование микроконтроллеров
-
Программное Обеспечение Для Шпионских Камер
19 Oct, 24 -
«Частное Решение Проблем Человечества»
19 Oct, 24 -
Мисс Дьюи: Поиск Секс-Символа И Порнозвезды
19 Oct, 24 -
Библиотека Сериализации Json Для Erlang
19 Oct, 24 -
Автоматический 3D-Сканер Размера Упаковки
19 Oct, 24
