STM32 и USB (практика)

[VladislavS]

Что же вы RM то стесняетесь читать?

изображение_2023-03-02_183335830.png

(40.37 КБ) 853 скачивания

И потом. Открываем раздел 34.17 OTG_FS programming model, там полностью по пунктам вся инициализация.

[danone78]

Вот я уже думаю, попробовать принудительно перевести в режим периферии, а потом из него отправить запрос согласования с хостом HNP. Мутно как-то все это.

[VladislavS]

RM таки читать не хотите?

[danone78]

я только с ним и работаю. Просто непонятно, зачем ID линия, если она не работает? И еще вопрос для контроля: бит-бандингом в область 0х50000000 не попасть, то есть только чтение-изменение-запись?

Добавлено after 1 minute 58 seconds:
вот кстати уже готовый перевод, чтобы не париться, кто-то уже постарался
http://microsin.net/programming/arm-wor ... 7264963928

[VladislavS]

[uquote="danone78",url="/forum/viewtopic.php?p=4380257#p4380257"]я только с ним и работаю. Просто непонятно, зачем ID линия, если она не работает?[/uquote]Что конкретно из раздела 34.4 не работает? Зачем вам вообще эта ID-линия, вы хост руками поднимать собрались?

[uquote="danone78",url="/forum/viewtopic.php?p=4380257#p4380257"]И еще вопрос для контроля: бит-бандингом в область 0х50000000 не попасть, то есть только чтение-изменение-запись?[/uquote]Большинство регистров периферии устроено так, что требуют либо R, либо W. Операция RMW скорее исключение. Если речь про USB-OTG (судя по адресу), то посмотрел свой код и нашёл всего одно место с RMW. Больше разговоров.

[danone78]

Я забыл выставить номер альтернативной функции. Все работает.

[danone78]

не сочтите за наглость, я опять со своим самоваром. Пазл не сложился, есть пара ключевых вопросов:
1- может быть так, что при подключении микроконтроллера к pc, usb host контроллер pc, по отношннию к подключаемому к нему stm32, находится в роли периферийного устройства?
2 - энумерация проходит без участия оппонента по связи или это зависит от роли?

[VladislavS]

1. Мне не попадались PC, порты которых могут быть device.
2. Энумерацию проводит host, чтобы узнать что к нему подкулючили. Девайс в это время ведёт себя тупо "как на допросе".

Может спецификацию почитать таки? Там столько интересного!

[COKPOWEHEU]

Вот тут я разбирал как USB работает на самом низком уровне - реверс vusb для AVR, то есть чистый ногодрыг: https://habr.com/ru/post/460815/
Грубо говоря, если вам что-то послали, вы должны ответить подтверждением или отказом (ACK / NAK). И наоборот, если хост у вас что-то запрашивает, вы посылаете ему данные и дожидаетесь его подтверждения.
Если говорить про аппаратный модуль, то не знаю как в вашем камне, а в stm32f1 надо явно прописать сохранение адреса и ответ в виде ZLP (пакет длиной 0 байт). Точнее наоборот, сначала ответить, и только потом сохранять адрес, иначе контроллер будет игнорировать запрос на подтверждение.
Как-то так:

Код: Выделить всё

if(req == (USB_REQ_STANDARD | USB_REQ_DEVICE)){
      if(setup_packet.bRequest == SET_ADDRESS){ //запрос на установку адреса на шине
        uint8_t USB_Addr = setup_packet.wValue;
        usb_ep_write(0, NULL, 0); //сначала посылаем ответ!
        while( (USB_EPx(0) & USB_EPTX_STAT) == USB_EP_TX_VALID ){} //дожидаемся пока хост его прочтет
        USB->DADDR = USB_DADDR_EF | USB_Addr; //и только потом меняем адрес
        return;
...

[danone78]

Спасибо, статья что надо, истиный дзен. У меня с ethernet-ом таких проблем не было как с usb. С самого запуска модуля otg-fs отлавливаю rxflvl (фифо не пустой), в принудительном режиме устройства, в разной последовательности инициализаций. Получаю прерывания, сначала старт фрейма одновременно со сменой режима, потом или энумерация, или вместе с ней резет, потом еще что-то незначительное. Но rx-fifo всегда пуст. Если вопреки правилам я прочитаю pop регистр, то выскакивает бит непустого фифо, но это я так понимаю его "непредсказуемое поведение". Компутер меня видит как неизвестное устройство, после энемерации скорость получаю правильную, с rcc мудрил всякое, но "оно" не коньяк и не кофе.

Добавлено after 26 minutes:
Забавно то, что энумерация проходит без ошибок даже если ничего не подключено и скорость выставляется full sped.

Добавлено after 1 hour 15 minutes 39 seconds:
Предполагаю, можно попробовать сделать правильный резет после устанвки forced device mode так чтобы этот бит не сбросился и возможно понадобится управление через power clock and gating ahb регистр.

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4383136#p4383136"]то не знаю как в вашем камне,[/uquote]У него не так.

Добавлено after 17 minutes 58 seconds:
danone78, выводите в логи все события и вашу реакцию на них. Только так получится понять что происходит.

На самом деле, кода в USB-OTG device даже меньше, чем в обычном типа f103-го. Просто сильно больше разных событий и разобраться на какие как реагировать и реагировать ли вообще не сразу получается. На переключение host <-> device забейте тупо забить. Включите принудительно device и не парьте себе мозг.

[danone78]

Power on programming done (dctl)=1
Вот чего нехватало.
Если быстро отловить все события с самого момента включения модуля usb, то можно увидеть, что он запускаетия в режиме device, но потом сразу переобувается в host. Внешние подтягивания id ни чего не дают.

[НАПАЛМ]

Всем привет
Хочу поделиться радостью, наконец-то осилил работу с буффером USB и сумел пройти процесс энумерации, используя cmsis (stm32f070)

Дескрипторы использовал вот такие:

Спойлер

Код: Выделить всё

const uint8_t USB_DEVICE_DESC[] = {

	// ***Default Device Descriptor***
	0x12, // bLength - Size of the [Device] descriptor in bytes (0x12 = 18)
	0x01, // bDescriptorType - [Device] descriptor type code
	0x00, // bcdUSBL - Claimed version compliance (0x0110 = USB v1.1; 0x0200 = USB v2.0)
	0x02, // bcdUSBH
	0x00, // bDeviceClass - Indicates that this device is of no particular device class
	0x00, // bDeviceSubClass - Indicates that there’s no particular subclass
	0x00, // bDeviceProtocol - No device-specific protocol
	0x40, // bMaxPacketSize - Indicates the maximum packet size for Endpoint0 (0x40 = 64)
	0x83, // idVendorL - Manufacturer’s Vendor ID (0x10C4 - CP2102, 0x0483 - STMicroelectronics)
	0x04, // idVendorH
	0x40, // idProductL - Manufacturer’s Product ID (0xEA60 or 0xEA70 - CP2102) (VID 0x0483; PID 0x5740; STMicroelectronics Virtual COM Port)
	0x57, // idProductH
	0x00, // bcdDeviceL - Product version in BCD
	0x01, // bcdDeviceH
	0x00, // iManufacturer - Manufacturer string descriptor index (0x01 - if we will use string descriptors)
	0x00, // iProduct - Product string descriptor index (0x02 - if we will use string descriptors)
	0x00, // iSerialNumber - Serial string descriptor index (0x03 or 0x05 - if we will use string descriptors)
	0x01  // bNumConfigurations - Number of possible configurations
};

const uint8_t USBD_CDC_CFG_DESCRIPTOR[] = {

	// ***Default Configuration Descriptor***
	0x09, // bLength - Size of the descriptor in bytes
	0x02, // bDescriptorType - Configuration descriptor type code
	0x20, // wTotalLengthL - Total length of data returned for configuration 0 (stored in little-endian order) (0x0020 or 0x0037) (0x0020 = 32)
	0x00, // wTotalLengthH
	0x01, // bNumInterfaces - Number of interfaces in this configuration
	0x01, // bConfigurationValue - Indicates the value to be used in a Set Configuration packet to activate this configuration
	0x00, // iConfiguration - Index of the string descriptor describing this configuration (if we will use string descriptors)
	0x80, // bmAttributes - Indicates the characteristics of the device when this configuration is selected (bit 7 set: Device is bus powered; bit 6 off: Device is self powered)
	0x64, // MaxPower - Maximum power consumption in 2mA units. For self-powered devices, this field is zero (0x64 = 100 = 200 mA)

	// ***Default Interface Descriptor***
	0x09, // bLength - Size of the descriptor in bytes
	0x04, // bDescriptorType - Interface descriptor type code
	0x01, // bInterfaceNumber - The interface described by this descriptor
	0x00, // bAlternateSetting - Indicates the alternate setting which enables the interface to operate as described
	0x02, // bNumEndpoints - This interface has 2 Endpoints
	0x02, // bInterfaceClass - Indicates that this is a vendor-specific interface (Base Class 02h - Communications and CDC Control)
	0x00, // bInterfaceSubClass - No particular subclass
	0x00, // bInterfaceProtocol - The interface uses no specific protocol
	0x00, // iInterface - Index of the string descriptor describing this interface (0x02, 0x03, or 0x04 - if we will use string descriptors)

	// ***Default IN Endpoint (1) Descriptor***
	0x07, // bLength - Size of the descriptor in bytes
	0x05, // bDescriptorType - Endpoint descriptor type code
	0x81, // bEndpointAddress - IN Endpoint 1 (0x81 or 0x82)
	0x02, // bmAttributes - Bulk Endpoint
	0x20, // wMaxPacketSizeL - The maximum packet size is 64 or 32 bytes (0x0040 = 64; 0x0020 = 32)
	0x00, // wMaxPacketSizeH
	0x00, // bInterval - Not used for Bulk Endpoints

	// ***Default OUT Endpoint (2) Descriptor***
	0x07, // bLength - Size of the descriptor in bytes
	0x05, // bDescriptorType - Endpoint descriptor type code
	0x02, // bEndpointAddress - OUT Endpoint 2 (0x01 or 0x02)
	0x02, // bmAttributes - Bulk Endpoint
	0x20, // wMaxPacketSizeL - The maximum packet size is 64 or 32 bytes (0x0040 = 64; 0x0020 = 32)
	0x00, // wMaxPacketSizeH
	0x00  // bInterval - Not used for Bulk Endpoints
};

В винде ожидаемо получил ошибку с кодом 10, потому что, как я понял, у каждого вендора свой проприетарный CDC протокол, со своими командами и наборами конечных точек.

изображение_2023-03-31_155713754.png

(18.44 КБ) 60 скачиваний

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

[JackSmith]

каждого вендора свой проприетарный CDC протокол,

в Linux cdc-acm дрйвер как раз универсальный, а всякие там uart-преобразователи навроде FT232R, PL2303 идут в ядре отдельными модулями.

[НАПАЛМ]

[uquote="JackSmith",url="/forum/viewtopic.php?p=4394273#p4394273"]

каждого вендора свой проприетарный CDC протокол,

в Linux cdc-acm дрйвер как раз универсальный, а всякие там uart-преобразователи навроде FT232R, PL2303 идут в ядре отдельными модулями.[/uquote]
Спасибо, посмотрю
Там есть какие-то подводные камни, о которых стоит заранее знать? Возможно проверенные временем примеры работы?

[JackSmith]

да вроде нет. у меня прога самописная для Linux, монитор порта последовательного порта. она одинаково работает как c CDC так и с ttyUSB девайсами. но проблем. если какие-то вопросы будут, смотрите исходники CDC-ACM драйвера в ядре.

[COKPOWEHEU]

[uquote="НАПАЛМ",url="/forum/viewtopic.php?p=4394284#p4394284"]Там есть какие-то подводные камни, о которых стоит заранее знать? Возможно проверенные временем примеры работы?[/uquote]
Есть, конечно. Слишком многие рукожопы производители предпочитают вместо стандартной реализации CDC реализовывать собственные протоколы, которые требуют разработчикам ОС писать под каждую такую кривульку собственный драйвер.
Отдельно под виндой бывает проблема если VID:PID уже под что-то зарезервированы или просто не могут быть адекватно распарсены (в линуксе, разумеется. такой проблемы нет). Как это починить точно не знаю. Можно разве что попробовать поиграться с теми же VID:PID.

[JackSmith]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4394437#p4394437"]Отдельно под виндой бывает проблема если VID:PID уже под что-то зарезервированы .[/uquote]
В Linux тоже будут проблемы, если vid:pid уже забит под какое-то известное устройство. А так, драйверу должно быть без разницы.

[VladislavS]

Всего то нужно - соблюдать спецификацию.

[COKPOWEHEU]

[uquote="JackSmith",url="/forum/viewtopic.php?p=4394535#p4394535"]В Linux тоже будут проблемы, если vid:pid уже забит под какое-то известное устройство.[/uquote]
Разве что вы пытаетесь назначить VID:PID от какой-то кривульки, у которой дескрипторы говорят о стандартном устройстве, но требуют специальных дров, и вам не повезло реализовывать то же самое устройство. Ну или вы сами пытаетесь реализовать vendor-specific (хотя даже тогда можно в udev прописать что захочется). В общем, под линуксом проблем на порядок меньше.