Передача 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 А по моему - и 30 мало

через сколько пользователь разобьёт эту систему?
мелькания вызывают агрессивность и головные боли

Сообщение от VBDUnit Ну так я затеял весь сыр-бор как раз потому, что существующие реализации амбилайта мне не понравились,

ну и чем не понравились? историю вопроса почитал? исследования психологов? или просто "нужно круче"? зачем нужны 144 светодиода на метр? там светодиоды впритык практически стоят а угол их 120 градусов. Световое пятно на экране(считай стенка) будет отличатся одного светодиода от другого?

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

Сообщение от VBDUnit это не совсем стандартный ambilight, светодиоды, в том числе, в разные стороны светить должны.

а это главный вопрос-зачем?
для чего вообще была эта штука придумана ambilight?

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

Сообщение от VBDUnit На периферии колбочек мало, но они всё же встречаются.

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

1

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

нет, идея в том, что этот МК может напрямую управлять своими GPIO как вы хотите, и с довольно большой скоростью. Другими словами, вы получаете "пианино", управляемое пакетами через USB. И что там на выходе этого пианино - SPI (как решение расширения количества пинов с пом. 74HC595) или что-то еще - тут не важно. Важно, что вы получаете надежную схему управления GPIO со стороны ПК.

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

да, я уже подзабыл как там было все (. Навен, когда говорил о CAN + USB - речь действительно шла только об одном CAN и на F105. В других же вариантах действительно речь шла о передаче по UART (с одним или двумя CAN).

Сообщение от VBDUnit вывод кадра в ленту занимает 7 мс, и у нас остается 23 мс на заливку данных.

Вы все время делаете неправильную нагрузку на ваш софт, предполагая, что всем процессом управляет процессор. В МК процессор - это иногда вообще бесполезная, читай, ненужная вещь, необходимая лишь для конфигурации периферии . В случае с хардверными блоками все намного проще - ваша задача делится на хендлеры (функции), вызываемые в прерывании таймера, и функции управления периферией, такой как USB и что-то еще, что даст _удобно_ развернуть GPIO. Будь то экстендеры типа HC595, о которой я упомянул выше, или что-то, с чем удобно работать через готовый интерфейс + DMA контроллера. В этом случае Ваш процессор можно спокойно вообще уводить в HALT и заниматься сугубо обработкой прерываний.

1

Сообщение от ValeryS Сообщение от VBDUnit А по моему - и 30 мало через сколько пользователь разобьёт эту систему? мелькания вызывают агрессивность и головные боли Сообщение от VBDUnit Ну так я затеял весь сыр-бор как раз потому, что существующие реализации амбилайта мне не понравились, ну и чем не понравились? историю вопроса почитал? исследования психологов? или просто "нужно круче"? зачем нужны 144 светодиода на метр? там светодиоды впритык практически стоят а угол их 120 градусов. Световое пятно на экране(считай стенка) будет отличатся одного светодиода от другого? Добавлено через 1 минуту Сообщение от VBDUnit это не совсем стандартный ambilight, светодиоды, в том числе, в разные стороны светить должны. а это главный вопрос-зачем? для чего вообще была эта штука придумана ambilight?

Пожалуйста, просто помогите мне доделать эту штуку. Если я окажусь неправ, то можно будет потом показывать на меня пальцем и говорить "вот так бывает с теми, кто не умеет прислушиваться к умным людям". А если я окажусь прав, то появится довольно интересная и красивая штука.

Сообщение от Voland_ нет, идея в том, что этот МК может напрямую управлять своими GPIO как вы хотите, и с довольно большой скоростью. Другими словами, вы получаете "пианино", управляемое пакетами через USB. И что там на выходе этого пианино - SPI (как решение расширения количества пинов с пом. 74HC595) или что-то еще - тут не важно. Важно, что вы получаете надежную схему управления GPIO со стороны ПК.

Вы все время делаете неправильную нагрузку на ваш софт, предполагая, что всем процессом управляет процессор. В МК процессор - это иногда вообще бесполезная, читай, ненужная вещь, необходимая лишь для конфигурации периферии . В случае с хардверными блоками все намного проще - ваша задача делится на хендлеры (функции), вызываемые в прерывании таймера, и функции управления периферией, такой как USB и что-то еще, что даст _удобно_ развернуть GPIO. Будь то экстендеры типа HC595, о которой я упомянул выше, или что-то, с чем удобно работать через готовый интерфейс + DMA контроллера. В этом случае Ваш процессор можно спокойно вообще уводить в HALT и заниматься сугубо обработкой прерываний.

Это прямо вот то, чего я пытаюсь сделать с самого начала - то самое надёжное пианино, которое просто переключает GPIO по времени. Только вот годы программирования под ПК делают свое дело - я не очень представляю себе, как это всё может делаться без процессора. Т.е. там внутри физически коммутируются аппаратные блоки с нужными таймерами? А как функция управления периферией договорится с GPIO? Ну то есть вот таймер пнул аппаратный блок, он получил и расшифровал с USB данные, дальше... просто запихнул в GPIO? Без конвертаций и подготовки? Это вообще законно?)

0

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

Жирный и содержит много ненужного. Но "на крайний случай" сгодится, наверное.

Сообщение от VBDUnit А как функция управления периферией договорится с GPIO?

Через прямой доступ к памяти. Таймер на каждое свое событие UEV (можно и другие события настроить) пинает соответствующий блок DMA. Тот в свою очередь берет данные по определенному адресу и пишет их в другой адрес, инкрементируя затем то, что сказано было инкрементировать.
В случае двойной буферизации для работы с портом через ODR делаем так. Сначала настраиваем таймер и DMA, указав DMA адрес периферии, инкремент памяти и отсутствие инкремента адреса периферии. Далее заполняем один буфер (каждое значение uint16_t и будет значением ODR этого порта в заданный момент времени), указываем блоку DMA адрес памяти, запускаем DMA. Тем временем заполняем второй буфер. При получении прерывания готовности переключаем блоки. Если же нужно выдерживать какую-то паузу, а скорость заполнения буфера выше скорости его передачи, то блок можно начать заполнять по прерыванию половины передачи DMA. Или даже запустить в однократном режиме другой таймер, а на его переполнение начать заполнять буфер.

1

Сообщение от VBDUnit Это вообще законно?)

ну, насколько я понимаю, Cypress очень хорошо реализовали обмен данными с софтом своего процессора, тем самым обеспечив высокоскоростной обмен. Например, даже старые логические анализаторы Saleae Logic на базе CY7C68013A справлялись с потоком до 100мбит/с, что вполне достаточно для очень многих проблем в дебаге коммуникации. Соответственно, какой бы ни был процессор (8051-совместимый, вроде бы) внутри, он обеспечивает такой поток при работе с GPIO.

PS: это обсуждение довольно давнее, но вроде бы на этих модулях люди организовывали и двусторонний обмен данными (а значит управляли и GPIO, а не только читали состояние), а это значит что Ваша задача осуществима. Правда, к сожалению, я до этого так и не дошел, хотя, в задумках организовать "плеер" сохраненных диаграмм от saleae был в планах, но так и не осуществился. На сегодня эти процы заметно эволюционировали, и вы можете расчитывать и на скорости в USB3.0...

1

Сообщение от VBDUnit А как функция управления периферией договорится с GPIO? Ну то есть вот таймер пнул аппаратный блок, он получил и расшифровал с USB данные, дальше

Я в другой теме давал ссылку https://www.cyberforum.ru/blog... g5169.html

Сообщение от Eddy_Em Сначала настраиваем таймер и DMA, указав DMA адрес периферии, инкремент памяти и отсутствие инкремента адреса периферии. Далее заполняем один буфер (каждое значение uint16_t и будет значением ODR этого порта в заданный момент времени), указываем блоку DMA адрес памяти, запускаем DMA. Тем временем заполняем второй буфер. При получении прерывания готовности переключаем блоки.

Зачем такие сложности?
Есть же прерывания при передаче половины и всего буфера. Тоже самое, но подменять ничего не нужно.

1

Я, кстати, у себя в ЖЖшке про GPIO через DMA писал.

Сообщение от locm Есть же прерывания при передаче половины и всего буфера.

Вообще-то, я в тексте это и написал! А подменять нужно обязательно: без двойной буферизации может быть приличная пауза между посылками. С нею же все ОК: как только передали один буфер, начали передавать второй, а первый тем временем заполняем.

1

Сообщение от Eddy_Em А подменять нужно обязательно: без двойной буферизации может быть приличная пауза между посылками.

Какая пауза. Буфер один. Пока передается первая половина, заполняем вторую и наоборот. Зачем подменять буферы?

1

Сообщение от locm Пока передается первая половина, заполняем вторую и наоборот

И действительно.

1

Хочу начать с простого - суметь передать данные с компьютера на отладочную STM32F072B Discovery, на ней как раз есть второй USB вход для работы с ней как с устройством. Как приноровлюсь хочу реализовать это уже на STM32F411CEU6 (она приехала, вместе с программатором).

Как я понимаю, проще всего работать через WinUSB. Со стороны ПК, как я понимаю, драйвер писать в таком случае не придется, я могу воспользоваться API-функциями вроде этой. Нашёл вот такой мануал: https://michaeltien8901.github... EVICE.html
Я в правильную сторону копаю?

0

Всем огромное спасибо за помощь!

Разобрался с CDC - вроде работает (данные отправляю из C# через стандартный SerialPort, скорость ставлю 10_000_000 бод, оно это ест, не знаю, какая реально у него получается скорость), передача и обработка инфы (8640 байт) занимает около 33 мс, самое то.

0

Получилась подсветка на 2318 диодов. Яркость где-то 40 000 люмен, кушает до 440 Вт. Контроллер на всякий подключен через гальваническую развязку.

Видео работы подсветки: https://www.youtube.com/watch?v=N8NRuhs1RoU

0

Сообщение от VBDUnit Тег YouTube не работает - пытаюсь вставить, получается просто пустое место

как видишь работает
1 копируешь адрес ссылки https://www.youtube.com/watch?v=N8NRuhs1RoU
2 удаляешь все до последнего слэша, в данном случае до знака равно N8NRuhs1RoU
3 выделяешь N8NRuhs1RoU,и жмешь кнопочку "Ютубе"
4 в появившемся окне выбираешь время воспроизведения, в данном случае с начала - "0" и получаешь [YOUTUBE="0"]N8NRuhs1RoU[/YOUTUBE]

0

Сообщение от VBDUnit страшный FPGA

Да не такие уж они и страшные.

Сообщение от VBDUnit какие-то адские контроллеры, которое могут переварить 48 Гб/с

Это наверное только оптика. Но какие же там будут проблемы с экранированием от помех.

0

Сообщение от ValeryS как видишь работает 1 копируешь адрес ссылки https://www.youtube.com/watch?v=N8NRuhs1RoU 2 удаляешь все до последнего слэша, в данном случае до знака равно N8NRuhs1RoU 3 выделяешь N8NRuhs1RoU,и жмешь кнопочку "Ютубе" 4 в появившемся окне выбираешь время воспроизведения, в данном случае с начала - "0" и получаешь

Спасибо, наконец-то я узнал, как заставить это работать

Сообщение от Worldmaster Сообщение от VBDUnit страшный FPGA Да не такие уж они и страшные. Сообщение от VBDUnit какие-то адские контроллеры, которое могут переварить 48 Гб/с Это наверное только оптика. Но какие же там будут проблемы с экранированием от помех.

Имеется ввиду там HDMI на 48 Гбит/с, и да - он оптический. Но сам разъём - электроника и медь, с помехами будет весело. А на выходе частоты гораздо меньше.

0

Не плохо но фиксацию движения экранов нужно сделать. А то как уши у слона болтаются когда доходят до предела.

Добавлено через 3 минуты
Здорово.

1

Сообщение от VladimirU Не плохо но фиксацию движения экранов нужно сделать. А то как уши у слона болтаются когда доходят до предела. Добавлено через 3 минуты Здорово.

Спасибо

По фиксации согласен, но пока не знаю как. В моём понимании для этого нужно заменить текущие приводы (люфты ужасные + масса уха под 35 кг- отсюда болтание) на линейные актуаторы. Но я пока не нашёл такие актуаторы, которые можно было бы руками туда-сюда двигать. То есть чтобы экраны могли двигаться как сами, так и вручную - подошёл к экрану и загнул/разогнул его рукой. Текущая схема, при всех её недостатках, это позволяет.

0

Сообщение от VBDUnit То есть чтобы экраны могли двигаться как сами, так и вручную - подошёл к экрану и загнул/разогнул его рукой.

Тут можно если финансы есть применить сервомоторы с энкодерами они 100% мотания уберут и можно организовать что то типо ЭУР на авто тоесть рукой слегка панель двигаешь сервомотор помогает.

0