Делюсь опытом Power Profiler на рельсах AdHoc protocol

pvvx

Активный участник сообщества
Как самый простой вариант - это мой же CV Meter, где я протокол передачи замеров подогнал под ограничения USB в 64 байта
64 - это самое неоптимальное. При передаче/приеме блока в 64 байта передается 2 блока - один в 64 байта, второй в 0 байт, который указывает что прошлый блок в 64 байта является законченной передачей.
Если передали 63 байта, то этого не происходит. Вроде это фича от MS при CDC. В других классах этого нет.
 

pvvx

Активный участник сообщества
Т.е. при получении 64 байт драйвер ожидает что будет ещё блок и ему необходимо передать или нулевой завершающий блок или блок с данными отличными от 64 байт.
В итоге блок на уровне выше ограничен размером fifo у USB чипа, но передается пачками по 64 байта.
Прям как в BT4.2 при указании MTU более 23 байт. Блоки укладываются в период опроса в 1 ms...
 

pvvx

Активный участник сообщества
Так-же сам драйвер от MS гонит сразу 256 байт (4 блока) и по подтверждениям угадывает - могет ли ваше устройство это сожрать.
 

pvvx

Активный участник сообщества
У STM "своя драйвера" и ничего об этом не знает... В итого часто ограничено трафиком в 64*1000 байт...
 

pvvx

Активный участник сообщества
Нормально передавать до 2048 байт (32 блока). Больше уже не столь выгодно... далее на скорость сильно не влияет в USB1.1, который только и есть у STM32...
FIFO у чипов на мамке всё равно больше - за 4 кило.
 

pvvx

Активный участник сообщества
В итоге throughput USB1.1 стремится к 800 кило/сек, а не как при использовании AdHoc - 1..2 кило в сек :)
А из-за тормозов самого MCU трафик падает к 400 кило/сек. Особенно падает при HAL STM32.
 

pvvx

Активный участник сообщества
Если следовать рекомендациям креативного клоуна про его калбаски и HAL от ST, то USB у STM32 вообще превращается в UART c 9600 бод как максимум.
 

A_D

Active member
64 - это самое неоптимальное. При передаче/приеме блока в 64 байта передается 2 блока - один в 64 байта, второй в 0 байт, который указывает что прошлый блок в 64 байта является законченной передачей.
Если передали 63 байта, то этого не происходит. Вроде это фича от MS при CDC. В других классах этого нет.
Ну я сделал так, как это возможно в HAL для STM32F103 и подобных для класса USB Custom HID, там Report ограничен в 64 байта вроде как. https://community.st.com/s/question...hid-increase-report-size-from-64-to-256-bytes Я ещё вернусь к этому вопросу скоро, тут платы измерителей приедут на неделе и там надо будет и прошивку допиливать и софт обновить - оч много чего нового в планах, как и разбор протокола и производительности в целом.
 

pvvx

Активный участник сообщества
Причину можно лехко описать – пока выполняется великий и неспостижимый деоптимизированный на байты машинно писанный калбак от AdHoc host уже начнет тормозить, т.к. ему нужон ответ в fifo usb поинта… И так-же всем известно, что работа даже с GPIO через HAL ST тормоз в более чем в 10 раз от реально возможной на том-же чипе. Аналогично и с трафиком на USB, а приплюсовав туда дикий деоптимизированный на байты код AdHoc - счет уже идет в дцать раз. По этому креативный клоун и не заканчивает пример для STM32F103 со своим AdHoc, а тольrо рекламирует свою белиберду.
 

A_D

Active member
У STM "своя драйвера" и ничего об этом не знает... В итого часто ограничено трафиком в 64*1000 байт...
Вот да, это для USB FS ограничение, а для USH HS этого ограничения нет, но это уже надо ставить внешний USB HS PHY и МК уже нужно ставить с поддержкой ULPI ... это избыточно всё как-то пока что.
 

pvvx

Активный участник сообщества
Ну я сделал так, как это возможно в HAL для STM32F103 и подобных для класса USB Custom HID, там Report ограничен в 64 байта вроде как.
Я про это и говорю - у STM своя фича. Всё равно на нем работают через HAL, а быстрее он не могет. По этому наверно и ограничили.
Да и у младших нету 2к буферов, если всё писать по классике...
И про скорость самого CPU тоже всё давно расписано - cortex для полного USB2.0 надо более сотни MHz.
 

A_D

Active member
Причину можно лехко описать – пока выполняется великий и неспостижимый деоптимизированный на байты машинно писанный калбак от AdHoc host уже начнет тормозить, т.к. ему нужон ответ в fifo usb поинта… И так-же всем известно, что работа даже с GPIO через HAL ST тормоз в более чем в 10 раз от реально возможной на том-же чипе. Аналогично и с трафиком на USB, а приплюсовав туда дикий деоптимизированный на байты код AdHoc - счет уже идет в дцать раз. По этому креативный клоун и не заканчивает пример для STM32F103 со своим AdHoc, а тольrо рекламирует свою белиберду.
Ну, с AdHoc можно сказать уже давно всё понятно... сколько месяцев прошло, а примера всё нет, но ладно, можно списать на COVID-19, может быть, скоро будет пример... или появится COVID-20 и релиз опять отодвинется. Просто в моём случае, я решил, что заплатив падением производительности я лучше получу быстрее работающий вариант (можно сказать почти как ардуино, но разбираться надо больше чем в ардуино - там бы просто всё скетчем в N-строк решалось бы, правда, получался бы СОМ-порт или подобное), в итоге, производительности хватило более чем.
 

pvvx

Активный участник сообщества
Таков ужас архитектуры аппаратуры устройств от ST. Всё обрезано до предела - типа жалели каждый кубический нанометр из песка :)
 

pvvx

Активный участник сообщества
Вот да, это для USB FS ограничение
Нету такого ограничения. Оно искусственное, наведенное от ST.
У TLSR8266 CPU вообще тормоз. Работает с кеша в RAM, в который программа поступает с SPI Flash. Т.е. примерно на порядок медленнее чем STM32F103.
Но без проблем прокачивает более 400 килобайт в USB-CDC. При этом у него USB не пользуется и DMA, а работает FIFO в который надо CPU побайтно запихать 64 байта в программном цикле...
Есть там режим с псевдо DMA к специальной usb-point, но оно повязано на I2S или DAC/ADC-SAR и требует NDA чтобы узнать как включить...
 
Сверху Снизу