Usb cdc что это

Обновлено: 01.07.2024

Дело в том, что для каждого класса устройств написаны свои спецификации, которые позволяют унифицировать общение с устройствами. Это удобно и разработчикам устройств (не надо каждый раз изобретать новые интерфейсы и протоколы) и производителям операционок (можно организовать поддержку всяких стандартных устройств на уровне операционок). Да и для простых пользователей навигация в менеджере устройств становится приятнее.

Наряду с классом, определить для чего предназначен девайс, как с ним общаться и какие дрова при этом использовать, помогает пара идентификаторов VID/PID, а также номер версии устройства.

Дескрипторы бывают стандартные и специфические. Стандартные дескрипторы для всех USB-устойств одинаковы, они обязательно есть в любом USB-устройстве и содержат общее описание устройства и его отдельных частей. Специфические дескрипторы содержат всякую специфическую для различных классов устройств информацию, соответственно, такие дескрипторы для каждого класса устройств свои.

Ниже описаны структуры и назначения различных стандартных дескрипторов:

Номер версии USB может принимать следующие значения:

Коды классов бывают следующими:

Битовая маска атрибутов содержит следующую информацию:

Дескрипторы строк являются необязательными. Если девайс не поддерживает дескрипторы строк, то во всех остальных дескрипторах индексы дескрипторов строк, содержащих текстовое описание, должны быть равны нулю.

При подключении USB-устройства, хост с помощью управляющих передач запрашивает у устройства список дескрипторов в следующем порядке:

стандартный дескриптор устройства
дескрипторы конфигураций

Причём при запросе дескриптора конфигурации хост получает сразу все дескрипторы (дескрипторы интерфейсов, конечных точек), относящиеся к этой конфигурации. Общий объём этих дескрипторов хосту заранее неизвестен, он хранится в поле wTotalLength дескриптора конфигурации, поэтому хост сначала запрашивает первые 8 байт этого дескриптора, запоминает из прочитанных данных значение поля wTotalLength, а потом снова запрашивает этот же дескриптор конфигурации, но размер запрашиваемых данных уже указывает равным wTotalLength. В результате такого трюка устройство присылает хосту все дескрипторы, относящиеся к данной конфигурации, в следующем виде:

Специфические дескрипторы мы рассмотрим подробнее когда будем разрабатывать какой-нибудь конкретный девайс, какого-нибудь определённого класса, а пока на этом всё.

Всем привет! Сегодня будем поднимать USB CDC (VCP) на плате stm32f401c-disco.

USB communications device class (коммуникационный класс устройства) — является составным классом устройства Универсальной последовательной шины. Класс может включать один (или более) интерфейс, такой как интерфейс пользовательского элемента управления, интерфейс передачи данных, аудио или интерфейс запоминающего устройства.

Базовый класс 02h (Communications and CDC Control)
Этот базовый класс определен для устройств, которые относятся к классу устройств спецификации связи. Эта спецификация определяет используемый набор подкласса и Протокола значений. Значения за пределами определения спецификации защищены. Обратите внимание, что связи класса устройств спецификации требуется несколько значений Кода класса (три), которые будут использоваться в описания устройств, а некоторые, которые будут использоваться в интерфейсе дескрипторов.

Базовый класс 02h
Подкласс xxh
протокол xxh
смысл Communication device class

Базовый класс 0Ah (CDC-Data)
Этот базовый класс определен для устройств, которые относятся к классу устройств спецификации связи. Это спецификация определяет используемый набор подкласса и протокола значений. Значения за пределами определения спецификации защищены. Эти коды класса могут быть использованы только в интерфейсе дескрипторов.

Базовый класс 0Ah
Подкласс xxh
протокол xxh
смысл CDC data device

4. Теперь нужно добавить в usbd_cdc_if.h несколько строк кода

5. Устраняем баг для USBD_CDC_TransmitPacket()

6. И добавляем пример в main.c

И все готова!, подключаем микро USB к плате, второй вывод к host-у и у нас появляется виртуальный com порт.

6 thoughts on “ Старт ARM. Поднимаем USB CDC. ”

I corrected it with:

if (size > CDC_DATA_HS_OUT_PACKET_SIZE) int offset;
for (offset = 0; offset < size; offset += CDC_DATA_HS_OUT_PACKET_SIZE) int todo = MIN(CDC_DATA_HS_OUT_PACKET_SIZE, size - offset);
int done = VCP_write(((char *) pBuffer) + offset, todo);
if (done != todo)
return offset + done;
>

with large data is not working, thanks

Точно, спасибо за инфу.

Есть одна проблема. Не передаются пакеты более 64 байт. Кто-нибудь решил ее?

Продолжаю разработку полностью шаблонной библиотеки под микроконтроллеры Stm32, в прошлой статье рассказал об успешной (почти) реализации HID устройства. Еще одним популярным классом USB является виртуальный COM-порт (VCP) из класса CDC. Популярность объясняется тем, что обмен данными осуществляется аналогично привычному и простому последовательному протоколу UART, однако снимает необходимость установки в устройство отдельного преобразователя.

Интерфейсы

Устройство класса CDC должно поддерживать два интерфейса: интерфейс для управления параметрами соединения и интерфейс обмена данными.

Интерфейс управления представляет собой расширение базового класса интерфейса с тем отличием, что содержит одну конечную точку (хотя, насколько я понял, без необходимости поддержки всех возможностей можно обойтись вообще без конечной точки) и набор "функциональностей", определяющих возможности устройства. В рамках разрабатываемой библиотеки данный интерфейс представлен следующим классом:

В базовом случае интерфейс должен поддерживать три управляющих (setup) пакета:

SET_LINE_CODING: установка параметров линии: Baudrate, Stop Bits, Parity, Data bits. Некоторые проекты, на которые я ориентировался (основным источников вдохновения стал этот проект), игнорируют данный пакет, однако в этом случае некоторые терминалы (например, Putty), отказываются работать.

GET_LINE_CODING: обратная операция, в ответ на эту команду устройство должно вернуть текущие параметры.

SET_CONTROL_LINE_STATE: установка состояния линии (RTS, DTR и т.д.).

Код обработчика setup-пакетов:

Ключевой момент нумерации, а именно формирование дескрипторов, выполнен по уже привычной схеме раскрытия variadic-ов, что позволяет избавиться от зависимости классов в иерархии:

Поскольку мои познания в CDC-устройствах весьма небольшие, из просмотренных примеров я сделал вывод, что управляющий интерфейс почти всегда одинаковый и содержит 4 функциональности: Header, CallManagement, ACM, Union, поэтому добавил упрощенный шаблон интерфейса:

Применение разработанных классов

Для использования разработанных классов достаточно объявить две конечные точки (Interrupt для первого интерфейса и двунаправленную Bulk для второго), объявить оба интерфейса, конфигурацию с ними и, наконец, инстанцировать класс устройства:

Отладка и тестирование

Написать код правильно с первого раза практически невозможно, поэтому очень полезным оказалось все-таки разобраться с инструментами перехвата USB-пакетов, поэтому кратко опишу особенности и проблемы, с которыми столкнулся лично я.

Так и не удалось применить логический анализатор, он просто ничего не показывает. Полагаю, что дело в том, что это самый дешевый клон Seale Logic и если бы был в наличи нормальный аппарат, то все бы получилось. Главное преимущество логического анализатора заключается в том, что он позволяет отслеживать обмен данными еще в процессе нумерации, в то время как программы на стороне хоста показывают пакеты только для тех устройств, которые эту нумерацию успешно прошли.

WireShark с установленным UsbPcap оказался весьма удобным, он нормально парсит все данные, так что поиск ошибок значительно упрощается. Главное, что нужно сделать - правильно установить фильтры. Не нашел ничего лучше, кроме выполнить следующие две операции:

Сначала отфильтровать по заведомо известному значению. Например, по значению PID, которое присутствует в ответе устройства на запрос GET_DEVICE_DESCRIPTOR. Фильтр: "usb.idProduct == 0x5711". Это позволит быстро определить адрес устройства.

Далее отфильтровать по адресу устройства с помощью оператора contains. Дело в том, что отображаемый адрес состоит из трех частей, последняя из которых является номером конечной точки (можно, конечно, перечислить все адреса). Фильтр: "usb.addr contains "1.19"".

Однако стоит заметить, что UsbPcap может доставить некоторые трудности, под катом опишу ситуацию, в которую недавно попал и потратил кучу времени и нервов.

Проблема с usbpcap

Для большей мобильности завел себе внешний SSD, на котором установлена Windows 10 To Go (Windows, предназначенная для установки на внешние носители). Хотя Microsoft вроде отказалась от поддержки этой технологии, в целом все работает. Прихожу с диском в новое место, гружусь с него, система подтягивает драйвера и все нормально (и быстро) работает.

Полный код примера можно посмотреть в репозитории. Пример протестирован на STM32F072B-DISCO. Как и в случае с HID, громоздкая библиотека (особенно менеджер конечных точек) сильно облегчили реализацию поддержки CDC, на все ушел примерно полный день. Далее планирую добавить еще класс Mass Storage Device, и на этом, наверно, можно остановиться. Приветствую вопросы и замечания.

Я собрал свой компьютер из частей, которые я приобрел в Интернете, я провел чистую установку Windows 7 Ultimate 64-разрядной версии с пакетом обновления 1 (полная версия, без взлома OEM) и несколько раз запускал Windows Update, чтобы получить самую последнюю версию обновления от Microsoft. Я был рад видеть, что все работает как ожидалось, никаких проблем, ни в программном, ни в аппаратном обеспечении. Затем я подключил свой новый телефон Samsung Galaxy S4 Plus (GT-I9506) к свободному USB-порту компьютера. Windows обнаружила следующие 3 разных устройства.

USB композитное устройство
Galaxy S4 (sg)
CDC Serial

Windows автоматически установила и настроила первые два устройства (см. Скриншот выше). За исключением устройства "CDC Serial". Это не устанавливало тот.

Что такое устройство "CDC Serial"?
Зачем мне это нужно?
Как мне это установить?

Первым делом я проверил руководство пользователя (полное руководство, а не руководство по началу работы). Там нет ни одной ссылки на "CDC Serial". Я не эксперт, но я понимаю кое-что из этого. «Композитное устройство USB» установлено, чтобы Windows могла общаться с телефоном через USB-кабель. «Galaxy S4 (sg)» - это имя, которое я дал своему телефону во время установки, и это устройство, которое представляет Windows как медиаплеер, использует протокол MTP, и это то, что отображается в Windows Explorer. ,

Как я должен знать, что такое "CDC Serial", если он не описан в руководстве пользователя? Я никогда не видел такого раньше ни на одном устройстве Android при подключении к ПК. Я выполнил поиск по «cdc serial» в Google, и все, что я мог найти, это то, что люди делали некоторые хаки для своих телефонов, например, рутировали, меняли ПЗУ и вообще просто взламывали его.

Так что, если я не хочу этого делать? Все еще важно настроить устройство "Последовательный CDC"? Как это влияет на функциональность телефона, например, при синхронизации данных между телефоном и ПК, если я решу, что не хочу следовать этим советам и советам по взлому, чтобы попытаться установить это устройство?

Я связался с технической поддержкой Samsung по этому поводу, и они понятия не имели, о чем я говорю. Они сказали, что изучат это, но это все. Никакой помощи.

В руководстве пользователя сказано, что я могу изменить тип USB-соединения с MTP на PTP. По сути, это делает телефон представителем Windows в качестве фотокамеры. Я попытался, чтобы не было никаких проблем с драйверами, не устанавливаемыми. Windows обнаружила только устройство «Galaxy S4 (sg)», и оно было автоматически настроено и установлено.

В этом режиме между телефоном и ПК можно передавать только файлы изображений. Так что это очень ограничивает, на мой взгляд. Но устройство «CDC Serial» не было обнаружено. Как так.

Читайте также: