Доброго всем!"
Использую BG12864E на ATMEGA2561 для вывода катящегося мячика. Прокатить плавно мячик с одной стороны полуэкрана в другой не составило труда - с задержкой выводим массив байтов на экран и сдвигаем по горизонтали. Но вот прокатить этот шарик между полуэкранами - задача, т.к. как только он заезжает за правый край полуэкрана, он тут же появляется в его начале. Переключая полуэкраны нельзя добиться плавного заезда, т.к. объект во всю свою длину перескакивает на второй полуэкран и получается резкий рывок. До сих пор не могу понять как это можно сделать. Конечная цель - чтоб бильярдный мячик бегал по экрану, отталкиваясь от его краев.
Поделитесь идеей как это можно сделать?
Заранее, спасибо!!!

Сдвигайте не на экране, а внутри МК, в буферной памяти экрана. Если он (буфер экрана) у вас конечно имеется

Не совсем понятен этот момент. Может можно фото показать или видео?

Я сдвигаю следующим образом - вывожу массив байтов нашего рисунка начиная со след адреса строки, предварительно стерев предыдущую картинку.
Что вы имеете под понятием буфер?



Т.к. фотика под рукой нет, изобразил схематический 2 расположенных друг возле друга полуэкрана и шарик, бегающий по ним. DOC1 - это то, что я хочу.
DOC2 и DOC3 - это то 2 варианта, которые сейчас получаются.

Что-то не понятно по этим картинкам. Наверно придется выложить исходник и описание на дисплей. Или постучать ко мне в аську

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

Чтобы не отпугивать желающих Вам помочь, выкладывайте картинки скромнее по размеру и общедоступном формате:
Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файла

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

Буфер есть и в самом ЖКИ (то биш экранная память), у многих он доступен в обе стороны. Так что если в МК с памятью напряженка, можно и им воспользоваться. Правда тогда могут получиться упомянутые rezident`ом мельтешения

Вот боюсь как бы хватило памяти МК на то, чтоб прописать каждый адрес 128*64 дисплея.
Или хватит? Т.е. в ОЗУ прописать каждую байтовую позицию вывода - и их получится 128*64= 8192? так?
пробовал накладывать изображения - сильно мельтешит.
Также делал процедуру стирания после вывода предыдущего изображения - мельтешит также.



В даташите вот вроде не указывают наличия экранной памяти((

Не так. Забыли поделить на 8 --> =1024. На каждый пиксель вполне достаточно 1 бита


Конечно, зачем же отдельно писать о том чего НЕ быть не может?
Любая отображаемая картинка хранится в памяти ЖКИ (точнее, в памяти встроенного контроллера). Вопрос только в том, есть ли возможность ее читать.
Обычно у подобных ЖКИ есть возможность организовать либо последовательный интерфейс, либо параллельный. Обычно в случае последовательного читать нет возможности, а в случае параллельного - есть. Уточните по ДШ.

Выложите лучше исходник и даташит на дисплей (если он на Си). Так дело быстрее пойдет

я думаю это некий аналог МТ18264А. Так вот как я эту проблему решил. Там тоже полуэкраны. Я их "обьеденил" пишу в обе половины страницу и колонку, а далее начинаю из 128 байтного буфера писать в память дисплея "точки" причем при переходе между 63 колонкой и 64 (на этой границе меняются половины экрана 64 это 0 колонка второго экрана) выбирается второй чип или полуэкран и он пишет во вторую половину. Признак второй половины это 1 в 7 бите 00FFFFFF 01000000. Когда счетчик байтов доходит до этого момента логика автоматом выбирает другой чип. Рисунок на весь экран выводится корректно!

Спасибо.
Вот исходники.

код прграммы - здесь шарик перепрыгивает через границу экрана, но не переезжает через нее.




Когда дохожу до 64 колонки конец картинки начинает заезжать на текущий полуэкран в его начало. Тут единственный способ это наверное на 63 колонке побайтово читать хвостик шарика во второй экран, а потом обрезанную основную часть в первый. Затем во втором экране читать массив байтов шарика на 2-й байт раньше с конца, и в 1-м выводить без последних 2-хбайтов. Ит.д. Другого пока ничего и не придумаешь.

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

Судя по всему, у топикстартера затруднения с разделением двух абстракций: формирование и вывод изображения. При использовании "экранного" буфера в ОЗУ осознание различия пришло бы быстрее, но у него видимо нет для этого ресурсов.

Нафига? после 63 колонки переключить половины дисплея! следующий байт будет выводиться в 64 колонку (если вы предварительно установили во второй половине номер странички и колонку, с которой во второй половине начнется запись озу экрана)

У меня грубо говоря в контроллере "ОЗУ экрана" не разбита на половины. Составляет 128 байт выводится целиком последовательно сначала в одну потом в другую половину автоматом (за счет логики переключения половин дисплея в момент перехода с 63 на 64 колонку). Можно писать данные в любое место страницы дисплея. Хоть на границе между 63 и 64 колонкой пару байт вывести.

63 это 0x3F (00111111)
64 это 0x40 (01000000)
за признак переключения половин можно взять 7 бит! Что я и сделал

Исходники для дисплея для AT91SAM7A3 если планируете использовать естественно подредактируйте под свою схему) +У меня возможны ошибки с назначением ног в коментах, так как не раз все правилось) Но!!! Код весьма работоспособный! Рисунок (наш логотип) виводит корректно! И шустро! Частоту не считал, но где-то около 800 кГц. Задержки можете поставить свои)