Добрый день, имеется дисплей LM5Q32. Подскажите как его подключить к ардуино и по возможности использовать с существующие библиотеки.
Интерфейс 8 бит параллельный.
Подсветка у дисплея высоковольтная, но будет заменена на светодиодную.
https://docs.rs-online.com/b2dc/0900766b805f3450.pdf

В теории возможно .. но с дуру можно член сломать..
внутренний драйвер -убогий- совсем шлак) .. для работы требует точный тайминг и вывод изображения построчно- даже если заставить ардуино программно работать с ним, это заберёт довольно ценных ног и пожрет память, оставшегося времени на работу самой программы не останется и артефакты тоже полезут наверняка.
Количество усилий и прямые затраты отправляют этот экран в помойку.

А где бы почитать больше информации, может что то на спортивном интересе и получиться сделать. Скорости отображения не требуется, будет статическая картинка на дисплее.

Дело в том, что если у него своей памяти нет, то для вывода статической картинки потребуются все те же ресурсы, что и для динамичного режима... в этом случае может оказаться необходимость в отдельной простенькой ардуине только для него. Фактически, удобства ради. Она будет заниматься только приёмом данных и выводом на экран и всё.

Добавлено after 4 minutes 6 seconds:
Да, вот здесь https://forum.arduino.cc/t/code-librari ... d/150568/5 человек с этим и столкнулся, пойдя по пути поиска драйверной микросхемы, но не найдя её.
Вообще, решение подобной задачи - интересно. Хотя и не очень практично, ради одного дисплея.

Добавлено after 9 minutes 22 seconds:
а вот и полная спецификация на него, теперь задача решаема:
Одно только неудобно: нужно 30 вольт напряжения на Vee. Впрочем, ток небольшой.

вариант выделить одну ардуину для управления дисплеем устраивает. 30 вольт тоже не проблема.
Как бы ознакомиться с протоколом передачи данных на дисплей, на что он будет похож, на 8080 ?
Сформировать тактовые импульсы с помощью выходов ардуины думаю получится, главное понять последовательность передачи данных по выводам. Где бы более подробные примеры посмотреть ?

Протокол будет такой, как захотите, он ведь между двумя Ардуино будет.
А та Ардуино, которая управляет дисплеем, будет аналогом строчной и кадровой развёрток обычного телевизора, в приложенном мною документе это видно. Если упрощенно на словах, то так:
1.Посылаете на контакт 1 (YD) сигнал начала кадра (scan start-up signal)
2. Устанавливаете цвет первых двух точек и часть третьей точки на линиях D0-D7
3. Тактируете эти данные сигналом на контакте 4 (XCK)
пункты 2 и 3 выполняются, пока не будут заполнены 320 точек, то есть, одна строка

4. Данные строки защёлкиваются сигналом контакта 2 (LP)
пункты 2,3 и 4 выполняются 240 раз, пока не заполнятся все строки.

и всё заново. Страница 6 (нумерация в правом верхнем углу) даташита

Главное учесть, что цвет точек располагается задом наперед, то есть:
D7, D6, D5 - это R, G, B первой точки
D4, D3, D2 - это R, G, B второй точки
D1, D0 - это R, G третьей точки,
а следующие данные уже так:
D7 - это B третьей точки
D6, D5, D4 - это R, G, B четвёртой точки
D3, D2, D1 - это R, G, B пятой точки,
D0 - это R шестой точки и т.д.

в телевизоре надо постоянно передавать... а то будет чёрный экран ))
а что там памяти нет ? там что то сказано про RAM...

на странице 9 всё написано

Добавлено after 2 minutes 39 seconds:


Добавлено after 6 minutes 58 seconds:
глянул тайминги... кадр обновляется максимально допустимо 6,6 мс. За это время надо заслать 9600 байт, то есть, тактирование XCK получается около 2 МГц... я не особо разбираюсь в ардуино, вытянет ли?
и да, самое главное-то, где их хранить?

Хотя, можно немного упростить, если, например, хранить весь фон во флэши, а изменять небольшие участки, но это делает узкоспециализированным применение.

я по английски читать не умею)) плохо учился в школе)))

благо ИИ мне всё перевёл))

ясно... обычный телевизор.

а я подключал с памятью... тоже всякие 320х240 RGB... от телефонов всяких...



там есть память.

нарисовал пол экрана...



и пошёл спать))


утром дорисовал вторую часть))


да... я тоже использовал отдельную ардуину...



но у меня была другая причина... остальные ардуины были заняты))



320х240 RGB... получил частоту обновления экрана ~6 кадров в секунду.

слайд-шоу))

ну и ладно.


потянет ли ардуина 2 МБит/с ?
конечно потянет !

у ардуины физический предел 10 МБит/с.



так что ещё с запасом))


в другой теме подключали монитор к ардуине... по VGA...

с памятью удобнее, ктож спорит... но мне вот бесплатно они не достаются, а и даже такие, как у ТС, не попадаются... у меня сплошные LVDS, как у обычных матриц... 8-битные мк очень сложно прицепить

А какой смысл в таких костыльных извращениях?
Взять ARM и на нём всё сделать - и работу с этим экраном (раз уж так нужно именно его окучить), и всё остальное.

Добавлено after 1 minute 7 seconds:
На ARM-е всё реализуемо. В одном флаконе контроллере, без отдельных.

Добавлено after 2 minutes 59 seconds:
Вопрос больше - как и когда обрабатывать полученные по интерфейсу данные, которые нужно отобразить? Если всё время будет отдано на ногодрыжное формирование таймингов для экрана, то на остальное времени просто не останется. Если же вклинивать обработку между кадрами или строками - скорей всего будет мерцание картинки.
Разве что можно размазать приём и обработку данных из внешнего интерфейса по циклу ногодрыга. Но получится сложно (особенно для новичка), очень костыльно и ограничено по функционалу.

А на ARM можно организовать параллельную работу. Без ногодрыгов. При помощи DMA + соответствующей периферии. Или же ещё лучше - напрямую на внешнюю параллельную шину посадить.
Зачем тогда костылестроение?

PS: В документе, выложенном в 1-м сообщении темы, описания диаграмм интерфейса нет. Но подписи сигналов LP и XCK наводят на мысль, что интерфейс - что-то типа SPI, только 8-разрядный. А значит - можно попробовать задействовать МК, которые имеют либо один octal-SPI, либо 2 quad-SPI (умеющих работать синхронно).

Добавлено after 37 minutes 17 seconds:
Да ладно? Правда???
А если открыть документ, выложенный в первом посте и почитать его?
То там вдруг можно обнаружить: "Frame frequency = 180 Hz". Очевидно - это требуемая номинальная частота обновления экрана.
Предположим: тактовая частота ардуины == 16МГц. Берём калькулятор в руки и считаем:
16e6/(320*240/8*180) = ~9.26 тактов. Итого - для вывода каждых 8 точек у нас имеется всего ~9.26 такта ардуины. За эти такты нужно видимо успеть:
1) щёлкнуть 2 раза сигналом XCK;
2) (возможно) также щёлкнуть 2 раза сигналом LP;
3) прочитать из буфера и вывести в порт очередной байт пикселей.
Это ещё не считая того, что нужно ещё как-то и приходящие от внешнего МК данные успевать обрабатывать.
Серьёзно всё это успеете за 9 тактов???

Вывод: У абдурины нет никаких шансов. Нет шансов выполнить требования документа из первого поста.
Хотя - сделать нечто, чего-то там кое-как показывающее, еле видное из-за мерцаний - может быть и можно. Зависит - от времени послесвечения пикселей. Если время послесвечения - очень большое, то что-то кое-как будет показывать. Если время = малое - будет бегающая по экрану строчка светящихся пикселей.

А нужно = 180. Т.е. - в 30 раз(!) больше.
Теперь попробуйте представить, что вы садитесь смотреть фильм, а проигрыватель, при частоте кадров кина == 30Гц, показывает вам его по 1 кадру за секунду. Причём - не держит этот кадр всю секунду на экране, а кратковременно вспыхивает на 1/30 секунду и потом гаснет на остальные 29/30 секунды.
Как вам такой просмотр понравится? Вот также и с вашими 6Гц.

Хотя на этом LCD, при медленной развёртке, скорее всего будет не весь кадр кратко вспыхивать, а будет бегущая по экрану цепочка горящих пикселей. Длиной = ~ 1/30 части всего экрана.
Как вам приятно такое "кино" будет смотреть?