Всем доброго дня!

Есть хост - STM32F407VG (STM32F4Discovery), есть вот такой индикатор MD070SD:
http://imall.iteadstudio.com/md070sd-7-16-...tft-module.html
Даташит на него:
ftp://imall.iteadstudio.com/TFT%20LCM/IM1...IM130820001.pdf

В качестве интерфейса обмена этот ЖКИ использует 16-битную параллельную шину - интерфейс 8080, вместо управляющего контроллера - CPLD.

Подключал ЖКИ к Дискавери в режиме аппаратного и программного 8080. Для аппаратного подобрал следующие тайминги (пробовал разные, вплоть до максимальных):
Address setup phase duration = 2 x HCLK
Address-hold phase duration = 0 x HCLK
Data-phase duration = 35 x HCLK

В обоих режимах работает, НО в аппаратном режиме если передается цвет с более чем 10 логичсекими единицами подряд (например, белый цвет - 0xFFFF), начинается пропуск пикселей и "сдвиг" изображения. Если передается большая картинка, где много светлых цветов, CPLD зависает - изображение медлено "выцветает".
В программном же режиме, изображение может сдвигаться независимо от передаваемого цвета абсолютно безсистемно: на одних и тех же задержках изображение 3 раза сдвинется, а 5 раз отобразится нормально.

Кто-нибудь сталкивался с подобными проблемами? Возможно, есть способы решения?

Я подключал к STM32F207 контроллер S1D13706, аппаратно. Разрисовал на листе в клетку все временные диаграммы, и подобрал нужные значения для записи в регистры FSMC.
Нарушений работы не замечал. Изображение "выцветало", пока отлаживался. Зависал контроллер. И плохие контакты были в соединении ЖКИ с его контроллером, тогда всякие чудеса вылезали.
Если программно и аппаратно работают по-разному, скорее всего, заданы слишком оптимистичные временные характеристики в аппаратном режиме.
Хорошо бы для начала высокочастотным осциллографом сигналы посмотреть. Там же еще выбираются разные режимы работы, что у процессора, что у контроллера ЖКИ...

Что-то похожее у меня было на S1D13A05. "Слишком белый" цвет приводил к каким-то непонятным эффектам. Разбираться не стал, а просто умножил в своей палитре R,G,B на 0.95 или около того - проблема ушла.

Для аппаратного режима пробовал устанавливать максимальные тайминги. В итоге оставил такие, продолжая увеличивать которые результат лучше не становится. FSMC использую в режиме 1, тип памяти - SRAM. Другие режимы работы FSMC для записи информации в индикатор принципиальных отличий не содержат. В CPLD вообще нет никаких настроек, касающихся передачи и т.п. Ее инициализация включает только установку яркости подсветки


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

Наложение маски делают на те разряды, которых все равно нет. Зачем?

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

Высокое напряжение менялось -> геометрия...

Не совсем понял что Вы имеете в виду. Подразумевалось принудительное обнуление младших разрядов цветовых каналов. Т.е. для формата RGB565 что-то вроде:



Вряд ли, ведь с черным цветом проблем не возникает, а с белым есть проблемы только в аппаратном режиме и то пропускаются пиксели выборочно - некторые отображаются нормально. Цифровая электроника...


Поясните, пожалуйста.

Это и имел в виду. Если в вашем CPLD или готовом контроллере этих битов физически не существует, то как они могут на что-то влиять? И обнулять их незачем.

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

У меня работает похожий вариант: дисплей 16-битовой шиной подключен к матрице, которая либо сама гонит данные из SFLASH, либо транслирует их из FSMC контроллера (STM32F437). Тайминги для FSMC подбирал по осциллографу, чтобы более-менее уложиться в требования даташита контроллера дисплея (цикл шины - 145ns). Для CPLD задача была противополжная - успеть загрузить экран за 20ms. Никаких "слишком белых" проблем не отмечено...

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

Но тогда бы проблемы с белым цветом должны были обнаруживаться и с программной реализацией 8080. А источник питания и правда не ахти - питание от USB. К тому же на некоторых линиях данных висят еще и светодиоды. Но с другими LCD таких проблем из-за этого не возникало.


В аппаратном режиме рабочий цикл тоже более-менее выдержан согласно даташита - ~200 нс. В программном около 300 нс, меньше не получается.

попробуйте для пробы закормить от нормального внешнего источника, заодно измерьте потребление..

у меня связка голая BeagleBone+3.5"tft работали от USB до первого плотного обращения к графике - т.е. потребление было на границе допустимого и это 3.5", а у вас 7"

А всё ли питается от одного источника напряжения? Может, проблема в паразитной запитке через защитные диоды по входу? Есть ли возможность поставить резисторы на шину данных (22-47 Ом)?

Эксперименты с индикатором приоставновлены на неопределенное время. Появилась другая работа. Всем спасибо за помощь!


Как только снова займусь индикатором, попробую запитать от нормально внешнего БП. Согласно ДШ максимальное потребление микросхем модуля индикатора - 150 мА, подсветки - 500 мА. Большинство тестов проводил при яркости подсветки 50 %.


Напряжение питания микросхем модуля - 3.3 В, подсветки - 5 В. Оба напряжения заводил с платы Discovery. Соответственно 5 В шло от USB компа через диод, 3.3 В с выхода стабилизатора.