Comments 24
Недостаточно просто подавать видеосигнал. Следует записать нужные значения в регистры драйвера экрана (сделать начальную настройку -- инициализацию). Везде бывает по-разному. Например, настроить и включить dc-dc, настроить кол-во бит на цвет, порядок бит, ориентацию картинки, параметры гамма коррекции и т д. Потом ещё выход из сна (sleep_out) и Display ON. А потом уже гнать видеопоток.
Добавляет сложности, особенно при отсутствии документации, но даёт большую гибкость и удобство использования. Например, картинку на экране, который на обложке статьи повернул, просто изменив пару битиков в нужном регистре. Удобно.)
Это при том, что на этот экран совсем не нашлось какой-то документации. Всё выяснялось в процессе обратной разработки.
У каких-то экранов есть дополнительные интересные функции. Например, CABC -- content adaptive brightness control.
Бывает сразу встроен контроллер ёмкостного сенсора.
...
На самом деле много чего интересного.) Только пока не очень понятно, на сколько тема интересна сообществу и востребована.
Есть ли интерес поэксперементировать с экранами/камерами? Или интересно лишь почитать по теме, узнать что-то новое? А может кто-то просто хотел бы заказать обратную разработку и получить данные, достаточные для использования модуля в своём проекте. И т д.
Отличная статья! Тоже, кстати, активно использую TPS61161
Получается, произвольный DSI экран можно подключить к конвертеру и пускать RGB данные? Я когда-то слегка изучал тему подключения CSI камер к RPi, и, насколько я понял, у камер регистры конфигурации свои у каждого производителя, и для официально поддерживаемых RPi камер чуть ли не свои блобы в дистрибутиве зашиты. С экранами нет такой шляпы?
У камер у каждой свои регистры конфигурации. Обычно описываются в даташитах, которые производители почему-то не очень любят распространять. Опенсорсные драйвера часто содержат таблицу инициализации регистров в виде бинарной таблицы регистр-значение, и по коду не поймешь, какие регистры за что отвечает. У меня есть опыт прикручивания камер к Nvidia Jetson и доработки драйверов. Играл с клоками, чтобы оптимизировать FPS, допиливал драйвер, чтобы в device tree можно было прописать желаемое разрешение, глубину цвета и биннинг, и именно на это разрешение конфигурировалась камера.
И у mipi камер и у dsi дисплеев такие регистры конфигурации. И я скажу больше, даже официальные дистрибьюторы часто дают просто набор байт, которые нужно писать по определенным адресам. Хорошо, если далут даташит на микросхему драйвера, в которую пишем, тогда можно посмотреть что и как конфигурируем.
в даташитах, которые производители почему-то не очень любят распространять.
MIPI стандарты закрытые, только для членов организации. К тому же не хотят делиться технологиями и ограничивают возможность использования.
Личный или коммерческий проект (если не секрет)?
С экранами такая же шляпа)
Недостаточно просто подавать видеосигнал. Следует записать нужные значения в регистры драйвера экрана (сделать начальную настройку -- инициализацию). Везде бывает по-разному. Например, настроить и включить dc-dc, настроить кол-во бит на цвет, порядок бит, ориентацию картинки, параметры гамма коррекции и т д. Потом ещё выход из сна (sleep_out) и Display ON. А потом уже гнать видеопоток.
Добавляет сложности, особенно при отсутствии документации, но даёт большую гибкость и удобство использования. Например, картинку на экране, который на обложке статьи повернул, просто изменив пару битиков в нужном регистре. Удобно.)
Это при том, что на этот экран совсем не нашлось какой-то документации. Всё выяснялось в процессе обратной разработки.
У каких-то экранов есть дополнительные интересные функции. Например, CABC -- content adaptive brightness control.
Бывает сразу встроен контроллер ёмкостного сенсора.
...
На самом деле много чего интересного.) Только пока не очень понятно, на сколько тема интересна сообществу и востребована.
Есть ли интерес поэксперементировать с экранами/камерами? Или интересно лишь почитать по теме, узнать что-то новое? А может кто-то просто хотел бы заказать обратную разработку и получить данные, достаточные для использования модуля в своём проекте. И т д.
Недостаточно просто подавать видеосигнал. Следует записать нужные значения в регистры драйвера экрана
А откуда конвертер RGB-MIPI или HDMI-MIPI берет эти данные? МК присылает по упомянутому в статье SPI?
Почитать про то, как делать такой реверс - очень интересно, для саморазвития. Но для хобби-поделок я бы взял экран, с которым меньше всего геморроя (так что как найти такой экран, тоже интересно)
Тема таких экранов меня заинтересовала, когда я купил фотополимерный принтер и узнал, что даже принтеры начального уровня имеют FPGA для отправки данных в экран. Появился вопрос, а нельзя ли вместо свзяки MCU+FPGA с глючными закрытыми прошивками использовать одноплатник типа малины/апельсинки, и выводить картинку как на обычный дисплей... Но в целом, эта идея выглядит сильно больше, чем у меня есть знаний и свободного времени.
А откуда конвертер RGB-MIPI или HDMI-MIPI берет эти данные? МК присылает по упомянутому в статье SPI?
В данном случае данные для записи в драйвер экрана посылаются с мк через SPI микросхеме SSD2828, а она отправляет пакеты экрану по Мипи интерфейсу.
Благодарю за обратную связь.)
а нельзя ли вместо свзяки MCU+FPGA с глючными закрытыми прошивками использовать одноплатник типа малины/апельсинки, и выводить картинку как на обычный дисплей...
Можно.) Для одноплатника нужно будет драйвер экрана под Линукс написать.
Только над подбирать подходящий одноплатник для конкретного экрана. Например, у одноплатника есть только 2 пары данных (2-lane), а экран хочет 3 или 4. Подробнее можете посмотреть здесь. Там же был комментарий про полимерный принтер.
Можно использовать связку мк+микросхема преобразования интерфейса или другие варианты.
Но в целом, эта идея выглядит сильно больше, чем у меня есть знаний и свободного времени.
Возможно, выглядит страшнее чем есть на самом деле. С неизвестным так часто бывает.)
Спасибо!
А как понять, сколько линий нужно дисплею? Я находил фото платы от своего принтера, там сильно больше дифпар, чем 3 или 4.
Скрытый текст
Всё правильно. Можно посчитать на плате, шлейфе экрана. Либо по схеме посмотреть, если есть. Или в документе на экран указано. Есть и другие варианты получить эту инф-ю.)
Обычно 1 тактовая дифф пара и 1...4 пары данных.
Может быть 2 порта Мипи. То есть 2х(clk+d0...d3). Как бы 2 экрана в одном.
Например, для экрана LS055R1SX04 (1440*2560 от полимерного принтера) из комментария под прошлой статьёй MIPI (2 ch, 4 data lanes). Потому и 2 микросхемы SSD2828 человек поставил.
init-sequence для дисплеев можно найти в коде Linux для девайса, их никогда не выносят в блобы. Конечно, если речь не об iPhone :)
https://github.com/kalltkaffe/galaxy-s3-kernel/blob/master/drivers/video/samsung/nt35560.c
А вот с китайскими матрасами для айфона интереснее. Я их не изучал, но полагаю что им вообще init-sequence не нужен и они работают в "захардкоженном" режиме?
Вот эта плата очень приятная :) Можно взять TTL RGB интерфейс с проца (в малине и allwinner-одноплатниках он есть) и подключить хороший IPS-дисплейчик большой диагонали.
И ещё: в смартфонах на чипсетах Spreadtrum SC6820 часто использовались 16-битные 8080 дисплеи с разрешением 480x320 на стандартных контроллерах ILI, на которые есть даташит. Так что если хватает пинов для 8080 - можно использовать и их :)
Кроме ILI ещё много разных. Попадаются с 8080 интерфейсом разной битности. 8...24. Такие разрешения попадались и с spi. Это в более старых телефонах (и не только) применялись. С течением времени найти их становится сложнее. Тем более, что многие о них знают и применяют в своих проектах.
На бОльшие разрешения обычно Мипи.
Инит нужен.
Да, интересная плата.)
Добавить бы легко доставаемое с запчастей от мобил и подключить к hdmi/DP/ USB-C дешевый, но +-норм дисплей от безрамочных смартфонов с 120+Hz. Там первым с такими ттх куууча лет уже, +многие были по 1к+ за дисплей+рамка+тачскрин на Ozon/Ali/...
Ато вроде и неплохи многие дисплеи, но рамка и тач с широченными полями, анрил мороки будет в diy проекте уменьшить их с достаточной крепкостью и тп внешкой на выходе.
Ещё бы и контроллер тача завести в систему; и к какой-ниб Radxa x4 на n100 подключить. +сенсор освещенности, приближения и тп дефолтные достать, rgb светодиоды для подсветки уведомлений. +Облепить мелкими кнопками и тд.
Нужны ли резисторы согласования уровня?
Это не для согласования уровня, а антизвонные. Небольшое сопротивление вместе с крошечной паразитной емкостью выводов и монтажа образуют простейший фнч, который сглаживает выбросы при переключении высокоскоростных сигналов. Их можно было оставить. Особенно, если линии длинные с высокой паразитной индуктивностью.
Если взять ёмкость монтажа+входную ёмкость микросхемы 3...5 пФ, резистор 22 Ом, то частота среза ФНЧ будет
f = 1/(2πиRC)= 1/2*3,14/22 Ом/(3...5)*10^-12 Ф = 2,4...1,45 ГГц.
Пусть у нас разрешение экрана 1920х1200, 24 бита на цвет, 60 кадров/с
PixelClock = (Высота + VSync + VFP + VBP) (Ширина + HSync + HFP + HBP) FPS = 162 МГц.
5я гармоника 810 МГц, 7я -- 1134 МГц.
...
Возможно, вы правы и польза от ФНЧ была бы.) Спасибо.)
Но для согласования уровней последовательно включенный резистор тоже используется.
а меня, как умеренного "зеленого" всегда расстраивает что нельзя что-то использовать повторно, ну или это выходит безумно дорого.
Нда.... электроника для начинающих....
Запускаем MIPI DSI экраны от смартфонов. Разработка схемы основной платы. Часть 1. Обзор решений, создаём своё