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

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

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

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

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

Даташит я смотрел. Однако по нему мне непонятны некоторые моменты. К примеру из каких соображений выбирать частоту 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 не сможет обеспечить необходимую частоту кадра. Не говоря о то, что выполнять другие задачи.
Это вкратце. Есть и нюансы.

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

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

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

Не погорячился. Только поправлю сначала. Для выдачи тетрады нужен один тактовый импульс 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, в смысле регистровую пару.

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

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

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

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

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