STM32 разработка GUI

[COKPOWEHEU]

jcxz, ну да, ну да. По DMA отправлять кусок фоновой картинки и куски всех кнопок с разными смещениями. Вместо того чтобы сделать по-человечески и рисовать линиями и прямоугольниками.
Ну и про "по частям" кому другому втирайте.

[Foxhound]

Итого в сухом остатке....
Я правильно понимаю, что все изобретают свои велосипеды?

[Zhuk72]

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

А тач-скрин к самому ЖК никак не относится.
При считывании информации с сенсора вы получаете координаты касания, к которым соотносите координаты графических объектов и так получаете управление.

Это то, что я понял недавно (и реализовал), впервые связавшись с графическим ЖК (ST7735).

[jcxz]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008854#p4008854"]jcxz, ну да, ну да. По DMA отправлять кусок фоновой картинки и куски всех кнопок с разными смещениями. Вместо того чтобы сделать по-человечески и рисовать линиями и прямоугольниками.
Ну и про "по частям" кому другому втирайте.[/uquote]Вижу, что ничего не поняли из того что я писал.
Выдохните и перечитайте ещё раз.

Добавлено after 2 minutes 56 seconds:
[uquote="Zhuk72",url="/forum/viewtopic.php?p=4009293#p4009293"]вывод одной точки.
Далее создаются или находятся железонезависимые функции графических примитивов:[/uquote]Если примитивы рисовать поточечно, то GUI будет работать со скоростью черепахи, сжирая все ресурсы CPU при этом.

[Reflector]

[uquote="Zhuk72",url="/forum/viewtopic.php?p=4009293#p4009293"]Для работы с цветными графическими дисплеями нужно иметь 2 основные функции: начальную инициализацию (с сопутствующими ресетами, ориентацией и пр.) и вывод одной точки.[/uquote]
Да, если хочется чтобы STM32 отрисовывал графику медленнее AVR, то именно так и нужно делать

[COKPOWEHEU]

Вижу, что ничего не поняли из того что я писал.

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

[jcxz]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4009312#p4009312"]Если вы неспособны сформулировать свою мысль так, чтобы ее можно было однозначно и правильно понять с первого раза, не стоит винить в этом окружающих. Попробуйте еще раз.[/uquote]Разжую предельно просто: В одном моём проекте используется цветной LCD 320x240 пикселей, на котором рисуется GUI. Рисуется в видеопамяти, которая находится во внутренней памяти STM32F4xx и пересылается затем в память контроллера LCD. Без использования внешней памяти. Скорость вывода - предельная для данного интерфейса подключения.
Начинайте думать как мне это удалось. При том что, как думаете:
[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008740#p4008740"]Угу. Учитывая, что в контроллере физически не хватит памяти даже на пол-картинки.[/uquote]
У кого-то "и на полкартинки не хватит", а у меня всё это заняло всего = 38400+4096 байт внутренней памяти МК.
Видимо всё дело в кривости рук.

[COKPOWEHEU]

Объем памяти для видеобуфера (поскольку вы говорите о видеобуфере как о едином целом, повода рассматривать отображение по частям нет) 320х240х2 = 150 кБ. Оперативки в контроллере stm32f103 всего 20 кБ. Мы ведь рассматриваем наиболее распространенный случай. Впрочем и в других контроллерах пускать на ветер 150 кБ вряд ли кто станет.
Отсюда вывод: реализовать все именно так, как вы описали невозможно.
Значит описание не соответствует действительности.

Начинайте думать как мне это удалось.

Вы ссылку мою смотрели? Даже не начинайте думать как мне это удалось.

[linkov1959]

Foxhound, Так есть же VTFT для STM32 у ME.https://forum.mikroe.com/
Все как на VB с формами и элементами управления. Нет поддержки SPI, но умельцы решают эту проблему. Я баловался с ILI9341.

[jcxz]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4009350#p4009350"]Отсюда вывод: реализовать все именно так, как вы описали невозможно.[/uquote]Ладно бы если-б только вашей квалификации не хватало, чтобы самостоятельно найти решение. Но вы даже не умеете прочитать и понять готовых советов как это делается, а ведь ничего экстраординарного нет:
[uquote="jcxz",url="/forum/viewtopic.php?p=4008752#p4008752"]Для GUI (без полупрозрачностей!) достаточно 4 бит на пиксел - и на весь видеобуфер вполне хватит внутренней памяти многих нежирных МК.[/uquote]

[COKPOWEHEU]

достаточно 4 бит на пиксел - и на весь видеобуфер вполне хватит внутренней памяти многих нежирных МК.

Хорошо, если вы не способны посчитать даже это, я помогу: объем всего видеобуфера для дисплея 320х240х(4/8) = 38400. Объем памяти 20480, чуть ли не вдвое меньше.
Если вы еще пять раз повторите подобную чушь, правдоподобнее она не станет.
.
Конечно, на подобных контроллерах рисовать GUI можно. Но обычно это делается послойно. Сначала из какой-нибудь постоянно памяти загружается фон, потом поверх него рисуются по одному элементы управления. При реакции на события перерисовываются только те элементы, которым нужна анимация.
Более сложный вариант - рисовать как в компьютерных играх чуть ли не трассировкой лучей: на какой координате (и соответственно цвету пикселя) каждого элемента соответствует каждый пиксель экрана. Такой способ более плавный, но гораздо более сложный и затратный по скорости.
В совсем мощных контроллерах - по крайней мере если на плате установлено очень много оперативки - можно уже пользоваться способом jcxz - выделить огромный буфер, отрисовать в него все, потом разом выплюнуть на дисплей.
.
Но по-хорошему, повторяю, не стоит идти на поводу моды и маркетологов: интерфейс в первую очередь должен быть удобным, что подразумевает наличие механических элементов управления и своего индикатора на каждый контролируемый параметр.

[Eddy_Em]

Да не нужен там такой огромный буфер! Разделить экран на спрайты 8х8 для цвета, понадобится не более 10 байт на спрайт, т.е. в 6.4 раза меньше, чем надо для попиксельного отображения. Правда, это все равно много.

[COKPOWEHEU]

Для обычных применений - разумеется не нужен. Осталось донести эту мысль до jcxz.
Достаточно, как я и описал, по очереди вывести все что нужно - фон, элементы управления и т.д. Ну мигнет оно при первой отрисовке, ну и что.
Но не забывайте о мощных системах, где уже полноценный процессор и полноценная ОС используется. Впрочем, там и полноценные графические библиотеки доступны. Ну хотя бы framebuffer / X11.

[jcxz]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4009679#p4009679"]Объем памяти 20480, чуть ли не вдвое меньше.[/uquote]Где 20480??? В STM32F469? Что за бред? Откройте мануал на него - прочитайте сколько там ОЗУ.
Вижу что вам очень хочется спорить, так что готовы нести любую чушь лишь бы спорить....

Добавлено after 1 minute 18 seconds:
[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4009809#p4009809"]Для обычных применений - разумеется не нужен. Осталось донести эту мысль до jcxz.[/uquote]Донесите лучше мануал на STM32F469 до себя, чтобы не нести всякую ахинею.

Эксперд млин....

[COKPOWEHEU]

Где 20480??? В STM32F469?

Нет, конечно. В stm32f103, мы же про него говорим.