Графический интерфейс для STM32F103RBT6 проблемы

[FreeDoom2010]

Здравствуйте! Недавно приобрел себе отладочную плату MINI-STM32-V3.0.

Поигрался с демонстрационной версией прошивки и ее исходниками. Так как нет исходников на графический интерфейс решил написать GUI для себя. Написал функцию, которая выводит окно по заданным координатам.

При выводе окна поверх другого возникает вот такая картина

Спойлер

Ссори за качество!! Фотал на телефон(( Пробовал создать массив и в него копировать содержимое той области экрана, где должно вывестись окно. А потом выводить окно. Но как оказалось у мк слишком мало озу!!!
Другой способ требует перерисовку экрана целиком, что требует много времени и само обновление заметно.

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

Исходник

[cahek80]

сделайте картинку побольше. у меня на 4К телевизоре не на весь экран разворачивается...

[shads]

сделайте картинку побольше. у меня на 4К телевизоре не на весь экран разворачивается...

Гениальный ответ ...
У меня тоже возникло подобное пожелание... только так ярко это описать я бы не догадался ...

[FreeDoom2010]

я так понимаю по теме ответа не дождусь!!

[shads]

Вроде бы у тебя там 20кб оперативки... это действительно - ничто - для цветного дисплея (((

А какие параметры дисплея, сколько на сколько пикселей ? Какая глубина цвета используется? какая максимальная глубина вложений окон планируется?

(Я вообще то в этом - 0 полный... просто мне это тоже может скоро пригодится...)

[FreeDoom2010]

Дисплей с контроллером ili9320 320 x 240. 16bit цветов . Хотелось бы 2-3 окна выводить поверх. Если ничего не придумаю придется искать другие решения!

[ArtDen]

По теме - научись фотографировать и уменьшать фотографии )

[FreeDoom2010]

На счет фотографий - исправлюсь

[shads]

Дисплей с контроллером ili9320 320 x 240. 16bit цветов .

Даже если у тебя было бы 8 бит на пиксель - это уже 76800 байт... а у контроллера 20000 байт RAM... т.е. даже видео буфер в РАМ не сделать... а тем более как то хранить или обрабатывать графику - вообще не вариант с этими контроллером и дисплеем...

Так что в твоем случае можно сделать в РАМ только символьный буфер дисплея и его уже использовать для рефреша и отрисовки дисплея.
Но тогда дисплей будет жестко разбит на знакоместа, т.е. рамки окон тоже рисовать псевдографикой... тогда можно будет сохранять данные под вновь создаваемыми окнами...

Например если символ будет занимать 8х12 пикселей, то это получится 40 символов по горизонтали и 20 строк по вертикали...
Тогда, весь буфер экрана в РАМ займет 800 байт... тогда в принципе, хоть весь экран сохраняй перед рисованием нового окна... ну а если только конкретное место сохранять, то вообще получится очень много возможных вложений...

[MisterDi]

Даже если у тебя было бы 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++;
    }

}

[FreeDoom2010]

Внимательно посмотрел функцию ili9320_PutChar. действительно можно ускорить ее выполнение. Вот только таблицу символов переписывать нужно. Может кто подскажет какую-нибудь программу для создания шрифтов? Вручную думаю долго будет писать!!

Посетила идея подключить внешнее sdram. Стоит это делать без fsmc?

[Sergi]

Недавно понадобилось выводить информацию на LCD 400х240
Был организован терминал по стандарту EGA. 16строк по 50 символов. 2 байта на знакоместо.
Оформлено в виде окна, без сохранения фона.Поддерживаются управляющие символы
http://vg.ucoz.ru/forum/10-211-6#4925
Обсуждение здесь

[MisterDi]

Посетила идея подключить внешнее sdram. Стоит это делать без fsmc?

Нет смысла. Без fsmc будет слишком сложно управлять SDRAM. Если использовать Static RAM, то можно, но ИМХО толку мало.

Может кто подскажет какую-нибудь программу для создания шрифтов? Вручную думаю долго будет писать!

Когда-то пользовался IconEdit и LCDicon.

[True]

Но как оказалось у мк слишком мало озу!!!
Другой способ требует перерисовку экрана целиком, что требует много времени и само обновление заметно

Вроде бы у тебя там 20кб оперативки... это действительно - ничто

Люди на дисплеях видео крутят, применяя PIC-AVR среднего уровня, а тут 32-х битный АРМ...

[shads]

Люди на дисплеях видео крутят, применяя PIC-AVR среднего уровня, а тут 32-х битный АРМ...

Ух ты... а можно примерчик... чтобы AVR или PIC среднего уровня - выводил видео на цветной 320х240 дисплей...

И кстати... вы думаете что любой ARM в 32 бита - это сразу - решение любого вопроса?

[True]

вы думаете что любой ARM в 32 бита - это сразу - решение любого вопроса?

зачем любого? если конкретно здесь человек, используя АРМ, несколько цветных квадратиков не может нарисовать, ибо "много времени и обновление заметно".

То, что вы не представляете, как это делается и не можете это сделать, не значит, что это невозможно.
Хотя, что бы не быть голословным, вот, по первым ссылкам из гугла
http://www.youtube.com/watch?v=wDr4hh4CybE
http://www.youtube.com/watch?v=IWRHRnUdFno

[shads]

Люди на дисплеях видео крутят, применяя PIC-AVR среднего уровня, а тут 32-х битный АРМ...

Ну так вы хоть бы намекнули, что предлагаете это делать с помощью SD или HDD...
Атож цитируете сообщение с упоминанием 20кб ОЗУ контроллера, и тут же утверждаете что этим можно видео крутить...

[True]

А как ОЗУ, место для обработки данных, связано с SD, местом(источником) для хранения данных? В общем, что б не болтать попусту - "вы не в теме".

[shads]

Ну да... "я не в теме"...
Я же писал

(Я вообще то в этом - 0 полный... просто мне это тоже может скоро пригодится...)

[ibiza11]

В памяти не обязательно хранить попиксельный образ экрана. Можно в памяти создать конечный список объектов, находящихся на экране, и в зависимости от их порядка на ходу вычислять и генерировать их изображения.
Например объект "окно" имеет свойства:
1)размеры (x,y)
2)положение на экране (x,y)
3)заголовок
4)основной текст
И т.д.