[AndyBig 8]

Для своих нужд сделал библиотеку для графических LCD с контроллером T6963. Так как ничего подходящего в этом отношении найти в инете я не смог, то подумал, что такая библиотека будет интересна не только мне :). Библиотека написана и оттестирована на ATmega64, но легко может быть перенастроена для любых других AVR.

Есть возможность оптимизации для скорости или для размера кода. При отпимизации для скорости скорость, в основном, заметно возрастает (больше чем в 2 раза) при отрисовке текста в графическом режиме, но размер кода увеличивается почти в два раза.

О скорости... Скорость отрисовки 160 символов мелким шрифтом занимает 129 милисекунд (с оптимизацией библиотеки для размера кода) или 109 милисекунд (с оптимизацией библиотеки для скорости). Скорость отрисовки имиджа размером 80х80 занимает 16 милисекунд (с оптимизацией библиотеки для размера кода) или 13 милисекунд (с оптимизацией библиотеки для скорости). Это все замеряно при 14 МГц тактовой частоты.

 

Основные цели, которые я преследовал при ее создании:

- отрисовка имиджей

- отрисовка простейших графических примитивов

- (главное) графические шрифты; то есть вывод текста в графическом режиме с использованием своих шрифтов

Возможности библиотеки на сегодня:

- конфигурация дисплея (включение/выключение курсора, графики, текста и т.п.)

- очистка текстовой области, графической области и всего дисплея

======== текстовый режим =========

- вывод отдельных символов и текста в текстовом режиме

- вывод целых чисел с форматированием в текстовом режиме

- вертикальный скроллинг текста (автоматический или принудительный)

- вывод двузначного хексового значения unsigned char

======== графический режим ========

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

- поддержка нескольких шрифтов; шрифты хранятся в ROM в виде таблиц, количество доступных шрифтов ограничено только объемом flash-памяти контроллера; шрифты, в отличии от встроенных в дисплей, непропорциональны (к примеру, Courier - пропорциональный шрифт, а Arial - нет)

- выбор текущего шрифта

- вывод отдельного символа и текста текущим шрифтом с форматированием

- вывод целых знаковых чисел текущим шрифтом с возможностью выравнивания по правому краю

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

- отрисовка и очистка отдельных пикселей

- расчет ширины текста в пикселях в текущем шрифте

- рисование линий с указанными координатами начала и конца

- рисование круга с указанными координатами центра и радиусом

 

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

 

Библиотека будет развиваться, так что все предложения и замечания очень приветствуются :).

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

Кроме того, с удовольствием приму помощь в ее оптимизации по скорости и размеру кода.

lcd_t6963.rar - исходники библиотеки

bmpconv.rar - конвертер битмэпов

font_md.bmp - вид среднего шрифта

font_sm.bmp - вид мелкого шрифта

[Make_Pic 0]

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

 

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

[AndyBig 8]

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

1. Не считаю эту свою поделку достойной звания коммерческого продукта :).

2. Не готов оказывать необходимую в таких случаях поддержку.

3. Думаю, что мне эта вещь и так принесет прибыль, ведь делал я ее не только для собственного удовольствия :).

 

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

[Vict59 0]

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

[Rash 0]

Тема интересная и т.к. скачали её столько людей значит людям нада! :cheers:

Продолжай в том же духе

[BVU 0]

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

[AndyBig 8]

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++, хотя и не оформлен в класс...

Изменено 21 ноября, 2005 пользователем AndyBig

[smr80 0]

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

[rat 0]

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

[Igor26 0]

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

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

 

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

brezenhem.zip

Изменено 22 ноября, 2005 пользователем Igor26

[BVU 0]

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

 

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

[vet 0]

BVU

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

[BVU 0]

BVU

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

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

Я имел в виду что должны быть и наверняка существуют алгоритмы более оптимальные, чем Брезенхем.

[AndyBig 8]

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

Значит, займусь этим на досуге :).

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

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

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

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

1. определяется адрес изменяемого байта в ЖКИ

2. Определяется состояние ЖКИ (свободен или нет)

2. В ЖКИ посылается команда SET ADDRESS POINTER

3. В ЖКИ посылается команда SET BIT

Так что, простор для оптимизации есть.

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

Да, поточная запись может помочь, особенно при закрашивании/очистке регионов, при выводе изображений, при скроллинге экрана... Я до этого еще не добрался, но обязательно доберусь :).

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

Сейчас оптимизировать отрисовку линии можно так: не вычислять перед каждым очередным пикселем адрес изменяемого байта в ЖКИ, а инкрементировать изначально вычисленный адрес на единицу или на количество байт в графической строке.

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

[BVU 0]

К тому же, я не нашел в даташите на Т6963 времени выполнения различных команд.

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

Writing_Software_for_T6963C_based_Graphic_LCDs.pdf