TFT LCD. Вопрос подключения., необходима любая информация Опции

[Nixon]

Стал вопрос о создании контроллера для TFT LCD Samsung LTS350Q1. В родной доке на него настолько скудный материал, что даже понять назначение сигналов понять невозможно. Если кто-то сталкивался с подобным - просьба помочь.

[-=KiV=-]

А какой там интерфейс? Есть несколько стандартных вариантов цифровых интерфейсов TFT LCD и впридачу еще стандавтные аналоговые PAL, NTSC. У меня где-то была информация по 6-bit RGB intrface, и по-моему видел где-то у себя на фирме по PanelLink. Напиши, что конкретно там за сигналы. Может разберемся.

[Nixon]

18-битный RGB интерфейс данных плюс шесть цифровых линий управления - STV, CKV, STHR, HCLK, INV, LD, плюс еще куча аналоговых сигналов плюс 5 напряжений питания и главное отсутствие вменяемой документации.

В принципе уже написана hdl-модель управляющего драйвера (на уровне интуиции), но любая дополнительная информация приветствуется

Ссылка на единственную доступную доку для него - http://www.samsung.com/us/Products/Semicon...ts350q1-pe1.pdf

[-=KiV=-]

Да... уж...
Если у Вас есть микросхема LCC3600, описання в конце этого документа, то в общем-то у нее на входе обычный 6-bit RGB, без всяких извратов, за исключением того, что индикатор повернут на 90 градусов - т.е. у него 240 точек на 320 строк (срециально для PDA ).
Мы как-то использовали стандартные 320x240 и 640x480. Но разницы большой нет. Только LCD был NEC с широким диапазоном температур. А так все то-же. Описание могу попробовать откопать.

А вот если у Вас просто ЖКИ ...
Ладно, попробуем разобраться. Итак.

Главное подать на него все питающие напряжения (стр. 12 описания) + VREF-ы. И соблюсти последовательность их подачи (описана на той-же странице). В противном случае или не заработает, или может вообще сгореть. Последовательность подачи напряжений можно реализовать соответствующим включением стабилизаторов и выбором выходных емкостей, или взять стабилизаторы с сигналом разрешения, или ключи на выходе стабилизаторов. Еще у MAXIM есть специальные контроллеры для выработки всех напряжений на подобные ЖКИ. Тип не помню - посмотрите на их сайте. Но очень дорогие и плохо доставабельные. Хотя пару штук может как образцы пришлют. Еще есть вариант включить VDD, а потом _ОДНОВРЕМЕННО_ все остальные напруги. Правда такой вариант не для всех ЖКИ проходит. Но современные (разработки 2002 и позже по моим данным) это терпят.

Потом по цифровым сигналам.
На стр. 24 разрисована вся времянка весьма подробно. На страницу раньше - параметры сигналов.

Все сигналы завязаны на HCLK. Вернее на его передний фронт похоже (в 6-bit RGB все по заднему фронту). Соответственно в табличке временных параметров все сигналы даны относительно его. Это самый высокочастотный сигнал и соответственно все остальные генерятся просто из него. Единственное, я не нашел времени установки/удержания данных относительно HCLK. Но можно просто выдавать очередные данные по заднему фронту HCLK.

Вообще весь процесс отображения кадра начинается с переднего фронта сигнала STV (Vertical Start Pulse). Он сбрасывает внутренний счетчик строк ЖКИ в ноль.
Дальше через время STV_Setup_Time должен прийти передний фронт HCLK, но до этого за время STHR_hold_time до HCLK должен прийти фронт сигнала STHR, который соответственно сбрасывает счетчик пиксел строки ЖКИ в ноль. Правда в описании микросхемы похоже должен пройти спад импульса STHR до начала выдачи данных. Это нужно увы проверять опытным путем
Далее по переднему фронту HCLK данные 6-бит по каждому цвету (всего 18) защелкиваются во внутреннем сдвиговом регистре. К приходу фронта HCLK данные уже должны быть выставлены и стабильны.
После прихода 240 импульсов HCLK данные для строки готовы, и они сигналом... Ха! Ха-Ха-Ха! В описании действительно есть ошибочки! На времянке нарисован сигнал TP - это по логике сигнал LD интерфейса! По нему данные должны быть защелкнуты из сдвигового регистра в драйвер строки!
Вообще этим-же сигналом должен переключиться счетчик строк, но здесь есть некий сигнал CKV, который похоже это делает. Но его времянка (в частности сдвиги относительно STHR и LD) мне не очень понятны.
Сигналы реверса полярности REV тоже имеют интересную времянку, но похоже это связано со схемой на стр. 19. Короче придется подстраивать ...
Далее сигнал INV должен переключаться в противоположную полярность каждую строку импульсом STHR.
Ну и добавляете как нарисовано пустых импульсов по пикселам - до 254 и по строкам - до 327.
Кстати, в каждом очередном кадре сигнал INV должен иметь обратную полярность в одинаковых строках, так-же как и REV. Для этого число строк и сделано нечетным.

Вот пока все, что понял по описанию.
Удачи!

ЗЫ А кстати, где ЖКИ брали и сколько стоит, если конечно не военная тайна.

[Nixon]

Большое спасибо за столь обстоятельный ответ !!!

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

Экранчик привезли по случаю напрямую из юго-восточной Азии (в кармане). По цене - четверть московской (именно это и понравилось).

Управляющий чип LCC3600 по сути - контроллер разверток и ничего более. Поэтому и появилось желание сделать контроллер и драйвер "в одном флаконе" самим.

[Nixon]

Кстати, все продавцы, к которым мы обращались по поводу продажи TFT LCD, советовали покупать Sanyo - мотивируя это тем, что данная фирма поставляет и всю мелочевку для своих LCD - контроллеры, драйверы питания, разъемы и ост.
А с этим Samsung'ом, глядя на его разъем, я еще побегаю

[-=KiV=-]

Номиналы резисторов, которые обозначены NC теоретически должны быть одинаковы. Кстати, именно поэтому между некоторыми VREF стоят по одному резистору, а между некоторыми по два. Это теоретически. А практически одинаковыми _обязаны_ быть попарно - самый верхний и самый нижний, второй снизу и второй сверху и т.д. Попробуйте для начала поставить все по 47 кОм, а потом можете уменьшать где-то до 10 кОм. Эти резаки влияют на контраст и цветопередачу, поэтому все изменения будете видеть визуально.
Кстати, в описании очень верно замечено, что схема неоптимальна :D. Я применял ЖКИ, в которых вся приведенная схемотехника уже присутствовала, включая микросхему типа LCC3600. Так вот, там на плате обычно после этого резисторного делителя по каждому VREF стоял операционник в режиме неинвертирующего повторителя.

[Nixon]

Еще раз спасибо за помощь!!!

[-=KiV=-]

Еще раз о времянке сигналов: на разъем выведены сигналы драйверов ЖКИ. Надо просто найти описание микросхем драйверов. На них обычно дается более полная инфа.
Попробуйте на сайте самасунга поиск по ключевым словам "TFT LCD Driver IC". И просто выберите микросхему, похожую на те, что используются в этом ЖКИ. Я думаю это многое прояснит.

[DIM]

Еще раз о времянке сигналов: на разъем выведены сигналы драйверов ЖКИ. Надо просто найти описание микросхем драйверов. На них обычно дается более полная инфа.
Попробуйте на сайте самасунга поиск по ключевым словам "TFT LCD Driver IC". И просто выберите микросхему, похожую на те, что используются в этом ЖКИ. Я думаю это многое прояснит.

немного поработал с ЖКи от ноутбуков
в общем несколько наблюдений.

1. Смотреть на тип интерфейса - LVDS or TTL
с TTL просто (относительно).
2. Проще всего прикрутить серийный контроллер. Много от EPSON (S1dxxxx).
дороговаты. В питере ~20 USD. нужна EDO память!.
Был хороший со встроенной - сняли с производства.
3. По поводу времянок. У всех примерно одинаковые (но разные). По хорошему нужна документация.
4. Наступил на грабли с сигналом ENAB. для разных дисплеев имеет различный сдвиг относительно строчного импульса.
5. Хорошо разобрали все эти темы на форуме cooler.irk.ru и IXBT

[FPGA]

Большое спасибо за столь обстоятельный ответ !!!

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

Экранчик привезли по случаю напрямую из юго-восточной Азии (в кармане). По цене - четверть московской (именно это и понравилось).

Управляющий чип LCC3600 по сути - контроллер разверток и ничего более. Поэтому и появилось желание сделать контроллер и драйвер "в одном флаконе" самим.

Nixon, если не трудно, можно поподробнее о кадровом буфере: на чем и по какому принципу реализовано (FIFO, Dual Port RAM) и т.д.

[Nixon]

Кадровый буфер был внешний - 512k 10ns SRAM. На самом простом ACEX'е делался контроллер развертки и двухпотоковый конвейерный контроллер SRAM (один поток от хоста на запись или чтение SRAM, второй поток от контроллера TFT на чтение). В результате для внешнего хоста контроллер TFT представлялся в виде 60 ns SRAM (согласен не совсем оптимально, но мне этого было достаточно). Контроллер TFT и хост-контроллер имели возможность асинхронного доступа в кадровый буфер одновременно и независимо друг от друга.

[FPGA]

Кадровый буфер был внешний - 512k 10ns SRAM. На самом простом ACEX'е делался контроллер развертки и двухпотоковый конвейерный контроллер SRAM (один поток от хоста на запись или чтение SRAM, второй поток от контроллера TFT на чтение). В результате для внешнего хоста контроллер TFT представлялся в виде 60 ns SRAM (согласен не совсем оптимально, но мне этого было достаточно). Контроллер TFT и хост-контроллер имели возможность асинхронного доступа в кадровый буфер одновременно и независимо друг от друга.

Nixon, т.е. 2 микросхемы SRAM, так? И если так, то как вы обеспечивали идентичность содержимого буферов? Кстати, почему не совсем оптимально? На мой взгляд, очень удобная конфигурация.

[Nixon]

Микросхема SRAM одна. И кадровый буфер в ней всего один. По сути контроллер данной SRAM эмулировал двухпортовую память (разносил запросы от двух разных хостов по времени - SRAM то очень быстрая). Поскольку снаружи мы эмулировали интерфейс 60ns SRAM, то в эти 60ns элементарно укладывалось несколько реальных обращений к кадровому буферу, как от внешнего хоста, так и от внутреннего конроллера TFT. Специальной синхронизации по заполнению буфера и его отрисовке не делал за ненадобностью - при кадровой 50 Гц полное время заполнения буфера ~10 ms. Моргания не видно. Хотя сделать синхронизацию не трудно.
В общем лучше посмотрите исходник, будет понятнее

P.S. Насчет неоптимальности - если внимательно посмотрите, то увидите, что накладные временные расходы контроллера SRAM составляют не много ни мало 100%. Теоретически можно было бы их уменьшить хотя бы до 10-20%, усложнив для этого блок формирования тактовых частот.

Прикрепленные файлы

 controller.rar ( 1.98 килобайт ) Кол-во скачиваний: 346
 scheme.rar ( 36.69 килобайт ) Кол-во скачиваний: 313

 

[Shread]

Сам делал контроллер для TFT матриц, с интерфесами наблюдается достаточная однородность, не то что с STN и особоенно DSTN(с последними с каждой новой матрицей возникали проблемы, т.к сигналы формировались очень разнообразно). В первом проекте использовал Alter'у на 128 макроячеек, из семейства max3000+двухпортовую озу AL422 производства AverLogic. Альтера занималась формированием сигнала DE, для матрицы, к слову сказать, отличия интерфейсов матриц как правила именно этим сигналом и ограничиваются. Некоторые сами получают этот сигнал из синхроимпульсов. С цифровым интерфейсом цвета в основном все стандартно, т.е сколько-то бит на цвет(и два бита бывает) помножить на три(три цвета), в резултате в три раза больше ног вообще. Для работы с микроконтроллерами контроллер делался, количество цветов было ограниченно 16-ю(не было нужды в большем кол-ве), сопряжение с мк посредством SPI. Что касаемо LVDS, тут тоже все прозрачно, изначально сделать все под цифровой выход матрицы, а потом поставить преобразователи интерфейса, и все. Можно и по другому решить этот вопрос, если в едничных количествах использовать и расстояние в пол метра до матрицы устроит, то можно просто снять lvds драйверы с матрицы, и завести цифру напрямую, это будет выгоднее с экономической точки зрения.