Комментарии 34
Для 1.1 и 2.0 FS на импеданс можно забить, на идеальное выравнивание длин тоже - скорость мизерная, игра не стоит свеч. А вот дальше оно уже начинает быть очень актуальным... Но, с другой стороны, я не видел чего-то ардуино-подобного с готовыми портами 2.0 HS или 3.+, так что любитель врядли где-то столкнется с разводкой таких сигналов.
Я сходу из того, что можно купить и порграться обывателю только Cypress FX3 назову. И то, usb3kit стоит за 10к рублей. Сами чипы поискать нужно. Ну и да, это уже точно не arduino-подобное) но я лично завозил в openocd поддержку threadx на этом чипе (часть sdk), так что работать можно вполне комфортно)
ch32v307 и подобные имеют на борту USB HS физику
Больше мы не будем касаться в статье USB-C
Я бы коснулся в том аспекте, что если USB-C разъем на плате таки стоит (а что еще ставить в портативных устройствах, не micro USB же) — то нужно обе CC линии прижать к земле через два резистора по 5.1 килоом. Без них устройство будет работать только через кабели Type A - Type C.
а что еще ставить в портативных устройствах, не micro USB же
Я как раз за micro-USB из-за их несколько большей механической надежности. То, что он "устарел" и тому подобное, меня не смущает, особенно не смущает в отношении устройств Full Speed, да и High Speed тоже не сказать, что страдает от применения "устаревшего" типа разъема. Кабели тоже в ближайшие лет так много едва ли станут дефицитом.
нужно обе CC линии прижать к земле через два резистора по 5.1 килоом
Что будет "приятной" неожиданностью для тех, кто не читал но осуждает мануалы и берет готовые breakout платки, на которые вполне аккуратно распаян сам разъем - очень, как по мне, удобная штука для всякого DIY, но во имя Великой Китайской Экономии На Спичках отсутствуют по сути обязательные резисторы.
Странно, я как раз сдувал эти резисторы с этих платок (дальше pd контроллер стоял)...
С механической прочностью у microUSB как раз совсем плохо. На практике USB-C переносит больше подключений/отключений. А совсем хорошая прочность была у miniUSB, но там разъем великоват и из-за этого ушел в небытие.
У miniUSB была проблема в другом - низкая надежность разъема на кабеле, при внешней неубиваемости на вид.
Мой личный опыт - ни одного разрыва поврежденного при нормальной эксплуатации mini или micro USB, в том числе в телефонах, которым уже по семь-восемь лет, но уже есть один сдохший USB-C, причем сдохший в двухлетнем телефоне, то есть где замена копеечной детали становится до черта дорогой процедурой из-за того, что закленный клеем аппарат трудно разобрать и приходится отдавать на аутсорс тем, кто это умеет делать. Замена кабеля - легко, недорого и не требует вообще никаких усилий, знаний, опыта и специальных инструментов, поэтому пусть бы лучше кабели были самым слабым звеном, но никак не разъемы.
Прежде чем менять USB-C в телефоне, попробуйте другой кабель. Там бывает износ контактов (тоненькие они очень). Но новый, неизношенный кабель может еще долго работать.
Вообще, USB-C разъем это тот еще компромис между передаваемой мощностью и размерами. И он очень чувствителен к позиционированию на плате. Бывает что при монтаже он становится на 0.2-0.3 мм глубже внутрь корпуса, и писец. Кабель довольно быстро перестает дотягиваться до контактов и начинаются проблемы с зарядкой.
Прямо сейчас на столе пара nucleo с miniUSB, один нормальный, второй чуть шевельнешь отваливается. Причем это контакты, а не какой-нибудь непропай или кабель. Оба новые из упаковки, я уже ненавижу этот разъем!
Я как раз за micro-USB из-за их несколько большей механической надежности.
Если устройство стационарное и не очень мелкое, то я ставлю старые добрые полноразмерные USB B. И паять удобно, и убить малореально, и провод не дефицит.
У меня практика показывает, что достаточно 5.1кОм кинуть на одну линию, СС1.
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Кроме того, я воспринимаю Linux как слой HAL. Если на микроконтроллере можно запустить Linux, то мы сможем удобно отображать все эти устройства, нам не придётся пользоваться неуклюжими библиотеками HAL и так далее.
Вот это попробуйте перевести на нормальный человеческий язык.
Это гарантирует, что наша плата Nucleo будет вести себя с точки зрения хоста как устройство последовательного порта (CDC). Благодаря этому хост сможет настроить подходящие драйверы для работы с нашим собственным устройством.
Ну и какие драйвера нам потребуются для Windows и Linux, какой все же тип устройства был реализован согласно стандарту USB?
CDC, Communication Device Class. Внутри может быть, конечно, не только uart, но вроде как винда подтягивает стандартный драйвер. Как для UVC, UAC, MSC и HID (для последнего отдельно хендлятся клава и мышка).
Тот же FT232 реализован не как CDC. Ему нужен свой драйвер. Да, он может идти сразу в системе, но всё же.
Об этом и идет речь, что тип устройства необходимо было озвучить в заголовке или как минимум в аннотации. Далее хотя бы немного написать про классы устройств USB, и немного описать тип CDC, вот тогда пост был бы годным. А так +1 в копилку критикам корпоративных блогов, что публикуют материал низкого качества.
Вы помните размеры стандарта и USB in a Nutshell? А ведь последний, имхо, самое короткое полное руководство по USB. Ну никак ты не напишешь про USB, чтобы было и достаточно полно, и чтобы вжух - и готово)
Мне особо и помнить не надо). Напротив меня в книжную полку вставлена книга Стандарты и спецификация USB, толщина заметно больше Библии, скажу более, это одна из самых толстых моих книг. Но это не избавляет, хотя бы кратко технически грамотно описать предмет рассмотрения. Не буду первооткрывателем, тему можно разбить на два поста, первый стандарт и теория, второй практика. И основная моя претензия заключается в низком качестве исходного материала. Автору исходника претензий нет, он так чувствует, имеет на это право, а вот к переводчику есть. У меня есть пост Безопасность встраиваемых систем Linux. Тема безопасности знаете тоже не маленькая, но все же я считаю, что смог донести основную идею и концепцию исходного поста, Introduction to Embedded Linux Security. Я не занимался тупой копи-пастой, материал был не только переведен, а еще существенно изменен и дополнен, там, где требовалось пояснение. Потому что исходный пост рассчитан на западного читателя, специалиста по информационной безопасности.
В итоге: качественный исходный материал + качественная переработка + хорошая адаптация = дала хороший материал, который самому интересно почитать и другим не стыдно показать.
А вот вопрос, который занимает меня:
Я интересуюсь созданием устройств с USB HID.
Популярные МК, годящиеся для этого - AtMega32u4, STM32F103C8T6, STM32f411CEU6, STM32F401CCU6, rp2040, rp2350, ESP32-S3. И у них у всех USB2.0 с FullSpeed. Но почему-то на глаза мне не попадается что-нибудь похожее, но более быстрое, даже USB2.0 HS, не говоря об USB 3.
Я понимаю, что это не ответ на ваш вопрос, но вроде как для сферического HID в вакууме более высокие скорости не дают практических преимуществ - не нужно, нечем загрузить более жирный канал. Ну и сами контроллеры, наверное, не могут быстрее принимать и передавать осмысленные данные из-за внутренних ограничений, преодолевать которые разработчики почему-то не считают нужным, хотя все, что вы перечислили, не сказать, что прямо таки слабые и ни на что сверх мигания светодиодом не годные устройства.
У HID максимальная скорость 64кбайт/сек, 1000 опросов по 64 байта на пакет в секунду. Дальше вроде никак.
STM32f4 имеют HS без PHY (он отдельным чипом), но толк от такой скорости будет только в bulk-режиме, правильном использовании DMA, и оооочень специфических задачах (для которых лучше взять FPGA). Вон, господа, клепавшие пастильду, писали тут про разгон MSD - даже до предела FS не догнали, увы, на текущих либах камень не вывозит. Если с нуля написать весь стек, может и вывезет, но времени уйдет на это... Страшно подумать, игра не стоит свеч.
Если нужен HS дешево, то это rv1103/rv1106 (LuckFox) или Milk V-Duo, 64 метра оперативки, загрузка uSD или SPI-Flash, на борту линукс, стоит 5-8 баксов за плату. У меня rv1103 в режиме MSD выдает неплохую скорость, стек usb там вылизан неплохо так. Все никак не соберусь статью наклепать про эти платки...
У HID максимальная скорость 64кбайт/сек, 1000 опросов по 64 байта на пакет в секунду. Дальше вроде никак.
Неправда. Если устройство high speed - максимум 1024 байта на пакет и до трех пакетов в каждом микро-кадре (т.е. 24 пакета в одном кадре, поскольку кадр делится на 8 микро-кадров).
Вон, господа, клепавшие пастильду, писали тут про разгон MSD - даже до предела FS не догнали, увы, на текущих либах камень не вывозит. Если с нуля написать весь стек, может и вывезет, но времени уйдет на это... Страшно подумать, игра не стоит свеч.
Не знакомился подробно с их работой, но выводы странные. При эмуляции UART я прекрасно выжирал всю FS полосу без особых проблем (и без DMA), процессор при этом почти простаивал. Это была STM32G4 на 160 мегагерцах, т.е. м.б. на чуть меньшем контроллере нагрузка будет выше, но 12 мегабит (сырых, реальных меньше) — это явно не то, от чего микроконтроллеры умирают. Возможно, нагрузку давал другой компонент (к чему-то же этот MSD был подключен).
Неправда. Если устройство high speed - максимум 1024 байта на пакет и до трех пакетов в каждом микро-кадре (т.е. 24 пакета в одном кадре, поскольку кадр делится на 8 микро-кадров).
В теории да. На практике совместимость такого устроства будет плохой, не все системы умеют пакеты более 64 байт. В дополнение ко всему, использовать hid для передачи большого количества данных - отвратительная практика, для последователей которой есть отдельный котёл в аду. Хуже только передача полугиговой прошивки через BLE...
Возможно, нагрузку давал другой компонент (к чему-то же этот MSD был подключен).
Как минимум чтение/запись карты памяти. Там надо лихо жонглировать DMA-запросами, для чего надо переписать весь стек, текущий на такое не расчитан. С отдачей контента чисто из памяти проблем как раз нет...
На практике совместимость такого устроства будет плохой, не все системы умеют пакеты более 64 байт.
Сильное утверждение, учитывая, что стандарт USB прямо требует поддержки и, соответственно, все комплаенс-сертификации это проверяют. Собирать ради этого HS HID прошивку я, конечно, не буду, но смотрю на это (особенно на оценку "плохой", предполагающую огромную несовместимость) с большим скепсисом.
Как минимум чтение/запись карты памяти. Там надо лихо жонглировать DMA-запросами, для чего надо переписать весь стек, текущий на такое не расчитан. С отдачей контента чисто из памяти проблем как раз нет...
Т.е. 12 мегабит скопировать из памяти в USB без DMA можно и вы сами говорите, что никаких проблем нет, а 12 мегабит скопировать из SDIO/SPI в память без очень аккуратного обращения с DMA нельзя?
На практике совместимость такого устроства будет плохой, не все системы умеют пакеты более 64 байт.
Писать HS HID прошивку и не пришлось, поскольку так уж получилось, что HS HID устройство само в руки приплыло. Elgato Stream Deck, панелька с экраном и настраиваемыми кнопочками.
Прекрасно работает, использует пакеты по 1024 байт для передачи картинки. И думаю (учитывая, что это серийный продукт для не-технической аудитории), что никаких особых проблем совместимости не испытывает.
STM32U5 (не вся серия, только некоторые камни) имеют встроенный HS PHY. Например, можно купить вот такую девборду за 100 баксов и поиграться. Другие серии (например, F4) умеют в HS, но только с внешним PHY (из микроконтроллера торчит не сам USB, а ULPI интерфейс ко внешней микросхеме).
USB 3.0 встречается, но либо на специализированных микросхемах типа Cypress FX3 (но это не МК в классическом смысле, а скорее конвертер интерфейса), либо на полноценных процессорах типа STM32MP2. Микроконтроллерам такой поток осмысленно обработать будет сложно.
Во-первых, мне не нравится, что нам нужно генерировать кучу бойлерплейта при помощи IDE после щелчков в UI-меню. Мне бы хотелось, чтобы у меня была более гибкая библиотека, параметризируемая в коде, чтобы можно было написать что-то типа InitUsbDevice(UsbClass.CDC), а не ползать по UI для генерации кода. ..... Я не просто так упомянул, что Linux может работать в качестве USB-устройства: мне кажется, это гораздо более чистый подход. Linux API гораздо надёжнее и стандартизированнее. Работа с Linux будет основана на взаимодействиях с псевдофайлами и системными вызовами. Пользовательское пространство очень чётко отделено от пространства ядра. Кроме того, я воспринимаю Linux как слой HAL.
Автор сильно недооценивает количество "железных" блоков в контроллере которые делают возможной поддержку USB. Да и вообще всю эту периферию. Перекладывать все это на Линукс в надежде на то, что Линукс сделает тебе "хорошо и прозрачно" это ..мммм.. наивность какая-то! Гибкость Линукса при работе с железом обеспечивается драйверами. Но их кто-то должен писать и именно внутри драйверов будет сидеть весь этот boilerplate код. А создание драйверов для всех вариантов периферии которая бывает в контроллерах это немного неподъемная задача, т.к. вариантов этой периферии несколько даже внутри одного семейства контроллеров.
И это не говоря о том, что часть инициализации периферии делается на этапе прошивки устройства путем прописывания магических чисел в регистровые файлы конфигурации, прожигания фьюзов и т.п. А уж выяснение какие аппаратные блоки можно активировать одновременно - это отдельная прикольная задача. Конфигуратор из IDE может хоть проверить, что все эти режимы тактирования, назначения ног (для конкретной модели контроллера), IO блоки не конфликтуют друг с другом. А повесить эту задачу на драйвера OS прошитой в контроллер - это просто не реально!
Вендоры тоже неохотно делятся подробностями конфиругирования встроенных устройств. Бывает что требуют подписать NDA, а бывает что дают только скомпилированный бинарный blob который магически включает то, что вам обещано.
Ну и как вишенка на торте, портирование Линукса на все архитектуры контроллеров - это отдельное большое удовольствие. Все эти i51, AVR, ARM xx, и прочие будет очень приятно поддерживать. А про защищенный режим на половине архитектур можно будет просто забыть.
Одинаковая длина линий, ближайшее расположение, попадание в требуемый импенданс... интересно, кабель FrontPanelUSB любого корпуса системного блока насколько соответствует этим требованиям? По его растрёпанному в местах разводки виду как-то даже удивительно это ;)
Как эти стать из чат жопэти достали.
Создаём своё первое USB-устройство