Графический дисплей LCD 12864 (128x64 пикселя) на ST7920

[slav0n]

[uquote="afz",url="/forum/viewtopic.php?p=4098341#p4098341"]Какие картинки? С фото возиться не хочу, дорожки там, частично, идут по второй стороне. И что неясного в том, что концы подковы потенциометра коротко звонятся на VDD и VSS, а лвижок, не менее коротко, на V0?[/uquote]
бухой?

[afz]

Чтото мне совсем не нравится этот дисплей в зелено-черной версии. Я таки добился того, чего хотел - чтобы почти не было видно неактивных пикселов (новый дисплей светил неактивные пикселы светло-серым,"вполнакала", а активные - темно-серым).Сейчас - да, неактивные почти не видны, только этот самый "темно-серый" на самом деле не особенно темный, картинка все равно малоконтрастная. Удвоенного напряжения на VOut тоже не нашел, там в точности VDD. Конечно, может быть, какринка малоконтрастная оттого, что напряжение с USB идет не 5.0, а 4.7 (просаживается?). но, по-любому, фотки с сине-белыми картинками смотрятся гораздо лучше.

Для пробы перенес это дело на другой комп. Напряжение VDD получилось 4.9В, опять прорезался фон из невыбранных пикселей. Блин, этой дряни еще и питание надо ХОРОШО стабилизировать...

[GoldenAndy]

afz, Моя думать, что стабилизировать надо напряжение контраста , а не питания.
Можно, например, для не-батарейного применения накачать вольт 6 дросселем, стабильнуть стабилитроном 5.1 вольта + последовательно диод 4148 (термокомпенсация) - и дальше это напряжение шимом гнать в пин контраста

[slav0n]

у меня на синем контраст ​4.08 вольта
городить такой огород не имеет смысла

[afz]

Убрал подальше ардуиновские шнурки, взял разъем IDC-40, взял хороший полуметровый ленточный кабель 6 проводов, распустил ему концы, с одной стороны зарядил и прорезал в нужные ноги IDC-40, надел его на дисплей одним рядом, с другой стороны обжал 6 одиночных контактов DuPont, подключил к Ардуинке, теперь можно свободно взять работающий дисплей в руку и подрегулировать.

Так вот. Зелено-черный дисплей - бяка. Крутишь этот потенциометр, одновременно изменяется яркость фона и яркость изображения. Фон светлеет, изображение сереет. Когда фон становится почти не видным, изображение становится серым. Когда фон виден сильно, изображение темно-серое. То есть, это не контрастность в истинном смысле, а что-то левое.

[GoldenAndy]

afz, У черного-на-зеленом есть плюс - в отличие от белого-на-синем, информация видна и без подсветки.
А касательно контраста - вполне нормальный там контраст.


И мне он больше нравится, нежели бело-синий

[afz]

shads, возвращаюсь к вашему сообщению от 29 июня 2016 (страница 6).

Либка получилась достаточно компактная, помоему около 1-2 кило, даже на мега8 можно легко развернуться...

Вы ее, похоже, убрали с форума, но я в свое время ее утянул и сохранил. Так вот, наконец-то, дошли до нее руки и я переделал ее на SPI - сначала сменил ноги на ноги аппаратного SPI, а затем заменил программный SPI аппаратным. Все получилось в лучшем виде, при кварце 16 мГц и делителе 64 частота получилась 250 кГц, одна полная передача трех байтов занимает 96 мкс, что не намного дольше заявленных 72 мкс для 7920. То есть, оно, конечно, выводит медленнее, чем на предельных 72 мкс, но, практически, незаметно. Ну, и один байт передается 64 * 8 = 512 тактов, т.е. передачу спокойно можно делать в прерываниях, даже в программе на Си.

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

Да, с трудом удерживаюсь от желания переписать всё это на асме - тот же диалог с I2C прекрасно укладывается на аппарат сопрограмм, да и выдача по SPI тоже, а на Си такое не сделаешь...

Добавлено after 1 hour 1 minute 51 second:

Вы ее, похоже, убрали с форума, но я в свое время ее утянул и сохранил.

А, нет, недоглядел, лежит она, на стр. 7, сообщение от 12 июня 2017.

[GoldenAndy]

afz, как показывает практика, эти дисплеи держат SPI до 1.75 МГц (по паспорту 1.66(6) МГц макс).
Я игрался на СТМке с шагом 250 кгц. На 2 МГц уже начнаются глюки.
Для АВР, где делитель SPI - это 2,4,8 или 16, оптимальным был бы кварц 12 мгц. Тогда При делителе 8 SPI будет молотить на 1.5 МГц.

Тогда можно дергать прерывание от таймера каждые 75-80-85 мкс, а в прерывании уже отдавать 3 (6) байта по SPI. Если SPI работает на 1.5 МГц, то байт будет уходить за 0,66*8 = 5.33 мкс. Это 64 такта МК. В принципе, даже с ожиданием флага готовности, можно считать , что один байт уходит за 6 мкс.
Нужно отправить 3 или 6 байт (зависит от команды). Это 18 или 36 мкс. Ну плюс 5 мкс на вход/выход из прерывания. (я прореализацию на Си. На асме можно оптимизироваться сильнее)
Итого, голая отправка данных из прерывания таймера - это от 23 до 41 мкс.
Перывание молотит раз в 80 мкс.
Т.е. половину времени МК проводит в прерывании.

Много это или мало? Для каких то сверхзагруженных реалтаймовых устройств - много.
Для простых бытовых устройств типа часиков, таймера и прочего - с головой хватает.

[slav0n]

та шо ж вы эту индикацию с ног на голову ставите?
нафига ее разгонять, если для человека достаточно всего 25 Гц максимум

[afz]

Тогда можно дергать прерывание от таймера каждые 75-80-85 мкс

На фига здесь нужен таймер, и на фига высокая скорость SPI? SPI настроен на 32 мкс, каждое прерывание от него посылаем очередной байт трехбайтовой последовательности, и все. Остальные преобразования делаем уровнем выше, по сигналу от драйвера SPI. Грубо говоря, SPI сам себе таймер. И пусть прерывания от него идут втрое чаще, чем были бы от таймера, все равно одно прерывание в 512 тактов - это немного. А дальше - все просто. Получив отметку, что три байта по SPI отправлены (и, если надо), генерим следующие 3 байта и отдаем их драйверу SPI. Тот, когда будет готов, снимет их в свою память, и начнет передавать, отметив, что можно генерить следующие три байта. Как-то так, без деталей, конечно.

[GoldenAndy]

afz, Т.е. какой то внешний движок должен отслеживать, что СПИ отстрелялся и бегом-бегом готовить данные...
--
Я поступил у себя немного по другому. Есть видеопамять и несколько флагов.
А драйвер в прерывании таймера обрабатывает эти флаги и обновляет, при необходимости, только те строки, которые поменялись. Внутри там конечный автомат. Все остальное время прерывание по таймеру не делает ничего.

но тут уже сколько людей - столько и путей.

[afz]

А касательно контраста - вполне нормальный там контраст.

Значит мне достался не совсем удачный экземпляр дисплея. Или я его чем-то подпортил...

Т.е. какой то внешний движок должен отслеживать, что СПИ отстрелялся и бегом-бегом готовить данные...

Для таких задач я, обычно, клепаю собственную простенькую ОС РВ. Есть таблица задач, диспетчер ее постоянно просматривает. Если нашлась задача, готовая к выполнению, она выполняется, после чего возвращается в диспетчер. Все задачи предельно короткие, выполняются очень быстро. Если надо чего-то подождать, вызывается таймерная задача, которая прописывает таймер на заданное время, и опять же уходит в диспетчер. Если устройство батарейное, то последней задачей (с минимальным приоритетом) ставится задача Idle, которая переводит процессор в Sleep-mode.

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

[GoldenAndy]

afz, У каждого свой сложившийся подход к построению программ.
У меня, в основном, это большой мегацикл 1000 раз в сек.
А в нем отслеживание событий от периферии и реакция на них. Плюс временнЫе задачи.

Касательно дисплея - у меня сделано так, что основная программа вообще не знает про дисплей ничего.
У дисплея есть свой драйвер, который надо пинать по таймеру каждые 80 мкс. Для основной программы из драйвера доступны 2 функции - включить/выключить пиксель и очистить дисплей.
Все остальное реализовано внутри драйвера на конечном автомате. Мне такой подход удобнее.
Достаточно подключить драйвер к основной программе, отдать ему процедуру записи байта в дисплей и дергать его каждые 80 мкс.
А вся логика написана один раз и работает.

[slav0n]

а я просто выделил кило рамы видеобуферу и постоянно вывожу его на дисплей в мейнлуп без пинков и привязки ко времени

[WiseLord]

[uquote="slav0n",url="/forum/viewtopic.php?p=4101603#p4101603"]а я просто выделил кило рамы видеобуферу и постоянно вывожу его на дисплей в мейнлуп без пинков и привязки ко времени[/uquote]
Крайне неэффективно. И память отъело, и огромная часть процессорного времени занята подвисанием в задержках дисплея в главном цикле.

[slav0n]

возражу.
это крайне эффективно, универсально и никаких подвисаний
цена - кило рамы

докази:
http://primuss3.com/forum/index.php?board=8.0
http://primuss3.com/forum/index.php?board=35.0

[WiseLord]

Если видеобуфер отсылается на дисплей в главном цикле, то нужно отправить 128*64/8 = 1024 байта только данных, плюс ещё на порядок меньшее число команд. Любая запись в дисплей требует паузы порядка 60мкс, т.е. в Вашем варианте, грубо, обновление экрана будет длиться около 70мс. То есть, отрабатывается, максимум, 13 главных циклов в секунду.

Это при том, что, из 60мкс, требуемых для записи байта в дисплей, на собственно запись (в порт + строб) нужно 1..2мкс, а остальное - просто бесполезное ожидание.

[GoldenAndy]

Народ. Маленький вопрос. У вас есть проекты, где вы напрямую рисуете в дисплее без видеобуфера в ОЗУ?
(ну да, я понимаю, если Мега 8 - там озу всего кило)

[slav0n]

Если видеобуфер отсылается на дисплей в главном цикле, то нужно отправить 128*64/8 = 1024 байта только данных, плюс ещё на порядок меньшее число команд. Любая запись в дисплей требует паузы порядка 60мкс, т.е. в Вашем варианте, грубо, обновление экрана будет длиться около 70мс. То есть, отрабатывается, максимум, 13 главных циклов в секунду.

ну, и шо?

[afz]

Крайне неэффективно. И память отъело, и огромная часть процессорного времени занята подвисанием в задержках дисплея в главном цикле.

Зависит от. Если все делать ТОЛЬКО в прерываниях, то этот цикл вполне заменит собой обычную Idle многозадачки. Ну, и если вместо тупого ожидания циклом _delay (то есть считая количество прохождений эттого цикла, пока не пройдет нужное время), совместить этот подход с моим, то есть организовать там просмотр флажков и вызов некоторых процедур по значениям этих флажков, то может получиться довольно прилично...