Приветствуем на Форум Херсона. Форум Херсонской молодежи.. На данный момент Вы находитесь на форуме как Гость и имеете очень ограниченные возможности и права. Что бы писать или отвечать в темах, загружать картинки, файлы на форуме Вам нужно зарегистрироваться, что совершенно бесплатно. Регистрация очень быстрая, не откладывайте эту процедуру! Если возникнут проблемы с регистрацией напишите нам. |
|
Программирование Все вопросы по написанию программ |
Просмотр темы (Новые вначале) |
20.08.2009 08:23 | |
Lester |
раз памяти мало, то прийдется ее экономить и изменения на экране применять не глобально, а накапливать, т.е. после: 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 ) |
20.08.2009 08:19 | |
ustas | Дай что ли слайдов посмотреть , я все о том же, картинку бы с блоками, я так понимаю что у вас будет несколько вариантов "скринов" (страниц) со своими контролами. И скорее всего от этого и будете отталкиваться т.е. битовую матрицу разобьете на матрицы поменьше (контролы), сделаете "класс" (возможно не совсем корректно употребление данного слова в контексте работы с микроконтроллером) состояния для каждого контрола и "класс" состояния для "скрина" (страницы). На скорую руку полистал, катастрофически мало информации по теме, тем более что я не в теме . Но я таки за подход - разбиение на мелкие элементы (декомпозиция) и каждый элемент (контрол) уже имеет ограниченное число отображаемой информации соответственно рулить такими маленькими матрицами проще. |
20.08.2009 08:04 | |
VoVaN | Ну, в целом - да, но пока что вопрос стоит в эффективном взаимодействии контроллера и дисплея. |
20.08.2009 07:33 | |
ustas | А как вы на "бумаге" распланировали gui? Есть решение по размещению текстов, элементов управления gui? |
19.08.2009 22:48 | |
VoVaN |
Гуй для микроконтроллера Итак, гуй для большого АРМа и большого ТФТ я уже написал. Теперь взвалили задачу посложнее. Нужно написать гуй для атмеги8 и маленького (133*64) ч/б дисплея работающего по И2Ц. Вопрос - в организации эффективного алгоритма работы с изображением при ограниченых ресурсах (нет тут тех восьми метров памяти и сотен мегагерц, которые позволяли ворочять несколькими видеостраницами, двумя десятками шрифтов и двумя сотнями иконок.). Данные в память дисплея пишутся побайтно (он организован как 133*8, т.е. один байт - столбец из восьми пикселей) или пакетно (ну, соответствует спецификации И2Ц). Читать из памяти дисплея нельзя. Плохое решение навскидку. unsigned char FrameBuffer[8][133]; unsigned char ChangingMask[133]; т.е. фреймбуфер редактируется попиксельно (туда будет, собственно, рисоваться гуй, текст, графика и.т.д), и при каждом изменнии устанавливается единица в соответствующем разряде соответствующего элемента маски обновления; периодически маска просматривается на предмет ненулевых битов, из фреймбуфера выбираются соответствующие байты и отсылаются в ЛЦД. Вроде всё хорошо (в частности, доступный на чтение буфер и оптимизация перерисовки), однако только под это нужно 1197байт памяти, что слишком много. Хорошее решение - ??? |