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

 
 
> Вопрос новичка по бегущей строке
Mark71
сообщение Jan 15 2010, 08:50
Сообщение #1





Группа: Участник
Сообщений: 9
Регистрация: 31-03-08
Пользователь №: 36 358



Поднимаю в очередной раз уже избитую и давно поднадоевшую всем тему по организации динамической индикации в бегущей строке. Просто ни на одном из форумов, посвященой этой теме, не могу найти ответ на, казалось-бы, простой вопрос: какими програмными или аппаратными методами добиваются плавного движения текста (чтобы не было растяжения и сжатия при движении, скачков, при переходе с одной матрицы на другую).
У меня 16 светодиодных матриц 8х8, постолбцовая регенерация слева направо (хотя пробовал и наоборот, но улучшения не получил), соответственно скважность 8. Частота регенерации 100Гц (хотя пререпробовал много других частот), соответственно для одного пикселя частота 800Гц. Движение текста справа налево.
Привожу текст обработки прерывания для одного столбца c подробными комментариями:

CODE
#pragma interrupt_handler timer0_ovf_isr:10
void timer0_ovf_isr(void)________//вывод одного столбца(0-7) во всех 16 индикаторах на 1,25мс (1,25мс * 8 = 10мс = 100Гц)
{
unsigned char number_indic = 0,_//номер индикатора
____________gb_index, delay;__//номер позиции в графическом буффере
//number_col - номер столбца - внешняя переменная
ClrBit(PORTC,COL);___________//выключаем все столбцы (выводы дешифратора 1 из 8 в состоянии лог.1)
TCNT0 = 0xB2;______________ //перезагрузка таймера
tick++;_____________________//тикалка
//WDR();___________________//сброс сторожевого таймера
for (gb_index = number_col; gb_index < 128; gb_index += 8) {__//распихиваем данные из буффера в 574-е регистры по
_______________________________________________________//положительному перепаду
______________________________________________________//всего 16 итераций в этом цикле
______________________________________________________WR_BUS_DATA = graphic_buffer[gb_index];
______________________________________________________delay++; //задержка
______________________________________________________PORTB = number_indic; //выбираем индикатор
______________________________________________________number_indic++;
______________________________________________________SetBit(PORTB,WR_INDICATOR)
;__//формируем положительный перепад
______________________________________________________delay++; //задержка
______________________________________________________ }//end for
WR_BUS_DATA = number_col;__//выставляем на шину номер столбца
number_col++;______________//увеличение номера столбца (внешняя переменная)
SetBit(PORTC,COL);__________//включаем текущий столбец на всех 16-ти индикаторах на 1,25мс до следующего прерывания
if (number_col > 7 ) {
___________________ number_col = 0;
____________________shift_graphic_buffer(); //сдвиг графического буфера влево на одну позицию
___________________}
}

Понимаю, что все банально, тупо в лоб, без изысков, но текст двигается, но двигается с большими проблемами (см.выше)
shift_graphic_buffer() - по времени занимает 165мкс, если верить протеусу
Причем и в реально собранном устройстве и смоделированном в протеусе проблемы с движением одни и теже ( протеус рулит smile.gif )
Я даже не прошу исправить код, просто подскажите теоретически в каком направлении двигаться sad.gif
Скачок текста при переходе с одного индикатора на друой связан, как я понимаю, с увеличением паузы между 1-го столбцом одного индикатора и 7-м столбцом следующего. Фактически время между засветками равно времени двух регенераций. Вот и возникает скачок. И как с этим бороться?
Кстати очень сильное увеличение чатоты регенерации привело к более менее приличному результату, но яркость упала до еле различимой. Несколько циклов регенерации между сдвигами также улучшают ситуацию, но приводит к удвоению, утроению и т.п.
пикселов. Ведь как-то делают на частоте 75 или 100Гц регенерация-сдвиг-регенерация и текст без проблем бежит, вот только как...

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

Сообщение отредактировал Omen_13 - Jan 21 2010, 01:20
Причина редактирования: Оформление кода
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
Александр Куличо...
сообщение Jan 21 2010, 00:52
Сообщение #2


Местный
***

Группа: Свой
Сообщений: 256
Регистрация: 6-03-06
Из: Украина, г. Винница
Пользователь №: 15 017



Двойная буферизация не спасает от скачков между панелями. Бороться можно тремя путями.
Путь 1.
Сделать развертку по строкам, а не по столбцам. Если кол-во строк равно скважности, то такой проблемы не возникает. И при движении текста появляется эффект наклона букв и нет эффекта растяжения/сжатия Для "правильного" наклона вправо развертку нужно начинать с нижней строки. (в дальнейшем предполагаю, что строки нумеруются снизу) Алгоритм обычный - а) вывод с 0-й по 7-ю горизонталь б)сдвиг буфера влево на 1 вертикаль.
Если скважность 1:8, а кол-во строк 16 (2 панели одна над другой, каждая со скважностью 1:8), то при обычном подходе движущееся изображение будет "рваться" между панелями.
Для "правильного" отображения нужно организовать вывод на экран так, светящаяся активная строка развертки верхней панели "подхватывала" развертываемое изображение нижней панели.
Разъясняю:
Допустим, табло высотой в 16 точек состоит из 2х панелей, расположенныйх одна над другой. Каждая панель высотой в 8 точек. Развертка на панелях - снизу вверх, с 0-й по 7-ю строку. Развертка на обеих панелях синхронная, т.е. управление строчными ключами обейх панелей можно объединить. Таким образом, имеем 2 одновременно активных ключа. (2 луча, если проводить аналогию с ЭЛТ)
При отображении строка на верхней панели должна "подхватывать" изображение нижней, т.е. после 7й строки нижней панели 0-вая строка верхней должна продолжать отрисовывать тот же кадр. Так как оба ключа панелей работают одновременно, то нижняя панель в это же время должна рисовать уже следующий кадр изображения (возможно, уже сдвинутый влево на 1 точку). ТО есть мы дожны иметь 2 буфера - для верхней и нижней панели. и сдвиг изображения в буфере верхней панели делать на 1 кадр позже.

Проще говоря, изображение на каждой следующей (верхней) панели должно отставать ровно на 1 кадр развертки от изображения на предыдущей(нижней) панели, т.е. при регенерации 100Гц - на 10 мс. И так с каждой вышестоящей панелью (при высоте в 24,32,40 точек...).
Или выражаясь немного по-иному, каждый луч (лучем называю активный ключ, который пробегает с нижней строки нижней панели к верхней строке верхней панели) должен рисовать свой кадр. На строке высотой 16 точек таких луча 2 и, соответственно, в одно и то же время на строку выводится 2 разных кадра. И на каждый луч нужно иметь свой буфер.


Путь 2. Оставить развертку "по столбцам". Здесь эффекта наклона букв нет. Алгоритм реализации движения, собственно, ничем не отличается от первого пути. Принцип тот же. Только панели стоят боком. Но немного сложнее в реализации, так как здесь двумя или тремя буферами не обойдешся (ширина строки обычно > 24 точек). Насчет, эффекта растяжения/сжатия - ничег не скажу. На моей строке такого не наблюдал. Хотя на строках других производителей он мне даже понравился. Может, не наблюдал из-за того, что расстояние наблюдения строки было слишком малое. А от этого много чего зависит.

Ну, и 3-й путь (мой любимый) - статика. И для светодиодов полезно, и программировать проще некуда smile.gif. И побочных эффектов никаких нет. Благо, стоимость драйверов растворяется в стоимости хороших светодиодов.

З.Ы. "1 кадр развертки" специально выделил для того, чтобы отличать его от одного кадра генерируемого изображения. Т.е. когда одно генерируемое изображение выводится 2,3,4..... кадра.
Go to the top of the page
 
+Quote Post



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

 


RSS Текстовая версия Сейчас: 24th July 2025 - 23:37
Рейтинг@Mail.ru


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