Для своих нужд сделал библиотеку для графических LCD с контроллером T6963. Так как ничего подходящего в этом отношении найти в инете я не смог, то подумал, что такая библиотека будет интересна не только мне . Библиотека написана и оттестирована на ATmega64, но легко может быть перенастроена для любых других AVR.
Есть возможность оптимизации для скорости или для размера кода. При отпимизации для скорости скорость, в основном, заметно возрастает (больше чем в 2 раза) при отрисовке текста в графическом режиме, но размер кода увеличивается почти в два раза.
О скорости... Скорость отрисовки 160 символов мелким шрифтом занимает 129 милисекунд (с оптимизацией библиотеки для размера кода) или 109 милисекунд (с оптимизацией библиотеки для скорости). Скорость отрисовки имиджа размером 80х80 занимает 16 милисекунд (с оптимизацией библиотеки для размера кода) или 13 милисекунд (с оптимизацией библиотеки для скорости). Это все замеряно при 14 МГц тактовой частоты.

Основные цели, которые я преследовал при ее создании:
- отрисовка имиджей
- отрисовка простейших графических примитивов
- (главное) графические шрифты; то есть вывод текста в графическом режиме с использованием своих шрифтов
Возможности библиотеки на сегодня:
- конфигурация дисплея (включение/выключение курсора, графики, текста и т.п.)
- очистка текстовой области, графической области и всего дисплея
======== текстовый режим =========
- вывод отдельных символов и текста в текстовом режиме
- вывод целых чисел с форматированием в текстовом режиме
- вертикальный скроллинг текста (автоматический или принудительный)
- вывод двузначного хексового значения unsigned char
======== графический режим ========
- вывод изображений по указанным координатам; изображение может обрезаться по вертикали и горизонтали
- поддержка нескольких шрифтов; шрифты хранятся в ROM в виде таблиц, количество доступных шрифтов ограничено только объемом flash-памяти контроллера; шрифты, в отличии от встроенных в дисплей, непропорциональны (к примеру, Courier - пропорциональный шрифт, а Arial - нет)
- выбор текущего шрифта
- вывод отдельного символа и текста текущим шрифтом с форматированием
- вывод целых знаковых чисел текущим шрифтом с возможностью выравнивания по правому краю
- очистка, заполнение и инверсия указанных прямоугольников
- отрисовка и очистка отдельных пикселей
- расчет ширины текста в пикселях в текущем шрифте
- рисование линий с указанными координатами начала и конца
- рисование круга с указанными координатами центра и радиусом

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

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

Зачем так? А почему не по protoss-овски продавать по всем существующим и не существующим инетовским конференциям по микроконтроллерам и да же конференциям для домохозяек и голубых за долларЫ?

Это я так - вспомнил тему минувших дней.

В принципе, я могу понять Протосса, каждому ведь хотелось бы что-то заработать своими трудами... Но во-первых у меня несколько иное отношение к этому, а во-вторых имеется несколько объективных причин:
1. Не считаю эту свою поделку достойной звания коммерческого продукта .
2. Не готов оказывать необходимую в таких случаях поддержку.
3. Думаю, что мне эта вещь и так принесет прибыль, ведь делал я ее не только для собственного удовольствия .

А вообще интересно - насколько такая вещь интересует людей? Стоит ли организовать страничку, на которую выкладывать обновления, помощь, поддержку? Или это пустая трата времени?

IMHO тема очень интересная и актуальная!!!

Тема интересная и т.к. скачали её столько людей значит людям нада!
Продолжай в том же духе

AndyBig , кокой алгоритм Вы использовали для рисования линий с указанными координатами начала и конца? И как быстро будет происходить отрисовка диогональной линии на экране скажем (240x128)?

BVUЕсли не ошибаюсь, это алгоритм Брезенхэма. Суть его в том, что сначала находится вектор приращения (X или Y), по которому затем идет итерация с расчетом координаты по второй оси.
Время - пожалуйста (в милисекундах для ATmega64 14 MHz):
-----------
при оптимизации библиотеки под размер
1. Отрисовка линии (0,0 - 239,127) - 5,17
2. Очистка региона, заполнение региона (0,0 - 239,127) - 42,60
3. Отрисовка круга с координатами центра 120,64 радиусом 63 - 9,51
4. Отрисовка строки длиной 250 символов графическим мелким немоноширинным шрифтом с автопереносом - 162,47
при оптимизации библиотеки под скорость
1. Отрисовка линии (0,0 - 239,127) - 5,08
2. Очистка региона, заполнение региона (0,0 - 239,127) - 37,60
3. Отрисовка круга с координатами центра 120,64 радиусом 63 - 7,98
4. Отрисовка строки длиной 250 символов графическим мелким немоноширинным шрифтом с автопереносом - 138,40

Кстати, забыл упомянуть - код писан в EC++, хотя и не оформлен в класс...

Думаю, такая библиотека была бы интересна и ее стоило бы выложить...

Не найдется литературы по ентому самому алгоритму Брезенхэма?

Посмотрите это

и это http://stratum.ac.ru/textbooks/kgrafic/add...al/addit13.html

На сколько мне известно алгоритм Брезенхамма построения линии не обладает оптимально-скоростными качествами (возможно, что и ошибаюсь), но имеет оптимальную линейность. Может кто работал с построениями графических пакетов и может предложить что-то другое (более быстрое). Все наверно согласитесь, что для графических приложений скоростные характеристики отрисовки есть задача номер один! Проблема достаточно стоящая, что бы начать ее обсуждение...

P.S. Поможем своими рекомендациями для AndyBig усовершенствовать его работу!

BVU
думается мне, что в данном случае узкое место - не отработка алгоритма (на Брезенхема вычислительные затраты копеечные, пара сложений на точку), а собственно вывод на устройство.

Эту проблему не обойти... Она лимитируется - железом. Здесь по всей видимости если позволяет граф. контроллер применять передачу данных блоками с автоиндексированием, что заметно сокращает время не использую при этом передачу (постоянно) адресной информации. Но передаваемые данные не всегда имеют инкрементную адресную последовательность, кроме как прорисовка горизонтальных или вертикальных линий (зависит от графической матрицы).
Я имел в виду что должны быть и наверняка существуют алгоритмы более оптимальные, чем Брезенхем.

Значит, займусь этим на досуге .
Честно говоря, я до сих пор не занимался плотно векторной графикой, в основном я работал с растрами, но почитав литературу, я пришел к выводу, что этот алгоритм как раз оптимален по быстродействию, т.к. имеет наиболее легкую (причем целочисленную) математику. Если я не прав, то с благодарностью приму ссылку на описание более быстрого алгоритма. Другое дело - сама реализация этого алгоритма в применении ЖКИ - тут оптимизировать, думаю, еще можно. Об этом я упомяну дальше.
Я пока ничего не думал по этому поводу, но сейчас просто поэксперементирую - уберу собственно вывод вычисленных точек на ЖКИ и замерю время . Но мне так же кажется, что вывод результатов занимает значительное время. Перед каждой попыткой дать какую-то команду дисплею, дисплей в цикле опрашивается на предмет занятости. Кроме того, при передаче/приеме каждого байта в/из ЖКИ делается пауза в 2 такта - это необходимое условие контроллера ЖКИ. Всего для вывода одной точки при рисовании линии сейчас производятся следующие действия:
1. определяется адрес изменяемого байта в ЖКИ
2. Определяется состояние ЖКИ (свободен или нет)
2. В ЖКИ посылается команда SET ADDRESS POINTER
3. В ЖКИ посылается команда SET BIT
Так что, простор для оптимизации есть.
Да, поточная запись может помочь, особенно при закрашивании/очистке регионов, при выводе изображений, при скроллинге экрана... Я до этого еще не добрался, но обязательно доберусь .
С отрисовкой линий потоковая запись не пройдет так на ура - тут, как правильно заметил BVU, оптимизация будет заметна только при горизонтальных или очень близких к горизонтальным линиях. К тому же, еще и не все ЖКИ поддерживают потоковое чтение/запись.
Сейчас оптимизировать отрисовку линии можно так: не вычислять перед каждым очередным пикселем адрес изменяемого байта в ЖКИ, а инкрементировать изначально вычисленный адрес на единицу или на количество байт в графической строке.
Оптимизировать же работу на уровне железа можно тем, что бы не проверять каждый раз состояние ЖКИ. Можно вообще плюнуть на это, надеясь, что после предыдущего обращения к ЖКИ прошло достаточно времени, а можно как-то проверять прошедшие с предыдущего обращения к ЖКИ такты контроллера. Вот правда, первый способ совсем ненадежен, а второй громоздок. К тому же, я не нашел в даташите на Т6963 времени выполнения различных команд.

AndyBig, посмотрите вот этот документ, может что нибудь прояснит, там в разделе 2. Basics of Writing to, and Reading from the T6963C немного оговариваются времянки на команды контроллера.

Вот время в милисекундах без вывода в ЖКИ (только математика):
1. Отрисовка линии (0,0 - 239,127) - 0,18
2. Очистка региона, заполнение региона (0,0 - 239,127) - 1,02
3. Отрисовка круга с координатами центра 120,64 радиусом 63 - 0,06
4. Отрисовка строки длиной 250 символов графическим мелким немоноширинным шрифтом с автопереносом - 9,66

Солидная прибавка в скорости, правда?

Надеюсь, не будете меня хаить, как уважаемый Make_Pic, за то, что я влез в вашу дисскусию по поводу драйвера ЖКИ со своим мнением.

Хочу высказаться по поводу проверки состояния ЖКИ. Я думаю, что нет смысла проверять состояние ЖКИ. Есть смысл построить алгоритм так, что бы время исполнения алгоритма превышало предполагаемое время работы ЖКИ по выполнению команды МК. Я, по крайней мере, стараюсь делать так всегда, будь то графический или символьный ЖКИ. Времени выполнения же команд Т6963 скорее всего Вы и не найдете. А найдете скорее всего диаграммы таймингов циклов записи-чтения где будет указана минимальное время цикла обращения к ЖКИ.

По поводу алгоритма Брезенгхема могу с уверенностью сказать, что пока это самый быстрый метод построения отрезков. Достаточно того, что он до сих пор применяется в 3D графике. Добавлю, что и алгоритмов Брезенгхема несколько. Я по крайней мере применял два - 4-х и 8-и связной развертки. Хотя идея у всех алгоритмов одна, о которой было сказано выше.

С уважением, Андрей (PROTTOSS)

BVUУ меня есть этот документ, но он скомпилирован на основе родного даташита на контроллер, просто в нем более доходчиво и упрощенно расписаны основы работы с контроллером. В этом документе имеются тайминги самой шины, но не выполнения команд, например, запись байта, установка пикселя, установка внутреннего указателя памяти...
Я попробовал сейчас убрать проверку статуса дисплея, заменив ее простой задержкой после каждой команы. То есть после записи в ЖКИ команды мега ждет несколько циклов, подразумевая что за это время ЖКИ успеет обработать команду и вернуться в состояние готовности. Так вот, я дошел до задержки в 70 циклов, при меньшей задержке на экране появляются артефакты, ЖКИ не все команды успевает обработать за это время. Однако при такой задержке после каждой команды время отрисовки сильно выросло даже по сравнению с кодом, проверяющим состояние ЖКИ. Для установки оптимальных задержек необходимо знать время выполнения ЖКИ каждой команды. Это можно узнать экспериментальным путем, но мне кажется, смысла в этом нет . Больший смысл будет в оптимизации самого кода. Например, переписать базовые процедуры на асме . Но я с асмом завязал лет 10 назад... Ну и всякие алгоритмические ухищрения .
Не согласен . Это заведомое ограничение на быстродействие драйвера, к тому же способ не особо ненадежен - ведь могут попасться дисплеи и с меньшей тактовой частотой своего контроллера. А могут и с большей, тогда все быстродействие дисплея будет тормозиться драйвером.
Что тайминги выполнения команд не найду - согласен .

Вы считаете, что ввод функции LCD_Wait() длительностью в несколько микросекунд перед каждым обменом по шине МК-ЖКИ - это лучший способ? И мне немного не понятно, разве выпускаютcя дисплеи на основе Т6963 с разными тактовыми частотами? К сожалению пока нет даташита на Т6963, но постараюсь найти в ближайшее время.

Скажем, две микросекунды, хотя мне кажется, можно добиться и меньшего значения. Диагональная линия состоит примерно из 272 точек, при задержке на каждую по две микросекунды это составит 0,57 милисекунд. Не так уж много за гарантированную надежность.
Проверка статуса состоит из:
1. Установить порт шины на ввод
2. Выставить сигнал CD
3. Сбросить сигнал READ
4. Сбросить сигнал CE
5. Пропустить 2 цикла
6. Прочесть из порта шины
7. Выставить сигнал CE
8. Если !(считанное значение & 0x03), то к пункту3
9. Выставить сигнал READ
Немного, правда ведь?

Вот выдержка из даташита на Т6963: "The oscillation frequency is ajusted according to the display size". Кроме того, еще в одном месте накладывается ограничение только максимальной частоты, но не минимальной. И приводятся значения РЕКОМЕНДУЕМЫХ частот при различных комбинациях матрицы дисплея.
Сам даташит прикладываю .

Частота, которая рекомендованна в даташите, не относится к таймингам внешнего интерфейса дисплея. Значение частоты связанно с размерностью ЖКИ матрицы. Естественно, чем больше матрица, тем выше значение частоты контроллера, его обслуживающего. Ведь ему приходится обслуживать большее количество точек за лимитированное время (тайминги внешнего интерфейса). Но внешний интерфейс, как правило, имеет стандартные для одного класса устройств тайминги. Эти тайминги даны на стр. 29-32 выложенного Вами даташита. Или Вы хотите сказать, что тайминги у чипа с 19 Мгц будут меньше чем у чипа с 5 Мгц? :-) . Между внешним интерфейсом и внутренней шиной данных чипа всегда есть набор логики, который синхронизирует работу этих двух шин. Так что по поводу разных скоростей работы разных (по размеру дисплеев) ЖКИ скорее всего Вы заблуждаетесь.

Хотя это все демогогия..наверное. У Вас есть такой дисплей и опыт с ним работы, у меня нет ни того ни другого.





В догонку. Посчитайте, сколько в некоторых циклах Вы посылаете команд, а потом еще и данных, за тем все это помножте на 2 мкс (хотя я не уверен, что 2 мкс, даже при 62,5 нс на команду).

Ради Бога, извините, что придираюсь к Вашему драйверу. Вы же просили замечания и предложения :-)

Я переписал процедуры проверки статуса дисплея на асме, при незанятом дисплее проверка проходит чуть меньше 2 микросекунд (1,9).
По поводу таймингов - есть тайминг шины и есть тайминг выполнения команд. Вы же сами подчеркивали, что это разные вещи . Я, кстати, нашел документ, в котором указано максимальное время выполнения команд, так вот оно указано в тактах ЖКИ-контроллера. Большинство команд выполняются за 32 такта, но некоторые не привязаны к количеству тактов и требуют обязательной проверки статуса ЖКИ для проверки их выполнения.
Я совершенно не обижаюсь, критика всегда нужна . Но в этом вопросе я придерживаюсь мнения - лучше чуть медленнее, но надежнее .

Русский даташит по T6963
http://www.gaw.ru/html.cgi/txt/lcd/chips/t6963/index.htm

решил скачать.

Переделал слегка...
prottoss, все таки мой путь оказался выигрышнее Вашего, судя по результатам . Вот временные характеристики для дисплея 240х128 и контроллера mega64 16MHz, в милисекундах:
1. Отрисовка линии (0,0 - 239,127) - 2,15
2. Очистка региона, заполнение, инвертация региона (0,0 - 239,127) - 22,72
3. Отрисовка круга с координатами центра 120,64 радиусом 63 - 4,85
4. Отрисовка строки длиной 250 символов графическим мелким немоноширинным шрифтом с автопереносом - 115,26

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

:-)))

1.Если Вы судите по отрисовке линий, то Вы ошибаетесь. При отрисовке линий в моей библиотеке используется процедура Set_Pixel(), при остальных операциях с экраном - другие.

2. Моя библитека не рисует круги

3. Вывод строки из 20 символов 6х8 (на всю длину дисплея 122х32) - 7 мс.

4. Очистка региона (0, 0, 122, 32) - 1,7 мс;

2. Закраска всего экрана – 1,86 мс;

3. Инвертирование всего экрана – 1,89 мс

Так я не понял, у кого быстрее. :-)))))))))

Я смотрел Вашу библиотеку. Первый вариант МОЕЙ был чем то похож на Ваш

По поводу заливки, очистки и инвертирования - сорри, ошибся . Чет не то посчитал . Но я еще не оптимизировал эти процедуры.
Но линии у меня рисуются быстрее, при этом размер увеличивается не сильно. По поводу символов - эти свои процедуры я не оптимизировал вообще и у меня несколько иной вывод - у меня немоноширинные шрифты, то есть у символов ширина плавающая. В приведенном примере мелкий шрифт - это символы высотой 10 и средней ширины 4,8 пикс.
Кстати, очистка графической области памяти занимает у меня 10,52 мс. Т.к. экран у меня больше Вашего в 8 раз, то разделив это время на 8 получим 1,315 мс, что чуть быстрее, чем у Вас.

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

Хых... Форум опять глючит...

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

Ну а касаемо проверки статуса - я думаю, что если контроллер при вводе-выводе каких то данных не требует проверки, то и не надо ее делать. У вас больше времени, чем требуется контроллеру на раздумье, уходит на команды rcall, ret и построение цикла do{}while. Это первое. Второе - команды установки линий ЧТЕНИЕ-ЗАПИСЬ и КОМАНДА_ДАННЫЕ можно тоже вынести в тело основных циклов. Опять прирост скорости. А надежность...Надежность нужна всегда, я не спорю. Но если временные характеристики шины ввода-вывода стандартизированы для дисплеев на данном контроллере, зачем думать что кто-то найдет контроллер с другими таймингами.

Вы же пишите драйвер не для Windows XP. Это не .exe файл. Вы поставляете исходный файл. В комментариях можно указать время исполнения команды, например для какой то частоты, например 16 МГц. И все. Пользователь сам примет решение, стоит ли ему растягивать циклы или нет.

Но это опять просто мое мнение. Удачи.

Ну, при оптимизации под скорость проверка статуса инлайнится в код, так что от rcall и ret это уводит .

Т6963 и SED1520 слишком разные по быстродеиствию, чтоб сравнит. B SED можно без проверки статуса писать ( T>=1 uS) , о 6963 не уверен.
код Andy легко читать и при желании корригировать.
только вот где-то читал, что лучше for(;;) исползовать, чем while(1) .

Гм... Сам я так никогда не думал .
Да, согласен.

И чем шрифты в используемого в билиотеке формата генерились?