реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> Библиотека для графических LCD, отдам в хорошие руки :)
AndyBig
сообщение Nov 19 2005, 18:57
Сообщение #1


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



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

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

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

Библиотека будет развиваться, так что все предложения и замечания очень приветствуются smile.gif.
Никаких ограничений в применении библиотеки не накладываю, только просьба - если вдруг кто-то будет использовать ее, пришлите, пожалуйста, свои отзывы о ней smile.gif.
Кроме того, с удовольствием приму помощь в ее оптимизации по скорости и размеру кода.
Прикрепленный файл  lcd_t6963.rar ( 11.55 килобайт ) Кол-во скачиваний: 1345
- исходники библиотеки
Прикрепленный файл  bmpconv.rar ( 201.54 килобайт ) Кол-во скачиваний: 1659
- конвертер битмэпов
Прикрепленный файл  font_md.bmp ( 1.84 килобайт ) Кол-во скачиваний: 977
- вид среднего шрифта
Прикрепленный файл  font_sm.bmp ( 1.16 килобайт ) Кол-во скачиваний: 747
- вид мелкого шрифта
Go to the top of the page
 
+Quote Post
Make_Pic
сообщение Nov 20 2005, 05:57
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 779
Регистрация: 9-10-04
Из: Россия, Пермь
Пользователь №: 828



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

Это я так - вспомнил тему минувших дней. wink.gif
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 20 2005, 10:53
Сообщение #3


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



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

А вообще интересно - насколько такая вещь интересует людей? Стоит ли организовать страничку, на которую выкладывать обновления, помощь, поддержку? Или это пустая трата времени?
Go to the top of the page
 
+Quote Post
Vict59
сообщение Nov 21 2005, 06:59
Сообщение #4


Участник
*

Группа: Свой
Сообщений: 70
Регистрация: 22-06-04
Из: Москва
Пользователь №: 109



IMHO тема очень интересная и актуальная!!!
Go to the top of the page
 
+Quote Post
Rash
сообщение Nov 21 2005, 07:23
Сообщение #5


Знающий
****

Группа: Свой
Сообщений: 639
Регистрация: 5-09-05
Пользователь №: 8 231



Тема интересная и т.к. скачали её столько людей значит людям нада! cheers.gif
Продолжай в том же духе biggrin.gif
Go to the top of the page
 
+Quote Post
BVU
сообщение Nov 21 2005, 15:28
Сообщение #6


Профессионал
*****

Группа: Свой
Сообщений: 1 301
Регистрация: 30-11-04
Из: Россия, Н.Новгород
Пользователь №: 1 264



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


--------------------
Не корысти ради, не в целях наживы, а во исполнение велений души!
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 21 2005, 19:02
Сообщение #7


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



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

Сообщение отредактировал AndyBig - Nov 21 2005, 19:03
Go to the top of the page
 
+Quote Post
smr80
сообщение Nov 21 2005, 22:29
Сообщение #8


Частый гость
**

Группа: Свой
Сообщений: 92
Регистрация: 17-05-05
Пользователь №: 5 129



Думаю, такая библиотека была бы интересна и ее стоило бы выложить...
Go to the top of the page
 
+Quote Post
rat
сообщение Nov 22 2005, 05:45
Сообщение #9


Местный
***

Группа: Свой
Сообщений: 497
Регистрация: 9-06-05
Из: Новосибирск
Пользователь №: 5 852



Не найдется литературы по ентому самому алгоритму Брезенхэма?
Go to the top of the page
 
+Quote Post
Igor26
сообщение Nov 22 2005, 06:23
Сообщение #10


Знающий
****

Группа: Свой
Сообщений: 521
Регистрация: 10-02-05
Пользователь №: 2 544



Цитата(rat @ Nov 22 2005, 09:45) *
Не найдется литературы по ентому самому алгоритму Брезенхэма?

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

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

Сообщение отредактировал Igor26 - Nov 22 2005, 08:09
Прикрепленные файлы
Прикрепленный файл  brezenhem.zip ( 514.6 килобайт ) Кол-во скачиваний: 264
 
Go to the top of the page
 
+Quote Post
BVU
сообщение Nov 22 2005, 06:52
Сообщение #11


Профессионал
*****

Группа: Свой
Сообщений: 1 301
Регистрация: 30-11-04
Из: Россия, Н.Новгород
Пользователь №: 1 264



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

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


--------------------
Не корысти ради, не в целях наживы, а во исполнение велений души!
Go to the top of the page
 
+Quote Post
vet
сообщение Nov 22 2005, 07:26
Сообщение #12


Знающий
****

Группа: Свой
Сообщений: 550
Регистрация: 16-06-04
Из: Казань
Пользователь №: 32



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


--------------------
Главная линия этого опуса ясна мне насквозь!
Go to the top of the page
 
+Quote Post
BVU
сообщение Nov 22 2005, 07:40
Сообщение #13


Профессионал
*****

Группа: Свой
Сообщений: 1 301
Регистрация: 30-11-04
Из: Россия, Н.Новгород
Пользователь №: 1 264



Цитата(vet @ Nov 22 2005, 10:26) *
BVU
думается мне, что в данном случае узкое место - не отработка алгоритма (на Брезенхема вычислительные затраты копеечные, пара сложений на точку), а собственно вывод на устройство.

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


--------------------
Не корысти ради, не в целях наживы, а во исполнение велений души!
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 22 2005, 13:45
Сообщение #14


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



Цитата
Думаю, такая библиотека была бы интересна и ее стоило бы выложить...
Значит, займусь этим на досуге smile.gif.
Цитата
На сколько мне известно алгоритм Брезенхамма построения линии не обладает оптимально-скоростными качествами (возможно, что и ошибаюсь)
Честно говоря, я до сих пор не занимался плотно векторной графикой, в основном я работал с растрами, но почитав литературу, я пришел к выводу, что этот алгоритм как раз оптимален по быстродействию, т.к. имеет наиболее легкую (причем целочисленную) математику. Если я не прав, то с благодарностью приму ссылку на описание более быстрого алгоритма. Другое дело - сама реализация этого алгоритма в применении ЖКИ - тут оптимизировать, думаю, еще можно. Об этом я упомяну дальше.
Цитата
думается мне, что в данном случае узкое место - не отработка алгоритма (на Брезенхема вычислительные затраты копеечные, пара сложений на точку), а собственно вывод на устройство.
Я пока ничего не думал по этому поводу, но сейчас просто поэксперементирую - уберу собственно вывод вычисленных точек на ЖКИ и замерю время smile.gif. Но мне так же кажется, что вывод результатов занимает значительное время. Перед каждой попыткой дать какую-то команду дисплею, дисплей в цикле опрашивается на предмет занятости. Кроме того, при передаче/приеме каждого байта в/из ЖКИ делается пауза в 2 такта - это необходимое условие контроллера ЖКИ. Всего для вывода одной точки при рисовании линии сейчас производятся следующие действия:
1. определяется адрес изменяемого байта в ЖКИ
2. Определяется состояние ЖКИ (свободен или нет)
2. В ЖКИ посылается команда SET ADDRESS POINTER
3. В ЖКИ посылается команда SET BIT
Так что, простор для оптимизации есть.
Цитата
Здесь по всей видимости если позволяет граф. контроллер применять передачу данных блоками с автоиндексированием, что заметно сокращает время не использую при этом передачу (постоянно) адресной информации. Но передаваемые данные не всегда имеют инкрементную адресную последовательность, кроме как прорисовка горизонтальных или вертикальных линий (зависит от графической матрицы).
Да, поточная запись может помочь, особенно при закрашивании/очистке регионов, при выводе изображений, при скроллинге экрана... Я до этого еще не добрался, но обязательно доберусь smile.gif.
С отрисовкой линий потоковая запись не пройдет так на ура - тут, как правильно заметил BVU, оптимизация будет заметна только при горизонтальных или очень близких к горизонтальным линиях. К тому же, еще и не все ЖКИ поддерживают потоковое чтение/запись.
Сейчас оптимизировать отрисовку линии можно так: не вычислять перед каждым очередным пикселем адрес изменяемого байта в ЖКИ, а инкрементировать изначально вычисленный адрес на единицу или на количество байт в графической строке.
Оптимизировать же работу на уровне железа можно тем, что бы не проверять каждый раз состояние ЖКИ. Можно вообще плюнуть на это, надеясь, что после предыдущего обращения к ЖКИ прошло достаточно времени, а можно как-то проверять прошедшие с предыдущего обращения к ЖКИ такты контроллера. Вот правда, первый способ совсем ненадежен, а второй громоздок. К тому же, я не нашел в даташите на Т6963 времени выполнения различных команд.
Go to the top of the page
 
+Quote Post
BVU
сообщение Nov 22 2005, 13:58
Сообщение #15


Профессионал
*****

Группа: Свой
Сообщений: 1 301
Регистрация: 30-11-04
Из: Россия, Н.Новгород
Пользователь №: 1 264



Цитата(AndyBig @ Nov 22 2005, 16:45) *
К тому же, я не нашел в даташите на Т6963 времени выполнения различных команд.

AndyBig, посмотрите вот этот документ, может что нибудь прояснит, там в разделе 2. Basics of Writing to, and Reading from the T6963C немного оговариваются времянки на команды контроллера.
Прикрепленные файлы
Прикрепленный файл  Writing_Software_for_T6963C_based_Graphic_LCDs.pdf ( 31.79 килобайт ) Кол-во скачиваний: 366
 


--------------------
Не корысти ради, не в целях наживы, а во исполнение велений души!
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 22 2005, 14:04
Сообщение #16


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



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

Солидная прибавка в скорости, правда? smile.gif
Go to the top of the page
 
+Quote Post
prottoss
сообщение Nov 22 2005, 14:10
Сообщение #17


Гуру
******

Группа: Свой
Сообщений: 2 720
Регистрация: 24-03-05
Пользователь №: 3 659



Цитата(AndyBig @ Nov 22 2005, 20:45) *
Оптимизировать же работу на уровне железа можно тем, что бы не проверять каждый раз состояние ЖКИ. Можно вообще плюнуть на это, надеясь, что после предыдущего обращения к ЖКИ прошло достаточно времени, а можно как-то проверять прошедшие с предыдущего обращения к ЖКИ такты контроллера. Вот правда, первый способ совсем ненадежен, а второй громоздок. К тому же, я не нашел в даташите на Т6963 времени выполнения различных команд.


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

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

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

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


--------------------
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 22 2005, 16:25
Сообщение #18


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



BVUУ меня есть этот документ, но он скомпилирован на основе родного даташита на контроллер, просто в нем более доходчиво и упрощенно расписаны основы работы с контроллером. В этом документе имеются тайминги самой шины, но не выполнения команд, например, запись байта, установка пикселя, установка внутреннего указателя памяти...
Я попробовал сейчас убрать проверку статуса дисплея, заменив ее простой задержкой после каждой команы. То есть после записи в ЖКИ команды мега ждет несколько циклов, подразумевая что за это время ЖКИ успеет обработать команду и вернуться в состояние готовности. Так вот, я дошел до задержки в 70 циклов, при меньшей задержке на экране появляются артефакты, ЖКИ не все команды успевает обработать за это время. Однако при такой задержке после каждой команды время отрисовки сильно выросло даже по сравнению с кодом, проверяющим состояние ЖКИ. Для установки оптимальных задержек необходимо знать время выполнения ЖКИ каждой команды. Это можно узнать экспериментальным путем, но мне кажется, смысла в этом нет smile.gif. Больший смысл будет в оптимизации самого кода. Например, переписать базовые процедуры на асме smile.gif. Но я с асмом завязал лет 10 назад... Ну и всякие алгоритмические ухищрения smile.gif.
Цитата
Я думаю, что нет смысла проверять состояние ЖКИ. Есть смысл построить алгоритм так, что бы время исполнения алгоритма превышало предполагаемое время работы ЖКИ по выполнению команды МК.
Не согласен smile.gif. Это заведомое ограничение на быстродействие драйвера, к тому же способ не особо ненадежен - ведь могут попасться дисплеи и с меньшей тактовой частотой своего контроллера. А могут и с большей, тогда все быстродействие дисплея будет тормозиться драйвером.
Что тайминги выполнения команд не найду - согласен smile.gif.
Go to the top of the page
 
+Quote Post
prottoss
сообщение Nov 22 2005, 16:58
Сообщение #19


Гуру
******

Группа: Свой
Сообщений: 2 720
Регистрация: 24-03-05
Пользователь №: 3 659



Цитата(AndyBig @ Nov 22 2005, 23:25) *
Не согласен smile.gif . Это заведомое ограничение на быстродействие драйвера, к тому же способ не особо ненадежен - ведь могут попасться дисплеи и с меньшей тактовой частотой своего контроллера. А могут и с большей, тогда все быстродействие дисплея будет тормозиться драйвером.


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


--------------------
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 22 2005, 18:09
Сообщение #20


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



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

Цитата
разве выпускаютcя дисплеи на основе Т6963 с разными тактовыми частотами?
Вот выдержка из даташита на Т6963: "The oscillation frequency is ajusted according to the display size". Кроме того, еще в одном месте накладывается ограничение только максимальной частоты, но не минимальной. И приводятся значения РЕКОМЕНДУЕМЫХ частот при различных комбинациях матрицы дисплея.
Сам даташит прикладываю smile.gif.
Прикрепленные файлы
Прикрепленный файл  T6963C.rar ( 1.15 мегабайт ) Кол-во скачиваний: 240
 
Go to the top of the page
 
+Quote Post
prottoss
сообщение Nov 22 2005, 19:11
Сообщение #21


Гуру
******

Группа: Свой
Сообщений: 2 720
Регистрация: 24-03-05
Пользователь №: 3 659



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


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

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





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

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


--------------------
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 22 2005, 20:57
Сообщение #22


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



Я переписал процедуры проверки статуса дисплея на асме, при незанятом дисплее проверка проходит чуть меньше 2 микросекунд (1,9).
По поводу таймингов - есть тайминг шины и есть тайминг выполнения команд. Вы же сами подчеркивали, что это разные вещи smile.gif. Я, кстати, нашел документ, в котором указано максимальное время выполнения команд, так вот оно указано в тактах ЖКИ-контроллера. Большинство команд выполняются за 32 такта, но некоторые не привязаны к количеству тактов и требуют обязательной проверки статуса ЖКИ для проверки их выполнения.
Я совершенно не обижаюсь, критика всегда нужна smile.gif. Но в этом вопросе я придерживаюсь мнения - лучше чуть медленнее, но надежнее smile.gif.
Go to the top of the page
 
+Quote Post
Rash
сообщение Nov 23 2005, 09:40
Сообщение #23


Знающий
****

Группа: Свой
Сообщений: 639
Регистрация: 5-09-05
Пользователь №: 8 231



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

решил скачать.
Прикрепленные файлы
Прикрепленный файл  T6963_rus_.ZIP ( 548.1 килобайт ) Кол-во скачиваний: 325
 
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 26 2005, 14:51
Сообщение #24


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



Переделал слегка...
prottoss, все таки мой путь оказался выигрышнее Вашего, судя по результатам smile.gif. Вот временные характеристики для дисплея 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

То есть, с учетом размеров экрана, моя библиотека в два раза быстрее Вашей smile.gif.
Прикрепленный файл  lcd_t6963.rar ( 7.98 килобайт ) Кол-во скачиваний: 794
- библиотека.
Прикрепленный файл  lcd_t6963.rar ( 7.98 килобайт ) Кол-во скачиваний: 794
- хидер со шрифтами, добавлен шрифт крупных цифр.
Прикрепленный файл  font_nums_big.bmp ( 680 байт ) Кол-во скачиваний: 372
- вид шрифта крупных цифр.
Прикрепленные файлы
Прикрепленный файл  fonts.rar ( 4.62 килобайт ) Кол-во скачиваний: 299
 
Go to the top of the page
 
+Quote Post
prottoss
сообщение Nov 26 2005, 18:38
Сообщение #25


Гуру
******

Группа: Свой
Сообщений: 2 720
Регистрация: 24-03-05
Пользователь №: 3 659



Цитата(AndyBig @ Nov 26 2005, 21:51) *
Переделал слегка...
prottoss, все таки мой путь оказался выигрышнее Вашего, судя по результатам smile.gif . Вот временные характеристики для дисплея 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

То есть, с учетом размеров экрана, моя библиотека в два раза быстрее Вашей smile.gif .


:-)))

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

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

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

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

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

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

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

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


--------------------
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 26 2005, 21:05
Сообщение #26


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



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

Это все я не к тому, что бы начать меряться письками, а к вопросу о проверке статуса дисплея smile.gif. Похоже, что она не оказывает значительного влияния на временные характеристики, но надежность, согласитесь, повышает smile.gif.
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 27 2005, 11:40
Сообщение #27


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



Хых... Форум опять глючит...
Go to the top of the page
 
+Quote Post
prottoss
сообщение Nov 28 2005, 12:54
Сообщение #28


Гуру
******

Группа: Свой
Сообщений: 2 720
Регистрация: 24-03-05
Пользователь №: 3 659



Цитата(AndyBig @ Nov 27 2005, 04:05) *
Это все я не к тому, что бы начать меряться письками, а к вопросу о проверке статуса дисплея smile.gif . Похоже, что она не оказывает значительного влияния на временные характеристики, но надежность, согласитесь, повышает smile.gif .


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

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

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

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


--------------------
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 28 2005, 16:06
Сообщение #29


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



Ну, при оптимизации под скорость проверка статуса инлайнится в код, так что от rcall и ret это уводит smile.gif.
Go to the top of the page
 
+Quote Post
proba
сообщение Nov 28 2005, 16:25
Сообщение #30


Местный
***

Группа: Участник
Сообщений: 358
Регистрация: 29-05-05
Пользователь №: 5 526



Т6963 и SED1520 слишком разные по быстродеиствию, чтоб сравнит. B SED можно без проверки статуса писать ( T>=1 uS) , о 6963 не уверен.
код Andy легко читать и при желании корригировать.
только вот где-то читал, что лучше for(;;) исползовать, чем while(1) .
Go to the top of the page
 
+Quote Post
AndyBig
сообщение Nov 28 2005, 18:08
Сообщение #31


Иногдящий
****

Группа: Свой
Сообщений: 691
Регистрация: 28-02-05
Пользователь №: 2 931



Цитата
код Andy легко читать и при желании корригировать

Гм... Сам я так никогда не думал smile.gif.
Цитата
только вот где-то читал, что лучше for(;;) исползовать, чем while(1)
Да, согласен.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Mar 24 2009, 07:27
Сообщение #32


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(AndyBig @ Nov 19 2005, 21:57) *
Два шрифта - мелкий и средний - уже включены в библиотеку. При желании их можно изменить, удалить или добавить еще шрифты smile.gif.

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


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 11th August 2025 - 13:17
Рейтинг@Mail.ru


Страница сгенерированна за 0.01717 секунд с 7
ELECTRONIX ©2004-2016