Подскажите, потянет ли ATmega128 такой индикатор?
Я хочу купить себе ЖКИ, для этого решил даже сьездить в столицу (в Киев) и поискать там ЖКИ.
Я нашел пока только одну фирму, которая торгует ЖКИ по нормальным ценам.

Сначала я думал купить знакосинтезирующий ЖКИ, но потом посмотрел, что этот графический ЖКИ, даже дешевле знакосинтезирующих с большим количеством знакомест.

Страничка магазина с индикатором расположена тут http://www.flycont.com/html/graphic.html
Он второй в списке.

Я не нашел никакой документации на индикатор в интернете, кроме даташита с того же магазина. (в и-нете он тоже нашелся)
В даташите только одна страница, на которой есть физические размеры, распиновка разьема и ни слова о способе вывода информации на индикатор.
На рисунке в даташите показана структурная схема, где 5 контроллеров KS0086 управляют столбцами (SEG80) и еще два таких контроллера - строками (COM80).

Как я понял у контроллера индикатора нет памяти и его нужно обновлять постоянно.
Может у кого нибудь уже есть опыт работы с драйвером KS0086 ЖКИ?
Даташит на драйвер есть тут:
http://datasheet4u.com/html/K/S/0/KS0086_S...ronics.pdf.html

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

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

А вот собственно даташит на индикатор: (147Кб)

Я при помощи ATMega128 управлял индикатором 128х128. Процессор выполнял еще кучу функций (общение с АЦП, прием и посылка по COM и еще кучу внутренней логики). Никаких проблем не было.

А что если попробовать управлять цветным ЖКИ Color STN RGB - 1 бит на цвет (LM8M64 фирмы Sharp, 640х240), такие меги потянут? Интерфейс у него параллельный, по цене он даже дешевле, зато даташит на него есть толковый, что мне очень нравится. По моим подсчетам, на обновление всего экрана нужно потратить 57600 тактов (это без учета задержек)
А если обновлять его 25 раз в секунду, то это съест 1440000 тактов, тоесть около 2 MIPS (опять же без учета задержек)

У этого дисплея минимальное время обновления экрана составляет 17 мс (59 Гц), следовательно, на строку потребуется 17мс/244=70 мкс. За это время надо передать 90 байт вместе с клоком. На один байт получается 70/90=0.77 мкс. Для 16-мегагерцовой меги это составит примерно 12 машинных тактов.

Дальше, на весь экран потребуется 90*244=21960 байт, а значит - внешнее озу, и не менее 3 тактов на чтение и запись. Если выводить динамически, то возникнет ещё один вопрос, откуда брать информацию для следующего кадра, и хватит ли времени.

Вывод такой: 16-МГц контроллер будет занят под завязку, но попробовать стоит.

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

Но проблемма у меня в реализации обмена данными, может у вас есть наработки на таком ЖКИ?

Вопрос, для чего это все надо. Если нужно побыстрее запустить ЖКИ, то лучше выбрать другой (более интеллектуальный) ЖКИ. Если нужно потренироваться в программировании, то тогда и наработки не нужны :-)
Используйте SPI - это проще.
А передача данных - комплексный вопрос. Каких данных, с какой скоростью, с какой периодичностью.

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

Предположим, вы решили сделать управление дисплеем на отдельном контроллере. Предположим у вас 64 КБ внешней памяти, половина которой озу1 хранит данные текущего кадра, а вторая половина озу2 - следующего. Что должен делать контроллер дисплея каждые 0.7 мкс (порядка 12 машинных циклов (МЦ))?

1) принять байт извне в регистр2, скажем по спи (1МЦ).
2) разместить байт из регистра2 в озу2 по текущему адресу хранения (Z+) (4 МЦ).
3) прочитать байт из озу1 (Y+) в регистр1 (4МЦ).
4) выдать из регистра1 в дисплей вместе с синхроимпульсом (1 МЦ).

Итого, не менее 10 МЦ из 12 возможных. Как видите, особо не разбежишься. К тому же это необходимый минимум, так что без определённых хитростей не обойтись, скажем, объединение чтения из озу, выдача в дисплей и формирование строба.

Потянет ли по времени - это половина вопроса.
Второй вопрос, хватит ли памяти. Если вначале строить образ экрана в RAM, а потом передавать его в индикатор то потребуется 8000байт RAM памяти. Расчет простой, 1 пиксель - 1 бит. 400х160=64000 бит или 8000байт. Другими словами нужна внешняя RAM.
Если информация только текстовая, то в RAM храним коды отображаемых символов, а при выводе на индикатор на лету преобразуем их в изображения сиволов, используя знакогенератор, хранящийся в FLASH памяти программ. В этом случае внутренней памяти хватит, но зачем тогда использовать графический индикатор?

Тогда память будет внешняя, скорее всего двойного объема, для текущего и следующего кадра, для этого понадобится микросхема 640х480х3=460800 бит или 57600 байт. Я попробую поставить 128Кбайтное статическое ОЗУ, между двумя банками буду переключаться с помощью еще одного порта МК.

А поскольку на первые 255 байт памяти отражаются регистры контроллера, то буду использовать область памяти начиная с конца ОЗУ (1EFF - FFFF) и еще целых 7,749 Кбайт будет свободно в каждом банке.

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

Вы что такое курите, что приход такой? Как вы умножаете, и почему бы не начать с адреса 0х1100?