Пока свой. Считаем, что для отправки это сыровато. Вот когда проведём исчерпывающее тестирование и Заказчик погоняет на большом наборе боевых данных, тогда... Но идея уже достойна публикации, поэтому и описали. Потом детали забудутся.
По первому пункту, всё просто. У Заказчика был свой список контроллеров, и менять он его не хотел. И за решение своей проблемы оплачивал работы. Поэтому замечательно, что производители тоже думают над решением этой проблемы, но Заказчику требовалось решить на его технике. И у нас есть разрешение опубликовать результаты исследований.
По второму - всё тоже не сильно сложно. Мы на тестовых примерах разобрались с этой самой таблицей GOT, на очередном совещании с Заказчиком показали всё на эту тему, получили чёткое указание больше в этом направлении не работать... И, собственно, не работали. Так что боевых метрик мы не снимали.
Без конкретики, сама идеология в начале статьи расписана. При этом было бы полбеды, если бы выросла прошивка. Когда прошивка растёт - данные в ОЗУ сдвигаются. А когда они не сдвигаются - растёт не прошивка, а требования к ОЗУ. А его мало. Это - то, что успели выяснить до того, как нам сказали идти другим путём.
Вот Вам готовое решение для Тинси, основанное на библиотеках Ардуино. Я своё делал на его базе. Повторю - шагать нельзя! Только ставить точки останова и смотреть переменные, когда эти точки сработали. Дело в том, что там всё делается за счёт внедрения в точку останова команды SVC, если неверно определено положение следующей вставки - всё упадёт.
Проблем с UART и I2C не замечали во время проекта. Да и откуда им там быть? Может, конечно, тестовые задачи были недостаточно суровые. Но надеюсь, нет их.
Не нашёл, как в новом дизайне править комментарии.
Я-то в голове MCUXPressные библиотеки держал. А Ардуиновские UART библиотеки настолько удивительные, что там всё, что угодно может случиться, если работать через верхний уровень. Низкоуровневые - относительно приличные. Но опять же, в статье не показано, как шла работа.
По первому пункту, я наловчился хоть как-то вести отладку через MCUXpresso, но используя UART вместо JTAGа. Так можно. На стороне Тинси реализуется функционал GDB Stub, а самому GDB надо сообщить, что он работает через UART. В одной из следующих статей планирую рассказать про это, если интерес будет (часть статей уже написана, они точно будут опубликованы, а эта - ещё не оформлена даже в виде DOC файла, так как первая статья была встречена очень холодно, а писать ради писанины - скучно). Но там полный изврат. Лучше, чем ничего, конечно. Можно ставить точки останова и просматривать любые переменные. Но шагать - опасно. Так что хоть оно и работает, я продолжаю утверждать, что нормальная отладка под Тинсей 4.1 невозможна.
А так я вообще люблю работать с Кейлом и не стремлюсь к изучению каких-то новых сред разработки. Но у нас был проект. Нам надо было освоить работу именно Тинси 4.1 именно через MCUXpresso и именно со всем широчайшим спектром тех библиотек. Заказчик разрешил опубликовать все результаты. Отчёт для Заказчика был на английском и несколько скучный. А тут я публикую своё видение на русском, со своей расстановкой акцентов. Так что изучал MCUXpresso я за зарплату, имея точный список библиотек, которые следует освоить. А силы на изучение Visual Micro, может, и появятся, но даже не знаю, когда. А в описании там деталей нет, как там отладка выполняется.
По второму же пункту - я прочитал статью. Скажу честно, по такому описанию какую-то диагностику сделать не смогу. Синхронная передача - всегда лучше, чем асинхронная. Но сам я с асинхронной никаких проблем не имел. Однако, там такое дикое сочетание возможных проблем... Вплоть до соотношения Baud Rate с частотами кварцев на обеих сторонах. И масса, масса, масса всего прочего. Так что ничего не могу сказать, не пощупав реальную систему. Иногда ощупывать приходится долго.
Да, там же, на crowd supply. Прелонч-страница была опубликована, прошли рассылки по их клиентам, собрали базу "подписавшихся", тех кто ожидает запуск, а потом запуститься так и не получилось - была очень долгая коммуникация (несколько месяцев), в процессе у нас уже и сам продукт изменился, решили не запускаться вообще.
Удачи! Надеюсь получится запустить проект. Мы два года назад со своим сервисом предоставления доступа к отладочным платам all-hw.com застряли на прелончевом этапе, пол года нас "мурыжили" менеджеры Crowd Supply, задавали всё больше и больше дополнительных вопросов, при этом не отвечали на наши, в итоге все "затухло" и мы просто отказались от продолжения. Но, возможно, это нам не повезло или не хватило терпения.
Спросил у тех, кто планирует это дело. Получил следующий ответ:
Пока планов таких нет, но планы довольно динамичны - платы появляются в основном в связи с проведением того или иного мероприятия, а иногда и просто из любопытства. Ближе всего к появлению в публичном доступе платы NVIDIA Jetson, Xilinx, а также с архитектурой RISC-V. Но если кто-то проспонсирует появление в сервисе H7 или организует публичные мероприятия на этих платах (тренинги, учебные программы и пр.), то она вполне может оказаться на первых позициях в этом списке.
Наш Заказчик захотел, чтобы одновременно использовался USB Host и USB Device. Родных библиотек от Тинси было явно недостаточно. Я сунул нос и загрустил. Потом долго и нудно правил их. А потом появилась вот эта идея... И родные библиотеки USB от NXP реализованы красиво, прозрачно и сопровождаемо.
Цикл статей не столько про саму среду разработки, сколько про библиотеки, которые идут с нею в нагрузку. Хотя, и про среду тоже... Но в целом - можно скачать SDK отдельно и пользоваться в любой среде. Я выбрал родную, чтобы меньше правок делать. Чем меньше правок при обучении, тем больше можно сосредоточиться на том, чему учимся. Плюс можно повторять шаги за мной, не держа в уме, что надо было что-то заранее поставить. Я стараюсь показывать действия от момента "поставили среду, начали работу". Дальше - каждый скорректирует под себя, если сама суть понравится.
В общем, может, и выбирают для работы со звуком. Но если попробовать библиотеки от самой NXP - возможно, можно будет выбрать и для других задач. Пусть все увидят такую возможность! Жаль только, что на плате нет отладочного порта...
Значит, есть повод сделать статью, когда четвёртую библиотеку её автор разгонит. Тогда я сделаю полезную нагрузку. На этот раз, в обе стороны! И опять, на радость знакомому, писавшему софт для осциллографа, сделаю много осциллограмм и сведу всё в таблицу.
Я никогда не забиваю память F103 под завязку. Ни ОЗУ, ни ПЗУ. С инженерной точки зрения, мне перечисленное Вами не интересно. Даже до ограничения бесплатного Кейла в 32К не добирался ни разу, а всего флэша там 64К. А насчёт научного подхода — мой научный руководитель много интересного говорил… Короче, это не для меня. Я — инженер до мозга костей, и горжусь этим. Все эти скучные таблицы, не имеющие практического смысла — они для кого-то другого. Я их даже не читаю, не говоря про составление.
Короче, эти параметры, на мой взгляд, вторичны. А вот производительность — это да. Её вечно не хватает. На ней и сосредоточился. Она примерно одинаковая. Но у одной из них спорная устойчивость, хоть и не доказаны проблемы.
Загрузка ядра — в прошлой статье были осциллограммы, там был виден процент нахождения в прерывании.
Но на серьёзную статью ушли бы недели или даже месяцы, а их нет. Поэтому просто проверил, стоит откинуть библиотеки или не стоит. Оказалось, что не стоит откидывать. Скоростные библиотеки не свалишь первым порывом ветра. Их можно пробовать применять!
И всё равно против психологии не попрёшь. Все, кто привык к классике — будут пользоваться классикой, несмотря на затраты ОЗУ и ПЗУ. Потому что хватает. Нужен убойный аргумент, почему надо перейти попробовать. И они теперь будут знать, что приспичит поднять производительность — есть выход. И вот тогда пойдут и попробуют.
Ибо от куба готовы отказаться многие, а вот пересмотреть код usb-драйвера, желающих думаю будет гораздо меньше.
В целом, согласен с Вами. Но в частности, комментарии под статьями — это здорово! В комментариях под этой сатьёй собрались авторы сразу трёх USB библиотек, написанных с нуля! Я даже сделал статью-экспромт, в которой погонял две из их начерно и указал, где поглядеть про третью.
Сунул нос. В CubeIDE всё это внедрено. И svdшники автоматически подхватываются, если в нём проект создан, и переменные автоматически обновляются, если их поместить на вкладку LiveExpressions. Так что проводить проверку USB библиотеки там можно без светодиодов, чисто средствами SWD.
Вот этим Кейл и хорош, что он знает, с чем работает. У него тысяча и один недостаток, но связь через отладочный порт он держит идеально. За это я его и люблю. Но если кто-нибудь, владеющий информацией заметит нашу беседу — может, он поделится с нами знанием, как сделать то же самое через то, чем сейчас модно пользоваться (GNUшные вещи, будь то GDB или LLDB)
Это не Эклипса забота, а openocd, ведь через что подключаться решает именно он. Ну и программатор еще. Например, мой самодельный st-link в JTAG не умеет вообще.
Но работа идёт через Эклипсу
Кейл классно svd файлы подглатывает
Это честно говоря не знаю что такое
XMLник, в котором все порты подробно расписаны. Я, было дело, играл в Altera Cyclone V SoC (ПЛИС с ARM Cortex A на борту). Так чтобы в том отладчике можно было всё красиво смотреть, даже ручками эти файлы для портов, которые в ПЛИС описал, делал. Муторно, но результат того стоит!
Поищите файлы *.svd там, куда Кубик (CubeIDE) или ещё чего для компиляции STM установлено. Вот я сейчас нашёл — D:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\plugins\ com.st.stm32cube.ide.mcu.productdb.debug_1.4.0.202007081208\ resources\cmsis\ STMicroelectronics_CMSIS_SVD\STM32F103.svd. Найдёте подобное у себя — загляните внутрь. Красота! А Кейл этим пользуется, чтобы пояснять, что там где в портах. Остальные просто обязаны делать то же самое, просто не на поверхности оно, скорее всего!
У меня уже есть материалы для статьи, где я хочу это дело подробно расписать. Мы с ребятами случайно нашли, что если всё собрать с отладочной информацией DWARF2 (у Вас в makefile она тоже добавляется), а потом просто открыть обычную Эклипсу и в ней настроить проект на elf файл (просто отладчику ткнуть в elf, и всё!!!), то можно будет всё отлаживать, бегая по исходникам. Удобно! Можно было бы оформить в виде статьи, попутно расписав весь набор требуемых вещей (как раз OpenOCD, GDB), зачем они нужны и как проверяется, что они зацепились (показать мои любимые команды для проверки и ответы для случая, когда всё работает). Но есть опасение, что будет много выкриков «Я это и так знал». Поэтому руки опускаются. Были у меня такие статьи…
Главная беда известных мне методов отладки через OpenOCD/GDB — они для любого обращения к процессору стопорят его. Если я ничего не путаю, через настоящий JTAG по-другому нельзя. Но у нас же не он, а SWD!!! А Кейл через SWD работает, не трогая ядро. Вот надо разобраться, можно ли так же всё настроить при работе через Эклипсу. Это первое. А второе — Кейл классно svd файлы подглатывает и порты дешифрует через них очень красиво. Не останавливая ядро! Как в Эклипсе это делать — тоже пока не знаю.
Там есть много UARTов. Мой любимый — UART1, ноги A9, A10. Через него можно вывести абсолютно всё. А если это сообщение об ошибке — оно может быть любой длины, без опасения, что создастся задержка. После ошибки всё равно уже работать бесполезно.
Кейл ещё позволяет отслеживать память через SWD, не останавливая процессор и не внося ощутимых задержек. Я просто генерил меандр на ноге, ставил осциллографу запуск по повышенной длительности и мониторил память Кейлом. Осциллограф факты задержек бы отследил. Всё было просто замечательно. Записывая данные в эту память, можно много чего наотслеживать хоть в дампе, хоть через просмотр переменных в процессе исполнения программы.
Вообще, в этом плане Кейл просто замечательный. Я там обожаю порты (UART, SPI, прочие) отслеживать на лету. Все проблемы настройки выявляешь в момент. Вот бы научиться так же в Эклипсе делать! А то ребята как попросят помочь, а у них Эклипса. И придумывай, как выкручиваться… Наверняка же тоже так можно, надо просто знать, как…
Если бы приём не шёл — ушёл бы NAK и в прерывание бы не вошли. Не было бы нового всплеска на жёлтом канале. По крайней мере, в фирменной библиотеке — так. А тут — всё срабатывает. Ну, а устойчивость проверять уже будут те, кто начнёт использовать. Под нагрузкой надо будет убедиться, что всё работает. Не обязательно отправлять. Можно просто контрольную сумму считать. Чтобы были заметны перепутанные буфера — CRC. Там от последовательности результат зависит.
Но это вопрос не для одного дня. Начерно — NAKов нет. А они вырабатываются аппаратурой. Вот все ли данные доходят до потребителя — вопрос интересный.
Если честно, то вот применительно к STM32 я этот вопрос не проверял. Мне надо было сделать эталон для измерения просадки скорости промежуточными звеньями на шине. А уже из невозможности его сделать получилось исследование.
Но в целом — с точки зрения самой шины в обратную сторону всё намного лучше. Главный на шине же хост. И когда он хочет послать данные на скорости FS — он всегда их посылает. Сколько раз пытается, столько посылает весь пакет, тратя время. А обратно — он просто посылает запрос, не занимая шину ради прокачки самих данных. Уже в этом лучше.
Ещё могу точно сказать, что правило «чем больше размер запрошенного блока, тем быстрее бежит поток» соблюдается и там. Собственно, эти графики зависимости скорости от размера блока я впервые построил именно при приёме данных, когда читалку NAND Flash 12 лет назад делал.
Остальное — надо пробовать. Я обязательно попробую со вновь найденной библиотекой. Её надо будет изучить вдоль и поперёк. Если она устойчивая — переходить на неё.
Вот на STM32F4 у меня был забавный подводный камень. Я перетащил прошивку MARLIN для 3D принтера на него (дело было давно, тогда ещё не было готовых вариантов). Работаю. Даю её знакомым. У них всё регулярно виснет. У меня обменом занимается Simplify3D, у них — CuRa. У них виснет. В общем, после долгих опытов выяснил, что при большой нагрузке на порт прекращается передача данных. Даже написал свою стресс-программу, которая за 10-20 посылок всё роняет.
Погуглил — были такие вопросы на форуме ST Ответ — «А вы не гоните много данных». Легко сказать! Долго ли, коротко ли, а опытным путём выяснил, как сделать так, чтобы не висло. Надо было отправлять данные как раз из контроллера в хост не в любой момент, а когда пришло прерывание SOF. Копишь-копишь в кольцевом буфере, пришёл SOF — отправил. Зависания ушли. Почему — не знаю. Является это проблемой конкретно F4 или всех STM — не знаю. На всякий случай, я на всех STM32 по SOFу отправку инициирую, благо там не так много в моих проектах обычно уходит.
Пока свой. Считаем, что для отправки это сыровато. Вот когда проведём исчерпывающее тестирование и Заказчик погоняет на большом наборе боевых данных, тогда... Но идея уже достойна публикации, поэтому и описали. Потом детали забудутся.
По первому пункту, всё просто. У Заказчика был свой список контроллеров, и менять он его не хотел. И за решение своей проблемы оплачивал работы. Поэтому замечательно, что производители тоже думают над решением этой проблемы, но Заказчику требовалось решить на его технике. И у нас есть разрешение опубликовать результаты исследований.
По второму - всё тоже не сильно сложно. Мы на тестовых примерах разобрались с этой самой таблицей GOT, на очередном совещании с Заказчиком показали всё на эту тему, получили чёткое указание больше в этом направлении не работать... И, собственно, не работали. Так что боевых метрик мы не снимали.
Без конкретики, сама идеология в начале статьи расписана. При этом было бы полбеды, если бы выросла прошивка. Когда прошивка растёт - данные в ОЗУ сдвигаются. А когда они не сдвигаются - растёт не прошивка, а требования к ОЗУ. А его мало. Это - то, что успели выяснить до того, как нам сказали идти другим путём.
Вот Вам готовое решение для Тинси, основанное на библиотеках Ардуино. Я своё делал на его базе. Повторю - шагать нельзя! Только ставить точки останова и смотреть переменные, когда эти точки сработали. Дело в том, что там всё делается за счёт внедрения в точку останова команды SVC, если неверно определено положение следующей вставки - всё упадёт.
GitHub - ftrias/TeensyDebug: GDB proxy and debugging support to Teensy 3/4
Проблем с UART и I2C не замечали во время проекта. Да и откуда им там быть? Может, конечно, тестовые задачи были недостаточно суровые. Но надеюсь, нет их.
Не нашёл, как в новом дизайне править комментарии.
Я-то в голове MCUXPressные библиотеки держал. А Ардуиновские UART библиотеки настолько удивительные, что там всё, что угодно может случиться, если работать через верхний уровень. Низкоуровневые - относительно приличные. Но опять же, в статье не показано, как шла работа.
По первому пункту, я наловчился хоть как-то вести отладку через MCUXpresso, но используя UART вместо JTAGа. Так можно. На стороне Тинси реализуется функционал GDB Stub, а самому GDB надо сообщить, что он работает через UART. В одной из следующих статей планирую рассказать про это, если интерес будет (часть статей уже написана, они точно будут опубликованы, а эта - ещё не оформлена даже в виде DOC файла, так как первая статья была встречена очень холодно, а писать ради писанины - скучно). Но там полный изврат. Лучше, чем ничего, конечно. Можно ставить точки останова и просматривать любые переменные. Но шагать - опасно. Так что хоть оно и работает, я продолжаю утверждать, что нормальная отладка под Тинсей 4.1 невозможна.
А так я вообще люблю работать с Кейлом и не стремлюсь к изучению каких-то новых сред разработки. Но у нас был проект. Нам надо было освоить работу именно Тинси 4.1 именно через MCUXpresso и именно со всем широчайшим спектром тех библиотек. Заказчик разрешил опубликовать все результаты. Отчёт для Заказчика был на английском и несколько скучный. А тут я публикую своё видение на русском, со своей расстановкой акцентов. Так что изучал MCUXpresso я за зарплату, имея точный список библиотек, которые следует освоить. А силы на изучение Visual Micro, может, и появятся, но даже не знаю, когда. А в описании там деталей нет, как там отладка выполняется.
По второму же пункту - я прочитал статью. Скажу честно, по такому описанию какую-то диагностику сделать не смогу. Синхронная передача - всегда лучше, чем асинхронная. Но сам я с асинхронной никаких проблем не имел. Однако, там такое дикое сочетание возможных проблем... Вплоть до соотношения Baud Rate с частотами кварцев на обеих сторонах. И масса, масса, масса всего прочего. Так что ничего не могу сказать, не пощупав реальную систему. Иногда ощупывать приходится долго.
Да, там же, на crowd supply. Прелонч-страница была опубликована, прошли рассылки по их клиентам, собрали базу "подписавшихся", тех кто ожидает запуск, а потом запуститься так и не получилось - была очень долгая коммуникация (несколько месяцев), в процессе у нас уже и сам продукт изменился, решили не запускаться вообще.
Удачи! Надеюсь получится запустить проект. Мы два года назад со своим сервисом предоставления доступа к отладочным платам all-hw.com застряли на прелончевом этапе, пол года нас "мурыжили" менеджеры Crowd Supply, задавали всё больше и больше дополнительных вопросов, при этом не отвечали на наши, в итоге все "затухло" и мы просто отказались от продолжения. Но, возможно, это нам не повезло или не хватило терпения.
Спросил у тех, кто планирует это дело. Получил следующий ответ:
Пока планов таких нет, но планы довольно динамичны - платы появляются в основном в связи с проведением того или иного мероприятия, а иногда и просто из любопытства. Ближе всего к появлению в публичном доступе платы NVIDIA Jetson, Xilinx, а также с архитектурой RISC-V. Но если кто-то проспонсирует появление в сервисе H7 или организует публичные мероприятия на этих платах (тренинги, учебные программы и пр.), то она вполне может оказаться на первых позициях в этом списке.
Наш Заказчик захотел, чтобы одновременно использовался USB Host и USB Device. Родных библиотек от Тинси было явно недостаточно. Я сунул нос и загрустил. Потом долго и нудно правил их. А потом появилась вот эта идея... И родные библиотеки USB от NXP реализованы красиво, прозрачно и сопровождаемо.
Цикл статей не столько про саму среду разработки, сколько про библиотеки, которые идут с нею в нагрузку. Хотя, и про среду тоже... Но в целом - можно скачать SDK отдельно и пользоваться в любой среде. Я выбрал родную, чтобы меньше правок делать. Чем меньше правок при обучении, тем больше можно сосредоточиться на том, чему учимся. Плюс можно повторять шаги за мной, не держа в уме, что надо было что-то заранее поставить. Я стараюсь показывать действия от момента "поставили среду, начали работу". Дальше - каждый скорректирует под себя, если сама суть понравится.
В общем, может, и выбирают для работы со звуком. Но если попробовать библиотеки от самой NXP - возможно, можно будет выбрать и для других задач. Пусть все увидят такую возможность! Жаль только, что на плате нет отладочного порта...
Короче, эти параметры, на мой взгляд, вторичны. А вот производительность — это да. Её вечно не хватает. На ней и сосредоточился. Она примерно одинаковая. Но у одной из них спорная устойчивость, хоть и не доказаны проблемы.
Загрузка ядра — в прошлой статье были осциллограммы, там был виден процент нахождения в прерывании.
Но на серьёзную статью ушли бы недели или даже месяцы, а их нет. Поэтому просто проверил, стоит откинуть библиотеки или не стоит. Оказалось, что не стоит откидывать. Скоростные библиотеки не свалишь первым порывом ветра. Их можно пробовать применять!
И всё равно против психологии не попрёшь. Все, кто привык к классике — будут пользоваться классикой, несмотря на затраты ОЗУ и ПЗУ. Потому что хватает. Нужен убойный аргумент, почему надо перейти попробовать. И они теперь будут знать, что приспичит поднять производительность — есть выход. И вот тогда пойдут и попробуют.
В целом, согласен с Вами. Но в частности, комментарии под статьями — это здорово! В комментариях под этой сатьёй собрались авторы сразу трёх USB библиотек, написанных с нуля! Я даже сделал статью-экспромт, в которой погонял две из их начерно и указал, где поглядеть про третью.
XMLник, в котором все порты подробно расписаны. Я, было дело, играл в Altera Cyclone V SoC (ПЛИС с ARM Cortex A на борту). Так чтобы в том отладчике можно было всё красиво смотреть, даже ручками эти файлы для портов, которые в ПЛИС описал, делал. Муторно, но результат того стоит!
Поищите файлы *.svd там, куда Кубик (CubeIDE) или ещё чего для компиляции STM установлено. Вот я сейчас нашёл — D:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\plugins\ com.st.stm32cube.ide.mcu.productdb.debug_1.4.0.202007081208\ resources\cmsis\ STMicroelectronics_CMSIS_SVD\STM32F103.svd. Найдёте подобное у себя — загляните внутрь. Красота! А Кейл этим пользуется, чтобы пояснять, что там где в портах. Остальные просто обязаны делать то же самое, просто не на поверхности оно, скорее всего!
Главная беда известных мне методов отладки через OpenOCD/GDB — они для любого обращения к процессору стопорят его. Если я ничего не путаю, через настоящий JTAG по-другому нельзя. Но у нас же не он, а SWD!!! А Кейл через SWD работает, не трогая ядро. Вот надо разобраться, можно ли так же всё настроить при работе через Эклипсу. Это первое. А второе — Кейл классно svd файлы подглатывает и порты дешифрует через них очень красиво. Не останавливая ядро! Как в Эклипсе это делать — тоже пока не знаю.
Кейл ещё позволяет отслеживать память через SWD, не останавливая процессор и не внося ощутимых задержек. Я просто генерил меандр на ноге, ставил осциллографу запуск по повышенной длительности и мониторил память Кейлом. Осциллограф факты задержек бы отследил. Всё было просто замечательно. Записывая данные в эту память, можно много чего наотслеживать хоть в дампе, хоть через просмотр переменных в процессе исполнения программы.
Вообще, в этом плане Кейл просто замечательный. Я там обожаю порты (UART, SPI, прочие) отслеживать на лету. Все проблемы настройки выявляешь в момент. Вот бы научиться так же в Эклипсе делать! А то ребята как попросят помочь, а у них Эклипса. И придумывай, как выкручиваться… Наверняка же тоже так можно, надо просто знать, как…
Но это вопрос не для одного дня. Начерно — NAKов нет. А они вырабатываются аппаратурой. Вот все ли данные доходят до потребителя — вопрос интересный.
Но в целом — с точки зрения самой шины в обратную сторону всё намного лучше. Главный на шине же хост. И когда он хочет послать данные на скорости FS — он всегда их посылает. Сколько раз пытается, столько посылает весь пакет, тратя время. А обратно — он просто посылает запрос, не занимая шину ради прокачки самих данных. Уже в этом лучше.
Ещё могу точно сказать, что правило «чем больше размер запрошенного блока, тем быстрее бежит поток» соблюдается и там. Собственно, эти графики зависимости скорости от размера блока я впервые построил именно при приёме данных, когда читалку NAND Flash 12 лет назад делал.
Остальное — надо пробовать. Я обязательно попробую со вновь найденной библиотекой. Её надо будет изучить вдоль и поперёк. Если она устойчивая — переходить на неё.
Вот на STM32F4 у меня был забавный подводный камень. Я перетащил прошивку MARLIN для 3D принтера на него (дело было давно, тогда ещё не было готовых вариантов). Работаю. Даю её знакомым. У них всё регулярно виснет. У меня обменом занимается Simplify3D, у них — CuRa. У них виснет. В общем, после долгих опытов выяснил, что при большой нагрузке на порт прекращается передача данных. Даже написал свою стресс-программу, которая за 10-20 посылок всё роняет.
Погуглил — были такие вопросы на форуме ST Ответ — «А вы не гоните много данных». Легко сказать! Долго ли, коротко ли, а опытным путём выяснил, как сделать так, чтобы не висло. Надо было отправлять данные как раз из контроллера в хост не в любой момент, а когда пришло прерывание SOF. Копишь-копишь в кольцевом буфере, пришёл SOF — отправил. Зависания ушли. Почему — не знаю. Является это проблемой конкретно F4 или всех STM — не знаю. На всякий случай, я на всех STM32 по SOFу отправку инициирую, благо там не так много в моих проектах обычно уходит.