Комментарии 132
Статья и оформление огонь!
обязательно всплывёт какая‑нибудь кристаллизация смазки в подшипниках под воздействием тока
Подшипники могут просто приварится в месте контакта, ведь пятно контакта стремится в точку.
Кстати да. А потом их отхрустят приводы, потом они снова приварятся — шарик постепенно превратится в абразив, и износ подшипника улетит в космос очень быстро. Вот, собственно и ответ, почему так делать не надо.
Хотя, если применить какую‑нибудь токопроводящую смазку и залить туда до краёв, так, чтобы она не вытекала оттуда, пятно контакта можно будет расширить. В конце‑концов туда можно залить какой‑нибудь гафний и греть его, ну или ртуть — но тогда надо с герметизацией хорошо работать, а ещё она любит амальгамить всё подряд.
О, боги! Человеку надо передать мощность и он забыл простую формулу P = U * I. Лучше бы подсмотрел, как люди передают 50 Вт на 100 метров посредством тонких проводов в PoE. Напомню, что 50 Вт на 5 В это 10 А.
Ну снисходительнее надо быть, человек вообще не в теме проектирования и разработки таких систем. Т.е. очевидно отсутствует пониманием даже основ и элементарных нормативов, типа 6А/мм2 для провода, не говоря уже про учет типа прокладки, допустимого перегрева и т.д., отсюда и все проблемы. Туда же перетоки между БП, импульсные перегрузки, кучи конденсаторов, сдохшие контроллеры и т.д. А хобби это как раз вариант набить шишки и разобраться на собственном опыте и за свой счет - лишь бы не привело к пожару. Страшно когда люди с такими навыками лезут в промышленные или серийные решения - где-то была статья про контроллер лифта на ардуине или малине :)
Но сама работа над статьей заслуживает уважения, оформление шикарное и читать интересно.
UPD: для передачи я бы использовал UART или SPI с DMA, подобрав скорость и кол-во бит чтобы получить нужные интервалы.
Да не, я без наезда. Но правильно поставленный вопрос решал его проблему кардинально. Например, 1 БП на 48В и 2А (не дорого и компактно) без проблем бы потянул всю конструкцию. Локальные малогабаритные понижайки DC-DC, общая масса, исключающая перекосы потанцевалов, общая гальваническая развязка от промышленной сети и низкие безопасные напряжения. Это всё следствие лишь решения передать мощность а не ток.
К инженерной составляющей претензий нет, всё сделано шикарно и я так точно скорее всего не смогу. Хотя у меня есть дипломы по части машиностроения, по части АСУ и 30+ летний практический стаж в электронику и инженерию всяких устройств.
Страшно когда люди с такими навыками лезут в промышленные или серийные решения - где-то была статья про контроллер лифта на ардуине или малине :)
Когда в 96м году нам в подъезде меняли выгоревший в результате пожара лифт, то обновляли его вместе с машинным отделением. Шкафы управления и логики чисто на реле заменили на 1 шкаф со схемой. Когда я заглянул внутрь, то там было что-то типа MCS51 контроллера. Современные лифты с экранами и квазисенсорными кнопками с подсветкой тоже скорее всего на МК. Не вижу ничего плохого в этом.
Плохо не то, что лифты на МК.
Лет 30 назад, мне, тогда еще очень молодому человеку, гендир компании где я работал предложил автоматизировать аэропорт. Ни я ни он ничего обо всём этом не знали вообще, как и никто в компании(для простоты - мы арбузами торговали). Слава богу как-то замяли...
Полностью согласен, что вопрос именно в поставновке задачи. Чтобы правильно задать вопрос нужно знать половину ответа, т.е. владеть подходами к проектированию, инструментами, знать комплектацию и т.д. :)
По лифтам проблема не в МК, во всех взрослых PLC стоят те же мк. Вопрос именно в ардуино. Во-первых трассировка ардуины, во-вторых схемотехника, в-третьих подход к коду, кто видел - это просто мрак. Не имею ничего против как устройства для поделок, сам иной раз пользуюсь, когда по быстрому что-то проверить надо, но использовать это в реальных проектах - да ну нафиг. Т.е. если не единичное изделие, и подумать чуть дальше - поддержка, сопровождение, гарантия, надежность то проще сразу сделать нормально. Сугубо мое личное мнение, у меня дома стоит серийный 3д принтер DaVinci вроде как на платформе ардуино и даже работает, но от ардуины там только загрузчик, как я понял.
Спасибо!
для передачи я бы использовал UART или SPI с DMA, подобрав скорость и кол‑во бит чтобы получить нужные интервалы.
Уже после того, как я сделал эту штуку, я понял, что надо было использовать SPI. При тех скоростях что он даёт и при условии, что аппаратная поддержка SPI есть почти везде — можно было бы сцепить все ленты в одну и управлять через 1 пин. Только ленты надо было изначально брать другие. И как бонус я бы получил более высокую частоту обновления.
Я бы не стал формировать программно или имитировать последовательными интерфейсами протокол WS281x. Я бы поставил CPLD, сделал в неё SPI Slave и принимал бы чистые RGB выгружая 24 бита за раз. Можно подобрать скорость SPI так, чтобы передача каждых 3 байт по SPI соответствовало передачи 3 байт в интерфейс, можно сделать небольшой FIFO. Ну а если всё же идти по-тяжёлой на ПЛИС, то взял бы уже какой-нить доступный GoWin с хард ядром на нём, обвесил бы его этими интерфейсами для WS281x и это была бы полная замена STMки в треть Discovery:
CPLD
Так, спасибо что расширили кругозор :)
т. е. идея в том, что мы вот это вот недоfpga конфигурируем в качестве конвертера SPI → WS2812b с поправкой, что ширина импульса на входе и выходе должна кореллировать?
по-тяжёлой на ПЛИС, то взял бы уже какой-нить доступный GoWin с хард ядром на нём, обвесил бы его этими интерфейсами для WS281x и это была бы полная замена STMки в треть Discovery:
ИМХО это уже уровень, который я решил затронуть в последнюю очередь, если ничего другого не выйдет. Verilog меня особо не пугает, но я точно знаю, что после программирования осмыслять код как цифровую схему, а не как последовательные операции, будет очень тяжело, и ошибок будет очень много. Тут нужна другая интуиция, а не программистская. А у меня она успела уже задеревенеть :)
Хотя, как я понимаю, при наличии хорошей платы можно вообще дойти до прямой построчной расшифровки HDMI. Вроде бы я даже видел отладочные платы FPGA с входом HDMI.
т. е. идея в том, что мы вот это вот недоfpga конфигурируем в качестве конвертера SPI → WS2812b с поправкой, что ширина импульса на входе и выходе должна кореллировать?
Так точно. Байт улетает в SPI (посредством DMA) и на лету конвертируется в нужные импульсы. Если всё правильно посчитать, то вполне реально сделать такой конвертер, не вижу проблемы.
не вижу проблемы.
Она одна — надо освоить Verilog:) А ещё важнее — суметь перестроить мозг с программирования на концепцию языков описания аппаратуры.
На самом деле существование CPLD заставило меня взглянуть по новому на это всё. Раньше я думал, что такое делается только сразу на FPGA со всеми его замечательными особенностями. А тут, оказывается, есть промежуточная ступень. Это очень интересно, определённо захотелось поковырять тему.
Это да. Я вот недавно ковырялся: https://habr.com/ru/articles/896234/
Через 1 пин получается завести управление для чуть больше 500 таких светодиодов при 60 fps. Вполне прилично. Да и DMA через GPIO - весьма неплохое и хорошо масштабируемое решение.
Только в коде у вас не DMA (прямой доступ к памяти), а PIO (программный ввод-вывод). DMA как раз само аппаратно качает данные из RAM в GPIO, без участия процессора и кучи NOPов. Вот пример на примерно вашу скорость как раз.
Да, точно.
Причём можно программно перезапускать скан памяти синхронно с каждым видео-кадром. А можно зациклить скан аппаратно, и пользоваться памятью, как фрейм-буфером, больше не отвлекаясь на физический вывод.
Так вот что имелось ввиду, когда говорили что это всё на таймерах надо делать. А как у этих таймеров с шириной импульса? Способность держать 400 нс — это редкость, или часто встречается.
Разрешение аппаратного таймера - 1 такт его опорной частоты. Если частота даже 50 МГц, то разрешение 20 нс. Точность - абсолютная, таймер работает дискретно, считает в целых числах, на +-1/2 такта не может ошибиться.
Сам контроллер DMA внесëт неточность в пределах 2 тактов процессора. Т.к. соперничает с ним за шину данных, и кому-то из них приходится шину уступить при одновременном доступе.
Ширина импульса для срабатывания DMA не важна. Период таймера просто ставится на те самые 400 нс, и DMA срабатвает каждый период.
Так что 400 нс - это легко. Не обязательно применять FPGA. Но зато приходится разобраться, как соединянтся между собой периферия микроконтроллера, а это тоже своего рода FPGA)
Спасибо, Вы первый, кто смог объяснить понятным языком, как работает этот долбаный таймер. То есть я просто считываю с компа пакет в память и дальше просто триггерю таймер чтобы он пробежался по памяти и запихнул её в шину. А вот по считыванию без синхронизации есть вопрос:
Причём можно программно перезапускать скан памяти синхронно с каждым видео-кадром. А можно зациклить скан аппаратно, и пользоваться памятью, как фрейм-буфером, больше не отвлекаясь на физический вывод.
Технически да — я могу прямоточно жрать данные из COM и сразу отправлять их в ленты. Но всё равно какой‑то синхроимпульс «начать сначала» должен быть, потому что на компе в ОС задержки, измеряемыми сотнями микросекунд, делать геморно. В Windows, конечно, есть точный мультимедийный таймер, но всё равно — лучше, чтобы железо могло, отбивая пакеты данных, по моей команде тормознуть, чтобы показать начало кадра. Интересно, как такое сделать? Могу ли я всё это прямоточное железо в контроллере, которое само всё читает и пишет, заставить пропустить N тактов таймера? Или таймеру временно интервал увеличить?
А если, допустим, надо синхронизировать скан памяти с отправкой в шину и чтение данных с компа — как это тут делается? В программировании для этого я бы воткнул какой‑нибудь семафор (ManualResetEventSlim), и здесь, вероятно, тоже что‑то подобное программно. Но, как я понимаю, здесь и для этого есть какая‑то аппаратная приблуда?
Предположу, что между блоком, который читает‑пишет, и таймером, есть какая то «линия», которую я могу в нужный момент разомкнуть или замкнуть, и так управлять всем этим делом. И ещё какая‑то штука, сбрасывающая указатель считываемой памяти.
Это линия запроса DMA от таймера. Но её не обязательно размыкать в точный момент времени. И таймер можно не отключать, пусть себе запрашивает у контроллера DMA передачу постоянно. По крайней мере в стм32 ничего плохого не случится.
А вот получив и обработав данные, вы можете сказать контроллеру DMA: "Передай в GPIOС данные из буфера длиной N слов". DMA сделает N передач по таймеру и остановится.
Пока DMA с таймером отрабатывают это задание, вы можете в это время получать и обрабатывать следующий кадр. Можно в тот же буфер, можно в другой. И после обработки также перезапускаете DMA.
В принципе стм32 позволяет аппаратно управлять одним таймером от другого. Тогда можно ещё и абсолютно точно выдержать частоту кадров. Но я думаю, даже для 60 fps это уже лишнее.
А вот получив и обработав данные, вы можете сказать контроллеру DMA: "Передай в GPIOС данные из буфера длиной N слов". DMA сделает N передач по таймеру и остановится.
Хм. То есть передачу я скидываю на железо, а данные всё таки обрабатываю ручками. А что если перенести предобработку на комп — там AVX512, ему не трудно, и в контроллер будут прилетать уже прямо готовые для DMA данные. Можно ли в таком случае полностью перенести всё на железо? Чтобы он просто прямоточно жрал данные из COM и отправлял на DMA? Условно говоря, вообще без кода?
Вас видимо, ещё смутило, что редактор кода подсказывает - токен GPIOC - это тупо указатль на определённый адрес в ОЗУ. Ну ещё со свойством volatile.
На самом деле это периферия, железное железо. У ядра ARM нет отдельного адресного пространства для портов ввода-вывода, как у х86, х51, AVR. Всё логически есть одно плоское пространство адресов. И это как раз печально знаменитые британские учёные, разработчики ядра, продумали очень удачно, ИМХО
Есть гарвардская архитектура МК/ЭВМ - тут все типы ресурсов разделены: команды отдельно, данные отдельно, порты ввода-вывода отдельно. Это AVR в классике по сути.
А есть архитектура фон Неймана. Тут всё в единой куче, как у ARM.
Но в x86, как я понимаю, команды и данные вместе, а порты ввода‑вывода и прочее отдельно, так?
Нет, там сегменты есть. То, что они физически могут быть в одном месте не значит, что они вместе. Это как с i8080: его слово состояния позволяет разделять порты ввода-вывода, код и данные и даже стек, однако практически все ПК на нём на это наплевали и используют модель с общей памятью, в том числе даже порты не всегда разделяют.
Вас видимо, ещё смутило, что редактор кода подсказывает - токен GPIOC - это тупо указатль на определённый адрес в ОЗУ. Ну ещё со свойством volatile.
Ну, на самом деле не очень. Я туда не лез глубоко, но из опыта по С++ — я вполне ожидал, что GPIOC может оказаться какой‑нибудь сложной штукой, которая перегрузила операторы "*" и "->", а ODR, в свою очередь — типом, перегрузившим оператор "=". И под капотом там черт знает что может происходить, например, инлайнится машинная инструкция работы с железякой. Или, как вариант, местный компилятор может особым образом отрабатывать именно работу с GPIOA/B/C. Вариантов много.
А вот что это реально указатель, и кусок памяти по этому адресу — это и есть железо, и GPIO это просто участок памяти, я реально не подозревал. Спасибо, что открыли глаза :)
То, что в лифте получает команды от кнопок, управляет приводом, открывает двери, и так далее - там, без сомнений, только ПЛК с хорошей помехозащищённостью и отказоустойчивостью. Но если в кабине установлен TFT-дисплей (теперь часто встречается), вот он уже может управляться любым ширпотребным одноплатником, да и сам быть ширпотребным, встречаются даже с битыми пикселями с завода. Потому что если там что-нибудь зависнет или сдохнет, на безопасность и вообще работоспособность лифта это не повлияет. Просто перестанет отображать номера этажей, и всё. Кстати, он не зависал ни разу, ну или этого никто не видел - сторожевой таймер тут же перезагружал.
Спасибо за комментарий! Да, признаю — косяков действительно море, и всё можно было сделать намного проще и безболезненней, и далеко не только по питанию. Но мне было действительно интересно и весело с разбегу влезть в то, с чем не имел дела, и посмотреть, что получится :)
Как выразились ниже — главное, чтобы не за чужой счёт, и чтобы это не подвергало риску других людей.
Статьи, сделанные с таким старанием, лично я готов вообще на любую тему читать..
Прикольная реализация, заморочился по полной. Я посоветовал подключать провода к БП через наконечники НШВИ так надежнее и проше подключать.
Спасибо! Про НШВИ буду знать — действительно полезная штука, чтобы жилы не разбегались
Достаточно пропаять. К наконечникам хорошо кримпер. Если соединение не под потолком, и их не 100 шт.. Деды без наконечников обходились ;)
Очень расстроился, увидев несколько проводов, заведенных в одну клемму
С одной стороны, я уже понимаю, что так делать плохо, с другой стороны «не чини то, что работает». Хотя в данном случае ломаться нечему. Вроде бы.
Так то бывают разные конструкции клемм. некоторые просто созданы для обжима 2 проводов.
А, это то я понимаю. У меня подсветка в коробке через Wago соединена с жилами сети.

Я про ситуации в духе «подсоединил правильно, но сместил провода → телик пошёл открываться → клема зацепилась за что‑то → фазу вырвало и она случайно задела +5В → все ленты на телике взорвались». Ну вот такие вот рандомные моменты, когда прилетает вообще не с той стороны, с которой ждёшь.
Мне кажется, если уж делать, то наверно лучше поставить рядом с БП что‑то типа маленького распределительного щитка, с колодками‑крышечками, как это принято. И каждый провод отдельно прикрутить через гильзу. Чтобы не лепить куст из клемм.
Проблема решалась покупкой лент на WS2815 / WS2811 с питанием 12в.
Да) Ещё лучше — каких‑нибудь SPI‑лент под тем же напряжением или выше. И STM32 BlackPill
SPI-лента - это как? Прямо с четырьмя сигналами прямо?
Я не вижу тут SPI. Я вижу тут синхронный UART.
Эм. По ссылке APA102 — она, насколько я знаю, именно SPI, а не UART. Но мои знания про это только теоретические, я до неё ещё не добрался, поэтому спорить не буду — если ошибся, то ошибся.
Почитал плотнее - действительно, это USART в режиме SPI. Т.е., обычный синхронный UART но без стартового и стопового битов (они не нужны в синхронном режиме). А синхронизация делается посылкой большого количество одинаковых битов (32 бит подряд). SPI же использует nSS для синхронизации. Так что можно использовать как SPI так и USART (не путать с UART!).
У лент на 12/24 V разрешение сильно ниже. Светодиоды управляются группами по 3 или 6 штук, и ещё место под контроллер выделяется. Автор, вроде, про это писал даже.

WS2815 на скрине ниже. 144диода/метр, 12в. Бонусом яркость повыше, частота PWM выше, и не боится отказа диода так как линии данных две.

Круть. А есть такое же, только SPI? Это, как я понимаю, тот же протокол WS2812b, просто с дублированием в обратную сторону.
Есть ленты с sk9822 (клон APA102). В данном случае подделка лучше, ибо яркость задаётся не PWM, встроенным токовым драйвером.
Так. А в чём минус APA102 тогда? Почему PWM сразу плохо?
Не плохо. Но бывает краем глаза мерцание видно даже на высоких частотах. Особенно, если светодиодов немного (в вашем случае, это, конечно, не так). Ну и токовый драйвер меньше помех по питанию даёт.
Мне sk9822/APA102 нравятся именно наличием SPI. Очень удобно работать с ними.
Интересно. А по другим характеристикам sk9822 не уступает? Скажем, максимальная частота обновления? Спектр диодов?
Спасибо, интересно. Как минимум, тут 5кГц ШИМ вместо 19 кГц у оригинала, но это всё равно вкусно, это эквивалент отсутствия ШИМа как такового. Хотя я на своих ШИМ (400 гц примерно) не вижу, хотя он там есть. А вот про спектр ничего.
Я знаю, что у WS2812b спектр — полная дичь. Когда их снимаешь, приходится вручную ставить баланс белого и потом еще цветокором вправлять оттенки, чтобы то, что снято, было хотя бы чуть‑чуть похоже на то, что видишь. А использовать их как источник света для съёмок просто невозможно. Интересно, как у sk9822 с этим дела — вдруг лучше.
Интересно, попробую как нибудь. То есть, там по 9 светодиодов в каждом корпусе, но с меньшим током, что-ли?
Т. е. до сих пор нет лент с высоким разрешением и напряжением? Я просто где‑то видел SPI‑ленты с 244 диодами на метр, вроде как независимыми, но про напряжение не в курсе.
А как вариант - сделать по мелкому бп на отдельные сегменты ленты, и провести туда 220 - там сложнее было-б хорошо это 220 проложить + доп вес (но он был-бы не критичный).
Ну и ленты наверное лучше на 24 вольта, кроме того, при динамической подсветке неравномерность на них была-б практически незаметна, ИМХО.
А как вариант - сделать по мелкому бп на отдельные сегменты ленты, и провести туда 220 - там сложнее было-б хорошо это 220 проложить + доп вес (но он был-бы не критичный).
Ну... наверное сформулировать можно так: когда я начинал это делать, то казалось, что с тремя БП проще. А когда понял, что не проще, было уже поздно и проще было доделать :)
Ну и ленты наверное лучше на 24 вольта, кроме того, при динамической подсветке неравномерность на них была-б практически незаметна, ИМХО.
Тут зависит от плотности диодов. Фокус в том, что чтобы блики именно перемещались плотность нужна высокая. Как я понял за 3 года эксплуатации, синхронное движение подсветки с картинкой существенно усиливает «состояние потока», сильнее «затягивает» в виртуальную реальность. Мозг видит что ВСЁ вокруг шевелится в одну сторону — значит, ты по‑настоящему движешься.
Но тут в комментариях люди показали ленты с высоким напряжением и высокой плотностью диодов, т. е. сейчас, как я понимаю, уже нет такой зависимости прямой, что чем больше напряжение, тем ниже разрешение ленты.
Вставлю и я свои 5 ненужных копеек:
Спасибо за статью. И текст читается легко и приятно, а графика действительно радует глаз.
Стал бы я играть/работать на таком компе? Нет. Все же мой глаз не охватит 3 монитора
Не задумывались привести проект в состояние готового продукта? В том смысле, чтобы всякие коробочки, аккуратные PCB. Как проекты по DIY клавиатурам. И пусть висит в гитхабе.
Я очень скептически настроен к людям, которые рвутся в IT после курсов потому что "в IT хорошо платят", а не потому что им нравится сама эта работа. Но если вы потратили 3 года решая проблемы и с кодом и с железом, то возможно вам стоит попытаться в IT. Как ни крути, 3 года на одной идее не протянешь, тут не только упорство, но наверное и удовольствие от самого процесса разработки было.
Спасибо, рад что вам понравилось!
Стал бы я играть/работать на таком компе? Нет. Все же мой глаз не охватит 3 монитора
Я тоже в начале так думал :) На самом деле просто начинаешь голову поворачивать всё время, точно так же, как в автомобиле. Поначалу непривычно — ты вроде за компом, а тут надо поворачиваться постоянно, но потом привыкаешь. А от места на рабочем столе уже отказаться тем более не можешь. В общем, штука это коварная, привыкание незаметно, но если пересядешь за обычный комп — ощущение, что смотришь из бункера через щель. Тесно.
Не задумывались привести проект в состояние готового продукта? В том смысле, чтобы всякие коробочки, аккуратные PCB. Как проекты по DIY клавиатурам. И пусть висит в гитхабе.
Были мысли, но пока руки не доходят :)
Я очень скептически настроен к людям, которые рвутся в IT после курсов потому что "в IT хорошо платят", а не потому что им нравится сама эта работа. Но если вы потратили 3 года решая проблемы и с кодом и с железом, то возможно вам стоит попытаться в IT. Как ни крути, 3 года на одной идее не протянешь, тут не только упорство, но наверное и удовольствие от самого процесса разработки было.
Ну, сама работа длилась сильно меньше года. Три года оно эксплуатируется. А по IT — не могу сказать, что эта отрасль для меня совсем чуждая, всё‑таки я с 10 лет делаю софт :) Просто всё время это был именно софт — с алгоритмами, архитектурами и GUI, а контроллерами и железом я никогда до этого не занимался (какие‑то базовые знания по электронике, конечно были, но теоретические). А так да — удовольствие от процесса было более чем :)
На самом деле просто начинаешь голову поворачивать всё время, точно так же, как в автомобиле. Поначалу непривычно — ты вроде за компом, а тут надо поворачиваться постоянно, но потом привыкаешь.
Уже 5 лет как симулирую в VR. Купил ради HL:A, но потом попробовал порулить и полетать. И всё. Так вот, там постоянно вертишь головой - шея работает. Это естественное движение. Теперь не могу рулить глядя в плоский монитор - не чувствую габариты болида да и вообще, выглянуть в форточку на полном ходу - бесценно!

попробовал порулить и полетать
Симы это вкусно. А что в качестве органов управления?
Я вот больше шутеры как‑то люблю:) Одно время хотел взять очки вместе с омнидорожкой, но разочаровался, когда узнал, что нормальных онлайн шутеров под нее до сих пор не завезли, в основном сплошные демки или игры, напоминающие демки. Постепенно пришёл к трёхтеликовой системе — она совместима с классическим WASD управлением + не надо ничего на голову надевать. Хотя это дело привычки наверное.
Симы это вкусно. А что в качестве органов управления?
Штурвал да руль с педалями. Что же ещё? Я, конечно, не задрот, как некоторые. Особенно отчаянные ещё и кресло делают с отдачей:
Я по простому, на стульчике, как тут:
Видел такие штуки. Есть вообще вот такие турбоблевотроны:
Три телика с подсветкой сюда не воткнёшь, а вот в VR очках эпичность будет зашкаливать.
А как Вы установили руль и штурвал так, чтобы они не мешали? У меня просто пылится Logitech G29, на котором очень вкусно, внезапно, гонять в GTA5 с модом на руль, но пока руки не доходят его вклинить на стол. А тут и штурвал и руль сразу.
Ваш турбоблеволёт небезопасен для окружающих. Срочно обновляйтесь до безопасного!
А как Вы установили руль и штурвал так, чтобы они не мешали? У меня просто пылится Logitech G29, на котором очень вкусно, внезапно, гонять в GTA5 с модом на руль, но пока руки не доходят его вклинить на стол. А тут и штурвал и руль сразу.
Ну меняю, у меня не йок, к сожаленю, а стик, так что он места мало занимает. Раньше просто стол расставлял, сейчас иногда так же делаю в походном режиме сессию для гостей. Моё пилотское кресло не для всех.
Фотки гостевой сессии доковидных времён, тогда ещё не было отдельного уголка



Круть) Руль юзал, а вот периферией для авиасимов не пользовался никогда. Захотелось.
Вопрос: во втором случае проп‑контрол никак не зафиксирован? Типа там усилие не такое, чтобы как руль прикручивать к столу?
Всё надо прикручивать. И все устройства имеют для этого специальные монтажные отверстия. В пылу игры правильное закрепление может спасти само устройство. Сколько джойстиков мы сломали в детстве играя в спектрум только из-за того, что присоски отцеплялись в самый неподходящий момент...
Есть такое) Я руль сначала прикручивал обычными креплениями, пока однажды он не сорвался и не скатапультировал мышку в стену, а сам не намотал провода. После этого я просверлил стол и прикрутил его стальными винтами насквозь:)
Просто с рулем работаешь интенсивно (особенно в комбинации с мышкой, если одновременно приходится отстреливаться от погони), а пропконтрол и кнопочки эти все — по идее, там же все плавно, спокойно и без усилий, достаточно просто на ножки поставить, не? Штурвал да, он как руль. А доп кнопки то по идее не испытывают сильной нагрузки.
Штурвал да, он как руль.
Он даже хуже руля - его надо тянуть и толкать! Я всё ещё не оставил надежды купить йок за разумные деньги в моих краях, но пока только стиком балуюсь. Йок он же для одномоторников и некоторых лайнеров и выглядит вот так:

А стик у меня Logitech G Saitek Pro Flight X56 Rhino H.O.T.A.S., он удобен для всяких военных истребителей, можно рулить вертолётом (особенно если использовать удлинитель рукоятки, располагая стик на полу между ног) и некоторые эйрбасы с сайдстиками которые:

Кстати — для военных истребителей и вертолётов есть смысл брать Йок? Или стик для этого лучше, а штурвал больше для более спокойных полётов?
Logitech G Saitek Pro Flight X56 Rhino H.O.T.A.S.
Как у него с надёжностью? Вот в Logitech G29, к примеру, в коробке (она отдельно берётся, в комплекте только руль с педалями) через год эксплуатации задняя передача начала втыкаться с 3 — 5 раза — там надо влезть и подпаять контакт проводом, потому что изначально он жесткий и со временем разбалтывается. Ну и по шестеряням в руле народ говорит, что со временем могут хрустеть начать, но у меня до этого не доходило. Есть ли у этого стика подобные болячки?
Ну у меня пока таковых нет. Я, правда, и не задрачиваю 24/7, как некоторые. Да и более спокойные полёты обычно делаю. Первые часов 200 тупо лётную школу херячил, а там простые и размеренные манёвры на одномоторнике.
Первые часов 200 тупо лётную школу херячил
Жесть. Я думал там как‑то проще с обучением) Хотя в шутерах казуальщина — там часа имхо хватит чтобы приноровиться
Жесть. Я думал там как‑то проще с обучением)
В игре нет обучения как режима. Ну как в новых играх (и некоторых старых) в главном меню есть выбор "Обучение", где ты играешь, как правило, небольшой пролог, который тебя знакомит со всеми механиками игры. Тут такого нет. Лётная школа это отдельный класс заданий в самой игре. Например, вот:
По сути сим знакомит с реальными механиками, это почти как вождение при сдаче на права.
Три телика с подсветкой сюда не воткнёшь, а вот в VR очках эпичность будет зашкаливать.
Кстати, почти все лётные симы поддерживают AR. Люди строят кокпит на минималках, с реальными тумблерами и кнопками, только вместо экранов - хромаки вставлены. Потом в симе в AR шлеме (это шлем с камерами, как у Quest, например, или Vive Pro) ты калибруешь совмещение виртуального кокпита с реальным и он тебе на экранах и в окнах рисует как надо сам, а тумблеры, кнопочки и рычажки ты тыкаешь уже ручками, при этом ты через камеры видишь свои руки и рычажки. БОМЖ стайл полноценного кокпита.
Оформление супер. Есть лента с питанием +12 в и с каждым светящимся светодиодом. НЕ сегментами. Стоит на оранжевом магазине 2850 примерно за 5 метров. Покупал, проверял. Действительно все работает. Если нужно, могу скинуть ссылку.
Спасибо!
Если нужно, могу скинуть ссылку.
Скиньте пожалуйста, очень интересно. Это что‑то новое, или оно уже давно?
Вроде недавно появилась
https://sl.aliexpress.ru/p?key=TCXZ3BF
Визуализация на наивысшем уровне, такого не видел ни у топовых блогеров, ни даже у корпораций. Не, это просто восхитительно!
Мое почтение за статью. Кажется мне у вас есть не плохие такие задатки граф. дизайнер, в первые встречаю такую красивую статью на хабре.
Мне очень близка эта тема, я и сам разработчик и увлекся мк несколько лет назад, правда на уровне ардуино, но все же.
С WS2812B в своих проектах использовал ESP8266 и Arduino Pro micro. Компактно и производительно, благодаря ESP можно еще и прикрутить Веб интерфейс с управлением и настройкой, благо библиотеки для этого есть. Или можно взять ESP32C3/S3 и прикрутить еще что-то интересное ;)
Спасибо за статью, читать было очень приятно.
Мое почтение за статью. Кажется мне у вас есть не плохие такие задатки граф. дизайнер, в первые встречаю такую красивую статью на хабре.
Спасибо большое! Может быть, действительно — стоит попробовать ещё одно направление деятельности :)
С WS2812B в своих проектах использовал ESP8266 и Arduino Pro micro. Компактно и производительно, благодаря ESP можно еще и прикрутить Веб интерфейс с управлением и настройкой, благо библиотеки для этого есть. Или можно взять ESP32C3/S3 и прикрутить еще что-то интересное ;)
Как один из вариантов, я рассматривал каждую ленту посадить на свой отдельный ESP8266 и тупо по WiFi ими рулить одновременно. Но тут есть вероятность, что стадо из 17 ESPшек одновременно могут работать не очень стабильно. Ещё вариант рассматривал — по ESP32 на каждый телик.
В целом да, сейчас постепенно приходит желание сделать это в более вменяемом виде, чтобы, например, оно могло как‑то функционировать и без компа — а это как раз лучше делать так, как Вы расписали.
Как один из вариантов, я рассматривал каждую ленту посадить на свой отдельный ESP8266 и тупо по WiFi ими рулить одновременно.
На самом деле не обязательно, если сделать подтяжку к питанию на линию данных, то можно обойтись одной платой с линией большой длинны (это в теории, сам не проверял). Если ставить много ESP шум в радиоэфире будет ой какой веселый :)
Ещё вариант рассматривал — по ESP32 на каждый телик.
В целом хороший вариант. Подскажу один опен сорс проект, называется WLED. На нем делал-настольные лампы. Там есть готовое приложение под Android/OS и веб интерфейс (и прочие плюшки), как и способ синхронизации нескольких плат по сети. Может сам проект из коробки не подходит под Вашу задумку, но возможно натолкнет на полезные мысли ;)
На самом деле не обязательно, если сделать подтяжку к питанию на линию данных, то можно обойтись одной платой с линией большой длинны (это в теории, сам не проверял). Если ставить много ESP шум в радиоэфире будет ой какой веселый :)
Сейчас‑то понятно, в те времена я это планировал на случай не из‑за ослабления сигнала, а если мне вообще никак не удастся одновременно‑параллельно управлять лентами с одной платы. т. е. это резервный план — не получается все цеплять к одной плате — чтобы решить задачу, мы откатываемся к стандартным библиотекам, а значит, одна лента — один контроллер. И да, эфир я бы забил этим стадом. Поэтому до последнего не хотел в это лезть.
В целом хороший вариант. Подскажу один опен сорс проект, называется WLED. На нем делал-настольные лампы. Там есть готовое приложение под Android/OS и веб интерфейс (и прочие плюшки), как и способ синхронизации нескольких плат по сети. Может сам проект из коробки не подходит под Вашу задумку, но возможно натолкнет на полезные мысли ;)
Спасибо, интересная штука. Сейчас мне видится оптимальной такая архитектура: главный контроллер и ведомые, обслуживающие конкретные ленты. От главного к ведомым сигналы идут по UART, а они уже работают с конкретной лентой.
В главный контроллер засунуть модифицированную версию вот этой вот WLED. Когда с компа данные идут — оно тупо показывает то, что говорит комп. Если комп не дает данные (выключен или софт закрыли) — оно начинает думать само и выводить вот эти все штуки из WLED, с управлением по WiFi и всё такое.
главный контроллер и ведомые, обслуживающие конкретные ленты. От главного к ведомым сигналы идут по UART, а они уже работают с конкретной лентой.
А вот это как по мне отличная идея. Высокая отказоустойчивость, выход из строя одной платы (главной или подчинённой) не нарушит систему. Снизится нагрузка на контроллер и останется место под плюшки :)
Может знающие люди поправят, но для меня это выглядит хорошим решением.
В главный контроллер засунуть модифицированную версию вот этой вот WLED
Посмотрите плагины от сообщества, возможно есть такая опция. А если нет, то думаю будет не сложно адаптировать. Желаю успеха в этом направлении, пусть все получится :)
Это одновременно порнография и торт! Наверное очень много времени убили на все эти визуализации?
Большое спасибо, рад был стараться :) И что оно торт тоже приятно слышать :)
Наверное очень много времени убили на все эти визуализации?
Есть такое:) По 3D там я сделал мастер‑модель на основе Inventorовских моделей, которые на производство в своё время отправлялись. В мастер‑модели прорисовано всё и зариганы все провода. Вот она была самой долгой. Дальше просто когда что‑то надо показать выцепляешь нужный кусок и анимируешь как надо. Иногда надо было допиливать, но не сильно.
А живые съёмки это трэш, да :)
Вы пробовали замерить реальное потребление отдельного диода или всей конструкции в целом?
По моему опыту, цифра из даташита сильно завышена, раза так в 3. Из ваших расчетных 450Вт хорошо если 150Вт наберётся на полностью белом цвете и 100% яркости.
Спасибо, отличная идея. Наверное, попробую амперметр просто подоткнуть к клеммам подсветки в коробке. Можно даже в каждый БП подселить маленький контроллер, мерить ток и докладывать компу в реалтайме.
Нельзя амперметр. Нужен шунт и осциллограф. Учитывая импульсный характер нагрузки из-за ШИМ ток тоже будет импульсный. Именно поэтому вам помогли конденсаторы на клеммах ленты. И именно поэтому маленький конденсатор стоит на самой ленте возле каждого светодиода, но он недостаточный, просто немного сглаживает.
Господи боже, как это развидеть... Не представляю под чем нужно быть... это бутерат ?
Реквестирую от вас статью для тех, кто умеет паять, прошивать микроконтроллеры, но абсолютно не в теме, как просто и быстро сделать подобные визуализации. Некий туториал по типам визуализации вашей статьи. Уверен, получится не менее захватывающее чтиво!. Тем, кто занимается учебным процессом, это было ой как полезно. Одна анимация работы ленты с WSxxx супер наглядна и сразу понятна..
Хм, интересная идея. Главная проблема в
просто и быстро
тут мне надо будет хорошо подумать, как объяснить эти штуки без залезания в дебри графики и программирования.
Я думаю, пройдет небольшое время, и такое станет возможно делать нейросетями. Они пока от силы умеют только в органику, но до технических штук должны постепенно дойти — ведь DIY‑видео в сети много, есть на чём учить.
За идею спасибо — вероятно, попробую что‑нибудь такое сделать.
Лудится оно отлично, но изоляция быстро начинает плавиться
я занулил блоки тоненьким МГТФ‑проводком сечением 0,2 мм² — ведь он хорошо будет гнуться вместе с боковыми экранами
я заменил МГТФ на необъятную синюю сварочную сосиску сечением 25 мм²
Вы, вероятно, не знали о существовании кабелей в силиконовой изоляции с большим количеством очень тонких жил. Они и гибкие, и изоляция не плавится, и сечение будь здоров. В радиоуправляемых моделях движки могут потреблять до сотен ампер при напряжении питания 7.4...22.4 вольта и используются, в основном, именно такие кабели.

Великолепнейшая статья! Шикарнейшие и оформление, и содержание статьи! Огромное спасибо!
В качестве контроллера для таких лент шикарно заходит rp2040 от raspberry. У него есть pio, который позволяет буквально сделать выделенный блок для управления лентами и тупо в него по DMA rgb заливать прямо из памяти в виде трехбайтовых блоков без всяких конверсий.
Кстати у меня была одна из мыслей перейти на Raspberry Pico, но не из‑за этого, а потому что там легче блокировать прерывания, как я понял.
выделенный блок для управления лентами и тупо в него по DMA rgb заливать прямо из памяти в виде трехбайтовых блоков без всяких конверсий.
То есть именно параллельно сразу на кучу лент? Или там SPI?
https://mcuoneclipse.com/2023/04/02/rp2040-with-pio-and-dma-to-address-ws2812b-leds/
Именно сразу параллельно на много лент с однопроводным управлением. Я лично делал шесть каналов, но можно и больше. Вроде бы до восьми (по четыре на каждый блок PIO). Плюс весь этот процесс обновления вообще не грузит cpu, а работать напрямую с цветами в виде трехбайтных RGB структур получается быстро и удобно. В общем в реальности у меня лично процессор простаивал почти всегда при том, что ленты обновлялись настолько часто, насколько частота их шины позволяет (800k вроде бы). По сравнению с stm32 прямо другой уровень совершенно. Раньше такое можно было сделать разве что только на cypress (у них тоже блоки для реализации кастомной периферии есть), но у cypress совершенно другой уровень вхождения и ценники.
Кстати, на новой модели контроллера от raspberry должно поддерживаться ещё больше лент параллельно (12?)
Спасибо, вкусно. Получается, по одному контроллеру на телик.
В общем в реальности у меня лично процессор простаивал почти всегда при том, что ленты обновлялись настолько часто, насколько частота их шины позволяет (800k вроде бы).
Там другая проблема возникает (с моими лентами по крайней мере) — цвета начинают ехать, потому что зелёный светодиод меняет цвет медленнее, чем синий и красный — я выяснил это, когда изучал ленты снимая маленький кусочек на видео 960 к/c. Это можно купировать программно, но я решил не усложнять алгоритмы.
cypress (у них тоже блоки для реализации кастомной периферии есть), но у cypress совершенно другой уровень вхождения и ценники.
Так это ж вообще жесть, это оборудование для видеостен же и обработки сигналов на телевидении, с SDI и прочими наворотами. Как я понимаю, у них там есть коммутаторы с FPGA, которые можно прошить под свою задачу — и мы можем перенести анализ картинки в железо.
Насколько я знаю, HDMI — это уже жесть, а в моем случае это HDMI 2.1, в котором, кажется, поменяли способ передачи данных чтобы 48 Гбит/с сделать, и железо, которое это переварить может, ещё на порядок сложнее, как и сама обработка. То есть это прямо вершина жести FPGA.
Не успел отредактировать прошлый комментарий, поэтому напишу отдельным. Чтобы светодиоды не пытались получать питание с ножки микроконтроллера, можно (и стоит в общем-то для лишней стабильности и помехоустойчивости) поставить между микроконтроллером и первым(и) светодиодам(и) push-pull драйвер (чьё питание подключено не к питанию контроллера, а прям к той жирной линии, от которой светодиоды питаются). Можно взять какой-нибудь готовый драйвер для мосфетов (типа eicedriver от infineon), можно на bjt транзисторах собрать. Микроконтроллер можно запитать от того же источника, что и ленты, просто через диод шоттки и с жирным собственным буферным конденсатором. И тогда можно сильно сократить количество банок на лентах.
Советы про cpld и soc с fpga академически, конечно, интересны. Но, честно скажу, не очень практичны =)
У меня были мысли воткнуть на каждую ленту по гальванической развязке, я даже вроде находил микросхемы подходящих характеристик (в плане частоты), но всё-таки руки не дошли до этого.
А про pull-push драйверы не знал, хотя, казалось бы, идея лежит на поверхности, спасибо!
Советы про cpld и soc с fpga академически, конечно, интересны. Но, честно скажу, не очень практичны =)
Правильно ли я понимаю, что дело в пороге вхождения и знании кучи нюансов, которое появляется только с опытом? :)
Здесь уже один комментатор написал про CPLD, но вставлю и я свои 5 копеек….
Не так давно обнаружил полноценную SoC которая содержит в себе ARM + FPGA. И на этот ARM вполне ставят Linux и что самое прикольное, что непосредственно с этого Linux можно рулить FPGA-шкой. А еще там Ethernet и мог знает, что еще на борту.
А самое, пожалуй, приятное это цена. Этот SoC обзывается Zynq XC7Z010 и стоит такой на плате управления Antminer S9. Платы эти на известной площадке стоят (во всяком случае пока что) по цене за ведро, порядка 500-700р. Выводов выше крыши, на борту попутно DDR3 память.
Программатор в этой затее самое дорогое, но и это лечится покупкой RPI Pico и установкой на нее прошивки xvcd-pico и позволяет использовать RPI в качестве программатора.
Единственное, что я не настоящий сварщик, у самого пока получилось только помигать светодиодами и то на Spartan 6, до Zynq не дошел, хотя все имеется по рукой.
Но под ваш проект ну как будто бы оно прям само напрашивается. Либо HDMI читать либо забирать данные с Ethernet и раскидывать через FPGA на сколько угодно лент. Выводов у FPGA выше крыши, и разведенных выводов на плате майнера тоже хватает с головой.
Единственное, я понятия не имею, на сколько это все сложно сделать :) Но как будто бы Zynq прям просится в этот проект. И один такой чип сможет запросто рулить и сервоприводами и лентой и ещё что-то по дороге обрабатывать.
Спасибо!
Выводов выше крыши, на борту попутно DDR3 память.
Хм. А есть ли возможность из 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 здесь со своим количеством выводов очень выигрышно смотрится.
Хм. А есть ли возможность из FPGA докопаться до этой памяти?
Опишите DMA в логике - будет вам и доступ.
Тут вопрос — хватит ли этого FPGA для того, чтобы жрать картинку из HDMI
Хватить должно. Но реализовывать - офигеть не встать. FPGA - очень глубокая кроличья нора даже на таких рядовых задачах, как условные DSP фильтры.
Приветствую. Специально зарегался на Хабре, чтоб прокомментировать. Как уже писали, статья огонь, приблуда тоже огонь. Про реализацию ничего сказать не могу, в части затронутых вопросов шарю слабо, в остальной части не шарю вообще, но инженерная составляющая впечатляет. Интересная демонстрация решения возникающих проблем с использованием имеющихся знаний.
«И, как я понимаю, под действием электрического потенциала краска начала пропитываться сквозь бумажку в сторону источника этого самого потенциала. В результате пропитанная бумажка, стала проводником и замкнула плюс с корпусом БП, от чего тот ушёл в защиту. Что характерно, у минусового контакта бумажка не пропиталась»
Это ближе к электрофорезу или к электроосмосу? Если первое, то e-ink уже изобретён. Если второе, можно попробовать изобрести дисплей и на этом принципе.
Вопрос в скорости переключения) Собственно, если я не ошибаюсь, e‑ink так и работает — там электрическим потенциалом заставляют перемещаться частички чернил в капсулах‑пикселях.
Жгём-шьём контроллеры и кормим ядерную подсветку