[AndyBig 8]

Вот время в милисекундах без вывода в ЖКИ (только математика):

1. Отрисовка линии (0,0 - 239,127) - 0,18

2. Очистка региона, заполнение региона (0,0 - 239,127) - 1,02

3. Отрисовка круга с координатами центра 120,64 радиусом 63 - 0,06

4. Отрисовка строки длиной 250 символов графическим мелким немоноширинным шрифтом с автопереносом - 9,66

 

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

[prottoss 0]

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

 

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

 

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

 

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

 

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

[AndyBig 8]

BVUУ меня есть этот документ, но он скомпилирован на основе родного даташита на контроллер, просто в нем более доходчиво и упрощенно расписаны основы работы с контроллером. В этом документе имеются тайминги самой шины, но не выполнения команд, например, запись байта, установка пикселя, установка внутреннего указателя памяти...

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

Я думаю, что нет смысла проверять состояние ЖКИ. Есть смысл построить алгоритм так, что бы время исполнения алгоритма превышало предполагаемое время работы ЖКИ по выполнению команды МК.

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

Что тайминги выполнения команд не найду - согласен :).

[prottoss 0]

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

 

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

[AndyBig 8]

Вы считаете, что ввод функции 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". Кроме того, еще в одном месте накладывается ограничение только максимальной частоты, но не минимальной. И приводятся значения РЕКОМЕНДУЕМЫХ частот при различных комбинациях матрицы дисплея.

Сам даташит прикладываю :).

T6963C.rar

[prottoss 0]

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

Сам даташит прикладываю :) .

 

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

 

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

 

 

 

 

 

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

 

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

[AndyBig 8]

Я переписал процедуры проверки статуса дисплея на асме, при незанятом дисплее проверка проходит чуть меньше 2 микросекунд (1,9).

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

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

[Rash 0]

Русский даташит по T6963

http://www.gaw.ru/html.cgi/txt/lcd/chips/t6963/index.htm

 

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

T6963_rus_.ZIP

[AndyBig 8]

Переделал слегка...

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

 

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

lcd_t6963.rar - библиотека.

lcd_t6963.rar - хидер со шрифтами, добавлен шрифт крупных цифр.

font_nums_big.bmp - вид шрифта крупных цифр.

fonts.rar

[prottoss 0]

Переделал слегка...

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 мс

 

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

 

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

[AndyBig 8]

По поводу заливки, очистки и инвертирования - сорри, ошибся :). Чет не то посчитал :). Но я еще не оптимизировал эти процедуры.

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

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

 

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

[AndyBig 8]

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

[prottoss 0]

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

 

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

 

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

 

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

 

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

[AndyBig 8]

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

[proba 0]

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

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

только вот где-то читал, что лучше for(;;) исползовать, чем while(1) .