Форум РадиоКот

Добрый день. Возникла необходимость работать с TFT дисплеем NL2432HC22-41K. Как выяснилось он не имеет встроенного контроллера. по сему возникает вопрос. Каким образом программировать подобные дисплее. Буду благодарен если поможете разобраться с принципиальным отличием от TFT с контроллером, а также с начальной инициализциией.

Вот же первая ссылка из гугла, даташит на этот дисплей: http://www.farnell.com/datasheets/68773.pdf Читаете и вникаете, там всё расписано. Беглый осмотр привёл меня к мысли, что в этом дисплее развертка как в телеке, там даже две синхронизации: горизонтальная и вертикальная (со всеми таймингами). Только развёртываются вводимые параллельно данные, для этого три группы входов (для каждого цвета видимо) по шесть битов (разрядность одного цвета видимо).

Ох не потянет ARM с частотой 5 МГц на 18-ти пинах данные выставлять, не потянет. Хотя если через DMA слать... то может быть.

Я если честно никогда не работал с LCD без контроллера. Я собирался с этим LCD работать по SPI на не по 18 выводам. Обычно у LCD c контроллером отправляешь в виде команды положение пикселя который хочешь прорисовать и все. А как тут управлять работой абсолютно не понимаю. Как инициализировать понял, как отправлять данные понял. Но куда и как управлять его параметрами не имею понятия(

А почему 5 MHz? ведь STM32F4 может 168Mhz спокойно выдавать

надо глядеть в сторону 8279 (кр580вв79).
У ЖКИ надо не менее 50 раз в секунду менять полярность на инверсную.
Иначе они быстро деградируют.

Foxek писал(а):Как инициализировать понял, как отправлять данные понял. Но куда и как управлять его параметрами не имею понятия(

значит контроллер всё-таки есть.

ну какой то судя по всему есть, но из команд там только POwer ON, Power Off, Standby, Wake Up. А все остальное черт знает где. Команды выставления яркости, положения рисованного пикселя?

Foxek писал(а):Команды выставления яркости, положения рисованного пикселя?

Вы почитали даташит, на который я ссылку давал? Нет таких команд вообще. В этом дисплее используется развёртка как в электронно-лучевой трубке.

Знаете как обычный кинескоп у телека работает? Вот здесь такая же система. На входы D00-D05, D10-D15, D20-D25 подаётся яркость точки, которую драйвер гоняет по всему экрану, как луч в ЭЛТ. На вход CLK подаётся тактовый сигнал, который смещает точку вправо по строчке, а потом вниз на строчку в начало строчки (на странице 17 показана схема обхода луча). Параллельно с переходом на новую строчку должен подаваться сигнал VSYNСK, а при возвращении с последней на первую строчку сигнал HSYNCK (диаграммы приведены на 19 странице).

Foxek писал(а):Я собирался с этим LCD работать по SPI. Обычно у LCD c контроллером отправляешь в виде команды положение пикселя который хочешь прорисовать...

Этот дисплей принципиально другой.

bad2cat писал(а):надо глядеть в сторону 8279 (кр580вв79).

Здесь это вообще не в тему, на мой взгляд.

Удивительно, как некоторые товарищи приспособились эксплуатировать других.
Сами документацию не читают, а ждут когда это сделают другие и расжуют им бесплатно.

Foxek писал(а):Добрый день. Возникла необходимость работать с TFT дисплеем NL2432HC22-41K. Как выяснилось он не имеет встроенного контроллера.

Там обычный типичный контроллер с последовательным доступом.
И НЕ МОРОЧЬТЕ ЛЮДЯМ ГОЛОВУ. Не хотите разбираться сами - не ждите что вам это разжуют другие.

B@R5uk писал(а):Ох не потянет ARM с частотой 5 МГц на 18-ти пинах данные выставлять, не потянет.

Судя по времени включения и выключения пикcеля (Ton-Toff), реальная частота дисплея 30 кадров в сек. Загонять-то можно и все 60, но только с целью дитеринга пикселов.

Учитывая, что 5 Мгц - это частота интерфейса дисплея, кол-во точек 320х240 = 0,077 Мp, то вгонять по интерфейсу можно со скоростью 65 цветных кадров в секунду.
Контроллер данного дисплея хранит картинку как обычно, т.е. вогнали кадр и смотрите. Учитывая, что например STM 32 может работать на 32 МГц (L0,L1,L4 - ARM-Cortex-M0+), и даже на 80 (F0,F1,F4) и новые ещё выше на 216 МГц (F7 - ARM-Cortex-M7), а тратить нужно только 5 МГц из них (максимальная частота ввода для 65 кадров в сек), то любой ARM из этих справляется легко.

Учитывая, что в реальности, даже например для осциллоскопа или спектроскопа, требется всего 10-15 кадров в секунду, то затраты на обновления дисплея ниже ещё в 4-6 раз. Т.е. вообще не являются проблемой.

Кстати о DMA.
1.Оно требует накладных расходов по подготовке данных.
2.Занимает шину процессора (не знаю как в STM 32, но в старых процах, оно подвешивало и сам проц а не только интерфейс проца)
3.Используется в скоростных процессах (те, которые быстрее возможностей CPU в подготовке данных), когда проц не успевает.
В данном случае проц работает на 32 МГц, а требуется для обновления 10 кадров в секунду только 1 Мгц. А смысл его использовать?

bad2cat писал(а):Учитывая, что 5 Мгц - это частота интерфейса дисплея, кол-во точек 320х240 = 0,077 Мp, то вгонять по интерфейсу можно со скоростью 65 цветных кадров в секунду.

По точкам считать нельзя. Переход на новую строчку происходит не сразу после записи последнего пикселя предыдущей строчки. А запись пикселей происходит не сразу после перехода на новую строчку. Смотрите тайминги на странице 19 и таблицу на странице 18. Эффективная ширина экрана с точки зрения отсчётов CLK получается не 240 пикселей, а целых 256, а эффективная высота не 320, а 324. Вот и считаем: 5 МГц / (256 * 324) = 60,28 Гц

bad2cat писал(а):Учитывая, что например STM 32 может работать на 32 МГц (L0,L1,L4 - ARM-Cortex-M0+)

Lx -- это с пониженным потреблением. У них флэш работает очень медленно. Реально, на 32 мегагерцах летает только периферия, а сам процессор эффективно работает на 16 МГц, благодаря задержке в один цикл на чтение NVM. Прочитайте про это в этом мануале на STM32L0x3 на странице 70 в разделе Relation between CPU frequency/Operation mode/NVM read time.

bad2cat писал(а):Контроллер данного дисплея хранит картинку как обычно, т.е. вогнали кадр и смотрите.

Забавно. Тогда это серьёзно облегчает работу с дисплеем. Но что-то меня берут сомнения. В даташите про это есть где?

bad2cat писал(а):а требуется для обновления 10 кадров в секунду только 1 Мгц.

Хотите сказать, что CLK в этой дисплей можно загнать какой угодно, а не 5 МГц? Вроде чётко чёрным по белому написано: минимальная частота CLK 4,81 МГц, а максимальная 5,12 МГц. На 18-ой странице таблица.

B@R5uk писал(а):5 МГц / (256 * 324) = 60,28 Гц

А теперь пересчитайте с частотой 5,12 МГц. Не занудствуйте, речь о разах, а вы мелочь считаете.

B@R5uk писал(а):Lx -- это с пониженным потреблением. У них флэш работает очень медленно. Реально, на 32 мегагерцах летает только периферия, а сам процессор эффективно работает на 16 МГц, благодаря задержке в один цикл на чтение NVM.

Питание STM от 1В до 3,2В. Сниженное питание от 1,95 и ниже. Какое питание у дисплея?
Ну даже при скорости флеши в 16 МГц - это очень быстро.

B@R5uk писал(а):

bad2cat писал(а):Контроллер данного дисплея хранит картинку как обычно, т.е. вогнали кадр и смотрите.

Забавно. Тогда это серьёзно облегчает работу с дисплеем. Но что-то меня берут сомнения. В даташите про это есть где?

не знаю, вас хотел спросить - сам сомневаюсь

B@R5uk писал(а):

bad2cat писал(а):а требуется для обновления 10 кадров в секунду только 1 Мгц.

Хотите сказать, что CLK в этой дисплей можно загнать какой угодно, а не 5 МГц? Вроде чётко чёрным по белому написано: минимальная частота CLK 4,81 МГц, а максимальная 5,12 МГц. На 18-ой странице таблица.

Вы поняли о чём речь? О виртуальной частоте. Это как парциальное давление. Здесь это парциальная частота. Т.е. сколько тактов займёт обработка интерфейса данного дисплея (без подготовки данных, а это может занять и в 10 раз больше - отрисовка линий, подсчёты, вычисление Z-буфера пространства и т.д.).
Но вас я понял, действительно я пропустил мин F. Тут есть 2 варианта.
1. плохой - т.е. требуется постоянная поддержка изображения (это врядли), как регенерация в дин.памяти или аналоговой памяти , как в микросхемах звука для автоответчиков.
2. чуть лучше. частота требуется только для интерфейса, так как тактируется изнутри (как RS-232 без синхронизации, только паралельный).
Во втором случае, можно загнать один кадр (по медленному интерфейсу 5 МГц) и смотреть его сколько угодно времени без регенерации.
Или загонять 10 кадров в секунду (т.е. около 8 тыщ записей 18 бит каждые 100 мс. Общее время занятости проца на интерфейс составит 16%).
Хотя на скорости 32 МГц запись 0,77 Мp должна занять всего 2,4% времени проца. Это смотря как организовать вывод данных.

Я нигде не нашёл про то, можно ли выключать CLK или VSYNCK/HSYNCK. Допустим нельзя, что тогда? Как вы предлагаете генерировать CLK, таймером? Как тогда синхронно с CLK выдавать данные и синхронизацию на пины МК, в прерывании?

А ведь ещё нужно время, на то, чтобы прочитать в оперативке данные очередного пикселя и закинуть их в GPIO. Допустим чтение займёт 1 такт, GPIO в STM32 16-битные, значит закидывание займёт 2 такта. Я не программировал STM32 на ассемблере, поэтому не знаю, можно ли закинуть в порт два младших байта регистра CPU, а потом два старших байта этого регистра. Если нет, то ещё один так потребуется на сдвиг данных для вывода в другой порт. Уже 4 такта CPU только для вывода означают, что его частота должна быть в разы больше, чем 5 МГц. А времени на "другие дела" пока не остаётся.

Это всё если без DMA.

А ещё посмотрите на тайминги на странице 20 и подумайте, к чему приведёт неодновременный вывод данных в порты? Какой может быть максимальная задержка между выводом данных в два порта, чтобы удовлетворить временным требованиям на установку и удержание данных?

Н-дя
У меня версия, что хранение данных пикселей происходит в этих самых пикселях.
т.е. контроллер ЦАПует входные данные в 3-и ячейки одного пикселя, и на этом его функция оканчивается.
на 21-й странице видно что период сериального входа меняется от 450 до 100 нс. Т.е. управление как бы существует паралельно от изображения.
А изображение существует целиком только в аналоговом виде.

Странно тогда, что в документации нет времени отображения одной ячейки, по типу времени регенерации дин.памяти.

Нет, изображение в цифровом виде. Во всяком случае подаётся в дисплей в цифровом по 18-битному параллельному каналу.

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

B@R5uk писал(а):Нет, изображение в цифровом виде. Во всяком случае подаётся в дисплей в цифровом по 18-битному параллельному каналу.

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

Чё-та вы не врубаетесь. Пива попили ?
Я же тоже самое говорю.
подаётся в цифровом, ЦАПуется и хранится в аналоговом виде в пикселях (несколько десятков мс, например 30). Это моё предположение. Контроллер паралельно управляется по сериальному входу. Вобщем я повторяю свой пост ещё раз.

Я и представить не мог насколько это гемморный LCD. то есть по SPI его вообще нереально программировать, а если нужно еще выполнять прочие достаточно затратные для ядра действия, то вообще не прокатит?

Гуглом "stm32 rgb lcd".

Foxek писал(а):а если нужно еще выполнять прочие достаточно затратные для ядра действия, то вообще не прокатит?

Я так посмотрел мельком тему, и не нашел упоминаний конкретного мк, просто ф4. Поэтому бери stm32f427 или 429, у них есть встроенный контроллер как раз для подобных экранов. Будет работать вообще не занимая ядро, быстро и красиво.

Про stm32f427 интересная мысль.
Если графики много и она меняется каждый кадр, то вариант, где данные шлются сразу микроконтроллером на дисплей очень хорош. Дополнительный контроллер дисплея будет лишь тормозить апдейт. Потому как когда графики много, то сразу хочется воспользоваться апаратными возможностями по блендингу картинок. И все равно придется SRAM ставить для графического буфера в котором это все будет рендериться.

PS: Похоже наиболее правильный способ в этом разобраться - это купить STM32F429-DISCOVERY Там как раз дисплей, который по этому протоколу общается. Это интересно, потому как можно будет после этого использовать дешевые дисплеи от планшетов/телефонов напрямую.