Comments 73
Где-то после размера блока 4 килобайта, скорость упирается в 5.6 килобайт в секунду. Давайте я грубо умножу это на 8. Получаю условные 4.5 мегабита в секунду.
5.6КиБ * 8 = 44,5Киб. Кибибайты при умножении должны превратиться в кибибиты. 44,5 кибибита это примерно 0,0434 мибибита. Понятно, то там NRZI да ещё и приправлен битстаффингом, но не на три порядка же.
Спасибо! Действительно что-то я неверно перевёл байты в таблице в килобайты в тексте. 56X_XXX байт. Примерно 560 килобайт в секунду, конечно же.
560 * 8 = 4 480 килобит, грубо 4.5 мегабита.
Сейчас поправлю текст. Ещё раз спасибо.
560 * 8 = 4 480 килобит, грубо 4.5 мегабита.
Сейчас поправлю текст. Ещё раз спасибо.
Было бы интересно сравнить с ChibiOS, так как там свой USB-стек, не завязаный на кривоубогенький STM-овский HAL.
Статья ни о чем!
ТС наваял USB на основе калокуба и пытается доказать, что в проблемах виновато железо, а не рукожопые разработчики калокуба!
Реальные тесты нужно проводить: на «голом» CMSIS со своей реализацией USB. Тогда и всплывут реальные ограничения железа.
ТС наваял USB на основе калокуба и пытается доказать, что в проблемах виновато железо, а не рукожопые разработчики калокуба!
Реальные тесты нужно проводить: на «голом» CMSIS со своей реализацией USB. Тогда и всплывут реальные ограничения железа.
Сложный вопрос. Давным-давно, лет 5 назад, играл я в CMSIS RTOS. В те времена её вызовы проваливались в ту же самую MiddleWare, что и у Кубика используется. Дрйверы для ОС же поставляли те же самые STшники. Возможно, с тех пор что-то изменилось, но мне это было уже не интересно.
Я находил альтернативную реализацию, лишённую ряда слоёв. Но копирайты там были те же самые. Так что это просто другой вариант развития той же идеологии. И разумеется, за требуемое время из обработчика прерывания там выйти тоже ничего не успевало. Со всеми теми же самыми проблемами.
В общем, единственные, кто целенаправленно давил эту проблему — те самые китайские товарищи. Но тот самый USB 2.0 хаб испортил бы результаты и им… И это в статье доказано.
Я находил альтернативную реализацию, лишённую ряда слоёв. Но копирайты там были те же самые. Так что это просто другой вариант развития той же идеологии. И разумеется, за требуемое время из обработчика прерывания там выйти тоже ничего не успевало. Со всеми теми же самыми проблемами.
В общем, единственные, кто целенаправленно давил эту проблему — те самые китайские товарищи. Но тот самый USB 2.0 хаб испортил бы результаты и им… И это в статье доказано.
Порылся по Вашему профилю. Нашёл Вашу USB библиотеку на Гитхабе. Выглядит забавно. Настолько забавно (в хорошем смысле этого слова), чтобы показать всем. Будем измеряяяять. По результатам — отпишусь.
В общем, всё здорово!
Это было (для меня) нелегко, но я справился со сборкой Вашего проекта /F1-nolib/CDC_ACM под Windows. Результат при прямом подключении к материнке — просто замечательный. Через хаб — предсказуемо такой же, какой был.
Сделаю несколько замеров — дополню статью ссылкой на российского автора полезной библиотеки в Вашем лице…
Это было (для меня) нелегко, но я справился со сборкой Вашего проекта /F1-nolib/CDC_ACM под Windows. Результат при прямом подключении к материнке — просто замечательный. Через хаб — предсказуемо такой же, какой был.
Сделаю несколько замеров — дополню статью ссылкой на российского автора полезной библиотеки в Вашем лице…
Можете заодно и мою проверить: github.com/COKPOWEHEU/usb/tree/main/5.CDC_L1 (для F1 надо библиотеку из Core_F1 скопировать) если желание будет. Тоже на регистрах, без Куба. Ну и двойная буферизация имеется.
Как понял из статьи лично я, скорее не куба, а usb-драйвера, который поставляется отдельно. Куб я тоже не люблю (само приложение использую только для назначения пинов, чтобы в мануале не ковыряться), предпочитаю голый cmsis. Так что ситуация несколько хуже чем Вам кажется. Ибо от куба готовы отказаться многие, а вот пересмотреть код usb-драйвера, желающих думаю будет гораздо меньше.
Ибо от куба готовы отказаться многие, а вот пересмотреть код usb-драйвера, желающих думаю будет гораздо меньше.
В целом, согласен с Вами. Но в частности, комментарии под статьями — это здорово! В комментариях под этой сатьёй собрались авторы сразу трёх USB библиотек, написанных с нуля! Я даже сделал статью-экспромт, в которой погонял две из их начерно и указал, где поглядеть про третью.
UFO just landed and posted this here
UFO just landed and posted this here
Оптимизация на размер именно в Кейле даёт массу CALLов вместо автоматических инлайнов. Так что она точно на скорость в лучшую сторону не может повлиять.
Что до постепенного разгона — вопрос интересный. По крайней мере, я замерял для нескольких мегабайт.
Что до постепенного разгона — вопрос интересный. По крайней мере, я замерял для нескольких мегабайт.
UFO just landed and posted this here
Кстати, а измеряет Ваша программа или чужая? Просто подумалось, а не вещественные ли числа там делятся? Если они, то при росте порядка, идёт загрубление, что может приводить к интересным результатам.
А так — выше я в комментариях отписался (и новый раздел ближе к концу текста вставил), как удалось разогнать на любых объёмах. Тот же метод, что и у китайцев, но не абстрактное «Мы сделали», а скачана конкретная библиотека от отечественного автора. И получившиеся осциллограммы соответствуют предсказанным. Ну, и с USB 2.0 хабом, предсказуемо ничего не улучшилось.
А так — выше я в комментариях отписался (и новый раздел ближе к концу текста вставил), как удалось разогнать на любых объёмах. Тот же метод, что и у китайцев, но не абстрактное «Мы сделали», а скачана конкретная библиотека от отечественного автора. И получившиеся осциллограммы соответствуют предсказанным. Ну, и с USB 2.0 хабом, предсказуемо ничего не улучшилось.
Интересно, как вы это сделали, если стандарт USB 2.0 приводит максимальную пропускную способность для Bulk и 64-байтных пакетов равную 1216000, что есть 9.728 Mbit/s. Что-то тут не сходится...
Классная статья, хотелось бы узнать что там у вас за контроллер с EHCI, и вообще из дешевых вариантов контроллеров какой выбрать для FS USB?
Ну, дешёвый контроллер с FS — это всё тот же F103. Он замечательный по большинству параметров. А дикая скорость нужна не всегда. Чуть выше я в комментарии привёл график, полученный с использованием библиотеки EddyEm — с нею можно получить полноценную скорость. Я верил, что в комментариях мне подкинут идею (правда, для этого пришлось пошерстить его комментарии к чужим статьям, чтобы найти ссылку на эту библиотеку). Чуть позже дополню статью ссылкой на эту библиотеку.
EHCI — вот эта плата, процессор NXP IMXRT1062. Скоро выложу несколько статей со своими первыми впечатлениями о работе с нею. Но по цене это совсем разные весовые категории… И отладочного порта на этой плате нет. А так — забавная штучка.
EHCI — вот эта плата, процессор NXP IMXRT1062. Скоро выложу несколько статей со своими первыми впечатлениями о работе с нею. Но по цене это совсем разные весовые категории… И отладочного порта на этой плате нет. А так — забавная штучка.
UFO just landed and posted this here
1) HAL зло. Там тьма кода для покрытия всех возможных вариантов аргументов. Куча данных перекладывается с места на место (из структуры в структуру). inline помогает очень слабо.
2) HAL зло, написанное криворукими программистами, которые даже не пытаются сделать совместимость чипов на уровне софта, хотя на уровне железа STM такую совместимость декларирует (можно заменить один контроллер на более мощный той-же распиновки).
Возьмите 2 HAL разных контроллеров, совместимых по выводам и периферии — ВСЕ переименовано. Чтобы сменить контроллер, приходиться тупо проходить по коду и менять имена констант.
3) HAL зло, написанное криворукими программистами, которые получают оплату за кол-во изменившегося кода от версии к версии. и STM на это пофиг.
Берем 2 HAL разных версий: и видим например в коде настройки пинов замену for (int i...) цикл на int i =0; while (i<)… цикл.
Итог: совместимости нет. Оптимизации нет. Святая вера в оптимизации компилятора это бред. Если Вам нужна производительность, надо писать короткий и ПРАВИЛЬНЫЙ код, который будет оптимизироваться. А надеяться что компилятор заинлайнит стек из 30 вызовов — это бред.
П.С. Прошу прощения. Накипело. STM делает прекрасные контроллеры и полное Г. в библиотеках. Может соберемся и сделаем open-source CMSIS+HAL спроектированное и реализованное прямыми руками?
2) HAL зло, написанное криворукими программистами, которые даже не пытаются сделать совместимость чипов на уровне софта, хотя на уровне железа STM такую совместимость декларирует (можно заменить один контроллер на более мощный той-же распиновки).
Возьмите 2 HAL разных контроллеров, совместимых по выводам и периферии — ВСЕ переименовано. Чтобы сменить контроллер, приходиться тупо проходить по коду и менять имена констант.
3) HAL зло, написанное криворукими программистами, которые получают оплату за кол-во изменившегося кода от версии к версии. и STM на это пофиг.
Берем 2 HAL разных версий: и видим например в коде настройки пинов замену for (int i...) цикл на int i =0; while (i<)… цикл.
Итог: совместимости нет. Оптимизации нет. Святая вера в оптимизации компилятора это бред. Если Вам нужна производительность, надо писать короткий и ПРАВИЛЬНЫЙ код, который будет оптимизироваться. А надеяться что компилятор заинлайнит стек из 30 вызовов — это бред.
П.С. Прошу прощения. Накипело. STM делает прекрасные контроллеры и полное Г. в библиотеках. Может соберемся и сделаем open-source CMSIS+HAL спроектированное и реализованное прямыми руками?
STM делает прекрасные контроллеры
Не обольщайтесь. Скажем, стек USB там проектировали те еще наркоманы:
1. Регистр USB_EPxR: часть битов доступна только на чтение (это нормально). Часть — на чтение и запись (тоже пока нормально). Часть игнорирует запись единицы с сбрасывается записью нуля. А часть игнорирует ноль и перебрасывает значение при записи единицы.
2. Размер буфера под конечные точки нигде в инклюдах не прописан — только если догадаться, что он не часть оперативки и залезть в memory map (ссылок туда из соответствующего раздела тоже нет)
3. Организация буфера конечных точек: 256 штук 16-битных слов с 32-битной адресацией. Хочешь копировать побайтно — шиш тебе, перекодируй на лету.
4. Двойная буферизация. Она как бы есть — в изохронных и bulk точках. При этом переключение буферов на передачу осуществляется битом DTOG_RX. Буферов на передачу битом на чтение!
ИМХО В сравнении с ценой/возможностями альтернативы нет. STM покрывает 90% требований. Маленькие. Быстрые. Мощные. Дешевые. Куча периферии.
Возможно. Но и косяков хватает. Ну и не очень очевидно что с ними в ближайшем будущем случится.
В своё время, конкретно F103C8T6 на сайте обещали не снимать с производства в ближайшие 10 лет. Так что если сама фирма не развалится, то должно быть всё хорошо. Будем хотя бы на это надеяться.
Но как человек, живший при дефиците, я несколько десятков Пилюль купил давно. Для дома, для семьи… Уж больно они замечательные.
Но как человек, живший при дефиците, я несколько десятков Пилюль купил давно. Для дома, для семьи… Уж больно они замечательные.
А вот тут можно чуть подробнее? Я видимо эту новость пропустил. Спасибо.
Если вы про «неизвестно что будет», то я всего лишь про бардак с ценами. Никакой секретной информации у меня нет. А что до косяков, так в F103-их RTС ущербный, порты криво настраиваются, про USB отдельную нецензурную песню складывать надо
Да, но остальные или хуже, или дороже… Понятно, что они не вечны… Но вот прямо сейчас, если бы не дефицит на фоне пандемии, они популярны. А лет 10 назад я Мегу восьмую любил. Причём писал на ассемблере для неё.
У NXP библиотеки лучше сделаны. Да и сами они неплохи. Но ценаааааа… Я просто сейчас Teensy 4.1 по проектной необходимости изучаю. Но когда надо круть — можно и переплатить. Когда не надо — зачем переплачивать?
У NXP библиотеки лучше сделаны. Да и сами они неплохи. Но ценаааааа… Я просто сейчас Teensy 4.1 по проектной необходимости изучаю. Но когда надо круть — можно и переплатить. Когда не надо — зачем переплачивать?
Вы про 10 лет? Вот ссылка
Слева сверху зелёненькая надпись Active. Чуть правее от неё монетка десятикопеечная. Наведите на неё курсор…
Слева сверху зелёненькая надпись Active. Чуть правее от неё монетка десятикопеечная. Наведите на неё курсор…
Спасибо. Я пока не вижу проблемы. В программе пролонгации на 10 лет 100500 контроллеров. Что не так?
Не так совсем другое. Вот это не так. Остальное — просто замечательно. И эти 10 копеек наоборот внушают оптимизм. что всё наладится.
- Все эти режимы сделаны намеренно и нужны в разных ситуациях.
- Так он не фиксирован. Догадываться не надо, в Reference Manual написано про эту память.
- Не очень удобно, но исправлено в более новых контроллерах. Впрочем, DMA должен уметь делать такую конвертацию.
- Только DTOG_RX для такого endpoint называется SW_BUF, если Reference Manual почитать. А в остальном — почему бы и нет? Поскольку такой endpoint не может одновременно работать на чтение и на запись, часть битов не имеет смысла и может в теории использоваться как угодно.
Все эти режимы сделаны намеренно и нужны в разных ситуациях.Что им мешало сделать инверсию не по 1, а по 0 или наоборот чтобы запись 1 сбрасывала другой бит? Претензия-то не к тому, что разные способы доступа, а что маски кривые накладывать приходится
Так он не фиксирован. Догадываться не надо, в Reference Manual написано про эту память.Написано. Вот только ссылки туда из соответствующего раздела нет. И в инклюдниках ее размер не задефайнен.
Не очень удобно, но исправлено в более новых контроллерах. Впрочем, DMA должен уметь делать такую конвертацию.DMA умеет. Про новые контроллеры ничего сказать не могу.
Только DTOG_RX для такого endpoint называется SW_BUF, если Reference Manual почитать.Так кто ж спорит что они это задокументировали. Но зачем было заставлять дергать бит приема при передаче? Если уж «часть битов можно использовать как угодно», так и привязали бы бит передачи к передаче.
Для всего, кроме USB Middleware я использую mcucpp Константина Чижова. Она довольно здорово оптимизирует код, а также делает простой работу со сложными блоками (я использовал GPIO, таймеры, в том числе, в режиме ШИМ, UART, SPI). При этом ноги перекидывать при переразводке платы — сплошное удовольствие.
Правда, я давно не заглядывал, что у него там сейчас. Лет 5 назад скачал и развивал свой вариант. В столе даже есть пара статей про эту библиотеку, но знакомые отговорили от их публикации. Она же не моя. И типа нечего тут…
USB — приходилось пользоваться тем, что есть… Но буду изучать библиотеки, с которыми познакомился сегодня. Сейчас вставлю дополнение в текст…
Правда, я давно не заглядывал, что у него там сейчас. Лет 5 назад скачал и развивал свой вариант. В столе даже есть пара статей про эту библиотеку, но знакомые отговорили от их публикации. Она же не моя. И типа нечего тут…
USB — приходилось пользоваться тем, что есть… Но буду изучать библиотеки, с которыми познакомился сегодня. Сейчас вставлю дополнение в текст…
А что мешает опубликовать статьи? Вы же не пишете что это ваша разработка…
А то по вашей логике получается, что мы должны писать статьи только про свой код. Про linux/windows/appache/e.t.c. низя… ШТА? О_О А как учиться?
А то по вашей логике получается, что мы должны писать статьи только про свой код. Про linux/windows/appache/e.t.c. низя… ШТА? О_О А как учиться?
делает простой работу со сложными блоками (я использовал GPIOGPIO как раз штука простая, не знаю зачем в том же HAL или Arduino ее настолько изуродовали. К примеру, в моем варианте делается примерно так:
#define LED_RED B, 10, GPIO_PP_VS
GPIO_config( LED_RED );
GPO_ON( LED_RED );
GPO_OFF( LED_RED );Как это делается в mcucpp — есть в тексте статьи.
Где-то объявляем
Потом можно всегда поименять на другое
Затем — где надо, инициализируем
Первая строка нужна, чтобы на порт тактирование включить, оно там само определит, на какой GPIO подать, для более сложных блоков — и на GPIO ног, и на блоки подаст.
Ну, и работаем
Обратите внимание, что никаких переменных не заводится. Там работа через статические функции идёт. Как макросы, только легко читаются реализующие функции, и всё строго типизировано. И при вводе текста часто подсказки IntelliSense хорошие выдаёт, не надо всё помнить.
Оптимизируются так, что руками на ассемблере лучше не написать. Я проверял.
Где-то объявляем
typedef Mcucpp::IO::Pa0 oscOut; Потом можно всегда поименять на другое
Затем — где надо, инициализируем
oscOut::ConfigPort::Enable();
oscOut::SetDirWrite();
Первая строка нужна, чтобы на порт тактирование включить, оно там само определит, на какой GPIO подать, для более сложных блоков — и на GPIO ног, и на блоки подаст.
Ну, и работаем
oscOut::Set();
oscOut::Clear();
Обратите внимание, что никаких переменных не заводится. Там работа через статические функции идёт. Как макросы, только легко читаются реализующие функции, и всё строго типизировано. И при вводе текста часто подсказки IntelliSense хорошие выдаёт, не надо всё помнить.
Оптимизируются так, что руками на ассемблере лучше не написать. Я проверял.
Это что, С++ с его нечитаемыми шаблонами? Уж лучше макросы.
А можно при таком подходе хранить пины в массиве и в цикле проходить по всем?
1) Сейчас открыл ту свою статью, которая в столе лежит, проверил. Там этому посвящён целый раздел, который говорит, что строгая типизация действительно затрудняет именно хранение в массиве но в принципе — это возможно.
2) А вот у самого автора той библиотеки зато есть более интересная штука — PinList. Ноги, объявленные таким методом, объединяются в группу, которую можно заполнять занесением двоичной константы. Я в своих статьях как раз извращаюсь с их заполнением и смотрю, что выдаёт оптимитзатор. А оптимизатор там даёт идеальный код. На ассемблере с этой группой контактов обычно лучше не получится работать. Правда, в Кейле надо включить обязательно оптимизацию по времени. Если по размеру — всё будет хуже.
Собственно, из статьи про эти группы контактов я и узнал о существовании той библиотеки. Но когда скачал с Гитхаба, оказалось, что она — это не только GPIO, а ещё и масса других вещей. Надеюсь, за ссылку на очень старую статью на другой ресурс, меня не расстреляют. Она реально старая. Тогда библиотека ещё называлась avrcpp. Сегодня её надо гуглить по имени mcucpp. Вот, нагуглил текущее состояние.
2) А вот у самого автора той библиотеки зато есть более интересная штука — PinList. Ноги, объявленные таким методом, объединяются в группу, которую можно заполнять занесением двоичной константы. Я в своих статьях как раз извращаюсь с их заполнением и смотрю, что выдаёт оптимитзатор. А оптимизатор там даёт идеальный код. На ассемблере с этой группой контактов обычно лучше не получится работать. Правда, в Кейле надо включить обязательно оптимизацию по времени. Если по размеру — всё будет хуже.
Собственно, из статьи про эти группы контактов я и узнал о существовании той библиотеки. Но когда скачал с Гитхаба, оказалось, что она — это не только GPIO, а ещё и масса других вещей. Надеюсь, за ссылку на очень старую статью на другой ресурс, меня не расстреляют. Она реально старая. Тогда библиотека ещё называлась avrcpp. Сегодня её надо гуглить по имени mcucpp. Вот, нагуглил текущее состояние.
О, я помню эту статью! С PinList понятно, что это очень эффективный метод, но я не понимаю, как вообще подход с шаблонами кошерно применить к такой задаче (недавно как раз решал): прочитать два пина (или N пинов), сделать со значениями какие-то одинаковые операции, записать результат в другие два пина.
Массивы и обработка в цикле — чуть затруднены, но допустимы. Проверено. Надо будет сдуть пыль с тех двух текстов и, может быть, опубликовать их.
Прочитать все пины можно примерно так:
Записать +- аналогично, циклы заменяются на раскрытие variadic-ов.
template<typename...>
struct IndexOf;
template<typename _Need, typename... _Tail>
struct IndexOf<_Need, std::tuple<_Need , _Tail...>>
{
static const int value = 0;
};
template<typename _Need, typename _Head, typename... _Tail>
struct IndexOf<_Need, std::tuple<_Head, _Tail...>>
{
static const int value = IndexOf < _Need, std::tuple<_Tail...>>::value + 1;
};
template <typename... _Pins>
uint16_t ReadAll()
{
using PinList = std::tuple<_Pins...>;
return ((_Pins::Read() << IndexOf<_Pins, PinList>::value) | ...);
}Записать +- аналогично, циклы заменяются на раскрытие variadic-ов.
А ведь был же когда-то StdPeriph. И я его юзал, он заметно прозрачнее HAL. Но в нём не было USB.
Спасибо за статью!
Вопрос - а что со случаем, когда данные отправляются из МК в ПК? Какие подводные камни там?
Если честно, то вот применительно к STM32 я этот вопрос не проверял. Мне надо было сделать эталон для измерения просадки скорости промежуточными звеньями на шине. А уже из невозможности его сделать получилось исследование.
Но в целом — с точки зрения самой шины в обратную сторону всё намного лучше. Главный на шине же хост. И когда он хочет послать данные на скорости FS — он всегда их посылает. Сколько раз пытается, столько посылает весь пакет, тратя время. А обратно — он просто посылает запрос, не занимая шину ради прокачки самих данных. Уже в этом лучше.
Ещё могу точно сказать, что правило «чем больше размер запрошенного блока, тем быстрее бежит поток» соблюдается и там. Собственно, эти графики зависимости скорости от размера блока я впервые построил именно при приёме данных, когда читалку NAND Flash 12 лет назад делал.
Остальное — надо пробовать. Я обязательно попробую со вновь найденной библиотекой. Её надо будет изучить вдоль и поперёк. Если она устойчивая — переходить на неё.
Вот на STM32F4 у меня был забавный подводный камень. Я перетащил прошивку MARLIN для 3D принтера на него (дело было давно, тогда ещё не было готовых вариантов). Работаю. Даю её знакомым. У них всё регулярно виснет. У меня обменом занимается Simplify3D, у них — CuRa. У них виснет. В общем, после долгих опытов выяснил, что при большой нагрузке на порт прекращается передача данных. Даже написал свою стресс-программу, которая за 10-20 посылок всё роняет.
Погуглил — были такие вопросы на форуме ST Ответ — «А вы не гоните много данных». Легко сказать! Долго ли, коротко ли, а опытным путём выяснил, как сделать так, чтобы не висло. Надо было отправлять данные как раз из контроллера в хост не в любой момент, а когда пришло прерывание SOF. Копишь-копишь в кольцевом буфере, пришёл SOF — отправил. Зависания ушли. Почему — не знаю. Является это проблемой конкретно F4 или всех STM — не знаю. На всякий случай, я на всех STM32 по SOFу отправку инициирую, благо там не так много в моих проектах обычно уходит.
Но в целом — с точки зрения самой шины в обратную сторону всё намного лучше. Главный на шине же хост. И когда он хочет послать данные на скорости FS — он всегда их посылает. Сколько раз пытается, столько посылает весь пакет, тратя время. А обратно — он просто посылает запрос, не занимая шину ради прокачки самих данных. Уже в этом лучше.
Ещё могу точно сказать, что правило «чем больше размер запрошенного блока, тем быстрее бежит поток» соблюдается и там. Собственно, эти графики зависимости скорости от размера блока я впервые построил именно при приёме данных, когда читалку NAND Flash 12 лет назад делал.
Остальное — надо пробовать. Я обязательно попробую со вновь найденной библиотекой. Её надо будет изучить вдоль и поперёк. Если она устойчивая — переходить на неё.
Вот на STM32F4 у меня был забавный подводный камень. Я перетащил прошивку MARLIN для 3D принтера на него (дело было давно, тогда ещё не было готовых вариантов). Работаю. Даю её знакомым. У них всё регулярно виснет. У меня обменом занимается Simplify3D, у них — CuRa. У них виснет. В общем, после долгих опытов выяснил, что при большой нагрузке на порт прекращается передача данных. Даже написал свою стресс-программу, которая за 10-20 посылок всё роняет.
Погуглил — были такие вопросы на форуме ST Ответ — «А вы не гоните много данных». Легко сказать! Долго ли, коротко ли, а опытным путём выяснил, как сделать так, чтобы не висло. Надо было отправлять данные как раз из контроллера в хост не в любой момент, а когда пришло прерывание SOF. Копишь-копишь в кольцевом буфере, пришёл SOF — отправил. Зависания ушли. Почему — не знаю. Является это проблемой конкретно F4 или всех STM — не знаю. На всякий случай, я на всех STM32 по SOFу отправку инициирую, благо там не так много в моих проектах обычно уходит.
Как же это соотносится с тем, что данные спокойно идут во время обработки прерывания?А они идут? А то, может, игнорируются из за ошибки переключения буферов.
Как вариант, можно провести тест чтобы контроллер принимал поток байтов, что-то с ними делал и отсылал обратно, а комп проверял правильно ли данные пришли. Если тест только на прием, то, скажем, вернуть последовательность 0x00 — первый_принятый_байт — сумма — последний_принятый_байт — 0xFF. Просто чтобы в однородном потоке байтов надежно определять пакет и иметь возможность определить что счел пакетом контроллер.
Если бы приём не шёл — ушёл бы NAK и в прерывание бы не вошли. Не было бы нового всплеска на жёлтом канале. По крайней мере, в фирменной библиотеке — так. А тут — всё срабатывает. Ну, а устойчивость проверять уже будут те, кто начнёт использовать. Под нагрузкой надо будет убедиться, что всё работает. Не обязательно отправлять. Можно просто контрольную сумму считать. Чтобы были заметны перепутанные буфера — CRC. Там от последовательности результат зависит.
Но это вопрос не для одного дня. Начерно — NAKов нет. А они вырабатываются аппаратурой. Вот все ли данные доходят до потребителя — вопрос интересный.
Но это вопрос не для одного дня. Начерно — NAKов нет. А они вырабатываются аппаратурой. Вот все ли данные доходят до потребителя — вопрос интересный.
Это если про буфер точки забыть совсем. А если просто выставлять флаг готовности — имитация приема прекрасно заработает. В варианте с буферизацией я вообще не уверен, что оно будет NAK посылать.
Можно просто контрольную сумму считать. Чтобы были заметны перепутанные буфера — CRC. Там от последовательности результат зависит.Внутри пакета данные не путаются. Да можно просто передавать нарастающие значения, а контроллер пусть отслеживает что они именно нарастают и именно по одному. Правда, я не знаю есть ли на Пилюле еще светодиоды, на которые можно вывести ошибку.
Там есть много UARTов. Мой любимый — UART1, ноги A9, A10. Через него можно вывести абсолютно всё. А если это сообщение об ошибке — оно может быть любой длины, без опасения, что создастся задержка. После ошибки всё равно уже работать бесполезно.
Кейл ещё позволяет отслеживать память через SWD, не останавливая процессор и не внося ощутимых задержек. Я просто генерил меандр на ноге, ставил осциллографу запуск по повышенной длительности и мониторил память Кейлом. Осциллограф факты задержек бы отследил. Всё было просто замечательно. Записывая данные в эту память, можно много чего наотслеживать хоть в дампе, хоть через просмотр переменных в процессе исполнения программы.
Вообще, в этом плане Кейл просто замечательный. Я там обожаю порты (UART, SPI, прочие) отслеживать на лету. Все проблемы настройки выявляешь в момент. Вот бы научиться так же в Эклипсе делать! А то ребята как попросят помочь, а у них Эклипса. И придумывай, как выкручиваться… Наверняка же тоже так можно, надо просто знать, как…
Кейл ещё позволяет отслеживать память через SWD, не останавливая процессор и не внося ощутимых задержек. Я просто генерил меандр на ноге, ставил осциллографу запуск по повышенной длительности и мониторил память Кейлом. Осциллограф факты задержек бы отследил. Всё было просто замечательно. Записывая данные в эту память, можно много чего наотслеживать хоть в дампе, хоть через просмотр переменных в процессе исполнения программы.
Вообще, в этом плане Кейл просто замечательный. Я там обожаю порты (UART, SPI, прочие) отслеживать на лету. Все проблемы настройки выявляешь в момент. Вот бы научиться так же в Эклипсе делать! А то ребята как попросят помочь, а у них Эклипса. И придумывай, как выкручиваться… Наверняка же тоже так можно, надо просто знать, как…
Это да, поковырять можно. Я-то IDE-шками не пользуюсь, но иногда они тоже бывают полезны.
Насколько я понимаю, там сначала запускается openocd, который поднимает gdb-сервер. А уже к серверу коннектится Эклипс.
Насколько я понимаю, там сначала запускается openocd, который поднимает gdb-сервер. А уже к серверу коннектится Эклипс.
У меня уже есть материалы для статьи, где я хочу это дело подробно расписать. Мы с ребятами случайно нашли, что если всё собрать с отладочной информацией DWARF2 (у Вас в makefile она тоже добавляется), а потом просто открыть обычную Эклипсу и в ней настроить проект на elf файл (просто отладчику ткнуть в elf, и всё!!!), то можно будет всё отлаживать, бегая по исходникам. Удобно! Можно было бы оформить в виде статьи, попутно расписав весь набор требуемых вещей (как раз OpenOCD, GDB), зачем они нужны и как проверяется, что они зацепились (показать мои любимые команды для проверки и ответы для случая, когда всё работает). Но есть опасение, что будет много выкриков «Я это и так знал». Поэтому руки опускаются. Были у меня такие статьи…
Главная беда известных мне методов отладки через OpenOCD/GDB — они для любого обращения к процессору стопорят его. Если я ничего не путаю, через настоящий JTAG по-другому нельзя. Но у нас же не он, а SWD!!! А Кейл через SWD работает, не трогая ядро. Вот надо разобраться, можно ли так же всё настроить при работе через Эклипсу. Это первое. А второе — Кейл классно svd файлы подглатывает и порты дешифрует через них очень красиво. Не останавливая ядро! Как в Эклипсе это делать — тоже пока не знаю.
Главная беда известных мне методов отладки через OpenOCD/GDB — они для любого обращения к процессору стопорят его. Если я ничего не путаю, через настоящий JTAG по-другому нельзя. Но у нас же не он, а SWD!!! А Кейл через SWD работает, не трогая ядро. Вот надо разобраться, можно ли так же всё настроить при работе через Эклипсу. Это первое. А второе — Кейл классно svd файлы подглатывает и порты дешифрует через них очень красиво. Не останавливая ядро! Как в Эклипсе это делать — тоже пока не знаю.
если всё собрать с отладочной информацией DWARF2, а потом просто открыть обычную Эклипсу и в ней настроить проект на elf файл, то можно будет всё отлаживать, бегая по исходникам. Удобно!Кх-х-хм… Оно как бы для этого и нужно. Еще дизассемблировать можно чтобы сравнить выхлоп компилятора со строкой, из которой он получен.
Можно было бы оформить в виде статьи, попутно расписав весь набор требуемых вещей (как раз OpenOCD, GDB), зачем они нужны и как проверяется, что они зацепились (показать мои любимые команды для проверки и ответы для случая, когда всё работает). Но есть опасение, что будет много выкриков «Я это и так знал». Поэтому руки опускаются. Были у меня такие статьи…Ну вообще да, наличие в файле отладочной информации известно многим. Но если сделать упор не на этом, а на туториале по настройке окружения, может и взлетит.
Только без восторгов, как в вашем посте :) Не поймут.
Если я ничего не путаю, через настоящий JTAG по-другому нельзя. Но у нас же не он, а SWD!!! А Кейл через SWD работает, не трогая ядро. Вот надо разобраться, можно ли так же всё настроить при работе через Эклипсу.Это не Эклипса забота, а openocd, ведь через что подключаться решает именно он. Ну и программатор еще. Например, мой самодельный st-link в JTAG не умеет вообще.
Кейл классно svd файлы подглатываетЭто честно говоря не знаю что такое
Это не Эклипса забота, а openocd, ведь через что подключаться решает именно он. Ну и программатор еще. Например, мой самодельный st-link в JTAG не умеет вообще.Но работа идёт через Эклипсу
XMLник, в котором все порты подробно расписаны. Я, было дело, играл в Altera Cyclone V SoC (ПЛИС с ARM Cortex A на борту). Так чтобы в том отладчике можно было всё красиво смотреть, даже ручками эти файлы для портов, которые в ПЛИС описал, делал. Муторно, но результат того стоит!Кейл классно svd файлы подглатываетЭто честно говоря не знаю что такое
Поищите файлы *.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. Найдёте подобное у себя — загляните внутрь. Красота! А Кейл этим пользуется, чтобы пояснять, что там где в портах. Остальные просто обязаны делать то же самое, просто не на поверхности оно, скорее всего!
Работа идет через gdb, который наверняка и знать не знает что бывают какие-то там внутрисхемные отладчики. Он же для обычных ПК писался. То есть я полагаю, что вся эта платформо-специфика на openocd и заканчивается.
Хотя не факт… заклинания для прошивки у разных контроллеров все же отличаются. Возможно, openocd не обеспечивает той абстракции, на которую я так надеюсь.
Но уговорили, запущу виртуалку посмотрю. Вдруг и впрямь для чего-нибудь сгодится.
Хотя не факт… заклинания для прошивки у разных контроллеров все же отличаются. Возможно, openocd не обеспечивает той абстракции, на которую я так надеюсь.
Поищите файлы *.svd там, куда Кубик (CubeIDE) или ещё чего для компиляции STM установлено.Вы забываете, что я Кубом не пользуюсь и не уважаю. Текстовый редактор, консоль — большего и не надо.
Но уговорили, запущу виртуалку посмотрю. Вдруг и впрямь для чего-нибудь сгодится.
Вот этим Кейл и хорош, что он знает, с чем работает. У него тысяча и один недостаток, но связь через отладочный порт он держит идеально. За это я его и люблю. Но если кто-нибудь, владеющий информацией заметит нашу беседу — может, он поделится с нами знанием, как сделать то же самое через то, чем сейчас модно пользоваться (GNUшные вещи, будь то GDB или LLDB)
Сунул нос. В CubeIDE всё это внедрено. И svdшники автоматически подхватываются, если в нём проект создан, и переменные автоматически обновляются, если их поместить на вкладку LiveExpressions. Так что проводить проверку USB библиотеки там можно без светодиодов, чисто средствами SWD.
Давно было дело по памяти пишу. На stm32F102CBT делал устройство, которое цифрует сигнал и гонит данные по USB bulk. К сожалению нигде не записал результаты тестирования, но что-то в районе 7 000 000 b/s чистыми данными получилось выжать. Помню, что почти подобрался к теоретическому максимуму в 8 Mb/s. Размер bulk транзацкции у меня был 1024, и с учетом что каждый новый фрэйм стартует раз в 1мс, как раз и получается что чистых данных по bulk 8 Mb/s.
Прошу прощения, немного не понял, о каких 64 байтах идёт речь ??? Для bulk-транзакции размер пакета вроде 512 байт. Или Вы проверяли как hid-устройство? Впрочем автору респект и уважуха, статья отличная, утаскиваю в закладки. Мне это скоро предстоит, но только с usb hs и stm32h7.
И да, народ ругающий HAL. Сам его не люблю, но как понял из статьи, HAL тут особо ни при чём. Собака порылась не в HAL-е, в usb-драйвере. И именно его код надо смотреть. Что куда менее приятно.
И да, народ ругающий HAL. Сам его не люблю, но как понял из статьи, HAL тут особо ни при чём. Собака порылась не в HAL-е, в usb-драйвере. И именно его код надо смотреть. Что куда менее приятно.
Спасибо, надо в закладках оставить
Sign up to leave a comment.
Предельная скорость USB на STM32F103, чем она обусловлена?