Передача 2,5 Мбит/с с ПК на STM32

Привет всем! Мне нужно организовать передачу потока данных в 2,5 мбит/с с компа под Windows на STM32 F072B Disccovery с минимальной задержкой - т.е. где-то близко к 1 мс.

STM32 должен принимать данные с ПК и управлять пинами (по сути просто тупо последовательно пихать полученные данные в GPIO, без обработки, но с очень точными интервалами порядка 400 нс). Всё работает примерно так: 23 мс на получение данных, потом 7 мс на выдачу через GPIO, потом снова 23 мс на получение данных, 7 мс на выдачу и т.п. - и так около 30 раз в секунду. Исхожу из того, что процессор у нас одноядерный, а во время сеанса управления пинами в 7 мс мы должны соблюдать жесткий тайминг. Поэтому мы не можем использовать прерывания во время этих 7 мс, и должны весь прием успевать делать во время пауз в 23 мс.

Итого у нас есть 23 мс для того, чтобы принять около 83 кбит данных. Т.е. этот поток в 2,5 мбит/с не является равномерным, на самом деле это поток в 3,6 мбит/с, который должен прерываться на 7 мс 30 раз в секунду, чтобы дать контроллеру слить информацию в пины.


Во-первых, самое главное: способна ли вообще данная плата такой поток принять на вход? Хватит ли ей производительности? Хранить долго ничего не надо, памяти вроде хватает, а вот процессор и шины - я не уверен. Если не хватит, то какую мне следует взять для решения этой задачи?

Во-вторых, я пока вижу несколько вариантов решения задачи:
1) Написать вручную USB драйвер под Windows и по USB же принимать данные на STM32. Мне тут порекомендовали хороший фреймворк для работы с USB на STM32.

2) Передавать данные по UDP, прикрутив каким-нибудь образом Ethernet на STM32, либо как-то организовав сетевое соединение через USB (так вообще можно?), или передавать на малину (у неё есть Ethernet), а с неё уже на STM32, распараллеливая информацию по нескольким пинам, если одного мало.

3) Использовать вторую STM32 (есть) для параллельного приема данных, и через пины перекидывать на первую STM32. Опять же, как именно закидывать данные в STM32? В случае второго контроллера у нас уже будет не 23 мс на получение данных, а 30 мс, но нам всё равно надо как-то их туда забросить.

3) Использовать какой-нибудь известный, классический подход, про который я не знаю, но который все используют в таких ситуациях (он есть?)

Подскажите, пожалуйста, как оптимальнее решить задачу.

Миниатюры

     

   

0

Сообщение от VBDUnit и будет норм?

На али оно в три раза дешевле стоит!
Не нужно кормить российских барыг!!!!111

Сообщение от VBDUnit Хватит ли мне пинов, чтобы управлять 18 лентами?

Если ленты - тупые, то хватит. Если же адресуемые — нет. В этом случае нужно смотреть, сколько таймеров. Один таймер с выходом CC — одна лента.

Добавлено через 3 минуты
А, можно, конечно, генерить это ногодрыгом через DMA (в BSRR или даже ODR), но скорость будет еще ниже. И оперативки больше понадобится.

1

Сообщение от Eddy_Em В этом случае нужно смотреть, сколько таймеров. Один таймер с выходом CC — одна лента.

он не с таймерами хочет общается, о чем и разгорелся сыр-бор. А управлять лентами с GPIO

1

Ну, в принципе, если взять 144-ногий МК, то можно будет, наверное, пару полных свободных портов найти. А то и вообще там FSMC будет.
Только ТС говорил, что ему не важна скорость - там будет тупая подсветка, т.е. можно и вообще хоть 1000 светодиодов на один канал таймера повесить, все равно глаз не заметит смены, а если каждый светодиод больше 1 секунды будет непрерывно гореть, проблем вообще не будет.

1

Сообщение от Eddy_Em Только ТС говорил, что ему не важна скорость - там будет тупая подсветка,

я уже не знаю что ТС говорил, то скорость не нужна, то 30 кадров/секунду, то бегущий огонь на 2 метрах (288 светодиодов) медленный слишком

1

... присоединюсь к вышесказанному, по поводу буферизации в памяти и работы через несколько каналов DMA - все это "круто" только, на первый взгляд. А по факту - типовая работа МК. В вашем случае код во время работы буферов вообще ничем занят не будет - разве что копированием данных, которое тоже можно реализовать на DMA.

Есть сомнения, что USB CDC эффективно будет и стабильно будет работать на 2,5 мбита. У меня на STM32F103 удавалось получить в районе 1,5МБит/с, но МК еще что-то там делал с другими интерфейсами (CAN'ами). А в Вашем случае МК по-проще, все-таки. В альтернативу этому можно предложить внешний USB CDC на базе МК FTDI. Они на столе стабильно работали и на 4,8 МБит/с, но я не уверен, что такие режимы эффективно будут работать со всеми озвученными ОСями. Есть разница.

И ... просто в альтернативу предложу многоцелевые МК для USB: https://ru.mouser.com/datashee... 541393.pdf Такие штуки широко получили известность в виде Saleae Logic анализатора, на котором, как я понял, решение о направлении потока данных решается на уровне драйвера. В тандеме с EEPROM (куда заливается конфигурация драйвера) они просто идеально ложатся под задачу ТС.

PS: а почему не рассматривается задача на базе RPi? Ведь у нее на борту в принципе все есть для запуска - и управление можно организовать, и все что необходимо...

1

Сообщение от Voland_ . У меня на STM32F103 удавалось получить в районе 1,5МБит/с, но МК еще что-то там делал с другими интерфейсами (CAN'ами)

Учитывая то, что в F103 невозможно одновременно работать с USB и CAN, это совершенно логично: как USB может отправлять данные, когда отключен?
Но честные 12Мбит на 103 получить можно. А т.к. он помощней 0x2, то и напрягать его во время передачи данных можно активней.
Как я уже говорил, при двойной буферизации единственное требование — чтобы МК успевал заполнять второй буфер. А скорость отправки коротких буферов всегда будет максимальной.
А если у вас аппаратный USB работает медленней, чем внешний через USART, то вы явно что-то неправильно делаете! У вас точно ничего лишнего в обработке прерываний USB нет? Или вообще поллинг?

1

Сообщение от Eddy_Em Но честные 12Мбит на 103 получить можно.

Ну не 12, конечно. Все-таки накладные расходы никто не отменял. Надо слать SOF, надо кидать запросы на IN транзакции. Но 2.5 Мб/с проблемой быть не должны. Если не на ST-HAL'е, естественно.

1

Сообщение от COKPOWEHEU Если не на ST-HAL'е, естественно.

И не на SPL.
И вообще не на индусокоде от ST

1

Сообщение от Voland_ почему не рассматривается задача на базе RPi?

Параллельное управление большим числом светодиодных лент

Сообщение от Eddy_Em А если у вас аппаратный USB работает медленней, чем внешний через USART, то вы явно что-то неправильно делаете!

Для обслуживания USB нужно выполнить больше кода чем для USART. МК может не успеть.

1

Сообщение от Eddy_Em читывая то, что в F103 невозможно одновременно работать с USB и CAN, это совершенно логично

можно даже с двумя канами (на F105) можно (хотя, я давно не перепроверял. Там же были прерывания на одном векторе для USB и CAN1/2... То есть это надо смотреть. Ноги ремапятся, если в этом возникает подозрение)

Сообщение от Eddy_Em А если у вас аппаратный USB работает медленней, чем внешний через USART, то вы явно что-то неправильно делаете!

какое-то весьма странное заключение. Это ж совершенно не связанные блоки. Какой смысл их вообще между собой сравнивать?

PS: для USB CDC и другого, на F103 и F105 стоят внешне похожие но внутри и со стороны API немного разные блоки. И оба их я использовал USB FS, может быть если на HS с внешним интерфейсом - было бы быстрее. В моем случае я сканил два CAN и пихал пакеты в VCP (в тексте). В итоге иногда их скорости (по CAN) были выше возможностей FIFO, хотя FIFO очень хорошо мог поддерживать пиковые нагрузки.

Ах да, совсем забыл - я для более высокой скорости на F105 еще выносил функции по парсингу и отправке в RAM, потому что latency FLASH сильно тормозила на этом коде. А 64кб рама в F105 было достаточно и для этого тоже

Сообщение от COKPOWEHEU Если не на ST-HAL'е, естественно.

юзал SPL (несколько измененный - я немного поменял отправляющие функции и добавил пару фиксов (были не поддерживаемые флаги)), на тот момент HAL еще не появился.

1

Сообщение от Voland_ юзал SPL

Тогда понятно: из этого индусокода больше полутора-двух мегабит вообще никак не выжать.

1

Сообщение от Voland_ Там же были прерывания на одном векторе для USB и CAN1/2

У 103 общая память для USB и CAN.
Как решили эту проблему?

Миниатюры

 

2

Сообщение от locm У 103 общая память для USB и CAN.

Он же про 105 дальше написал, видать, про 103 очепятался. На F103 невозможно одновременно CAN и USB завести.

1

Сообщение от locm Сообщение от VBDUnit Это оно? Нет не оно. Здесь выберите STM32F411CEU6 https://aliexpress.ru/item/4001049840288.html Сообщение от VBDUnit А чем Вы пользуетесь, если не секрет? Пишу на регистрах и SPL. HAL, LL использую только в том случае если нет SPL. Куб использую исключительно для быстрой конфигурации тактирования (узнаю коэффициенты умножения/деления) и для подбора выводов с учетом задействованной периферии. Сообщение от VBDUnit Т.е. без IDE? Почему же? С IDE. Но кроме CubeIDE есть много других. Пользуюсь EmBitz, но не уверен что она подойдет вам. Сообщение от VBDUnit Надеюсь, встроенный программатор в нём есть. На плате есть 4 контакте интерфейса ST-Link. Можно использовать тот что на дискавери или купить отдельный.

Спасибо! Хотя бы имею представление об альтернативных вариантах работы с этими контроллерами.

Сообщение от locm Должно хватить. У порта A выведено 14 выводов. Остальные нужно будет подключить к порту B. Насколько помню в F407 у меня были сложности с выводом в GPIO через DMA. Если ничего не путаю, с GPIO может работать только DMA2, а доступ к его каналам только у нескольких таймеров (TIM6 и TIM7, если ничего не путаю). F401 и F411 немного отличаются от F407 и возможно эта проблема не актуальна. Нужно уточнять в даташите.

Скажите, я правильно понял, что если в даташите пишут "timers up to 100 MHz" и "up to 78 I/O fast ports up to 100 MHz", это, фактически, означает, что можно переключать пины вплоть до периода 10 нс? Мне, конечно, столько не надо, но хотелось бы иметь представление о том, что реально значат эти цифры.

Если мне хватит ОЗУ, то я правильно понял, что мне достаточно взять буфер с данными, и, условно говоря, скормить указатель на него в какой-то регистр, то эта штука автоматически по таймеру выполнит все переключения GPIO с равными интервалами?

Сообщение от Eddy_Em Если ленты - тупые, то хватит. Если же адресуемые — нет. В этом случае нужно смотреть, сколько таймеров. Один таймер с выходом CC — одна лента.

Лент 18, и все "адресные" (не адресные, а "адресные" - которые ws2812b). Только я не очень понимаю, зачем мне отдельные таймеры на каждую ленту.

Сообщение от Eddy_Em А, можно, конечно, генерить это ногодрыгом через DMA (в BSRR или даже ODR), но скорость будет еще ниже. И оперативки больше понадобится.

Сообщение от Eddy_Em Ну, в принципе, если взять 144-ногий МК, то можно будет, наверное, пару полных свободных портов найти. А то и вообще там FSMC будет. Только ТС говорил, что ему не важна скорость - там будет тупая подсветка, т.е. можно и вообще хоть 1000 светодиодов на один канал таймера повесить, все равно глаз не заметит смены, а если каждый светодиод больше 1 секунды будет непрерывно гореть, проблем вообще не будет.

Подсветка нужна не тупая. 18 адресных лент, 1 метр/144 диода каждая. Все управляются отдельно, все меняют своё состояние с частотой 30 Гц. Каждая лента управляется 1 пином, последовательно задаётся состояние каждого диода.

Вот протокол:
https://duino.ru/svetodiodnaya... l-ws2812b/

Сообщение от ValeryS я уже не знаю что ТС говорил, то скорость не нужна, то 30 кадров/секунду, то бегущий огонь на 2 метрах (288 светодиодов) медленный слишком

Эти две вещи - те две причины, по которым я делаю не больше, и не меньше, чем 30 гц. Меньше не имеет смысла, потому что для плавной картинки нам нужно выжать из ленты максимально большую частоту, на которую она способна. А больше не имеет смысла, потому что лента физически это не выведет + будет еще больше веселья в духе "как передать 5 Мбит/с" на контроллер, а не 2,5 Мбит/с.

Сообщение от Voland_ ... присоединюсь к вышесказанному, по поводу буферизации в памяти и работы через несколько каналов DMA - все это "круто" только, на первый взгляд. А по факту - типовая работа МК. В вашем случае код во время работы буферов вообще ничем занят не будет - разве что копированием данных, которое тоже можно реализовать на DMA. Есть сомнения, что USB CDC эффективно будет и стабильно будет работать на 2,5 мбита. У меня на STM32F103 удавалось получить в районе 1,5МБит/с, но МК еще что-то там делал с другими интерфейсами (CAN'ами). А в Вашем случае МК по-проще, все-таки. В альтернативу этому можно предложить внешний USB CDC на базе МК FTDI. Они на столе стабильно работали и на 4,8 МБит/с, но я не уверен, что такие режимы эффективно будут работать со всеми озвученными ОСями. Есть разница. И ... просто в альтернативу предложу многоцелевые МК для USB: https://ru.mouser.com/datashee... 541393.pdf Такие штуки широко получили известность в виде Saleae Logic анализатора, на котором, как я понял, решение о направлении потока данных решается на уровне драйвера. В тандеме с EEPROM (куда заливается конфигурация драйвера) они просто идеально ложатся под задачу ТС.

Т.е. идея в том, что для работы с ПК мы берем вот этот контроллер, он принимает данные с ПК, заливает в некую общую c STM32 память, а STM32 из этой же памяти пихает всё в ленты через пины, так?

Сообщение от Eddy_Em Учитывая то, что в F103 невозможно одновременно работать с USB и CAN, это совершенно логично: как USB может отправлять данные, когда отключен? Но честные 12Мбит на 103 получить можно. А т.к. он помощней 0x2, то и напрягать его во время передачи данных можно активней. Как я уже говорил, при двойной буферизации единственное требование — чтобы МК успевал заполнять второй буфер. А скорость отправки коротких буферов всегда будет максимальной. А если у вас аппаратный USB работает медленней, чем внешний через USART, то вы явно что-то неправильно делаете! У вас точно ничего лишнего в обработке прерываний USB нет? Или вообще поллинг?

Сообщение от Voland_ какое-то весьма странное заключение. Это ж совершенно не связанные блоки. Какой смысл их вообще между собой сравнивать? PS: для USB CDC и другого, на F103 и F105 стоят внешне похожие но внутри и со стороны API немного разные блоки. И оба их я использовал USB FS, может быть если на HS с внешним интерфейсом - было бы быстрее. В моем случае я сканил два CAN и пихал пакеты в VCP (в тексте). В итоге иногда их скорости (по CAN) были выше возможностей FIFO, хотя FIFO очень хорошо мог поддерживать пиковые нагрузки. Ах да, совсем забыл - я для более высокой скорости на F105 еще выносил функции по парсингу и отправке в RAM, потому что latency FLASH сильно тормозила на этом коде. А 64кб рама в F105 было достаточно и для этого тоже

Есть еще мысли, первый, самый простой - тупо взять 2 контроллера и снизить нагрузку на USB в два раза. Второй - это тоже взять 2 контроллера, но пока в 1 заливаются данные, второй их выводит на ленты, потом они меняются. Хотя, на самом деле, если приглядеться к протоколу работы с лентами, то можно увидеть, что вывод кадра в ленту занимает 7 мс, и у нас остается 23 мс на заливку данных. Если данные будут поступать неравномерно, а пачками в промежуточные 23 мс но с большей, чем 2,5 Мбит/с скоростью, то можно и на одном контроллере. Вообще пока ощущение, что можно взять малину как приемник UDP по Ethernet, с малины через пины перекидывать данные на одну/несколько STM32 быстрым, но не критичным к малиновскому подлагиванию протоколом, а с STM32 уже управлять лентами. Нагроможденная, переусложнённая дичь, но, я хотя бы уверен, что она точно сработает. Протокол можно взять готовый (если есть), если нет - можно сочинить свой голимый велосипед, и вывезти скорость за счёт числа используемых пинов.

Если что - я в контроллерах новичок, поэтому могу не совсем правильно понимать суть некоторых вещей.

0

Сообщение от VBDUnit Эти две вещи - те две причины, по которым я делаю не больше, и не меньше, чем 30 гц. Меньше не имеет смысла, потому что для плавной картинки нам нужно выжать из ленты максимально большую частоту, на которую она способна.

"смешались в кучу кони, люди"(с)
начнем с предыстории вопроса: Откуда взялось 30 Гц?
От американского телевидения 30 кадров в секунду, или 60 полукадров, частота там сети 60 Гц. в Европе, в России частности, соответственно 25 и 50 Гц
а в кино использовался 24 кадра в секунду звуковое и 16 кадров в секунду "немое"
все это сделано для того чтобы предать плавность движения в кадре, типа поднял руку, ударил мяч,...
нужна такая частота?
движения в ленте 30 светодиодов за 1 секунду глаз просто не заметит

1

Сообщение от ValeryS "смешались в кучу кони, люди"(с) начнем с предыстории вопроса: Откуда взялось 30 Гц? От американского телевидения 30 кадров в секунду, или 60 полукадров, частота там сети 60 Гц. в Европе, в России частности, соответственно 25 и 50 Гц а в кино использовался 24 кадра в секунду звуковое и 16 кадров в секунду "немое" все это сделано для того чтобы предать плавность движения в кадре, типа поднял руку, ударил мяч,... нужна такая частота? движения в ленте 30 светодиодов за 1 секунду глаз просто не заметит

По сути я делаю примерно это
https://www.google.com/url?sa=... egUIARCJAg
только в более суровом виде. То, что показывает лента, должно быть синхронизировано с тем, что показывает дисплей. Если они будут показывать что-то разное, глаз это увидит.

В моей ситуации OLEDы обновляются 120 к/с. Ленты физически на это не способны, они даже 60 не выведут. Поэтому идея в том, что мы анализируем каждый 4 кадр из тех, что идет на OLEDы, и потом подгоняем ленты под этот кадр. Дополнительное веселье состоит в том, что подсветку видит периферическое зрение, а оно гораздо чувствительнее к движению, чем желтое пятно на сетчатке.

0

Сообщение от VBDUnit По сути я делаю примерно это

Герц 5, по моему мнению, за глаза хватит

Сообщение от VBDUnit Если они будут показывать что-то разное, глаз это увидит.

инерционность зрения, тем более не периферийного, изучи
периферийное это палочки - шустрые они , но они черно-белое
а цветное это колбочки, но они тормознутые
так что попробуй: смени желтый цвет на синий, по яркости они примерно одинаковые, и смотри прямо на ленту а потом мимо(включится периферийное зрение) и найди частоту когда переключение заметно не будет

Сообщение от VBDUnit чем желтое пятно на сетчатке.

это которое слепое? так оно вообще ничего не видит

1

Сообщение от ValeryS Герц 5, по моему мнению, за глаза хватит

А по моему - и 30 мало
https://www.youtube.com/watch?v=cognkytrQZQ

Сообщение от ValeryS инерционность зрения, тем более не периферийного, изучи периферийное это палочки - шустрые они , но они черно-белое а цветное это колбочки, но они тормознутые так что попробуй: смени желтый цвет на синий, по яркости они примерно одинаковые, и смотри прямо на ленту а потом мимо(включится периферийное зрение) и найди частоту когда переключение заметно не будет

Проверил - жёлтый от синего отличается, не так сильно, как если смотреть прямо, но разница есть. Пробовал и резко переключать и плавно. Плюс краем зрения я спокойно вижу шим, который не вижу если смотрю прямо. На периферии колбочек мало, но они всё же встречаются.

Сообщение от ValeryS это которое слепое? так оно вообще ничего не видит

Жёлтое пятно

Слепое пятно

Добавлено через 2 минуты
А что насчёт Ethernet/UDP на STM32? Насколько это хуже/лучше/сложнее/легче?

0

Сообщение от ValeryS Герц 5, по моему мнению, за глаза хватит

Те "ambilight", что я встречал, даже медленней работали: от силы 1Гц (а то и все 0.5!).
Такого гигантского количества светодиодов для ambilight не нужно. Хватит одного на пять сантиметров.

В общем, нет нужды делить все на секции: светодиодов будет немного, скорость небольшая, все можно посадить на один таймер. Ну, можно располовинить на два. И не придется замедлять скорость передачи данных, дрыгая ногами через DMA!

Кстати, если там в протоколе не манчестерский код, а как у WS2815, то с ногодрыгом по DMA еще и извратиться придется: ведь для передачи 1 бита нужен будет не один такт таймера и один uint16_t, а три такта таймера, соответственно, и три uint16_t. Правда, если вешать параллельно 16 лент, то это таки даст экономию.

Добавлено через 2 минуты

Сообщение от VBDUnit А что насчёт Ethernet/UDP на STM32?

Сразу скажу: это — не для начального уровня. Хотя бы лет 5-7 поработай, наберись опыта - тогда можно будет свой стек IP писать. Потому что lwIP, которой все пользуются, — адово УГ.

Кстати, ТС, а как ты собираешься получать исходные данные для твоего ambilight? Самый простой способ — перехватывать данные, которые идут к монитору/телевизору по HDMI. Но там такая адова скорость, что придется отдельный МК заводить!

1

Сообщение от Eddy_Em Те "ambilight", что я встречал, даже медленней работали: от силы 1Гц (а то и все 0.5!). Такого гигантского количества светодиодов для ambilight не нужно. Хватит одного на пять сантиметров. В общем, нет нужды делить все на секции: светодиодов будет немного, скорость небольшая, все можно посадить на один таймер. Ну, можно располовинить на два. И не придется замедлять скорость передачи данных, дрыгая ногами через DMA!

Ну так я затеял весь сыр-бор как раз потому, что существующие реализации амбилайта мне не понравились, поэтому я решил сделать свой это не совсем стандартный ambilight, светодиоды, в том числе, в разные стороны светить должны. По идее напрашивается мысль распределить ленты между 2-3 контроллерами.

Сообщение от Eddy_Em Кстати, ТС, а как ты собираешься получать исходные данные для твоего ambilight? Самый простой способ — перехватывать данные, которые идут к монитору/телевизору по HDMI. Но там такая адова скорость, что придется отдельный МК заводить!

Я боялся что для нескольких HDMI 2.1 нужен уже какой-нибудь страшный FPGA. Если существуют какие-то адские контроллеры, которое могут переварить 48 Гб/с, то я был бы рад узнать, что это. Есть ещё вариант каждый сигнал дублировать, один пихать в телевизор, второй в нечто, уменьшающее разрешение, например, до 384х216, и потом уже эту картинку обрабатывать контроллером. Но такая цепочка железа может сгенерить неслабую задержку. Но в этом способе (будь то FPGA или контроллер) очень привлекает то, что можно не запоминать целиком изображение, а анализировать построчно, практически обнуляя ту самую задержку

Есть довольно хороший способ через API DirectX 11 - прямо в видеопамяти можно получать текстурку, на которой виден весь рабочий стол. Поскольку экраны объединены средствами видеокарты в один виртуальный, с ним можно работать, как с единым целым.

Добавлено через 1 минуту

Сообщение от Eddy_Em Сразу скажу: это — не для начального уровня. Хотя бы лет 5-7 поработай, наберись опыта - тогда можно будет свой стек IP писать. Потому что lwIP, которой все пользуются, — адово УГ.

А в чем заключается его убогость? Медленный, много жрет, или глючит? Он точно не подойдет для моей задачи? Может быть, я вынесу его в отдельный, более слабый STM32 и буду общаться с ним через пины.

0