USB STM32 : AUDIO COM DFU DEBUG (дневник)

Эва куда замахнулся.

Из коробки CubeMX для stm32f429 все работает.
СОМ - проверил и он работает в обе стороны.
AUDIO проверил, но пока сложно поддается. Вообще не понятна система USB после CubeMX. С помощью Геннадия Завидовского немного разобрался с последовательностью и "что" и за "что" отвечает, правда очень поверхностно. И тесты пока зашли в тупик. Получаю фрейм с USB и пока на этом все, всего один фрейм. Понятно, что причина в прокладке между клавиатурой и креслом , но все равно надо разбираться как-то. Вот и решил завести дневник может поможет

Ну и конечно же нужно чтобы все сразу работало. Вход выход аудио, ком порт, отладчик, ну и bootloader.

Описание от usb.org

audio30.pdf

(Честно дернуто с просторов интернета.)

В зависимости от назначения, все usb устройства разделены по классам. Это деление довольно широкое и объединяет довольно большие группы устройств. Например, класс HID (human interface device) включает все устройства человеко-машинного взаимодействия (мышки, клавиатуры и тому подобное), класс Printer — все печатающие устройства и так далее. Зачем это деление нужно?

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

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





VID — это уникальный идентификатор производителя (Vendor ID), а PID — это уникальный идентификатор продукта (Product ID). Каждый VID стоит денег и покупать его надо у некоммерческой международной организации, занимающейся разработкой USB, которая называется USB Implementers Forum или просто USB-IF. Покупая VID, производитель получает в своё распоряжение пачку PID-ов от 0x0000 до 0xFFFF и гарантии того, что серьёзные производители не будут делать свои продукты с такими же VID/PID (и писать под них свои дрова). То есть его оборудование будет идентифицироваться операционкой одназначно и она будет однозначно выбирать для работы с этим оборудованием нужные дрова.

Всю информацию о себе и отдельных своих частях (классы, VID/PID, интерфейсы, конечные точки …) устройства хранят в специальных структурах данных, называемых дескрипторами (от англ. description — описание).

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

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

Standard Device Descriptor (стандартный дескриптор устройства) — содержит информацию об устройстве вцелом и о количестве его возможных конфигураций. Такой дескриптор может быть в устройстве только один.

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

0x0100 — USB1.0
0x0110 — USB1.1
0x0200 — USB2.0
Коды классов бывают следующими:

0x00 — интерфейсы функционируют независимо друг от друга и каждый из них имеет собственный код класса.
0x01-0xFE — стандартные классы, поддерживающие различные спецификации для интерфейсов. Интерфейсы не могут функционировать независимо.
0xFF — класс устройства определяется изготовителем.
Если устройство поддерживает режимы HS и FS, то у него должно быть два разных дескриптора для этих режимов, один из которых — это стандартный дескриптор устройства, а другой — уточняющий дескриптор устройства.

еще

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

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

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

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