Заголовок сообщения: Графический интерфейс для STM32F103RBT6 проблемы
Добавлено: Ср сен 24, 2014 19:25:44
Родился
Зарегистрирован: Вт окт 22, 2013 05:16:19 Сообщений: 12 Откуда: Томская обл. г. Колпашево
Рейтинг сообщения:0
Здравствуйте! Недавно приобрел себе отладочную плату MINI-STM32-V3.0.
Поигрался с демонстрационной версией прошивки и ее исходниками. Так как нет исходников на графический интерфейс решил написать GUI для себя. Написал функцию, которая выводит окно по заданным координатам.
При выводе окна поверх другого возникает вот такая картина Спойлер Ссори за качество!! Фотал на телефон(( Пробовал создать массив и в него копировать содержимое той области экрана, где должно вывестись окно. А потом выводить окно. Но как оказалось у мк слишком мало озу!!! Другой способ требует перерисовку экрана целиком, что требует много времени и само обновление заметно.
В демо прошивке этот момент как то осуществлен и озу хватает для этого. Дочерние окна выводятся поверх основного окна.Их можно перемещать без такого эффекта. как у меня. При этом экран не нужно перерисовывать полностью. Все как мне нужно, только нет исходников
Дисплей с контроллером ili9320 320 x 240. 16bit цветов .
Даже если у тебя было бы 8 бит на пиксель - это уже 76800 байт... а у контроллера 20000 байт RAM... т.е. даже видео буфер в РАМ не сделать... а тем более как то хранить или обрабатывать графику - вообще не вариант с этими контроллером и дисплеем...
Так что в твоем случае можно сделать в РАМ только символьный буфер дисплея и его уже использовать для рефреша и отрисовки дисплея. Но тогда дисплей будет жестко разбит на знакоместа, т.е. рамки окон тоже рисовать псевдографикой... тогда можно будет сохранять данные под вновь создаваемыми окнами...
Например если символ будет занимать 8х12 пикселей, то это получится 40 символов по горизонтали и 20 строк по вертикали... Тогда, весь буфер экрана в РАМ займет 800 байт... тогда в принципе, хоть весь экран сохраняй перед рисованием нового окна... ну а если только конкретное место сохранять, то вообще получится очень много возможных вложений...
Даже если у тебя было бы 8 бит на пиксель - это уже 76800 байт
Для построения окон меню в обычной программе ИМХО достаточно 4 бит на пиксель. Бордюры окон можно делать графикой, а содержимое - тестом. Т.к. адресация экрана по-точечная, то в буфер можно сохранять только тот участок текста в окне, который будет закрываться новым окном. Алгоритм примерно такой: Каждое окно описывается текстом и координатами. При закрытии окна выводится только текст перекрытой области. У использованного Вами контроллера есть возможность не задавать координаты каждой точки при выводе символа. Можно выводить последовательно все точки по высоте символа без ввода нового адреса. Это сильно ускоряет вывод. upd Только что посмотрел функция ili9320_PutChar выводит по-точечно с заданием адреса каждой точки. Если правильно сделать таблицу символов, то скорость вывода можно увеличить процентов на 50. Сейчас на каждую точку дается команда установки адреса, что занимает 4 передачи по шине данных для каждой точки. т.е на 8 точек 32 передачи, а можно получить 11 передач на те же 8 точек. Примерно так:
Код:
void display_ascii(unsigned int x, unsigned int y,unsigned int w_color,unsigned int b_color) { unsigned char i,n,k=0; unsigned char str; unsigned int OffSet,z; x+=6; while(1) { if (lcd_buffer[k] == 0){ return;} z=lcd_buffer[k]; OffSet = (z+1)*6; for (i=8;i>0;i--) { str=ascii_lib[OffSet-i]; Set_ramaddr(x+i,y); for (n=0;n<8;n++){ if ( str & 0x01 ){WMLCDDATA(w_color);} else {WMLCDDATA(b_color);} str>>=1; } } x += 6; k++; }
Заголовок сообщения: Re: Графический интерфейс для STM32F103RBT6 проблемы
Добавлено: Вс сен 28, 2014 23:54:52
Родился
Зарегистрирован: Вт окт 22, 2013 05:16:19 Сообщений: 12 Откуда: Томская обл. г. Колпашево
Рейтинг сообщения:0
Внимательно посмотрел функцию ili9320_PutChar. действительно можно ускорить ее выполнение. Вот только таблицу символов переписывать нужно. Может кто подскажет какую-нибудь программу для создания шрифтов? Вручную думаю долго будет писать!!
Посетила идея подключить внешнее sdram. Стоит это делать без fsmc?
Недавно понадобилось выводить информацию на LCD 400х240 Был организован терминал по стандарту EGA. 16строк по 50 символов. 2 байта на знакоместо. Оформлено в виде окна, без сохранения фона.Поддерживаются управляющие символы http://vg.ucoz.ru/forum/10-211-6#4925 Обсуждение здесь
вы думаете что любой ARM в 32 бита - это сразу - решение любого вопроса?
зачем любого? если конкретно здесь человек, используя АРМ, несколько цветных квадратиков не может нарисовать, ибо "много времени и обновление заметно".
Люди на дисплеях видео крутят, применяя PIC-AVR среднего уровня, а тут 32-х битный АРМ...
Ну так вы хоть бы намекнули, что предлагаете это делать с помощью SD или HDD... Атож цитируете сообщение с упоминанием 20кб ОЗУ контроллера, и тут же утверждаете что этим можно видео крутить...
В памяти не обязательно хранить попиксельный образ экрана. Можно в памяти создать конечный список объектов, находящихся на экране, и в зависимости от их порядка на ходу вычислять и генерировать их изображения. Например объект "окно" имеет свойства: 1)размеры (x,y) 2)положение на экране (x,y) 3)заголовок 4)основной текст И т.д.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
...
