Помогите разобраться с lcd DG-32240 Опции

[alexsl]

Добрый день. Имеется индикатор DG-32240. Данный индикатор не имеет встроенного контроллера типа hd64646 или sed1335. На нем стоят только драйвера nt7086. Не могу найти схему подключения индикатора и контроллера.
За ранее спасибо.

[Itch]

А если нет контроллера, то чем собираетесь контролировать его и рисовать? AVR конечно потянет такое дело, но с трудом...

[alexsl]

А если нет контроллера, то чем собираетесь контролировать его и рисовать? AVR конечно потянет такое дело, но с трудом...

Вопрос заключается не чем рисовать, а каким образом, какие сигналы подавать на драйвера. Точнее какие - это в даташите на драйвера написано. Меня интересуют времянки этих сигналов. А еще лучше всего найти схему этого индикатора. Найти не как не могу. А с процессором проблем нет. Не потянет авр, возьмем арм.

[rezident]

Посмотрите даташит SG320240B, он вроде аналогом (по версии Компэл) DG-32240 является. Там кое-какие времянки имеются.
http://display.compel.ru/passive/passive_i...p?ser=SG320240B

[SergSit]

AVR не потянет. Покрайней мере на частоте 16Мгц. Проще, на мой взгляд, сделать схему управления на том же SED1335. Или на более мощном контроллере ЖКИ. На gaw.ru есть русское описание SED1335. А временные диаграммы надо искать в даташите на nt7086. На Google даташит есть. Там же, в даташите, есть примеры компановки LCD панелей. Судя по временным диаграммам, посмотрел одним глазом, SED1335 может им управлять. Недавно делал управления для LCD панели 400х160 точек, и тоже без контроллера LCD.

[alexsl]

AVR не потянет. Покрайней мере на частоте 16Мгц. Проще, на мой взгляд, сделать схему управления на том же SED1335. Или на более мощном контроллере ЖКИ. На gaw.ru есть русское описание SED1335. А временные диаграммы надо искать в даташите на nt7086. На Google даташит есть. Там же, в даташите, есть примеры компановки LCD панелей. Судя по временным диаграммам, посмотрел одним глазом, SED1335 может им управлять. Недавно делал управления для LCD панели 400х160 точек, и тоже без контроллера LCD.

Даташит я смотрел. Однако по нему мне непонятны некоторые моменты. К примеру из каких соображений выбирать частоту clk1? Не могли бы вы "на пальцах" объяснить принцип работы графического индикатора.

[SergSit]

Даташит я смотрел. Однако по нему мне непонятны некоторые моменты. К примеру из каких соображений выбирать частоту clk1? Не могли бы вы "на пальцах" объяснить принцип работы графического индикатора.

NT7086 это сдвиговый регистр на 80 разрядов. Т.е. чтобы получить матрицу точек 320 на 240 необходимо 4 регистра(4*80=320) на строку(для хранения одной строки). И 3 регистра(3*80=240) которые буду хранить номер строки в которую будут выводиться очередная строка из 320 точек. Фактически это тоже сдвиговый регистр по которому сдвигаеться логическая "1". Если она предположем, находиться в 33 разряде, значит информация из 4-х регистров отображиться в 33 строке ЖКИ. Данные вводяться на 4-х разрядной шине. C приходом CL2 данные записываются в строку и сдвигаються. Т.е чтобы записать 320 битов потребуеться 320/4=80 тактов CL2. Когда все данные помещены в строку приходит CL1, который разрешает отобратить строку и сдвигает "1" в регистр хранящий номер строки для отображения. После отображения всех строк приходит импульс кадра, который устанавливает строку для отображения №1. И все снова повторяется.
Частота определяеться просто. Для вашего случая. Если у вас 320 точек значит вам надо 80 тактов CL2. Минимальный период для CL2 из даташита 125нансек. Т.е для отображения строки понадобиться 80*125=10000нансек или 10мксек. Это и будет период CL1. Для кадра потребуеться 240*10мксек=2400мксек-2.4млсек. Это минимальные значения. Их можно увеличить.
Если хотите обеспечить частоту кадра 50Гц, то то для строки необходимо 20ms/240строк=84mks. Для загрузки одной тетрады потребуеться 84mks/80 примерно 1mks.
Если исходить их того, что величина такта AVR 62.5ns, то он за 1mks сможет выполнить, в лучшем случае, 1000ns/62.5ns=16 команд. Вывод AVR не сможет обеспечить необходимую частоту кадра. Не говоря о то, что выполнять другие задачи.
Это вкратце. Есть и нюансы.

[=GM=]

Для кадра потребуется 240*10мкс=2400мкс=2.4мс. Если хотите обеспечить частоту кадра 50Гц, то для строки необходимо 20ms/240строк=83мкс. Для загрузки одной тетрады потребуется 84мкс/80 примерно 1мкс. Если исходить их того, что величина такта AVR 62.5 нс, то он за 1 мкс сможет выполнить, в лучшем случае, 1000/62.5=16 машинных циклов (МЦ). Вывод: AVR не сможет обеспечить необходимую частоту кадра. Не говоря о то, чтобы выполнять другие задачи

Ну, вы тут погорячились немного с выводом. Время вывода одной тетрады из внешнего озу чисто программным способом составляет 5МЦ плюс 8 МЦ на формирование 4-х импульсов сдвига. Останется ещё 3*80=240МЦ=15 мкс от длительности каждой строки на другие задачи.

Но лучше сделать аппаратно на SPI, который может работать на половине тактовой частоты, т.е. на 8 МГц, обеспечивая побитную выдачу данных с соответствующими импульсами сдвига. Тогда половина времени строки (40 мкс) будет уходить на выдачу строки, а вторая половина (43 мкс) может быть посвящена другим задачам.

[alexsl]

NT7086 это сдвиговый регистр на 80 разрядов. Т.е. чтобы получить матрицу точек 320 на 240 необходимо 4 регистра(4*80=320) на строку(для хранения одной строки). И 3 регистра(3*80=240) которые буду хранить номер строки в которую будут выводиться очередная строка из 320 точек. Фактически это тоже сдвиговый регистр по которому сдвигаеться логическая "1". Если она предположем, находиться в 33 разряде, значит информация из 4-х регистров отображиться в 33 строке ЖКИ. Данные вводяться на 4-х разрядной шине. C приходом CL2 данные записываются в строку и сдвигаються. Т.е чтобы записать 320 битов потребуеться 320/4=80 тактов CL2. Когда все данные помещены в строку приходит CL1, который разрешает отобратить строку и сдвигает "1" в регистр хранящий номер строки для отображения. После отображения всех строк приходит импульс кадра, который устанавливает строку для отображения №1. И все снова повторяется.
Частота определяеться просто. Для вашего случая. Если у вас 320 точек значит вам надо 80 тактов CL2. Минимальный период для CL2 из даташита 125нансек. Т.е для отображения строки понадобиться 80*125=10000нансек или 10мксек. Это и будет период CL1. Для кадра потребуеться 240*10мксек=2400мксек-2.4млсек. Это минимальные значения. Их можно увеличить.
Если хотите обеспечить частоту кадра 50Гц, то то для строки необходимо 20ms/240строк=84mks. Для загрузки одной тетрады потребуеться 84mks/80 примерно 1mks.
Если исходить их того, что величина такта AVR 62.5ns, то он за 1mks сможет выполнить, в лучшем случае, 1000ns/62.5ns=16 команд. Вывод AVR не сможет обеспечить необходимую частоту кадра. Не говоря о то, что выполнять другие задачи.
Это вкратце. Есть и нюансы.

Спасибо за прояснение . Пойду по пробую запустить.

[SergSit]

Ну, вы тут погорячились немного с выводом. Время вывода одной тетрады из внешнего озу чисто программным способом составляет 5МЦ плюс 8 МЦ на формирование 4-х импульсов сдвига. Останется ещё 3*80=240МЦ=15 мкс от длительности каждой строки на другие задачи.

Но лучше сделать аппаратно на SPI, который может работать на половине тактовой частоты, т.е. на 8 МГц, обеспечивая побитную выдачу данных с соответствующими импульсами сдвига. Тогда половина времени строки (40 мкс) будет уходить на выдачу строки, а вторая половина (43 мкс) может быть посвящена другим задачам.

Не погорячился. Только поправлю сначала. Для выдачи тетрады нужен один тактовый импульс CL2. Вы не учли, что надо еще входить и выходить из прерывания. А это тоже 6-7МЦ на вход(мин)+ сохранить SREG при входе и востановить при выходе+выход из прерывания 4МЦ. Кроме того данные хранятся в ОЗУ байтами, как известно. Надо время извлечения нужной тетрады из байта извлеченного из ОЗУ. Кроме того надо время чтобы обработать счетчик точек и счетчик строк. Я пытался сделать это устройство на AVR. Не тянет он. Ужимал, учитывал каждый такт. Может я и ошибался. Максимум, что смог получить частоту кадра , что-то около 20 гц(надо вспоминать). Даже если использовать аппаратный SPI, то получаеться что он выдаст байт за теже 16МЦ.

[=GM=]

Не погорячился. Только поправлю сначала. Для выдачи тетрады нужен один тактовый импульс CL2. Вы не учли, что надо еще входить и выходить из прерывания. А это тоже 6-7МЦ на вход(мин)+ сохранить SREG при входе и востановить при выходе+выход из прерывания 4МЦ. Кроме того данные хранятся в ОЗУ байтами, как известно. Надо время извлечения нужной тетрады из байта извлеченного из ОЗУ. Кроме того надо время чтобы обработать счетчик точек и счетчик строк. Я пытался сделать это устройство на AVR. Не тянет он. Ужимал, учитывал каждый такт. Может я и ошибался. Максимум, что смог получить частоту кадра , что-то около 20 гц(надо вспоминать). Даже если использовать аппаратный SPI, то получаеться что он выдаст байт за те же 16МЦ.

Зачем входить и выходить? Вошли один раз, выдали всю строку и вышли. Зачем извлекать тетрады из байта, если можно хранить по одной тетраде в одном байте, понадобится 80*240=19200 байт внешней озу, смешная цифра, щас внешние озу только на 64КБ+ можно найти, ещё останется на второй кадр, один выводите, второй заполняете.

Вот код выдачи строки с частотой 50Гц, который надо повторить 80 раз. В регистре z находится указатель на кадровый массив, биты 3-0 ваша тетрада, бит4=0 - исходное состояние ноги CL2

Код

     ld   r16,z+    ;загрузим тетраду - 4MЦ
     out  portd,r16 ;и сбросим CL2 - 1MЦ
     sbi  portd,5   ;фронт CL2 - 2MЦ

Выдача тетрады занимает 7МЦ, на строку уходит 7МЦ*80=560МЦ или 35 мкс. Останется 83-35=48мкс на другие дела. Счётчик точек вам уже не нужен, счётчик строк у вас уже готовый, лежит в zl, в конце поставите сравнение zl c 240, если больше, то обнуляете zl. Ну и всё. При переходе на другой кадр просто заменяете весь регистр z, в смысле регистровую пару.

[SergSit]

Не додумал я. Не рассматривал такой вариант. А вариант похоже рабочий. Конечно надо все посчитать проверить. В моем варианте машинные циклы уходили, в основном , на обработку прерывания. В вашем коде неточность. Между отрицательным фронтом CL2 и сменной данных необходима задержка, в соответстыии с даташитом, минимум 30ns. Поэтому надо добавить команду CBI, что добавит 2МЦ. Но и сэтим дополнением свободного времени должно остаться достаточно))) Спасибо за науку. Как-нибудь попробую этот вариант. Результаты постараюсь выложить.
И еще поправочка- счетчик строк все рано нужен. Т.к. zl не отражает количество строк. Может вы имели ввиду регистровую пару Z?

[=GM=]

В вашем коде неточность. Между отрицательным фронтом CL2 и сменной данных необходима задержка, в соответствии с даташитом, минимум 30ns. Поэтому надо добавить команду CBI, что добавит 2МЦ. Но и с этим дополнением свободного времени должно остаться достаточно))) Спасибо за науку. И еще поправочка- счетчик строк все рано нужен. Т.к. zl не отражает количество строк. Может вы имели ввиду регистровую пару Z?

Ну я вам просто идею подкинул, а на тайминги даже не смотрел, только с ваших слов. Со счётчиком строк я чего-то намудрил, сначала думал хранить строки в 256-байтных массивах, потом передумал, в общем забудьте, вам просто надо после выдачи строки проверять (zh,zl) на предмет достижения конца кадра, это всего две команды.

[mse]

;О) Ну тут ещо вот что... Мелочь, конешно. ;О) для 320Х240 надо 9600 байт видеоозу(откуда он всё это богацтво будет лихо упихивать в ЛЦДшку). Соответственно, понадобится и ОЗУ для хознужд. Т.е. Надо варганить внешнее. Ещё такт. Плюс к тому, надо картинку формировать, а это достаточно затратное дело...Ну для растеризаццыи и собственно работы можно поставить второй МК, двухпортовое ОЗУ или арбитр на ОЗУ какой...;О)
ЦПЛДшка или ФПГАшка спасут гарантированно. СЕД1335 - тормоз ещо тот, ну и цена/доставаемость...
Т.е. реальные переспективы: ФПГА/ЦПЛД+ОЗУ, либо МК с контроллером унутре.

[=GM=]

... для 320Х240 надо 9600 байт видеоозу Надо варганить внешнее. Ещё такт. Плюс к тому, надо картинку формировать, а это достаточно затратное дело

Ну так, мы вроде четыре такта отвели под чтение из внешнего озу, посмотрите мой пост #14 (команда ld r16,z+), хотя на чтение достаточно три такта (по памяти). Так что 7 тактов на тетраду, это ещё много. Да и хранение видеоданных вроде бы обсуждали, пришли к выводу, что лучше хранить тетрадами, не надо паковать-распаковывать, память сейчас дешёвая, надо-то всего 20КБ на кадр. Такое впечатление, Сергей, что вы топик полностью не читали. Кстати, о каком формировании картинки вы толкуете?

ЦПЛДшка или ФПГАшка спасут гарантированно. СЕД1335 - тормоз ещо тот, ну и цена/доставаемость... Т.е. реальные переспективы: ФПГА/ЦПЛД+ОЗУ, либо МК с контроллером унутре.

Зачем ещё фпга, вроде бы пришли к тому, что в качестве контроллера графического дисплея 320х240 можно обойтись одним 16 МГц атмеловским МК, он будет больше половины времени простаивать. Ну а если взять 20 МГц клок, сами можете представить, что можно сделать...

[Антон Малыгин]

Похоже скоро мне ваш опыт наверное понадобиться..так как лежит дома безхозно экран 320*240. вот думаю на каком контроллере это сделать..т.к. вы все знаете что эти экраны идут без внутреннего контроллера. у меня написано на панели LSUBL6291A
у него на подсветку стоит люминесцентная лампа.
но при работе подсветка померла. вот и думаю что сдохла сама лампа или инвертор. как проверить лампу незнаю если честно, но думаю врядли обычной цешкой (мультиметром) это можно сделать.
А кстати ещё вопросик в оффтоп. почему все пишут на ассемблере?
Или код меньше получается? или просто привыкли все давно уже?
Или так как я пока только начинаю и пишу на Си, но с опытом люди понимают что Ассемблер эффективнее?

[mse]

Такое впечатление, Сергей, что вы топик полностью не читали. Кстати, о каком формировании картинки вы толкуете?

Не, не читал.
Ну как, какое формирование... Букевка "А" в знакоместе 8Х8 разложится на 8 байтиков(или 16 тетрад).
А если ещё есть какое графицкое изображение(график чего-то от чего-то) то вообще швах. Отрендерить изображение - нидецких ресурсов стоит.

Зачем ещё фпга, вроде бы пришли к тому, что в качестве контроллера графического дисплея 320х240 можно обойтись одним 16 МГц атмеловским МК, он будет больше половины времени простаивать. Ну а если взять 20 МГц клок, сами можете представить, что можно сделать...

от задачи зависит. Если рендеринг внешний, а этот АВР тока лопатой грузит, то да, справится(тока нужно как-нить двухпортовость обеспечить для внешнего или арбитраж по доступу к видеоОЗУ). Мож на малых скоростях смены инфы, тоже прокатит. А так, МАХ2 + те-же 32К и никакого геморроя. На рупь дороже(если не дешевле), так ещо нагрузить можно всякими прибамбасами логическими/скоростными. Дело вкуса, в общем.

[=GM=]

Не, не читал.
Ну как, какое формирование... Букевка "А" в знакоместе 8Х8 разложится на 8 байтиков(или 16 тетрад).
А если ещё есть какое графицкое изображение(график чего-то от чего-то) то вообще швах. Отрендерить изображение - нидецких ресурсов стоит

Надо бы читать, прежде чем отвечать, а то попадёте впроссак ненароком. Товарищ тему замутил на предмет построения графического контроллера, поскольку его ЖКИ имеет только драйвера. Вся тема крутится вокруг этого.

Если рендеринг внешний, а этот АВР тока лопатой грузит, то да, справится(тока нужно как-нить двухпортовость обеспечить для внешнего или арбитраж по доступу к видеоОЗУ). Мож на малых скоростях смены инфы, тоже прокатит. А так, МАХ2 + те-же 32К и никакого геморроя. На рупь дороже (если не дешевле), так ещо нагрузить можно всякими прибамбасами логическими/скоростными

Контроллер вроде занят 40% времени, остальные можно кинуть на приём данных следующего кадра. Зачем платить даже рубль, если можно не платить? Вверх предела нет.

[mse]

Надо бы читать, прежде чем отвечать, а то попадёте впроссак ненароком. Товарищ тему замутил на предмет построения графического контроллера, поскольку его ЖКИ имеет только драйвера. Вся тема крутится вокруг этого.

;О) Да я в курсе, чего он замутил. Проблема рендеринга и/или двухпортовости остаётся.
SED1335 как раз этим и болеет. Она прекрасно выводит данные из видеоОЗУ, но доступ к нему(ОЗУ) извне сопряжОн с такими издержками, что мама дорогая. Либо скорость(но фликкер по экрану), либо качество изображения(но динамической картинку можно назвать лишь с большой долей оптимизьма).
Не спорю, можно потрахаться и добиться относительной работоспособности. В случае с SED1335 это выливалось в перманентный опрос готовности или вывод прерывания с секретной ноги. Но полюбому, больше 10-12 БАЙТ в видеоОЗУ пропихнуть за один раз не получалось. А этот раз случается в конце строки. А если рисуем график в реальном времени. А если не один... Тоска, короче...
А в ФПГА, накрайняк, можно и простенький граф ускоритель замутить. И, при необходимости, цветность прикрутить. И аффтаматов всяких...В общем, дело вкуса и задачи. Мне пришлось с ФПГА связываться. И не пожалел. ;О)

[SergSit]

Дело движется)))) Вариант очень даже работоспособный и не надо ПЛИС. Хотя кому как нравиться или кому что надо. Кому красивости а кому и бюджетную разработку(с минимальной ценой). В моем случае ипользуеться ЖКИ 400Х160 точек. Для обеспечениячастоты кадра 50Гц необходимо строки выдовать через 125мксек. Немного подкоректировал код предложенный =GM= получил следующие результаты: строка выдаеться за 45мксек. )))))) Код для выдачи двух тетрад имееи вид
ld temp,X+
out Port_lcd,temp
cbi Port_lcd_upr, CL2
sbi Port_lcd_upr, CL2
swap temp
out Port_lcd,temp
cbi Port_lcd_upr, CL2
sbi Port_lcd_upr, CL2
Понятно что байт считаный из ОЗУ остается в регистре. Применив SWAP мы с энономили 2МЦ и главное теперь можно инфомацию хранить по байтно и т.д.
Согласен, что SED1335 еще тот тормоз. Этот вариант на AVR лишен главного недостатка SED1335 а именно плохого доступа к ОЗУ. Тк. контролер выдает информацию на ЖКИ из ОЗУ в прерывании. А остальное время контролер может делать с ОЗУ, что угодно)) Например формировать кадр, как и говорил =GM=.
Пытаюсь программу , выдающую строку, написать на СИ с ИАРом. Прихожу к выводу, что обработчик прерывания надо писать на асме а остальное на СИ. Задам вопрос к знатокам по оптимизации кода в ИАРе в соответствующем разделе форума. Может помогут.

[=GM=]

Дело движется)))) Вариант очень даже работоспособный и не надо ПЛИС.
Пытаюсь программу, выдающую строку, написать на СИ с ИАРом. Прихожу к выводу, что обработчик прерывания надо писать на асме а остальное на СИ

Я обычно оформляю ассемблерные подпрограммы так, чтобы можно было вызывать из Си. Тогда и прозрачно всё и отлаживать легко.

Вот подумал ещё, что для новых аврок можно вместо пары команд

cbi Port_lcd_upr, CL2
sbi Port_lcd_upr, CL2

поставить пару команд, которые дважды инвертируют CL2 (а в r17 заранее положить 0х10)

out pin_lcd, r17 ;инвертируем бит4
out pin_lcd, r17 ;инвертируем бит4 ещё раз

Вместо 8МЦ получится 4МЦ на две тетрады, т.е. экономия 4*50=200МЦ или 13 мкс.

[SergSit]

Написал программу выдачи строки на СИ и ИАР преоразует в ассемблер нужного вида.
А что значит "для новых аврок"? Где можно почитать про эту возможность? Но, насколько я понимаю, при исполнении этой команды остальные разряды порта будут установленны в "0". Если это так, то вариант не подойдет. Т.к. в порту еще используеться 3 вывода для формирования сигналов управления ЖКИ. Покрайней мере надо разбираться.

[=GM=]

Написал программу выдачи строки на СИ и ИАР преобразует в ассемблер нужного вида

Интересно. Взглянуть можно?

А что значит "для новых аврок"? Где можно почитать про эту возможность? Но, насколько я понимаю, при исполнении этой команды остальные разряды порта будут установленны в "0"

Нет, не так. Только запись 1 приводит к инверсии, а 0 ничего не даёт. Недавно было обсуждение вот здесь. Начиная с поста #64. И пораньше - здесь.

[SergSit]

Да посмотреть можно. Выкладываю проект для ИАРа. Про новую фичу незнал. Спасибо.

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

 lcd_400160_avr.rar ( 36.09 килобайт ) Кол-во скачиваний: 128

 

[=GM=]

Про новую фичу не знал. Спасибо

Ну так, работают люди...кодируют помаленьку(:-)

Выкладываю проект для ИАРа

Несколько вопросов по сишному коду.

1) Как так получилось, что оператор "temp=*point_ram_video++" переходит в "ld r16,x+"? А если нужно использовать регистровые пары Y и/или Z, что надо сделать? Или здесь есть определенные ограничения?

2) Откуда взялась функция __swap_nibbles(temp)?

3) Почему надо использовать CL2_1 вместо setbit(port,CL2), а не просто port |=(1 << bit)? В чём тут интерес? Или чем чудней, тем модней(:-)? (Это не к вам, это общее замечание, у вас замечательно всё получилось, вообще я поражён, как оказывается точно можно на си отобразить желаемый ассемблерный код)

[SergSit]

По пунктам.
1. Как получилось не знаю))) Это вопрос к компилятору. Насколько знаю, ИАР регистровую пару Y отводит под указатель стека данных. Поэтому он не использует ее для пользовательские нужды. А алгоритм использования X, Z не знаю. По идее ИАР их использует по очереди. Если создать еще один указатель, то это будет Z. Но это из области предположения.
2. В составе ИАР есть файл intrinsics.h. В этом файле есть уже готовые функции. Вся информация есть в помощи.
3. Так просто, для меня, удобочитаемо. И меньше писанины)
Честно тоже поражен))) Какой замечательный ИАР. Может воплотить задуманное)).