ЖКИ BG12864E на ATMEGA2561, Передвижение рисунка между полуэкранами Опции

[Slavast]

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

[rezident]

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

[Slavast]

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

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

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

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

Прикрепленные файлы

 Doc1.doc ( 338 килобайт ) Кол-во скачиваний: 50
 Doc2.doc ( 337 килобайт ) Кол-во скачиваний: 39
 Doc3.doc ( 388 килобайт ) Кол-во скачиваний: 34

 

[rezident]

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

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

[Slavast]

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

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

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

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

[Diusha]

128*64= 8192? так?

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

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

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