Спасибо, вкусно. Получается, по одному контроллеру на телик.
В общем в реальности у меня лично процессор простаивал почти всегда при том, что ленты обновлялись настолько часто, насколько частота их шины позволяет (800k вроде бы).
Там другая проблема возникает (с моими лентами по крайней мере) — цвета начинают ехать, потому что зелёный светодиод меняет цвет медленнее, чем синий и красный — я выяснил это, когда изучал ленты снимая маленький кусочек на видео 960 к/c. Это можно купировать программно, но я решил не усложнять алгоритмы.
cypress (у них тоже блоки для реализации кастомной периферии есть), но у cypress совершенно другой уровень вхождения и ценники.
Так это ж вообще жесть, это оборудование для видеостен же и обработки сигналов на телевидении, с SDI и прочими наворотами. Как я понимаю, у них там есть коммутаторы с FPGA, которые можно прошить под свою задачу — и мы можем перенести анализ картинки в железо.
Насколько я знаю, HDMI — это уже жесть, а в моем случае это HDMI 2.1, в котором, кажется, поменяли способ передачи данных чтобы 48 Гбит/с сделать, и железо, которое это переварить может, ещё на порядок сложнее, как и сама обработка. То есть это прямо вершина жести FPGA.
На самом деле не обязательно, если сделать подтяжку к питанию на линию данных, то можно обойтись одной платой с линией большой длинны (это в теории, сам не проверял). Если ставить много ESP шум в радиоэфире будет ой какой веселый :)
Сейчас‑то понятно, в те времена я это планировал на случай не из‑за ослабления сигнала, а если мне вообще никак не удастся одновременно‑параллельно управлять лентами с одной платы. т. е. это резервный план — не получается все цеплять к одной плате — чтобы решить задачу, мы откатываемся к стандартным библиотекам, а значит, одна лента — один контроллер. И да, эфир я бы забил этим стадом. Поэтому до последнего не хотел в это лезть.
В целом хороший вариант. Подскажу один опен сорс проект, называется WLED. На нем делал-настольные лампы. Там есть готовое приложение под Android/OS и веб интерфейс (и прочие плюшки), как и способ синхронизации нескольких плат по сети. Может сам проект из коробки не подходит под Вашу задумку, но возможно натолкнет на полезные мысли ;)
Спасибо, интересная штука. Сейчас мне видится оптимальной такая архитектура: главный контроллер и ведомые, обслуживающие конкретные ленты. От главного к ведомым сигналы идут по UART, а они уже работают с конкретной лентой.
В главный контроллер засунуть модифицированную версию вот этой вот WLED. Когда с компа данные идут — оно тупо показывает то, что говорит комп. Если комп не дает данные (выключен или софт закрыли) — оно начинает думать само и выводить вот эти все штуки из WLED, с управлением по WiFi и всё такое.
Вопрос в скорости переключения) Собственно, если я не ошибаюсь, e‑ink так и работает — там электрическим потенциалом заставляют перемещаться частички чернил в капсулах‑пикселях.
Хм. А есть ли возможность из FPGA докопаться до этой памяти? т. е. вот у нас ARM, вот FPGA. ARM, понятное дело, может работать с памятью. А можно ли сделать фишку, чтобы ARM писал в память, а FPGA её читал? И как то их синхронизировать?
Но под ваш проект ну как будто бы оно прям само напрашивается. Либо HDMI читать либо забирать данные с Ethernet и раскидывать через FPGA на сколько угодно лент. Выводов у FPGA выше крыши, и разведенных выводов на плате майнера тоже хватает с головой.
Тут вопрос — хватит ли этого FPGA для того, чтобы жрать картинку из HDMI. Я с FPGA никогда не работал, и не имею даже интуитивного понимания, как соотносить число логических блоков с решаемыми задачами. Например, сколько их надо для того, чтобы, ну, скажем, повысить яркость HDMI сигнала. т. е. мы не запоминаем кадр, а считали пиксель (ну или пару строк, если у нас цветовая субдискретизация), поменяли, отправили.
Ещё тут может возникнуть сложность с тем, что сигнал HDR. Я не знаю, как именно он кодируется в HDMI, но на компе для этого рабочий стол рендерится в числах с плавающей запятой половинной точности (fp16). В HDMI он, вероятно, залезает уже 10-битным, и, наверное, как целое число. Но для его грамотной оценки, чтобы потом отправить на ленту, его надо будет конвертировать в число с плавающей запятой. Здесь мы можем выкрутиться и сделать табличку на 1024 значения, которую один раз рассчитает ARM и потом FPGA будет просто юзать. Но здесь вопрос: где хранить таблицу? В памяти? Или тут надо отключить мышление программиста и сделать, чтобы ARM сам переконфигурировал FPGA в эту самую таблицу? Типа обработчик данных — это и есть та самая таблица? А хватит ли тут логических блоков? В общем, вопросов тут через край...
Ethernet и раскидывать через FPGA
А вот это уже выглядит гораздо проще. И да, FPGA здесь со своим количеством выводов очень выигрышно смотрится.
тут мне надо будет хорошо подумать, как объяснить эти штуки без залезания в дебри графики и программирования.
Я думаю, пройдет небольшое время, и такое станет возможно делать нейросетями. Они пока от силы умеют только в органику, но до технических штук должны постепенно дойти — ведь DIY‑видео в сети много, есть на чём учить.
За идею спасибо — вероятно, попробую что‑нибудь такое сделать.
Спасибо, Вы первый, кто смог объяснить понятным языком, как работает этот долбаный таймер. То есть я просто считываю с компа пакет в память и дальше просто триггерю таймер чтобы он пробежался по памяти и запихнул её в шину. А вот по считыванию без синхронизации есть вопрос:
Причём можно программно перезапускать скан памяти синхронно с каждым видео-кадром. А можно зациклить скан аппаратно, и пользоваться памятью, как фрейм-буфером, больше не отвлекаясь на физический вывод.
Технически да — я могу прямоточно жрать данные из COM и сразу отправлять их в ленты. Но всё равно какой‑то синхроимпульс «начать сначала» должен быть, потому что на компе в ОС задержки, измеряемыми сотнями микросекунд, делать геморно. В Windows, конечно, есть точный мультимедийный таймер, но всё равно — лучше, чтобы железо могло, отбивая пакеты данных, по моей команде тормознуть, чтобы показать начало кадра. Интересно, как такое сделать? Могу ли я всё это прямоточное железо в контроллере, которое само всё читает и пишет, заставить пропустить N тактов таймера? Или таймеру временно интервал увеличить?
А если, допустим, надо синхронизировать скан памяти с отправкой в шину и чтение данных с компа — как это тут делается? В программировании для этого я бы воткнул какой‑нибудь семафор (ManualResetEventSlim), и здесь, вероятно, тоже что‑то подобное программно. Но, как я понимаю, здесь и для этого есть какая‑то аппаратная приблуда?
Предположу, что между блоком, который читает‑пишет, и таймером, есть какая то «линия», которую я могу в нужный момент разомкнуть или замкнуть, и так управлять всем этим делом. И ещё какая‑то штука, сбрасывающая указатель считываемой памяти.
Спасибо, отличная идея. Наверное, попробую амперметр просто подоткнуть к клеммам подсветки в коробке. Можно даже в каждый БП подселить маленький контроллер, мерить ток и докладывать компу в реалтайме.
Видел такие штуки. Есть вообще вот такие турбоблевотроны:
Три телика с подсветкой сюда не воткнёшь, а вот в VR очках эпичность будет зашкаливать.
А как Вы установили руль и штурвал так, чтобы они не мешали? У меня просто пылится Logitech G29, на котором очень вкусно, внезапно, гонять в GTA5 с модом на руль, но пока руки не доходят его вклинить на стол. А тут и штурвал и руль сразу.
Большое спасибо, рад был стараться :) И что оно торт тоже приятно слышать :)
Наверное очень много времени убили на все эти визуализации?
Есть такое:) По 3D там я сделал мастер‑модель на основе Inventorовских моделей, которые на производство в своё время отправлялись. В мастер‑модели прорисовано всё и зариганы все провода. Вот она была самой долгой. Дальше просто когда что‑то надо показать выцепляешь нужный кусок и анимируешь как надо. Иногда надо было допиливать, но не сильно.
Спасибо, вкусно. Получается, по одному контроллеру на телик.
Там другая проблема возникает (с моими лентами по крайней мере) — цвета начинают ехать, потому что зелёный светодиод меняет цвет медленнее, чем синий и красный — я выяснил это, когда изучал ленты снимая маленький кусочек на видео 960 к/c. Это можно купировать программно, но я решил не усложнять алгоритмы.
Так это ж вообще жесть, это оборудование для видеостен же и обработки сигналов на телевидении, с SDI и прочими наворотами. Как я понимаю, у них там есть коммутаторы с FPGA, которые можно прошить под свою задачу — и мы можем перенести анализ картинки в железо.
Насколько я знаю, HDMI — это уже жесть, а в моем случае это HDMI 2.1, в котором, кажется, поменяли способ передачи данных чтобы 48 Гбит/с сделать, и железо, которое это переварить может, ещё на порядок сложнее, как и сама обработка. То есть это прямо вершина жести FPGA.
Сейчас‑то понятно, в те времена я это планировал на случай не из‑за ослабления сигнала, а если мне вообще никак не удастся одновременно‑параллельно управлять лентами с одной платы. т. е. это резервный план — не получается все цеплять к одной плате — чтобы решить задачу, мы откатываемся к стандартным библиотекам, а значит, одна лента — один контроллер. И да, эфир я бы забил этим стадом. Поэтому до последнего не хотел в это лезть.
Спасибо, интересная штука. Сейчас мне видится оптимальной такая архитектура: главный контроллер и ведомые, обслуживающие конкретные ленты. От главного к ведомым сигналы идут по UART, а они уже работают с конкретной лентой.
В главный контроллер засунуть модифицированную версию вот этой вот WLED. Когда с компа данные идут — оно тупо показывает то, что говорит комп. Если комп не дает данные (выключен или софт закрыли) — оно начинает думать само и выводить вот эти все штуки из WLED, с управлением по WiFi и всё такое.
По FPGA согласен. Но вроде как есть же какие‑то HDMI Receiverы как раз чтобы не руками сигнал декодировать? И с ними, по идее, должно быть полегче.
Да. Вот например. Жалко я про них слишком поздно узнал — всё бы было гораздо проще :)
А есть подробности? Там кейкапы как отдельные детали? Насколько она разборная? Можно ли купить их две и из второй собрать цифровой блок?
Вопрос в скорости переключения) Собственно, если я не ошибаюсь, e‑ink так и работает — там электрическим потенциалом заставляют перемещаться частички чернил в капсулах‑пикселях.
Круть) Руль юзал, а вот периферией для авиасимов не пользовался никогда. Захотелось.
Вопрос: во втором случае проп‑контрол никак не зафиксирован? Типа там усилие не такое, чтобы как руль прикручивать к столу?
Кстати у меня была одна из мыслей перейти на Raspberry Pico, но не из‑за этого, а потому что там легче блокировать прерывания, как я понял.
То есть именно параллельно сразу на кучу лент? Или там SPI?
Спасибо!)
Спасибо!
Хм. А есть ли возможность из FPGA докопаться до этой памяти? т. е. вот у нас ARM, вот FPGA. ARM, понятное дело, может работать с памятью. А можно ли сделать фишку, чтобы ARM писал в память, а FPGA её читал? И как то их синхронизировать?
Тут вопрос — хватит ли этого FPGA для того, чтобы жрать картинку из HDMI. Я с FPGA никогда не работал, и не имею даже интуитивного понимания, как соотносить число логических блоков с решаемыми задачами. Например, сколько их надо для того, чтобы, ну, скажем, повысить яркость HDMI сигнала. т. е. мы не запоминаем кадр, а считали пиксель (ну или пару строк, если у нас цветовая субдискретизация), поменяли, отправили.
Ещё тут может возникнуть сложность с тем, что сигнал HDR. Я не знаю, как именно он кодируется в HDMI, но на компе для этого рабочий стол рендерится в числах с плавающей запятой половинной точности (fp16). В HDMI он, вероятно, залезает уже 10-битным, и, наверное, как целое число. Но для его грамотной оценки, чтобы потом отправить на ленту, его надо будет конвертировать в число с плавающей запятой. Здесь мы можем выкрутиться и сделать табличку на 1024 значения, которую один раз рассчитает ARM и потом FPGA будет просто юзать. Но здесь вопрос: где хранить таблицу? В памяти? Или тут надо отключить мышление программиста и сделать, чтобы ARM сам переконфигурировал FPGA в эту самую таблицу? Типа обработчик данных — это и есть та самая таблица? А хватит ли тут логических блоков? В общем, вопросов тут через край...
А вот это уже выглядит гораздо проще. И да, FPGA здесь со своим количеством выводов очень выигрышно смотрится.
Где же Вы раньше были?) Спасибо за совет!
Я правильно понял, что там лужёная медь у них?
Хм, интересная идея. Главная проблема в
тут мне надо будет хорошо подумать, как объяснить эти штуки без залезания в дебри графики и программирования.
Я думаю, пройдет небольшое время, и такое станет возможно делать нейросетями. Они пока от силы умеют только в органику, но до технических штук должны постепенно дойти — ведь DIY‑видео в сети много, есть на чём учить.
За идею спасибо — вероятно, попробую что‑нибудь такое сделать.
Спасибо, Вы первый, кто смог объяснить понятным языком, как работает этот долбаный таймер. То есть я просто считываю с компа пакет в память и дальше просто триггерю таймер чтобы он пробежался по памяти и запихнул её в шину. А вот по считыванию без синхронизации есть вопрос:
Технически да — я могу прямоточно жрать данные из COM и сразу отправлять их в ленты. Но всё равно какой‑то синхроимпульс «начать сначала» должен быть, потому что на компе в ОС задержки, измеряемыми сотнями микросекунд, делать геморно. В Windows, конечно, есть точный мультимедийный таймер, но всё равно — лучше, чтобы железо могло, отбивая пакеты данных, по моей команде тормознуть, чтобы показать начало кадра. Интересно, как такое сделать? Могу ли я всё это прямоточное железо в контроллере, которое само всё читает и пишет, заставить пропустить N тактов таймера? Или таймеру временно интервал увеличить?
А если, допустим, надо синхронизировать скан памяти с отправкой в шину и чтение данных с компа — как это тут делается? В программировании для этого я бы воткнул какой‑нибудь семафор (ManualResetEventSlim), и здесь, вероятно, тоже что‑то подобное программно. Но, как я понимаю, здесь и для этого есть какая‑то аппаратная приблуда?
Предположу, что между блоком, который читает‑пишет, и таймером, есть какая то «линия», которую я могу в нужный момент разомкнуть или замкнуть, и так управлять всем этим делом. И ещё какая‑то штука, сбрасывающая указатель считываемой памяти.
Не, с колбасой.
Точно. Хотя во втором случае подшипники могут быть вольфрамовыми.
Нет, видимо я просто такой :) а бутерброды люблю, да.
Спасибо, отличная идея. Наверное, попробую амперметр просто подоткнуть к клеммам подсветки в коробке. Можно даже в каждый БП подселить маленький контроллер, мерить ток и докладывать компу в реалтайме.
Видел такие штуки. Есть вообще вот такие турбоблевотроны:
Три телика с подсветкой сюда не воткнёшь, а вот в VR очках эпичность будет зашкаливать.
А как Вы установили руль и штурвал так, чтобы они не мешали? У меня просто пылится Logitech G29, на котором очень вкусно, внезапно, гонять в GTA5 с модом на руль, но пока руки не доходят его вклинить на стол. А тут и штурвал и руль сразу.
Большое спасибо, рад был стараться :) И что оно торт тоже приятно слышать :)
Есть такое:) По 3D там я сделал мастер‑модель на основе Inventorовских моделей, которые на производство в своё время отправлялись. В мастер‑модели прорисовано всё и зариганы все провода. Вот она была самой долгой. Дальше просто когда что‑то надо показать выцепляешь нужный кусок и анимируешь как надо. Иногда надо было допиливать, но не сильно.
А живые съёмки это трэш, да :)
Спасибо, кажется я начал задумываться об апгрейде :)