Stm32 с чего начать изучение...

[Eddy_Em]

Товарищи, а кто-нибудь вообще поднимал на F407 USB-host? Я так, интереса ради спрашиваю.
Почуть начал с ним ковыряться, вижу, что OTG жутко отличается от USB у F0x2, F103 и F303. Нет дебильных toggle-флагов, но с другой стороны, как-то хрен поймешь, как это вообще завести. Авось, через месяц-два портирую CDC (а, может быть, и HID, только HID в реальной жизни нафиг не нужен).

Что интересно, на гитхабе вообще не нашел работы с USB на F407 без калокуба/SPL или opencm3. У народа совсем что ли никакой творческой жилки нет?
А про host ради интереса спрашиваю: понятно, что это вообще не нужно для МК, но хотелось бы посмотреть на размер кода, скажем, реализующего работу с внешней клавиатурой…

[azhel12]

Буквально сегодня довел +- до работоспособного состояния OTG FS, но пока только как Device, в целом, как я понял, грандиозной разницы с режимом хоста быть не должно: отправляй себе OUT/IN-пакеты в конечные точки и жди ответа. Сделал без куба, на шаблонах, так что творчество максимальное (правда, по мнению некоторых, несколько наркоманское).

[Eddy_Em]

azhel12, да мне host чисто посмотреть на адов объем кода интересен. Скажем, для подключения мыши туда из линукса придется тонну модулей клавиатуры тащить…
А ты не пробовал HS? Там принципиальная разница с FS есть? И можно ли выжать адовы мегабайты в секунду?

[azhel12]

Про HOST не подскажу тогда, хотя разогнался, возможно, что попробую скоро. Мне кажется, что по крайней мере для стандартных классов много тащить не придется, можно Wireshark-ом посмотреть, что ОС от мышки просит и воспроизвести.

Я почти уверен, что помимо нужного ОС (Windows так точно) спамит как по количеству, так и по типам запросов, то есть можно обойтись меньшим объемом. Когда-то делал эмулятор мышки, так там для девайса пакет был в районе 10 байтов.

HS не пробовал, но разницы там или совсем нет, или она минимальная, я так и не понял, зачем у них стоит и FS, и HS одновременно.

[Eddy_Em]

Да понятно, что самого HID будет как кот наплакал, а вот всего более высокого уровнем… Взять, скажем, простейшую клавиатуру: /usr/src/linux/drivers/hid/usbhid/usbkbd.c (398 строк), а бывают ведь и нестандартные. Мышка - и та 232 строки!..
А если флешку поддерживать? Вот жесть какая:

Код:

wc -l /usr/src/linux/drivers/usb/storage/*.[ch]
...
 22995 итого


И это - только базовый уровень. А еще - как минимум EXT2 или EXT3 надо. Сейчас все это заныкали в код EXT4, а он аж 61410 строк! Понятно, что никому нафиг EXT4 на флешке не нужна, там EXT2 за глаза, т.е. придется выдирать из какого-нибудь ядра еще первого поколения более-менее стабильный.

В общем, и врагу не пожелаешь такого титанического труда, как флешку присобачить к микроконтроллеру!

UPD: прошелся сейчас по своим исходникам для МК. Вот для F0x2:

Код:

for f in *; do [ ! -d $f ] && continue; echo -en "$f: "; cat $(find $f -name *.[hc]) | wc -l; done
3steppersLB: 4814
blink: 87
canbus: 960
CANBUS_SSI: 3376
CANbus_stepper: 4136
Chiller: 1480
F0_testbrd: 2810
htu21d_nucleo: 605
morze: 573
NUCLEO_SPI: 464
pl2303: 1631
QuadEncoder: 607
Servo: 1353
Snippets: 431
Socket_fans: 2734
TM1637: 850
tsys01_nucleo: 512
uart_blink: 288
uart_blink_dma: 296
uart_nucleo: 295
usbcan: 2309
usbcan_relay: 3023
USBHID: 1665
USB_pl2303_snippet: 1506


Или для F103:

Код:

BMP180: 2041
BMP280: 2421
CDC_ACM: 1509
chronometer: 3948
chronometer_v2: 3969
chronometer_v3: 9047
DHT22_DHT11: 1532
DS18: 2031
F1_testbrd: 1752
I2Cscan: 1842
led_blink: 89
LED_Screen: 20111
MAX7219_screen: 1841
MLX90640: 2818
PL2303: 1573
PL2303_ringbuffer: 1734
pl2303_snippet: 1388
pl2303_snippet_naked: 1201
pwmdmatest: 1300
pwmtest: 1350
RGB_LED_Screen: 11221
SevenCDCs: 2024
SI7005_HTU21D: 2250
SPI: 1356
Tetris: 8343
uart: 486
USB_HID: 1645
USB_SPI: 1763
ws2815: 1546


Везде, где больше 4000 строк, основное - это определение шрифтов (там и 5000 строк спокойно может быть, правда, часть я честно руками рисовал, без генератора). А тут внезапно - десятки тысяч строк. И ради чего??? Мне не нужно к МК подключать клаву, экран, флешку и т.п. хрень, если я хочу телескопом или каким-нибудь научным оборудованием управлять. МК сам подключен к компьютеру по USB или CAN, так и управляется…

Последний раз редактировалось Eddy_Em Пн ноя 07, 2022 23:33:05, всего редактировалось 1 раз.

[azhel12]

Eddy_Em писал(а):

В общем, и врагу не пожелаешь такого титанического труда, как флешку присобачить к микроконтроллеру!

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

[Eddy_Em]

Ну, если с нуля делать, то времени много уйдет. У меня на CDC больше полугода ушло… Правда, я и не очень-то активно пытался. А потом завел USART на 3Мбод, забульбенил буфер побольше и DMA, подключил преобразователь на ch340, да спокойно смотрел, что у меня там не так происходит. Какой-нибудь gdb совершенно не поможет понять, как оно там по прерываниям скачет и на каком этапе косяк происходит.

[azhel12]

В смысле Host-mode победили? Иногда в ваш гитхаб заглядываю, но не находил, если упустил, то дайте ссылку, пожалуйста. Я тоже в прошлом году побеждал CDC, сейчас вот MSC.
Знаю, что вы не любитель C++, но очень удачно иерархическая структура USB (Устройство->Конфигурации->Интерфейсы->Конечные точки + классозависимые сущности) накладывается на современные variadic-шаблоны. Например, так выглядит обработчик запроса дескриптора конфигурации:

Код:

template <uint8_t _Number, uint8_t _MaxPower, bool _RemoteWakeup = false, bool _SelfPowered = false, typename... _Interfaces>
class Configuration
...
static uint16_t FillDescriptor(ConfigurationDescriptor* descriptor)
{
  uint16_t totalLength = sizeof(ConfigurationDescriptor);

  *descriptor = ConfigurationDescriptor {
    .InterfacesCount = sizeof...(_Interfaces),
    .Number = _Number,
    .Attributes = {.RemoteWakeup = _RemoteWakeup, .SelfPowered = _SelfPowered},
    .MaxPower = _MaxPower
  };

  uint8_t* interfacesDescriptors = reinterpret_cast<uint8_t*>(descriptor);
  ((totalLength += _Interfaces::FillDescriptor(reinterpret_cast<InterfaceDescriptor*>(&interfacesDescriptors[totalLength]))), ...);

  descriptor->TotalLength = totalLength;

  return totalLength;
}


Конфигурации все равно, что там ниже, у нее просто есть набор интерфейсов. Обработчик запроса дескриптора интерфейса такой же:

Код:

template <uint8_t _Number, uint8_t _AlternateSetting, DeviceAndInterfaceClass _Class, uint8_t _SubClass, uint8_t _Protocol, typename _Ep0, typename... _Endpoints>
class Interface
...
static uint16_t FillDescriptor(InterfaceDescriptor* descriptor)
{
  uint16_t totalLength = sizeof(InterfaceDescriptor);

  *descriptor = InterfaceDescriptor {
    .Number = _Number,
    .AlternateSetting = _AlternateSetting,
    .EndpointsCount = EndpointsCount,
    .Class = _Class,
    .SubClass = _SubClass,
    .Protocol = _Protocol
  };
 
  uint8_t* endpointsDescriptors = reinterpret_cast<uint8_t*>(descriptor);
  ((totalLength += _Endpoints::FillDescriptor(reinterpret_cast<EndpointDescriptor*>(&endpointsDescriptors[totalLength]))), ...);

  return totalLength;
}


То есть интерфейсу тоже все равно, что там дальше, у него просто есть какие-то конечные точки.

Такая схема и на классы ложится хорошо. Например, сейчас делал MSC, там под интерфейсом лежат LUN-ы, поэтому класс параметризуется соответствующими variadic-параметрами и в одну строчку диспетчеризуется.

[Eddy_Em]

azhel12, да не, тупо device, конечно! Я ж говорю, что мне host вообще ни к чему.
Про С++ мне уже много кто говорит (особенно в плане разработки под PC, где я, по сути, чуть ли не каждый раз на С ООПщину реализую). Но у меня от современного С++ волосы дыбом встают. Не хочу я разбираться с таким сложным языком. Пока что С является оптимумом. Да и собирается не так долго, как С++ на шаблонах (а я подчас за 10 минут несколько раз переделываю код, компилирую, запускаю, и смотрю - так ли оно идет, отладка многопоточного софта - тот еще гемор).

[azhel12]

Eddy_Em, жаль, я уже обрадовался. Потому что с ваших CMSIS-ных сниппетов удобно срисовывать всё, так что поблагодарю, пользуясь случаем.
Сборка шаблонов - это полбеды, беда начинается, когда ошибки возникают, потому что компилятор считает своим долгом развернуть ВСЕ шаблонные аргументы и путь до места с ошибкой занимает много строк

[Eddy_Em]

azhel12, у шланга намного приятней диагностический выхлоп, чем у gcc. Я одно время даже сишные файлы в случае непонятной ошибки шлангом прогонял, чтобы понять, что там за ë-моë, но сейчас уже 12-й gcc вышел в stable (правда, я особо на передовую не лезу, пользуюсь 11-м для PC и 8 или 9 для STM32 (на десятом что-то не так было с тулчейном, прошивки не заводились).

[VladislavS]

azhel12 писал(а):

Например, так выглядит обработчик запроса дескриптора конфигурации:

Дескрипторы это константные сущности. Хорошо, если в результате будет не просто массив во флэш, а объект, который может отдать список интерфейсов и конечных точек, к примеру, да ещё и в компайлтайме. Не знаю, может видели, я вот так когда-то делал. C++ USB Descriptors.

[MLX90640]

современные variadic-шаблоны.

Новое - это хорошо забытое старое. Аналог valist в Си. И далеко не самый удачный способ.

[VladislavS]

MLX90640 писал(а):

Аналог valist в Си.

Даже не близко. Подробности для этой темы злобный офф.

[MLX90640]

Функциональный аналог. Реализацию, понятное дело, чутка иначе записали. Вообще, в С++ довольно много костылей, реализованных так же как и в Си, через подключаемых библиотеки.
Кто без лишнего холивара разбирается в языках, те знают достоинства и недостатки и трезво оценивают возможности, без крика и биться пяткой в грудь.

[VladislavS]

MLX90640 писал(а):

Функциональный аналог.

Ни разу не аналог. Пепеменное кол-во аргументов функции это про рантайм и реальные данные. Вариативный шаблон это про типы и константы на этапе компиляции. Причём как для функций, так и для классов. Если __VA_ARGS__ хотябы отдалённо в ту сторону, то va_list даже не рядом.

[azhel12]

VladislavS писал(а):

Не знаю, может видели, я вот так когда-то делал.

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

Можно наоборот пойти: объявить, как у вас в примере, дескрипторы, только модифицировать их, чтобы заодно они по конечным точкам распределили регистры, PMA и т.д.

[VladislavS]

azhel12 писал(а):

Можно наоборот пойти: объявить, как у вас в примере, дескрипторы, только модифицировать их, чтобы заодно они по конечным точкам распределили регистры, PMA и т.д.

Не, не, не! Никаких заодно. Дескрипторы это самостоятельные сущности, которые ничего не должны знать о том на каком чипе они работают. Вполне достаточно, что они "отдают" список и типы интерфейсов и конечных точек. Распихивать это всё по регистрам (на основе дескрипторов) - прерогатива класса конкретного чипа.

[COKPOWEHEU]

azhel12 писал(а):

очень удачно иерархическая структура USB (Устройство->Конфигурации->Интерфейсы->Конечные точки + классозависимые сущности) накладывается на современные variadic-шаблоны.

Пф-ф-ф, да она на дубовые Си-шные мракосы накладывается: https://github.com/COKPOWEHEU/usb/blob/ ... lass.c#L53

Авось, через месяц-два портирую CDC (а, может быть, и HID, только HID в реальной жизни нафиг не нужен).

Если устройство пройдет энумерацию, то 80% работы сделано. Останется только доработать специфику других типов конечных точек да алгоритм опроса.

[azhel12]

VladislavS писал(а):

Дескрипторы это самостоятельные сущности

Я не совсем согласен, дескриптор (даже само слово переводится как "описатель") - это описание сущности, не он главный, не он порождает сущности, а наоборот.
Вообще можно долго на этот счет спорить, я для себя постарался этот вопрос упростить до "не писать одно и то же дважды".
Например, слепил я дескриптор (на шаблонах, или на макросах, как COKPOWEHEU предложил, неважно), независимо определил интерфейсы/конечные точки (в C++ это будут скорее всего классы), которые, в принципе, не обязаны знать свои номера/классы и т.д. (хотя макс.размер пакета, наверно, должны, уже дублирование), здесь с вами согласен на 100%. Однако где-то мне потом все равно придется указать, что X точка в дескрипторе - это на самом деле Y точка в программе, чего я делать не хочу. Прошу прощения, что, возможно, непонятно объясняю, но как умею:)