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

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

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

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

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

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

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

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

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

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

Открыт интернет-магазин MEAN WELL.Market – весь ассортимент MEAN WELL, выгодные цены

Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России. На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.

Подробнее>>

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

LED-драйверы MOSO - надежные решения для индустриальных приложений

Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO подробнее>>

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

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

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

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

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

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

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

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

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

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

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

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

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

Победа?

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

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

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