Comments 116
Объявление среди читателей
Я хочу пива.
< Раньше здесь был анонс новой рубрики, но никто не оценил, поэтому оставлю так:( >
Ну и конечно-же не забываем о том, какие статьи ждут нас в ближайшее время!
У нас давненько не было статей в рубрике о принципах работы GPU из 90х и 2000х годов. Я планировал написать про Xbox Original и его GeForce 3 - первый GPU NV с поддержкой программируемого пайплайна, а также про PowerVR MBX - первый массовый мобильный GPU, который использовался, например, в Nokia N95, Dell Axim X51v (в виде Intel 2700G) и iPhone 2G/3G В процессе голосования в моей телеге, читатели выбрали статью именно про мобильный GPU!
Я продолжу развивать тематику бюджетных копий и их ремонта. Буквально вчера я купил подделку iPhone 14 Pro Max в неизвестном состоянии за тыщу рублей. Девайс оказался после воды и ребутился на заставке, однако мне удалось его оживить, перекопав половину платы. Я во всех подробностях расскажу, как диагностировать аппаратные проблемы программными методами, как читать логи и сопоставлять их с аппаратными болячками, а также подниму такой "айфон" и расскажу на что он способен в наше время!
Спасибо за крутяцкую статью. Как говорится, разрешите докопаться.
lcmData(0x2C);
lcmData(0x2D);
lcmCommand(0xB2);
lcmData(0x01);
lcmData(0x2C);
lcmData(0x2D);За такое всем студентам бил по рукам. Да и сам, когда спустя годы попытаешься понять что здесь происходит опухнешь. Все константы надо вынести в #define и обозвать что она означает. Тогда потом понять почему такая последовательность не возникнет вопросов.
Как минимум ставить комментарии, чтобы потом понять какая команда за что отвечает.
И зря били, тут дело вкуса.
Я всегда считал init sequence дисплея эдаким чёрным ящиком, который один раз проинициализировал с нужными настройками гаммы, LUT'ом, развёрткой и т.п, читабельным должен оставаться только основной интерфейс к нему. Разве что регистры DBI есть смысл обернуть в константы.
Более того, как я уже подметил выше, большинство коммерческих производителей смартфонов, планшетов и.т.п пихают весь init sequence просто в массив байтов, который нужно переслать на дисплей. НОЛЬ объяснений :)
понять почему такая последовательность не возникнет вопросов.
Я некоторые регистры наизусть помню, другие мне не проблема найти в ДШ :)
Нет вкуса в коде. Надо делать так, чтобы твой код могли прочесть и понять другие люди. Это грязный код, в котором легко ошибиться.
Ошибиться в чём, если это чёрный ящик? :)
Внешний интерфейс к дисплею должен оставаться более чем читабелен, как и манипуляция общепринятыми регистрами типа того же направления развертки или старта записи в VRAM. Инит никого не заботит, его один раз запилили и забыли. Нужно скорректировать, например, напряжение драйвера в самом контроллере? Посмотрели в ДШ где, что и как и скорректировали.
Не буду тебя убеждать в неверности такого подхода. Но читателям комментов скажу, что такой стиль плох и ведёт к большим ошибкам.
Инит никого не заботит, его один раз запилили и забыли
Ещё как заботит. Неправильно написанный инит, например, может приводить к нестабильной работе в определённых условиях, которых на столе у автора инита просто нет.
Например, был случай — STM32L1 глухо вис при выходе из STOP, исправлялось магией, то есть добавлением одного пустого такта после WFI(). Ну или написанием инита контроллера строго по RM, с соблюдением последовательности инициализации, корректного расчёта таймингов и проч. ;)
Не совсем корректное сравнение, дисплейчики - это совсем иной вопрос, поскольку там действительно есть возможность отправить определенный инит и пользоваться дисплеем дальше. Каких-то спорных моментов при соблюдении максимальной частоты шины, таймингов и правильной толщине/длине проводников обычно и не возникает, вендор драйвера дисплея уже всё давно отладил.
Чипсетная периферия - это совсем другой вопрос и вот здесь действительно могут возникать вопросы с временем реакции в тактах и т.д. Я уже пояснил Сергею, что юзать захардкоженные иниты в виде "чёрных ящиков" применимо для некоторых устройств, но неприменимо для всей остальной логики программы и перифии МК в том числе.
Не совсем корректное сравнение, дисплейчики - это совсем иной вопрос, поскольку там действительно есть возможность отправить определенный инит и пользоваться дисплеем дальше. Каких-то спорных моментов при соблюдении максимальной частоты шины, таймингов и правильной толщине/длине проводников обычно и не возникает, вендор драйвера дисплея уже всё давно отладил.
Микроконтроллер ничем не отличается.
Я устал спорить. Пусть каждый останется при своем.
Я вот тоже не понял зачем комментировать двоичный код присланный поставщиком дисплея, это в сущности прошивка.
Там комментатор верно подметил, что есть тулза для генерации инитов в виде блобов. Поэтому вполне оправданное решение :)
Потому что не всегда он просто присланный. Часто там часть последовательно, а часть — всякие настройки. И вот когда вы (или не вы) через два года захотите поменять режим фреймбуффера, то без комментариев вы отправляетесь искать даташит, а с комментариями — меняете один дефайн.
Тоже соглашусь, define - это всегда полезно.
Но вот в случае индикаторов, особенно если речь идет про всякую китайщину, все не так просто.
Очень часто доступная документация на индикатор не описывает, как его правильно инициализировать. Название микросхемы-контроллера упомянут - и все, крутись как хочешь.
Гугленье приводит к каким-нибудь библиотекам, с кучей команд, как в посте.
Да, можно вручную выяснить, что значит каждая команда (по документации на контроллер), но это не поможет понять, каким образом был определен порядок команд, откуда взялись значения, записываемые в регистры. Они все равно останутся "магическими".
А откуда последовательность команд взялась в найденной библиотеке? Не удивлюсь, если в конечном итоге - из NDA документации на индикатор.
Верно. Это на 7735 легко можно найти и инит, и дш. Или на ILI9341 например. А вот когда речь заходит о диковинных дисплеях на контроллерах GC - тут пиши пропало, мне лично пришлось копать исходники Linux какого-то китайского устройства.
С MIPI-матрицами вообще мрак: на них открытых даташитов практически вообще нет. Поэтому в процессе подключения DSI матриц к малинке условной, приходится как есть копипастить весь инит секвенс из существующего устройства, где этот дисплей используется.
В моём кейсе ещё всё относительно понятно. А там тупо:
char initSequence = { 0x1A, 0x3A, 0x5A, 0x3A }, где 0xFF - это сигнализатор о том, что пошла команда или данные. Вот и попытайся разобраться где и что :)
В общем, предлагаю Сергею прийти к такому консенсусу: инициализация периферии подобной дисплеям может быть черным ящиком. Работа с регистрами и периферией МК, или чего-то, что хорошо документировано (MMC например) как тупо с hex мейджик-числами - говнокод.
Гугленье приводит к каким-нибудь библиотекам, с кучей команд, как в посте.
В явном виде вставляете комментарий «Some magic numbers here, see <ссылка на откуда вы это взяли>».
Приведу пример. В своей библиотеке воспользовался готовой последовательностью инит от адафрут. Смотрю странно как-то цвет смотрится -- а там первичную яркость RGB каналов адафрут "на свой вкус" выставили. Поменял коэффициенты. А не знал бы что за команда, так и оставался бы у меня "странный цвет".
Не соглашусь, недавно решил запустить дисплей на st7789V2, нашел либу под него, но с другим разрешением, а оно не работает, оказалось что последовательность инит другая, а там все так же кодами, ничего не понятно, пришлось долго ковыряться, так что черный ящик не всегда работает, приходится лезть. В остальном либа работала хорошо.
к сожалению уже обычная практика и у производителей (сенсоры изображений, радиотрансиверы, всякие датчики положения с обработкой внутри), вместо нормальной документации выкладывать аппноуты вот ровно с такими портянками: для инициализации вот этого режима - пишите вот этот набор магических циферок по вот этим адресам, !описания которых иногда просто нет вообще!
Это печально
Реальный мир (предполагается массовая заводская электроника) он такой :)
Вспомни ту же дингу! Почти уверен, что инит дисплея там реализован тоже в виде набора команд без дефайнов, возможно даже скопипащенный откуда-то.
А ведь это просто один из десятков устройств на базе одной рефборды и там вероятно никто особо не заморачивался
Это хорошо, если с портянками. Хуже, если с описанием функций из SDK, у которых эти портянки хорошо спрятаны внутри.
Некоторые вендоры так делают потому, что драйвер опенсорсный а документация под NDA. А может из-за лени или из вредности. И не только с экранами но и с модулями камер например. Были у меня проекты где я подобный треш менял на нормальный код, и местами заменял константы на арифметику.
В практической части статьи мы подключим дисплей по протоколу MIPI DBI к RP2040 с использованием DMA. Интересно? Тогда добро пожаловать под кат!
И где обещанный mipi? Я вижу только spi.
На данный момент самые распространенные дисплеи - это I2C OLED.
Стоят везде, начиная от паяльников и заканчивая авто/мото.
Есть куча типоразмеров, матричные, стоят дешево, портебляют очень мало (0.49", 50% заполнение ~ 6mA).
Обычно монохромные (но цвет может быть белый/голубой/желтый), но есть и 2х цветные и цветные.
В большинстве случаев их хватает с лихвой на все, при этом они гораздо лучше смотрятся любого TFT/LCD, если речь не идет о картинках, а об выводах телеметрии, показометрах и интерфейсах.
P.S. за использование hex-кодов вместо констант есть отдельный щербатый котел...
Тоже верно. Правда SSD1306 тоже со временем выгорают, как и любой другой OLED, учитывая статичность выводимой информации.
Это заблуждение.
Не выгорают вообще заметно на глаз, на ютьюбе есть тест мужика, который тестировал их в течении нескольких лет одной картинкой.
Хм, я слышал обратное.
Возможно "невыгораемость" связана с одно-двухцветностью таких дисплейчиков?
Возможно. Речь именно о монохроме.
Само выгорание там, естественно, есть, но на глаз оно не заметно.
Тогда да, согласен пожалуй там в целом особо "выгорания" и не заметишь :)
Когда-то Samsung сделали концептуально похожий на SSD1306 полу-OLED, полу-TFT дисплей, вроде даже с AoD! В X120 было как-бы две матрицы с одним контроллером (судя по схеме), вроде-бы в большинстве таких девайсов оледы всё ещё живы и не выгорели.
Выгорание очень даже заметно. В используемом с 2016 года примерно 10...15 часов в неделю устройстве с 0,96" 2-цветным монохромным OLED уже второй дисплей поменял.
Но всё же Winstar OLED (или их графические аналоги) по живучести всё равно получше. Дома есть часы на таком индикаторе (купил попробовать этот экранчик и решил на нём что-то сделать), работают с 2021 года, и проблем с яркостью я не заметил.
А вот SSD1306, если что-то действительно по большей части статичное показывать, типа имитации семисегментника, действительно довольно быстро потеряет в яркости.
Подтверждаю, действительно отличные дисплеи! Я использую такой в генераторе сигналов и им полностью доволен
Winstar - переросток, у него область применения такая же, как у ЖК на КБ1013ВГ6 и HD44780, там и интерфейс не отличается. А SSD1306 хорош, когда нужна сверхминиатюрность.
Они, к слову, отличаются от HD44780 немного. Если на HD44780 повторно сделать инициализацию (например, сбросить контроллер, к которому он подрублен), то ничего не будет, Winstar OLED же зависнет. Поэтому надо либо передёргивать питание, либо отправлять ещё пару свойственных чисто ему команд (они все тоже ищутся).
Зависит от того, какая яркость выставлена.
P.S. за использование hex-кодов вместо констант есть отдельный щербатый котел...
Вот я тоже утверждаю, что это вселенское зло.
Помимо поиска по числу контактов стоит почитать профильные форумы типа такого. Очень вероятно, что такой экран кто-то до вас уже успешно запустил.
Было бы интересно почитать про подключение матрицы с интерфейсом LVDS. К МК STM32 (жирных серий типа H7) их вполне успешно подрубали.
Не шарю за дифференциалки срвсем
Самое время восполнить это упущение.
были обходные технологии, когда обычный (условно) ttl через 2XOR прогонялся и один вход дата, второй вход +, на второй паре дата и второй минус. таким образом избегают иголок.
да и проверить - дисплеи обычно терминируют эту шину определённым сопротивлением в 100 или 120 ом (не помню).
имхо - видел на сайте где парень запускал sdram модуль через avr. (https://sites.google.com/site/geekattempts/home-1/sdramthing/using-sdram)
уточнение - https://sites.google.com/site/geekattempts/home-1/drive-an-old-laptop-display-from-an-avr/lcd-concepts - https://github.com/ericwazhung/avr-lvds-lcd - там в тексте объясняет про xor (74LS86)
STM32 (или другие микроконтроллеры) c модулем LTDC (LCD TFT Display Controller) на борту. Как это делается хорошо описано, например, здесь. Также есть интересное видео по использованию этого модуля для управления матрицей ноутбука.
не удалять статью! Я ещё не прочитал! )))
Кстати, SPI устройствами можно управлять с обычного советского программатора на чипе CH341, на нём есть SPI шина. Хотел про это статью написать, но это как-то не очень серьёзно получается.
А чоб нет? :) Хорошее начинание, эдакий аппаратный USB SPI-контроллер! Причём насколько я знаю, CH341 управляется через COM-порт и фактически просто пробрасывает SPI-команды на флэху.
i2c тоже, читал AHT10 так
для этого есть адаптеры от ftdi, с человеческим mpsse, который почти что угодно изобразить может, не только spi.
либо китайские клоны usb blasterов, за те же пару $$ что и программаторы на СН341, и с простым как валенок протоколом.
а с китайской документацией на заре появления данных поделий от wch у меня как-то не очень сложилось и были какие-то грабли с драйверами, сейчас уже возможно поправили.
Частично разобрался как управлять SPI на CH341 через libusb, через исследование чужих исходников (но там много магии), могу теперь вручную программировать команды по документации, а не через GUI приложения всякие. Например, подключил слот для SD карт (что продаётся как модуль для Ардуино), и сделал чтение служебной информации с карт.
у ftdi есть человеческая документация и нормальные драйвера, ну и куча io на чипселекты, подключал 8 штук ацп. с оберткой в луа для удобства https://github.com/pavel212/uffi/blob/master/example/ads1263.md
а протокол USB blaster давно разобран и очень простой, ну и прикидывается он тем же мостом от ftdi, так что грубо говоря нужна только единственная функция FT_Write.
А i2c дисплеи вполне можно подключать к соответствующей шине на VGA/DVI/HDMI порту. Правда, иногда нужно добавить обманку: eeprom-микросхему с EDID.
Большой дисплей так, конечно, не подключишь - скорость обновления совершенно смешная получится, но вот символьные 1602 или 2004 показывают себя неплохо при таком использовании.
@dlinyj поступил круче. Он нашел, что I2C с VGA экспортируется в Linux и через него можно рулить дисплеями!
Недавно видел хак для обхода EDID, если драйвер не включает порт:
echo on > /sys/class/drm/card<номер и разъём>/status
Но всё равно надо правильное разрешение экрана где-то устанавливать.
https://habr.com/ru/companies/ruvds/articles/689982/
Проголосовал за подключение всех дисплеев, хотя не уверен насчёт вариаций RGB. Если это SCART, то да, если куча барелей, то вроде что-то подобное было на БК-0010-01 и цветному монитору к нему, но не уверен. Лучше бы сделал мультивыбор...
PS: Куда относится стандартный экран на Arduino Mega 2560, который подключается в правый двойной ряд дюпонов?
Если что, есть идея для следующей статьи: как сделать свой лаунчер (домашний экран) для андроид
я когда решил немного походить в дисплеи то тоже взял st7335, на него массы примеров и эти hex уже готово задефайнены. Да и сами примеры шикарные, например 3d с текстурированием и все шустро работает на старойдоброй stm32f1103
Интересно, хотелось бы ещё узнать, какие особенности есть у круглых дисплеев
Они квадратные. Это даже не шутка. просто обрезанный квадрат.
Натс все ответил за меня)) иногда типа округлые дисплеи просто, без шуток, подкрашивают, затемняя нужные участки
Этот фокус пройдёт, если сама железка, в которую установлен дисплей, квадратная. В круглых часах дисплей приходится делать круглым по-настоящему. Но для контроллера (а значит, и ПО) он всё равно квадратный, просто некоторые пиксели у него отсутствуют физически, если попробовать туда что-нибудь записать, контроллер ответит: "да, я это сделал", даже состояние соотв. ячейки видеопамяти изменится, но внешне ничего не произойдёт.
Ещё TFT-матрицы со стандартным соотношением сторон пилят, чтобы получить вытянутые. Ту часть, со стороны которой шлейф, оставляют, шов заново герметизируют. Остальное, увы, задействовать никак, это «хвост ящерицы». Но контроллер совершенно не замечает исчезновения части физических пикселей.
Скажите, а какой интерфейс обычно у дисплеев с фиксированным набором индикаторов (не знаю как они правильно называются) и можно ли перехватить с контактов передаваемую на них информацию? Хочется считывать показания не с дисплея глазами, а с проводов прибором.
Это сегментные индикаторы, их принцип схож с оными в весах, различных цифровых панелях и т.п. Ими можно рулить, включая сегменты по отдельности, но где и что находится вам придется узнавать самому. Я лично работал в основном с TFT-матрицами, так что с такими лучше обратиться к мастодонту "сегментщику" @MaFrance351
Видал такие в китайских лазерных рулетках, там COG. Подключен был по последовательной шине, вероятно, SPI.
Что за контроллер LCD там - не знаю. Но любом случае, реверс-инжиниринг протокола нужен, чтобы карту сегментов определить.
Это про боковой экран.
Также разбирал аналогичный старый дальномер (для гольфа), у него был перед окуляром простой LCD без контроллера - как в часах наручных.
Если что, на Aliexpress видел потроха таких дальномеров, которые сразу значения по UART выдают.
да, читал вашу статью про реверс инжиниринг рулетки, сильно. Дальномеры на Али видел, но от китайцев добиться годной документации по протоколу связи через uart не просто.
И почему-то потроха стоят дороже, чем готовый хороший дальномер, но это уже мелочи.
Там стоит либо "голая" матрица (которой можно дрыгать, например, при помощи МК STM 8 или 32 серии L), либо дисплейный модуль на контроллере NEC или Holtek.
у таких сегментных ЖК индикаторов довольно неприятное управление с кучей уровней,
и если нет возможности перехватить данные до контроллера (а они бывают встроенными в МК) то перехватывать напряжения управления непосредственно сегментов довольно гиблая затея, решаемая конечно, но при очень уж большой необходимости, нынче проще камерой будет распознавать что нарисовано. Или поверх дисплея печатную плату наложить повторяющую дисплей smd фотодиодами в нужных местах и читать уже их.
Туда залезть и прочитать несколько сложнее, чем кажется.
Если прям стекляшку подключить - то там не так все просто. Лучше использовать специальные драйверы. Вот тут принцип их работы: https://www.youtube.com/watch?v=ZP0KxZl5N2o
LVDS/eDP — Протоколы, используемые в матрицах ноутбуков, телевизоров и иногда планшетов. На физическом уровне близки к DSI, на программном — если честно, не знаю, но наслышан о некой стандартизации и высоком уровне совместимости.
Это обычный RGB, который через 7-битный сдвиговой регистр со встроенным умножением тактовой частоты на 7 превращён в 4...5 низковольтных дифпар. С помощью тупого сериалайзера легко делается из RGB, а через десериалайзер из него вытягивается RGB. Сделано для минимизации числа проводов и повышения частоты и разрешения дисплея - потому что для дифпар гораздо проще повысить частоту сигнала, чем для TTL.
Вот как? Хм, а привязка к EDID тогда зачем?
Спасибо за статью, в ней хорошие ответы на вопрос "у меня есть дисплей, как бы его подключить?". В хобби проектах использую ESP32 и возникает обратная проблема - есть микроконтроллер, какой дисплей выбрать чтоб прощё всего было с ним работать? Что посоветуете размером 2-3 дюйма, touch не нужен. Желательно с breakout пинами, потому как код я писать ещё умею, а вот паять - не особо. Например, какой дисплей у вас на КДПВ?
какой дисплей выбрать чтоб прощё всего было с ним работать
Если разрешение небольшое или не нужно сверхбыстрое обновление, то самое простое - на I2C-шине. Работать с I2C проще всех, т.к. он аппаратно есть практически у каждого контроллера, да и подключается по двум линиям.
Зависит от ваших нужд. Но если упомянули 2-3 дюйма, то только TFT панели. См. на алике SPI-дисплеи с 2.5" диагональю и смотрите используемый контроллер (подойдет любой)!
тогда вот про железки без пайки
Также вам могут быть интересны
Запускаем дисплей на STM32 через LTDC… на регистрах
Миникомпьютер из роутера с OpenWRT: разрабатываем USB-видеокарту
Подключение дисплея 10" ER-TFT101-1 к STM32F429 через FMC
Что можно сделать с большим дисплеем?
Вы тоже любите дисплеи?
Подключаем дисплей к любому одноплатнику с SPI: большой мануал о поиске экранчиков для ваших проектов
мне понравилось экспериментировать с дисплеями от смарт часов. на пример в своей статье https://habr.com/ru/articles/796987/ я рассказывал об опыте применения дисплея от смарт часов T800 Ultra. Как правило это качественные IPS дисплеи с хорошим разрешением и с емкостной сенсорной панелью, а бонусом вы еще получаете аккумулятор и беспроводную зарядку)
Совершенно согласен с Dlinyj насчёт магических цифр, надо хотя бы комментарии к командам оставлять, они бывают полезны вне инициализации.
Сейчас продумываю PIO драйвер на RP2040 для ILI9341/ST7789 для построчного скоростного вывода изображения из эмулятора ZX Spectrum, надо как минимум 30 FPS выжать, а лучше все 60 ?
Имхо ссылка на эту статью в ридми репы было бы удобно.
К использованию в разработках дисплеев от мобильников и прочего ширпотреба, отношусь отрицательно. Иногда надо что-то побыстрому собрать, найдешь готовый проект в сети - а там экранчик от хрен пойми чего, мелкий, да еще и на сопливом шлейфе который оборвется во время отладки... На мой взгляд лучше бы применять стандартные широко распространенные модули на HD44780 и подобные.
так если вот здесь к примеру ST3775 то он в куче дисплейчиков и новых и старых
Как вариант для @xirahai дисплеи от 3310, либо прижимные от сименсов - там нечему ломаться и рваться в силу конструктивных особенностей
Я не так давно начал писать похожую статью, но потом остановился. К этой статье у меня есть графическая библиотека, заточенная под мои потребности и мой последний проект, но прокт ещё не на 100% собран в железе.
Вот мой полу-продукт: https://github.com/jef-sure/dgx/blob/main/Notes.md
Недавно на работе подключал экран с параллельным RGB интерфейсом и для фана сделал старые добрые "шарики" из Shock. Заодно немного сломал мозг своим падаванам вопросом как это так я так ловко успеваю рисовать сотни шариков. Через некоторое время общими усилиями они догадались как делается этот эффект.
Мобильные экранчики в ваших проектах: большой и понятный о гайд о различных дисплеях