stm32 USB host

[HardWareMan]

danone78 писал(а):

Получается что раз в милисеунду обязательно на SOF прерывание залетать?

Конечно! SOF выдаёт хост каждое нормированное стабильное время (для USB1/USB2 это 1мс). Это базовая синхронизация шины. А ещё некоторые устройства используют его для определения спячки: если питание есть а SOFы пропали - можно спать, пока не прилетит новый SOF. Ну и для HID устройств SOF можно использовать как маркер обновления состояний кнопок, причём в некоторых мышах можно задавать количество SOF через которое происходит обновление: те самые игровые FS/HS мышки настраиваются на частоту опроса до 1000/секунду это оно и есть.

[COKPOWEHEU]

danone78 писал(а):

Разобрался что надо PID чередовать, вот только черный нечетный кадр пробовал менять и разницы не увидел. Получается что раз в милисеунду обязательно на SOF прерывание залетать? И.. я не понял где кнопки? Смещения координат я получаю, а кнопки то куда? Жму кнопку, прилетает пакет с нулями.

DATA1/DATA0 девайсы могут и не проверять. Хотя те, что я видел (кроме vusb) проверяли.
Кнопки должны быть в том же репорте. Но точнее стоит проверить по HID-дескриптору.
Возможно, поможет моя статья: https://habr.com/ru/articles/551720/

Если все биты описаны в мануале, то нормально.

Это вы, видать, забыли насколько криво они описаны.

Значит у вас размер точек был маленький.

Вроде почти до максимума тестировал. Там же 512-байтный кусок памяти, минус 64 байта на таблицу размещения, минус 8-64 байта на EP0, да пополам ради двойной буферизации. 220 байт за раз получается. Кажется, изохронные точки - единственные в USB-FS, на которые не распространяется ограничение 64 байта.

А значит - и максимальная скорость изохронной передачи ограничена - менее 1/4 от максимально возможной для USB-FS.

Только на прием ("микрофон"). На передачу ("динамик") хост шлет несколько запросов.

Получается - STM32L не соответствует даже требованиям USB-FS. Или не полностью соответствует.

Отчего же не соответствует. Аудиоустройства на нем делать можно? Можно. Даже скорость обмена вполне приемлемая получается. Этого с запасом хватит на два канала 16 бит 48 кГц.

Конечно! SOF выдаёт хост каждое нормированное стабильное время

Вроде бы это начиная с USB-2. Для LS посылать SOF обязательно только если нет обычного обмена. Потому что активность на шине - признак ухода в сон.

количество SOF через которое происходит обновление: те самые игровые FS/HS мышки настраиваются на частоту опроса до 1000/секунду это оно и есть.

Чего?!
Скорость обновления interrupt точки прописана в ней самой, и ни к каким SOF не привязана.

[VladislavS]

COKPOWEHEU писал(а):

Это вы, видать, забыли насколько криво они описаны.

Нормально всё описано. Непонятно, как может вызвать проблемы прямое указание на правила работы с битами? Операция "исключающее ИЛИ" с битами это так сложно?

изображение_2024-12-10_112447943.png

(53.31 KiB) Скачиваний: 262

[COKPOWEHEU]

Все возможные способы доступа это сложно. Извратные маски, которые вследствие этого приходится накладывать, это сложно. Что им мешало не по 1 инвертировать, а по 0? Или наоборот, по 1 сбрасывать бит в 0?

[smacorp]

Что мешало, что мешало... Я давно считаю, что спецификацию USB наркоманы писали, причём не абы какие, а в самый забористый приход или в период жуткой ломки, иначе непонятно за что они так подгадили человечеству.

[COKPOWEHEU]

smacorp писал(а):

Я давно считаю, что спецификацию USB наркоманы писали

Полностью согласен! 16-битные VID:PID. Хранение адреса на устройстве (при том, что реальная топология - дерево, а вовсе не шина). utf-16 для строк. Отсутствие прерываний (из-за чего пришлось вводить костыль с interrupt-точкой). Засовывание в диф пару не диф состояний. Манипулирование измерением напряжения вместо логических уровней (кажется, USB-HS так отличает себя от FS. Ну и PD, куда ж без него). 3.3 В на сигнальных линиях при 5 В на питании.
Это что с ходу вспомнилось.

[HardWareMan]

COKPOWEHEU писал(а):

количество SOF через которое происходит обновление: те самые игровые FS/HS мышки настраиваются на частоту опроса до 1000/секунду это оно и есть.

Чего?!
Скорость обновления interrupt точки прописана в ней самой, и ни к каким SOF не привязана.

Того!
Это Vendor-Specific реализация. Даже если заставить систему опрашивать мышь быстрее (вплоть до каждого SOF), это ещё не означает, что сам сенсор будет опрощен с такой же частотой. Поэтому, если опрашивать мышку чаще, чем она опрашивает свой сенсор, то мы просто получаем дублированные репорты либо NAK (смотря опять же как реализовал производитель). И это всё было разобрано чуть более полугода назад в этом треде: https://habr.com/ru/articles/811435/com ... t_26786417

[COKPOWEHEU]

HardWareMan писал(а):

Даже если заставить систему опрашивать мышь быстрее (вплоть до каждого SOF), это ещё не означает, что сам сенсор будет опрощен с такой же частотой.

Это означает, что максимальная частота опроса ограничена настройками эндпоинта. А внутри себя устройство может хоть миллион раз в секунду опрашивать (мало ли - усреднять, искать максимум), и это никак не привязано к протоколу обмена.

[HardWareMan]

COKPOWEHEU писал(а):

HardWareMan писал(а):

Даже если заставить систему опрашивать мышь быстрее (вплоть до каждого SOF), это ещё не означает, что сам сенсор будет опрощен с такой же частотой.

Это означает, что максимальная частота опроса ограничена настройками эндпоинта. А внутри себя устройство может хоть миллион раз в секунду опрашивать (мало ли - усреднять, искать максимум), и это никак не привязано к протоколу обмена.

bInterval в мс (считай - в SOFах). В дорогих игровых мышах он минимален, но это не воспрещает опрашивать их медленнее. Настройкой такого опроса занимается софт от этих мышей.

[COKPOWEHEU]

HardWareMan писал(а):

bInterval в мс (считай - в SOFах). В дорогих игровых мышах он минимален, но это не воспрещает опрашивать их медленнее. Настройкой такого опроса занимается софт от этих мышей.

Еще раз. SOF-то тут при чем? bInterval задается в миллисекундах. Частота опроса сенсора вообще внутреннее дело самой мыши. SOF вообще может не посылаться, для LS-устройств.

[jcxz]

COKPOWEHEU писал(а):

Вроде почти до максимума тестировал. Там же 512-байтный кусок памяти, минус 64 байта на таблицу размещения, минус 8-64 байта на EP0, да пополам ради двойной буферизации. 220 байт за раз получается. Кажется, изохронные точки - единственные в USB-FS, на которые не распространяется ограничение 64 байта.

Открыл тот свой проект на STM32L с изохронными USB. Вот так у меня распределена USB-ОЗУ:

Код:

#define USB_EP_NUM       2  //макс.кол-во эндпоинтов одновременно используемых в программе (не включая ep0)
#define USB_MAX_PACKET0  8  //Max Endpoint 0 Packet Size [8/16/32/64]
#define OFS2ADDR(ofs) ((u32 *)((char *)&usbMem + ((ofs) << 1 & ~3) + ((ofs) & 1)))

__packed union UsbBufDescTbl {
  struct {
    u16 addrTx, gap0;
    u16 countTx, gap1;
    u16 addrRx, gap2;
    u16 countRx, gap3;
  };
  struct {
    u16 addr, gap0;
    u16 count, gap1;
  } txrx[2];
};

__no_init struct UsbMem {
  u16 ep0[2][USB_MAX_PACKET0];
  union {
    u16 epStream1[2][epSize_ASET1]; //alt.set1
    u16 epStream2[2][epSize_ASET2]; //alt.set2
  };
  UsbBufDescTbl desc[2 + USB_EP_NUM];
} usbMem @ ".usb";

Получается - максимальный размер эндпоинта == (512-2*4*4-8*2)/2 = 232 байта. Если ничего не напутал.
Таблица размещения у меня = 2*4*4 = 32 байта (64 - это занимает в адресном пространстве).

COKPOWEHEU писал(а):

Только на прием ("микрофон"). На передачу ("динамик") хост шлет несколько запросов.

Для изохронных точек в USB-FS это невозможно. Там только один кадр на каждую точку за один фрейм (1 мсек).
В STM32L даже переключение буферов происходит аппаратно. По SOF-у.

COKPOWEHEU писал(а):

Получается - STM32L не соответствует даже требованиям USB-FS. Или не полностью соответствует.

Отчего же не соответствует. Аудиоустройства на нем делать можно? Можно. Даже скорость обмена вполне приемлемая получается. Этого с запасом хватит на два канала 16 бит 48 кГц.

Изохронные - это не только для аудио. Нам например нужно было более 600 КБ/сек (размер точки более 600 байт). С гарантированной полосой пропускания. И пролетели.
В результате - заменили STM32L на дедушку LPC1758 и получили вплоть до 1023 байт/мсек как с куста. Так как NXP не пожалел ОЗУ под USB-RAM.

COKPOWEHEU писал(а):

Скорость обновления interrupt точки прописана в ней самой, и ни к каким SOF не привязана.

Она же кратна целому количеству SOF. А значит логично её стартовать от счётчика, декрементируемого по SOF.

[COKPOWEHEU]

jcxz писал(а):

} usbMem @ ".usb";[/code]Получается - максимальный размер эндпоинта == (512-2*4*4-8*2)/2 = 232 байта. Если ничего не напутал.
Таблица размещения у меня = 2*4*4 = 32 байта (64 - это занимает в адресном пространстве).

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

jcxz писал(а):

Для изохронных точек в USB-FS это невозможно. Там только один кадр на каждую точку за один фрейм (1 мсек).
В STM32L даже переключение буферов происходит аппаратно. По SOF-у.

Не по SOF, а по запросам хоста, как и любые другие точки. На IN он посылает единственный запрос на фрейм. А на OUT - может несколько. Если настроить битрейт динамика так, чтобы не помещался в одну точку, хост прекрасно разбивает поток на несколько транзакций. wireshark-ом это прекрасно видно. Я пытался и на IN что-то сделать (размер точки, скорость опроса, даже в сторону синхронизации смотрел) но, похоже, не выйдет.

jcxz писал(а):

Изохронные - это не только для аудио. Нам например нужно было более 600 КБ/сек (размер точки более 600 байт). С гарантированной полосой пропускания.

Тут да, ограничение. Хотя я бы поставил какой-нибудь CDC-ACM и не мучился. Полоса пропускания современных хостов настолько больше предела USB-FS, что уж с этим проблем быть не должно.

Она же кратна целому количеству SOF. А значит логично её стартовать от счётчика, декрементируемого по SOF.

Всего лишь "совпадает". А начинать новое преобразование логично когда завершилось предыдущее. Или когда предыдущее послано. Интервал между interrupt-IN и interrupt-IN кажется более стабильным, чем между SOF и interrupt-IN.
Не надо лепить SOF куда попало.

[danone78]

https://cloud.mail.ru/public/8wGW/YGCiX9YTp

[HardWareMan]

danone78 писал(а):

https://cloud.mail.ru/public/8wGW/YGCiX9YTp

Победа?

[danone78]

Если не менять DATA 0/1 , то через кадр сыпятся Toggle error. Все отлично, но прилетает TXERR (Transaction error) в одной SUTUP транзакции. Ну мой драйвер любые повторы делает по событиям от прерывания канала не дожидаясь СОФ, все равно со второй попытки все проталкивается дальше. Если каждый пакетик слать в начале фрейма, то даже NACK-ов нету, а так мышь не успевает что-ли, или как-то надо мониторить конец кадра.

[jcxz]

danone78 писал(а):

Если не менять DATA 0/1 , то через кадр сыпятся Toggle error. Все отлично, но прилетает TXERR (Transaction error) в одной SUTUP транзакции. Ну мой драйвер любые повторы делает по событиям от прерывания канала не дожидаясь СОФ, все равно со второй попытки все проталкивается дальше. Если каждый пакетик слать в начале фрейма, то даже NACK-ов нету, а так мышь не успевает что-ли, или как-то надо мониторить конец кадра.

Т.е. - так толком и не заработало и причины ошибок не найдены...

[danone78]

Все, разобрался, работает отлично, без ошибок, даже без NACK-ов и на одном канале. То есть я вообще не задействую второй канал, просто переключаю канал после инициализации мышки под другой тип передач.
Весь обработчик прерывания от мышки уместился в 400 строк. Хрю