Дисплей LCD Nokia 6100 и AVR

[ua1arn]

1) Взять атмега644.
2) ARM

[B@R5uk]

Наращивать вычислительные ресурсы -- это как вариант. Я пока обрезал таблицу знакогенератора до 160 символов:



А вообще, вот так вот повозившись, начинаешь понимать всю мощь специализированных ЖКД со встроенным знакогенератором. А если ещё и знакогенератор программируемый...

[GARMIN]

Прикинул занимаемую память 3,25 КБ -- 36% от ПЗУ ATmega.

Никто не запрещает использовать сжатие RLE. Знакогенератор уменьшается в объёме раз в десять.

[B@R5uk]

GARMIN, скажите, пожалуйста, на символах какого размера вы пробовали применить RLE? Как боролись с тем, что изображения символов кодируются последовательностями бит различной длины? Сколько бит выделяли на хранение длины повторяющихся битов?

[GARMIN]

Сейчас нет под рукой проекта, но в старом наброске 21 символ 80*40 пикселей занял 5000 байт вместо 67000.
Для генерации шрифтов использовал программу "LCD Image Converter" https://code.google.com/p/lcd-image-converter/
Там всё в описании. Один байт на команду. до 127 бит в одной команде. Использовал битовую маску.

[B@R5uk]

Запилил я таки знакогенератор. Работает в кодировке CP-1251, символы — что на табличке выше:



К сожалению, на моём дисплее последние два столбца пикселей не отображаются (верхние две строки, видимо, тоже). Но память под них внутри есть.

Так же сделал цифровую матричную клавиатуру и подключил к этому же МК:



В связи с чем появилась возможность поиграться с внутренними настройками контроллера S1D15G10. В результате экспериментов я получил следующие данные.

Команда DATCTR. В первом параметре бит P12 реально имеет инвертированное значение относительно указанного в даташите. То есть при P12 = 1 запись в область памяти, заданную командами PASET и CASET, происходит по столбцам, а при P12 = 1 — по строкам. Биты P10 и P11 определяют направление нумерации пикселей дисплея, соответственно, в строках и в столбцах. Нумерация всегда начинается 0 и заканчивается 131. То есть, если P10 = 0, то начало координат находится в верху экрана (верх экрана — это там где разъём), и пиксели нумеруются сверху вниз. А если P10 = 1, то начало координат — внизу экрана, нумерация, соответственно, происходит снизу вверх. Если P11 = 0, то начало начало координат находится слева, а нумерация пикселей — слева направо. Если же P11 = 1, то начало координат — справа, и пиксели нумеруются справа налево. Важно заметить, что действие эта команда оказывает не сразу на изображение, уже имеющееся в памяти контроллера, а только на изображение, которое будет записываться в память контроллера после этой команды. Фактически, команда просто изменяет адресацию памяти для команды записи RAMWR.

Вот как это выглядит на практике: {чуть позже допишу}

Команда VOLCTR. Управление напряжением действительно предоставляет возможность регулировать яркость и контрастность дисплея в довольно широком диапазоне. Первый параметр команды осуществляет точную настройку, второй — грубую, причём диапазоны, задаваемые вторым параметром, очень сильно перекрываются. Уменьшение значений (как и уменьшение питания) приводит к затемнению картинки и увеличению контрастности (в пределе чёрный экран). Увеличение параметров приводит к увеличению яркости и падению контрастности (в пределе белый экран). С помощью этой команды можно выправить картинку при недостаточном или избыточном напряжении питания драйвера S1D15G10. Картинка оказалась очень чувствительной как к питанию, так и к силе света, падающего на чип (100-ватная лампочка, освещающая чип с расстояния в 30-40 см, может совсем "выключить" картинку). При этом, при напряжении питания от 2,5 вольт и ниже ясно видны артефакты в виде вертикальных полос в столбцах, где есть яркие пиксели. При сильно завышенном питании (3,5 вольта и выше) может не получится даже с нулевыми значениями параметров команды VOLCTR выставить приемлемое качество изображения, картинка будет "засвечена". К сожалению, у меня линии V_DD и V_DDI питания драйвера дисплея запараллелены, и это может оказывать определённое значение. Однако, во вполне приемлемом диапазоне питающих напряжений качество изображения можно выставить отличное.

Отдельно хочу сказать об удобстве вывода символов на этот экран. Это просто сказка! С помощью команд PASET и CASET в любом месте экрана можно задать окошечко, совпадающее со знакоместом символа, а потом сплошным потоком (одной командой RAMWR) лить цвета пикселей, при этом они автоматически заполнят окошечко и образуют изображение символа. Главное — правильно задать размеры (они должны совпадать с размером символа) и направление заполнения окошечка командой DATCTR. При этом второй параметр команд PASET и CASET задаёт максимальную координату включительно. Если в одной из команд первый и второй параметры совпадают, то таким образом можно рисовать горизонтальные и вертикальные линии. Нарисовать закрашенный прямоугольник — так вообще раз плюнуть: один раз задать координаты и залить нужное количество пикселей нужного цвета. К сожалению я не пробовал задавать первому параметру величину, большую, чем второму, поэтому не знаю как будет себя вести драйвер дисплея в этом случае.

[ua1arn]

в любом месте экрана можно задать окошечко, совпадающее со знакоместом символа

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

[B@R5uk]

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

[ua1arn]

Ловите ссылочку на индикаторно-незаваисимый уровень работы с дисплеем:
http://188.134.5.254/browser/hfreceiver ... lay.c#L779

А вот как выглядит gotoxy:
http://188.134.5.254/browser/hfreceiver ... 225.c#L309
http://188.134.5.254/browser/hfreceiver ... 225.c#L548

Обратите внимание - для группы символов, не занимаясь вычислением, сколько их всего там. Для больших символов так например я вывожу разную ширину (для цифр и для точки):

[B@R5uk]

Ох-ох! Много букаф, ниасилю. Да ещё си. Я всё на ассемблере пишу.

Картинка очень красивая, но как-то странно испорчена артефактами. Наверное, фотосервис радиокота не сумел правильно пережать изображение в таком гигантском разрешении (3072 на 2304 точки).

Для больших символов так например я вывожу разную ширину (для цифр и для точки):

Я тоже хотел так поначалу сделать. У меня даже символы заготовлены с различной шириной:



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

Обратите внимание - для группы символов, не занимаясь вычислением, сколько их всего там.

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

[ua1arn]

Контролировать оставшуюся ширину? При выдаче? Вообще-то это на этапе дизайна экрана решается. Разве только в случае реализации авто-скролла при выдаче какого-то лога...

[B@R5uk]

Ну, вот выше я привёл два фото, на которых по 128 символов изображено. Для их распечатки я лишь задал процедуре четыре координаты, а дальше просто печатал символы (вызывал процедуру печати символа). Процедура всё "делала сама", от меня не требовалось контролировать каждую строчку. С моей стороны никакой заботы, кроме той, что я выводил ровно 128 символов (после вывода 128-ого символа каретка возвращалась в начало области). Выложить код на изучение (в нём, правда, есть ещё процедура опроса клавиатуры, так что разбор может вызвать затруднение, хотя комментарии есть)?

[ua1arn]

Нет, спасибо. Мне во всяком случае не надо.
Попробуйте изучить С - тогда сможете более рационально с чужим опытом распоряжаться. Да и Ваш кому-то пригодится.
Для справки - код что я указал - проект, который транслируется для Атмег, ARM, TI Dolphino. ARM-ы нескольких фирм, с разной периферией и разными версиями машинного кода. Иногда даже алгоритмические проблемы отлаживались не на том процессоре, на котором были первоначально замечены.

[B@R5uk]

Да Си я прекрасно владею, даже лучше, чем ассембелром, во всяком случае для ПК. Просто в AVRStudio 4 первая попытка не взлетела, а разбираться в чём дело не было времени. Но этот разговор уже для другой темы.

[ua1arn]

Последний хороший компилятор для ATMeag:
Atmel AVR 8-bit and 32-bit Toolchain 3.4.2 - Windows
http://www.atmel.com/images/avr-toolcha ... 32.x86.exe
Те что Атмел сделал позже, приобрели странности - про компиляции некоторых кусков моего проекта заваливаются с внутренней ошибкой.

[B@R5uk]

Не долгой была радость. Дисплей упал и больше не включился. Придётся по старинке светодиодами мигать.