Комментарии 48
Для "домашней автоматизации" MIPI был бы интересен, но... Производители матриц так норовят сделать свой уникальный разъем. С тем же LVDS проще. А чтоб по минимуму зависеть лучше распространенные стандарты (желательно с DDC) типа (e)HDMI или (e)DP.
По камерам - ну в принципе та же история. Там, правда еще и зоопарк форматов (включая упакованные) в данных. Как мне кажется более или менее универсального решения нет. Опять же - дабы иметь минимум проблем, я бы настоятельно рекомендовал USB камеру. Там тоже зоопарк, но интерфейс не в пример проще.
Хватает сенсоров изображений с jpeg энкодером на борту, да и на дисплеях далеко не всегда надо обязательно 140fps отображать. И для первого и для второго с некоторой натяжкой хватило бы и lowpower режима с его 10МБит/с и любого дохлого МК без гигабитных интерфейсов. Но вот некая огороженность и отсутсвие человеческой документации раздражает.
Хватает сенсоров изображений с jpeg энкодером на борту
Вам хватает или имеется в виду, что их довольно-таки много?
Да, стандарт закрытый. Но найти что-то полезное можно. Помогает и обратная разработка.
Например, на экран на картинке у меня не было никакой документации. Но оно работает.)
Кстати, частота здесь около 60 кадров/с.
Вам хватает или имеется в виду, что их довольно-таки много?
ну не то что бы прям много, но некторые есть, OV56xx которые в каких-то старых айфонах использовались и как запчасти стоили прям копейки.
Неужто айфоновские экраны никак не описаны в сети? С учётом как их любят китайцы во всякие примочки типа программаторов и боксов для оных же ставить
Если экран без памяти кадра, то ему нужно давать картинку с какой-то минимальной частотой, чтобы не было миганий.
10 МБит/с мало. Пусть мы хотим 30 кадров/с и 24 бита/цвет.
10 000 000/30/24=13900. Т е разрешение у экрана выходит всего около 130х100.
Обычно разрешение хочется гораздо большее, и кадров/с 60 или более.
10 МБит/с мало.
больше в low power с lvcmos уровнями (которые из говна и палок на чём угодно изобразить можно) вроде не умеет. Для большего нужны отдельные гигабитные трансиверы, которые не везде есть.
Но довольно большое количество различных дисплеев которые в режиме "фоторамки" отображают статичные картинки которые можно хоть секунду обновлять.
Да и гонять данные через low power камеры/дисплеи вроде обычно не умеют ну или делают вид что не умеют, это опять же про качество и доступность документации.
качество и доступность документации.
А если бы документация была доступнее или кто-то показал бы примеры использования камер, экранов, то применяли бы их в своих проектах?
довольно большое количество различных дисплеев которые в режиме "фоторамки"
Вы имеете в виду именно с MIPI DSI интерфейсом или экраны вообще? Подбирали что-то под задачу, изучали варианты?
С памятью кадра мне больше попадались экраны с малым разрешением. А где побольше, там обычно (которые попадались) видеорежим. Может и есть большие с памятью кадра.
применяли бы их в своих проектах?
Я от какого-то то-ли 4-го то ли 5-го айфона пытался ковырять сенсор, вроде бы 5642. чтобы из него хоть как-то достать пожатую картинку в каком угодно низком разрешении/качестве, но через какой-нибудь "медленный" интерфейс, а не как положено. Но документация в виде каких-то скриншотов pdfa с китайского сайта и замечательные аппноуты омнивижена в виде нескольких страниц портянок вида i2cwrite(0xaabb, 0xcc); для инициализации различных режимов без описаний, одолеть не смог. Подозреваю что за прошедшие лет 10 лучше с документацией не стало, а совсем наоборот.
Вы имеете в виду именно с MIPI DSI интерфейсом или экраны вообще?
Вообще, если посмотреть вокруг есть довольно большое дисплеев которым и раз в секунду обновляться-то не особо надо. И вполне можно было бы обойтись любым мелким микроконтроллером без гигабитных трансиверов и соответствующих потоков видеоданных.
Ну и физически, особенно oled какой-нибудь, с чего бы отдельный пиксель после включения через сколько-то мс вдруг забыл своё значение яркости, что его надо обязательно N раз в секунду обновлять надо следующим кадром.
Хороший обзор получился. Для коммерческих проектов постоянно использую DSI и CSI (ну и, конечно, LVDS). Дисплеи дороговаты, но тонкие и качество картинки хорошее. Камеры, в основном, использую OV5640, ну и распберри.
Это вот отладка на двух SSD2828 для LS055R1SX04 (1440*2560 от полимерного принтера). Делаю, как я его называю полускалер. Суть в выводе статичной картинки для засветки фоторезиста, причем без задействования всяких одноплатников и ПЛИС. Максимум какой-то stm32. На данный момент заливка генерируется stm32f401, и с ним получается 2.5 раз в секунду обновить экран. Дальше в плане задействовать SPI Flash с ее fast read, для генерации видеосигнала для подачи на SSD2828.
Симпатично.)
Для такого применения достаточно 2 цвета или 1 бит на цвет (вместо обычных 16...24 бит/цвет). Учитывая, что входной интерфейс RGB и есть возможность объединить биты, можно без проблем генерировать нужный видеосигнал даже простым мк.
LS055R1SX04 (1440*2560 от полимерного принтера)
Принтер разобрали?) Или отдельно экранчик купили?
Ранее попадались видео, как люди на таких принтерах платки делают.
Как вариант сигнал с hmdi взять и преобразовать с помощью Toshiba TC358870XBG, как раз два порта DSI.
Купил комплект дисплей + скалер hdmi, дисплей уже без подсветки. Сначала генерировал изображение питон скриптом для проверки засветки. Светодиод 405нм 10 ватт, засветка полторы минуты. Потом думал взять одноплатник, но показалось что дорого выходит. Если получится генерить сигнал флеш памятью, то дальше работа в направлении засветки сразу двух сторон. И основная стоимость тогда будет два дисплея и 4 SSD2828, плюс всякая мелочь, ну корпус.
TC358870XBG тоже смотрел, но нужен либо одноплатник, либо ПЛИС. Плюс к SSD2828 есть исходники принтера, упомянутые в этой серии статей https://habr.com/ru/articles/520366/ . Если бы не исходники, навряд ли я получил бы результат.
Может отсюда какие-то идеи пригодятся.
Матрица съедает часть мощности. Ещё, скорее всего, мощность засветки неравномерна по площади матрицы.
Как-то немного помогал в проекте DLP-проектора с матрицей микрозеркал. Там видеосигнал тоже подавали по RGB интерфейсу, просто одноплатник взяли подешевле -- RPi zero 2.
TC358870XBG может без ПЛИС и одноплатника использоваться. Например, просто с компа брать сигнал.
одноплатник взяли подешевле -- RPi zero 2.
Я с ними не работал, и думаю буду долго разбираться, чтобы получить источник сигнала 2к для двух дисплеев. Да и в моей концепции тоже дорого. Поясню, есть Quad SPI flash, и их режим работы fast read. Как я понял, можно добиться потока 4 бит при частоте 50 Мгц. То есть, формируем дамп чтобы там были всякие VSYNC, HSYNC и тд. Зашиваем во флеш, запускаем fast read, и просто тактируем флеш, получаем быстрый нужный нам поток. Картинка ведь статична. Нужно больше 4 выводов, берем две флеш. Это теория, еще не проверена. Но если получится, думаю будет самое дешевое решение.
Например, просто с компа брать сигнал.
Не нравится мне этот вариант, хочу максимум автономности. Кроме того если в варианте двухсторонней засветки, это уже два видеовыхода нужно.
однобитный 1440*2560 это 460кБ влезет даже во внутреннюю память rp2350, который наружу может на 150МГц DDR, т.е. на 300МГц выплюнуть через HSTX, заодно сигналы синхронизации сформировать.
Я рассматривал такой вариант, но у меня нет опыта разработки rp2350, вникать буду долго, поэтому как первый вариант я рассматриваю генератор на флеш. Возможно позже займусь этим вариантом,по когда сделаю свою отладочную плату на rp2350 для mpp2508.
как вариант на попробовать можно ещё ft232h (ft2232h), там в режиме mpsse вроде можно 30МГц непрерывный однобитовый поток с ПК организовать, и заодно gpio дрыгать для hvsync.
Конкретно для этой задачи лучше бы подошел набор сдвиговых регистров, тк быстрый обмен нужен в одну сторону.
Тактовую частоту можно еще и легко удвоить, подав на вход элемента xor два сигнала одной частоты со сдвигом фазы на 90 градусов.
Идея с флешкой интересная. Но это нужно для каждой новой картинки прошивать память. Наверное, не самое удобное в использовании решение. Хотя, может и можно как-то удобно это делать.
Плюс нужно сделать какой-то преобразователь картинки в нужный формат.
Ради интереса можете посмотреть, как в проекте, использующем RPi zero, код написан и другое реализовано.
Ну предварительно как mass storage на smt32f401, который все равно нужен для инициализации ssd2828 и кольцевого запуска потока с генераторной флеш. В нем мало флеша, но закидываться будут сжатые файлы, которые будут распаковываться в дамп, и записываться на генераторную флеш. Возможно какое то беспроводное решение будет.
Может, все же SPI RAM использовать для хранения экранного буфера? Использовать для этого флэш как-то звучит,.. неправильно.
Подскажите дешевую SPI RAM на 4mbit.
Я не знаком с их номенклатурой, а поиски не дали внятных результатов. А с того что нашел, что у флеш, что у ram почти одинаковый обмен и они взаимозаменяемы. Флеш у меня есть, а ram нет. Поэтому на этапе экспериментов будет флеш. Дальше будет видно.
Флеш же, как понял 10к циклов перезаписи минимум. Думаю этого более чем хватит на любительское использование. А если не хватит, то учитываю дешевизну можно и перепаять. А учитывая почти взаимозаменяемость, можно будет и ram поставить.
На большие объёмы оно уже обычно PSRAM, т.е. внутри sdram который всю "динамику" прячет, а наружу выглядит как обычная асинхронная память. Но там надо аккуратно, могут быть некие грабли с непрерывной выдачей данных, и ограничением непрерывного чтения только в пределах страницы. "видеоданные" возможно придётся по строкам по границам страниц выравнивать.
В качестве компромиса между ram и flash ещё spi eepromы есть, с количеством циклов перезаписи получше. Ну и fram ещё но там на такие размеры цены уже негуманные.
Заказал ESP-PSRAM64H, приедет посмотрим что получится, хотя я еще и до флеш не добрался.
Note, however, that the maximum input clock frequency for burst operations which cross page boundaries is 84 MHz
То есть вроде позволяют всё-таки читать непрерывно, но на пониженной частоте (вместо 144МГц), видимо дополнительно кэшируя внутри, чтобы впихнуть открытие/закрытие страниц и рефреши.
Большинство psramов просто зацикливают burst внутри страницы.
Ну я тоже не очень знаком с номенклатурой; вот то, что часто в ESP32 модули ставят (т.е. относительно недорогое): APS6404L, LY68L6400, ESP-PSRAM64H. Вроде это все 64Мбит, должно с запасом хватить. По идее, флэш кроме числа перезаписей должна быть еще заметно медленнее, чем RAM, особенно на запись
Очень интересно, я бы почитал подробностей!
Тема действительно интересная для mcu - т.к. позволяет существенно сэкономить выводы. Но как обычно проблема со стоимостью дисплеев, 7 дюймов RGB можно купить за 17 usd на ali в розницу. А вот MIPI - гораздо дороже.
Экраны есть разные. Недостаточно сравнивать их только по диагонали. Нужно принимать во внимание ещё разрешение, тип матрицы, наличие и тип сенсорной панели и др.
7 дюймов RGB обычно с разрешением 800х480,1024х600,1280х720. Стоимость разная.
В магазинах запчастей можно найти экраны с/без ёмкостной панели. Цены начинаются примерно от 150 рублей (например, вот первый попавшийся).
Для примера листаю там же. Дисплей для Meizu MX3 в сборе с тачскрином 400 р. А это уже 5.1" IPS (1080x1800)
Huawei Honor X7 экран 6.74" IPS (720x1600) 90 Гц 550р
...
На Али можно найти много экранов от смартфонов с ценами около 1000 (больше/меньше)
Для примера Super AMOLED для Samsung Galaxy S III S3 i9300 i9300i i9305 900р+-
6,21-дюймовый дисплей для Huawei P Smart 2019 IPS (1080x2340), тоже около 1000 р.
И т д.
Как минимум, для экспериментов, это может быть интересно.
Для экспериментов да, для серии уже нет. Поэтому оно сразу пролетает.
Тяжело для заказчика обосновать повышение цены на дисплей в два раза :-(
Выпустили бы их недорогие.
В каждом конкретном случае лучше подходит что-то своё. Может и для DSI/CSI экранов/камер найдётся в серии применение.
Конечно, есть интересные альтернативы (например, дисплейные модули Двин, экраны с другим интерфейсом и др).
MIPI DSI экраны тоже используют в коммерческих проектах. В комментариях выше об этом писали.
Здесь, похоже, тоже был такой проект.
В вакансии старшего инженера-схемотехника в Яндекс среди прочих ожиданий от специалиста есть "Понимаете структуру и принципы работы популярных коммуникационных интерфейсов: CAN, UART, SPI, I2C, USB, Ethernet, MIPI, PCIe и др."
Возможно, они тоже используют камеры/экраны в своих проектах.
Для больших разрешений скорее подойдёт процессор, чем мк.
Не то чтобы выводы прям очень существенно экономятся. Но Мипи DSI сложнее, чем RGB. Зато и разрешения у экранов можно сделать побольше, и ЭМС лучше, при желании можно передать сигнал по кабелю на несколько метров.
Для RGB нужно 24+clk+hsync+vsync+DE+ DISP = 25...29
Для MIPI 2x(clk+D0...D3)+rst+te(не обязательно). = 11..12 Если ничего не забыл. Кол-во дифф. пар зависит от разрешения и конкретной модели.
Почитать бы про разработку драйверов под эти камеры и экраны. Когда-то давно была задачка такого плана, я аппаратно все подключил, а программист че-то долго возился и так ничего сделать и не осилил. Решили задачу в лоб переходником на другой интерфейс. А могли бы красиво, без лишних микросхем.
Что интересное делали (если не секрет или можно в лс) ?)
Под Линукс интересует?
Добрый день!
Да, под Linux, это, как мне кажется, наиболее распространенная ОСь для дисплейных продуктов. Интересен ваш опыт, раз вы готовы им делиться, такую информацию в систематизированном виде маловато.
У меня есть старенький MacBook Pro 15 - у него дисплей вроде бы ещё LVDS даже, но хотел в него что-нибудь армовое (а может и рисковое) поставить с большой батарейкой, эдакий долгоиграющий терминал.
Есть блок Lane assist от машины - две камеры на жёсткой металлической раме и какая-то логика без документации. Было бы интересно его отреверсить. Но это всё мои хотелки, для которых и коплю опыт )
А рабочие проекты пока без дисплейных модулей высокого разрешения. Увы, а может и к счастью.
Приветствую!
Интересен ваш опыт
Что интересует вообще, что больше всего? Напишите, пожалуйста, если есть что добавить. Интересно.
LVDS тоже есть варианты, как и к чему подключить. Есть одноплатники сразу с аккумуляторами (несущие или дополнительные платы).
Есть блок Lane assist от машины
Есть фотографии?)
без дисплейных модулей высокого разрешения
Через их использование появляются новые знания, а с ними и новые возможности. Ещё это попросту интересно.)
Была какая-то блочная камера от Sony и одноплатник на iMX вроде 8, надо было их подружить. В итоге к камере взяли скалер и воткнули в USB3.
Интересен именно процесс написания драйвера для видеосистемы линукс. Сейчас уже не вспомню где там были непроходимые грабли, но всякие простенькие камеры OV и прочие работали без проблем, а с этой не выходило прям никак.
Года четыре назад подключал аж два mipi-dsi дисплейчика 1920x480 к orangepi4. Пришлось немного поковыряться, разобраться с dtb и переписать драйвер фреймбуфера rk3399.
Оказалось, что по крайней мере тогда доступные mipi-dsi дисплеи попадались только каких-то детских размеров. Интересно, как сейчас с этим обстоят дела, есть ли такие размером > 10" ?
доступные mipi-dsi дисплеи
Доступные просто по цене/возможности купить или с какой-то документацией, кодом от поставщика/продавца?
Где брали ваши экраны?
Недавно работал с экранным модулем планшета 10,1” 1920х1200.
подключал аж два mipi-dsi дисплейчика 1920x480 к orangepi4.
Зачем понадобилось сразу 2?)
К чему можно подключить MIPI DSI экран?