Гуй для микроконтроллера

[VoVaN]

Итак, гуй для большого АРМа и большого ТФТ я уже написал. Теперь взвалили задачу посложнее. Нужно написать гуй для атмеги8 и маленького (133*64) ч/б дисплея работающего по И2Ц.

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

Данные в память дисплея пишутся побайтно (он организован как 133*8, т.е. один байт - столбец из восьми пикселей) или пакетно (ну, соответствует спецификации И2Ц). Читать из памяти дисплея нельзя.

Плохое решение навскидку.

unsigned char FrameBuffer[8][133];
unsigned char ChangingMask[133];

т.е. фреймбуфер редактируется попиксельно (туда будет, собственно, рисоваться гуй, текст, графика и.т.д), и при каждом изменнии устанавливается единица в соответствующем разряде соответствующего элемента маски обновления; периодически маска просматривается на предмет ненулевых битов, из фреймбуфера выбираются соответствующие байты и отсылаются в ЛЦД.
Вроде всё хорошо (в частности, доступный на чтение буфер и оптимизация перерисовки), однако только под это нужно 1197байт памяти, что слишком много.


Хорошее решение - ???

[ustas]

А как вы на "бумаге" распланировали gui? Есть решение по размещению текстов, элементов управления gui?

[VoVaN]

Ну, в целом - да, но пока что вопрос стоит в эффективном взаимодействии контроллера и дисплея.

[ustas]

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

[Lester]

Сообщение от VoVaN

Хорошее решение - ???

раз памяти мало, то прийдется ее экономить и изменения на экране применять не глобально, а накапливать, т.е. после:

push_pixel( x, y, 1 );

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

Lester добавил 20.08.2009 в 09:48
правда упаковка данных в очереди - отдельно стоящая задача, можно например сделать что-то вроде интерпретатора:

00 + координата( сколько там нужно бит ) - сменить Y;
01 + координата( сколько там нужно бит ) - сменить X;
10 - записать 0;
11 - записать 1;

т.е. в push_pixel анализировать какие координаты менялись и забивать все это в битсет

Lester добавил 20.08.2009 в 10:03
хотя конечно по задаче смотреть надо, например, посмотри какой максимальный регион у тебя обновляется, и если небольшой, то отведи не:

unsigned char FrameBuffer[8][133];

а например:

unsigned char x, y, width, height
unsigned char FrameBuffer[4][40];

и применяй уже его( то что предложил ustas )