Наконец, дошли руки до нового проекта. Изучил, насколько мозгов хватает. Мне непонятны некоторые моменты.
1. Допустим я хочу работать с LTDC в режиме L8 через CLUT. 565 на выходе. Вроде бы всё понятно никаких проблем не вижу.
При копировании цветных картинок тоже проблем не вижу. Получается что их надо кратными 4 точкам делать да и запускать в 32-ух битном цвете 1 в 1.
Фонты я сделал L4 b вот тут проблема. Либо вручную разворачивать L4 в L8, либо пробовать обычным DMA память - память, источник байт, получатель 16 бит, на предварительно очищенную память (если такое есть ещё). После чего делать альфа преобразование с цветом фонта. и потом прямое копирование DMA2D.
2. Допустим я хочу работать с LTDC в режиме 565 на прямую, а цветные картинки выводить через LUT. Вот тут проблема. По описанию CLUT имеет 2 режима 32/24 бита. Я что-то не пойму. То есть если я хочу преобразовать L8 -> 565(16), то такой возможности в DMA2D нет? И L4 -> 565 тоже нет. Или я чего-то недогоняю?
PS: Нашёл в регистре (DMA2D output PFC control register (DMA2D_OPFCCR)) Color mode: These bits define the color format of the output image. И там режим RGB565. То есть вариант работы 2 просматривается.
Для варианта L4 -> 8, только косвенные подходы. То есть сформировать CLUT на две точки Получится конструкция типа L4L4 -> L8L8.
Правда размер LUT не маленький 256 * 3 = 768 по минимуму. Вроде бы где-то читал, что можно FLASH таблицу использовать.
Короче буду думать пока. Наверное склоняюсь к варианту 2.
===
Если есть кто реализовывал аналогичные варианты - откликнитесь. Любопытно кто как делал.

Уже обсуждали - полноценно использовать ускоритель можно только если фреймбуфер в формате 565 или выше.

Спасибо.
А всё же. Кто-нибудь реализовывал графику ориентируясь на DMA2D? Косяки вылазят какие-нибудь?

Вечер добрый !
Тут лучше начать с "конца" - какая нужна итоговая графика ... т.е. X*Y*Color ?
В дискавери-429 все смотрится замечательно, ибо "четверть-VGA" и видеобуфер можно разместить в SRAM.
Но когда доходит дело до реала, например 800x480xполноцвет (размещение видеобуфера в SDRAM) то отрисовки
начинают напрягать. Совсем становится грустно если еще на все это накладывается работа проца с SDRAM.
Тут он становится ощутимым конкурентом и как результат - срыв синхронизации.
В итоге - палитра + NOP-вставки при обращении к SDRAM в цикле ... увы ...

если с SDRAM проблемы, то почему не подключить обычную SRAM в качестве видео буфера, ну или использовать SSD1963 на больших разрешения (800x480)

А можно не размещать в SRAM и разместить в SDRAM, благо она там есть.
Что-то не заметил, чтоб при работе видеобуфера из SDRAM что-нить дергалось.

Модно я здесь спрошу не совсем в тему?
Есть дисплей RGB 24 бит c aliexpress, можно ли его подключить в режиме 16 бит? На форуме микрочипа проскакивало якобы LSB0...2 подключить к LSB3, кто-то советует посадить неиспользуемые пины на землю. Кто в курсе, как правильно?

Самым правильным будет узнать тип контроллера, на котором сделан дисплей, и в datasheet-е посмотреть как включается 16-разрядный цвет.

никак, это готовый модуль с интерфейсом RGB 24 bit
вот такой

И что документации на него нет никакой?

Есть даташит с распинвокой и таймингами

Если подключить BIT0..2 к BIT3, то "вес" последнего увеличится до BIT4-BIT0 и получится ерунда.
Можно заземлить или подключить к BIT7, если жаль потерять 3%.

Да, действительно... спасибо за подсказочку!

Может показаться невероятным, но обычно амеры "http://www.tianma-usa.com/web/uploads/controller/20130614175157_IC%20Spec%20Request.pdf" не жадничают.
Особенно если прикинуться студентом.

"... если с SDRAM проблемы, то почему не подключить обычную SRAM в качестве видео буфера, ну или использовать SSD1963 на больших разрешения (800x480) ..." ©

"... А можно не размещать в SRAM и разместить в SDRAM, благо она там есть.
Что-то не заметил, чтоб при работе видеобуфера из SDRAM что-нить дергалось..." ©

- похоже нужно дождаться пятницы и адекватных сообщений ...
P.S. Доктор, а я что сказал ?
P.P.S. ну какой нафиг еще один видеоконтроллер ежели на борту 429-го есть свой ?! дык и я не заметил в QVGA ...

тут ситуация другая, если дисплей в строго такой конфигурации,то по-другому они не сделают. либо в шлейфе должны быть доп. управляющие сигнальные линии

На текущий момент применяю дисплей 4.3" 480х272. Но планирую изделие выпускать и с 7". С цветом определился буду делать 565.
Графика у меня, скажем, офисная. То есть видео, мне ни разу не надо. ОЗУ планирую внешнее. Пока делаю на 429, но планирую попозже переехать на 746 какой-нибудь.
Во внешнем озу пока не планирую ничего кроме видеобуферов.
Не совсем понимаю, как там могут какие-то срывы синхронизации быть? Что-то совсем в мозги это не лезет.
Я работал с таким дисплеем на LPC2478 - это вообще ARM7 100MHz. И он у меня справлялся с задачей. Здесь мы имеем CM4F с матрицей шин нового поколения и с тактовой 180МГц.
Я планирую навертеть по-максимуму. То есть 2 Layer, DMA2D практически везде. Фонты я уже сформировал L4.
Пока пишу нижний уровень. GUi буду писать свою.


А какие проблемы? Просто заземлите неиспользуемые биты.

Как оказалось никаких Можно заземлить, но лучше на MSB7 подать

Да, интерфейс здесь RGB - без вариантов, а вот выбор разрядности цвета в соответствующем регистре (а может и не в одном) наверняка есть. И значит, надо будет физически R,G,B[1..0]
не сажать на "0", а без выкрутасов подключать на LCD_R,G,B[1..0], что самое правильное.
Вот просто, тупо, pin-to-pin шина TM060RDH03 - выводы LTDC.

Да понятно, что так правильно, но у меня всего осталось на эту шину 16 бит, но мне не смертельно, там промышленный девайс и мне его не девочкам показывать

Не загружайте человека ерундой. Какие регистры? Как вы их программировать собрались? Где вы видите линии команд?
Представьте, что там стоит ЦАП вот и всё. На данный контроллер надо просто подать тактовую с формировагнием тактирования точки, строки кадра.

Не надо так нервно реагировать. Нет причины.
Найду datasheet, прочитаю, расскажу.

Я уже отнервничал своё. )) Даташит приведен - почитайте. Он абсолютно стандартен, поэтому и называется RGB. Достаточно посмотреть цоколёвку разъёма. Там всё видно.
Контроллера (в вашем понимании) нет. Поэтому используется внешний контроллер.

Так 72 вродеж было?

Вроде бы со всем разобрался, но некоторые вопросы всё же есть.
Разбирался с работой DMA2D. Вроде уже всё устаканилось в голове. Так пару вопросов которые можно и натурным экспериментом... (По поводу FIFO буфера)
Когда разбирал просматривал пример от ST для платы "STM324x9I_EVAL" из куба STM32Cube_FW_F4_V1.11.0\Projects\STM324x9I_EVAL\Applications\STemWin\STemWin_SampleDemo\EWARM
Там как раз есть работа с DMA2D а экранчик по RGB подключён.
И вот там непонятка есть...
Вот типовой пример работы с DMA2D

В целом всё понятно. Из текста видно что завершение транзакции они ожидают полингом.
Это, в принципе, не исключает обработку прерывания ....
Хотя при инициализации я не вижу его ...

Если посмотреть, к примеру в том же файле ...

То видно что на LTDC прерывание обрабатывается ...
Это же видно и в файле проекта stm32f4xx_it
Там есть обработчик LTDC_IRQHandler, но нет обработчика DMA2D_IRQHandler....

Но в приведенном примере я вижу:
DMA2D->CR = 0x00010000UL | (1 << 9); /* Control Register (Memory to memory with pixel format conversion and TCIE) */
То есть разрешаются прерывания по трансферу.
Это как? Хомут? И как у них это работает?
Кто прокомментирует?

Короче пишу на всех парах приложение. Сейчас лабаю gui. Всякие там кнопочки и прочие win элементы. Пишу с нуля. Под десятку затачиваю... )) Везде ускоритель использую.
В принципе даже поворот можно делать, хотя и есть нюансы (нет отрицательного смещения на строку). Можно линии выводить, текст, иконки с несколькими видами сжатия.
Удобно, что работает под отладчиком.
Уже обнаружились всякие мелочи. Пока комментировать не буду, тока вчера ночью примитивы запустил.
---
Пример, который упоминал, постом выше, как раз показывает как не надо делать. Показывает отличие примера, от коммерческого ПО. ((

Нужно больше гуев, хороши и разных=) Чем не устроили готовые решения ГУЙ (там уже по всем граблям люди прошли уже вроде)?

Это где? В GUI от uCOS? В смысле StemWin или как она там ...
А вы её смотрели? ))

смотрели, не всё гладко, но полностью написать свою не решился. Проще их баги исправлять перехватом сообщений и добавлять виджеты. Если б её исходники последних версий, то вообще проблем бы не было, т.к. многие их недочёты тянуться с версий 3xx и никто их не исправляет.
Интересно будет посмотреть ваш вариант по сравнению с emWin.

Человек же четко написал чем не устроили. (Зачем так акцентировать внимание именно на этом слове "ГУЙ"??) И написал также, что хочет разобраться до конца и пишет периодически об этом. Но вот после подобных заявлений наверно он начинает думать: "А нафига? Зачем я тут буду что-то писать если оно никому не надо?" А если посмотреть шире, на другие подобные темы/проблемы, то в итоге получается, что их авторы замыкаются в себе в большинстве случаев и в одиночку улучшают софт и пр. Т.к. некоторым оказывается это и не нужно вовсе. Вот так вот.

У меня самописное от начала и до конца. В начале страшно было. Попробовал нечто, скачанное с тырнета, и увидел, что это унылое тормознутое гамно. Сделал своё - оказалось совсем не страшно. К тому же у меня нет вот этих ваших пересекающихся окошек и прочих головняков. А сейчас в моде минимализм а-ля ведроид и вынь10 - там совсем всё просто.
А про грабли вы совсем не подумав ляпнули. Нет там никаких граблей. Всё просто и понятно. Просто нужно взять и сделать.

Ляпаете здесь Вы, я говорю исходя из опыта большого числа людей. Вы пробовали "нечто", а специалисты используют наработки, которые уже прошли Ваши стадии прыщей=) Если Вы готовы тратить свое время на написание готового, вместо того, чтобы направить его на другие вещи - дело Ваше, как в прочем, и каждого другого специалиста. Искренне желаю Вам удачи! ПС. да, свой компилятор и своя библиотека С тоже лучше чем скаченное "нечто" с тырнета.

Я не демократ, мне число людей по барабану. Мне качество нужно.

В таком случае библиотеку С и компилятор ARM Вы обязаны переписать с нуля. Без обид, но писать это самостоятельно - пустая трата времени


Прошу прощение за бестактную просьбу - можно глянуть часть Вашего кода оконного менеджера? Просто для успокоения любопытства. Неужели все так тривиально?

Демократ в Вашем понимании как-то отличается от его классического определения?

Это обобщение останется на Вашей совести.


Нельзя. Его нет.


Я в словарь не смотрел. Понимайте как хотите.

Благодарю за ответ. Вы полностью удовлетворили мои интересы


Да, лучше БУДУ писать то, что никому не надо=) Я имел ввиду, что взять готовый функционал и на нем реализовать свою идею проще, чем тратить время на написание гуя с нуля, а потом поверх его реализовывать свои идеи функционала. А то получается, что хотел написать терминал оплаты с графикой, а увяз на реализации ГУИ, вместо решения задач функционирвания и безопасности и удобства работы... как то так. Да и ГУЙ написал по причине лени писать GUI, ни в коем случае ни по какой другой причине

Например? Где "хороший и разный" гуй взять? Чтоб его можно было портировать в свой проект за адекватные сроки и усилия??
ЗЫ. Тоже писал свой интерфейс с нуля. Требовалась работа с несколькими окнами сразу, полноцветная графика с прозрачностью в формах и вне их, а так же подгружаемые ресурсные файлы форм, подгружаемые несколько типов шрифтов, до 64 виджетов на форму и т.п.
Работа не простая, скажу честно, много выявлено было глюков и недочетов, особенно в механизмах перемещения, частичного восстановления "затертых" фрагментов форм, особенно с учетом 2хслойной графики и многое другое. Потратил где-то около 3х месяцев на это дело, но получил именно то, что хотел.

Где все это можно взять готовое, с уже огороженными граблями?

лучше бы веб-браузер под stm кто написал

ИМХО, EmWin полностью отвечает тому, что написали. Свои виджеты добавляются без проблем, с окнами и скролами тоже нормально.
Но если хочется расширить функционал, дописываешь свои обработчики сверху встроенных, переопределив callback ф-ции или полностью свои виджеты рисуешь и подтягиваешь их как стандартные. Глюки на виджетах тоже правятся, через свои callback ф-ции, практически все виджеты поправляю. Менеджер памяти тоже есть, может не самый лучший, но он работает, единственое, что он вроде без сборщика мусора или дефрагментации. Альфа тоже есть. Всё, что нужно это нормальный драйвер LCD, и в данном случае подкрутить DMA2D по максимуму это большой плюс. Пока что ни чего лучше EmWin для мк не встречал то, что видел самописное, не выполняло и половины того, что нужно.
Ни кого ни к чему не призываю, каждый решает сам, чем ему заниматься.



Поддерживаю, это было бы очень полезным решением.

Порой "никому не надо" и "надо лично тебе" - оказывается синонимом. Всё зависит от поставленоой (или стоящей перед тобой) задачи.
Что есть "хороший ГУИ"? Универсальный? Для продажи да, согласен. Но мне для реального прибора нет!!! Трижды нет. Мне не надо чтобы размер выводимой кнопки задавалось в пикселях. То есть мне масштабируемая кнопка не нужна. И в этом случае построение этой кнопки на базе примитивов, которые используют пиксельную графику (ни разу ни с ускорителем), можно заменить несколькими выводами графической области. С преобразованием. Что увеличивает производительность в десятки раз!

Я писал несколько ГУИ. Опыт моей работы показывает, что драйвера, работа с железом, интерфейс пользователя и прочие мелочи составляют в лучшем случае 10% работы. Пишутся и вылизываются на начальном этапе, и как правило к ним не возвращаешься... Иногда расширяешь функционал, да и всё.
Применял и некоторые готовые. Из готовых мне больше понравилась идеология Микрочиповского. Недостатки те-же что и у uCOS-овского. Универсальность от железа, При попытке увязать конкретное железо, видишь что надо всю идеологию менять.

Вот в частности, у меня прибор коммерческого учёта энергоносителей. Месяцами и годами не выключается. В текущем меню более 500 пунктов. Текст составляет более 50000 строк. В пятницу звонили с ГродноАзота (некоторые вопросы были) там труба - 170 тыс м3 газа в месяц. Стоит FreeRTOS. У неё свой менеджер кучи. И тут Вы пишете "Менеджер памяти тоже есть, может не самый лучший, но он работает, единственое, что он вроде без сборщика мусора или дефрагментации.". Кучу у меня использует, в том числе Ethernet. У меня как HTTP сервер, так и TCP Modbus. Мне что потом искать почему это всё падает раз в месяц? Причём часть в закрытых библиотеках?
PS: в моём посте 25 приведен конкретный описанный мной хомут в примере от st при привязке ускорителя к ГУИ. При чём на самом деле там 2 хомута. Это я при тестировании на реальном железе увидел. Хомуты не критичные, не спорю. Видно что дралось из другого места и не вычистилось до конца. Почему никто не показал свою реализацию подключения? Видно там и общий подход... Применить DMA и остановить процессор на время выполнения операции. Это сильно конечно .... Нечего сказать. Даже гуёвина от Микрочипа при отсутствии ос позволяла отрабатывать в неблокирующем режиме ...

при удалении окна память высвобождается, но вот каким образом я не знаю, т.к. когда закрываю все окна, память возвращается к значению которое было (иногда +/- 10 байт). Утечки памяти там я не обнаруживал, если только сам её не высвободил. Лучший аллокатор или нет, возможности оценить нет, так он закрыт. Под него выделяется своя куча, так, что вашему менеджеру он не помеха. Как и писал раньше каждый решает сам, чем ему заниматься.
Про работу DMA я ни чего не писал, так что не пойму к чему это.
Запускал LCD со встроенными мк, на 429 пока перепрыгнуть не успел, хотя в ближайших планах. Интересно какие там грабли, т.к. скорость вывода сильно зависит от возможностей драйвера, а не только как GUI пиксели закрашивает.

Так я писал. Графический ускоритель - это DMA2D. В исполнении ST, по сути, обычный DMA канал умеющий копировать квадратную, а не линейную область памяти, с попутным преобразованием содержимого.
Для чего я его у себя приспособил, на сегодняшний момент:
1) Вывод прямой (вертикальной и горизонтальной).
2) Заливка области цветом.
3) Вывод текста. (Представляет собой вывод символа из сжатого состояния А4). При повороте используется программная часть (пока).
4) Вывод картинки из сжатого состояния L8.

Рассмотрим что есть отображения виджета, в общем случае. Вывод фона виджета с распаковкой L8 за 1 или N раз в зависимости от типа виджета. Вывод ндписи и/или иконки с распаковкой L8.
То есть всё делается ускорителем.

Теперь к вопросу о динамическом выделении памяти. В целом у меня отторжения нет. Я его использую. Использовал и для гуи. Но, в данном случае для себя не вижу смысла. У меня статические экраны. Они представляют собой окна с набором виджетов. Вырежу пример из прошлого проекта...

И есть описание самого объекта... ну например

Таким образом вся структура экранов прибора лежит у меня во флэши, элементарно редактируется.
В озу у меня расположены будут только свойства виджета... Ну там

Про ускоритель понятно, но это драйвер и на какой гуи его завязать без разницы, это однозначный плюс. Как дойдут руки, тоже буду подключать.
Разница в том, что emWin изменять размер, открывать/закрывать окна, наложение окон и т.п. Это всё я использую, поэтому не вижу смысла хранить в статике параметры окна которое может удалиться в любой момент. Написать это всё с нуля нет времени, а некоторое не имеет смысла. Подходы там я некоторые бы переделал, но нет последних исходников.

И как там сделать загружаемые файлы ресурсов, шрифтов?? К тому же использование динамической памяти - это зло в квадрате, неважно, какой там менеджер памяти...
Ну а это "Глюки на виджетах тоже правятся, через свои callback ф-ции, практически все виджеты поправляю." - в моем понимании вообще что-то с чем-то...
ЗЫ. раз уж EmWin считается лучшим, думаю пора свой продавать



Вот реально можете объяснить - зачем?? И что он делать будет способен. Я к тому, что на 2х ядерных ПК с частотами по 2ГГц с 2гигами оперы и то тормозит все это...



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

С точностью до наоборот. Начнёте подключать - поймёте.

Какое отношение работа с окнами имеет к динамике? У вас при создании окна выделяется память и инициализируются объекты. При закрытии окна - освобождается память. У меня просто при создании окна, программе которая отрисовывает, передаётся указатель на готовое окно с объектами. готовое окно размещено во флэши. А окна создаются на этапе компиляции.
Динамические объекты нужны только если вы на этапе компиляции не знаете как будет выглядеть ваш экран. Например, если вы делаете дисплей для ПЛК, и поставляете программу редактирования, то целесообразнее делать динамическую гуи. Статическая будет больше ресурсов забирать.
Для наглядности: если положение кнопки известно на этапе компиляции, то для статического объекта у вас во флэши находятся координаты x и y. Если неизвестно, то во флэши находится указатель на координаты, которые уже находятся в оперативной памяти. Для динамического объекта все поля объекта будут находится в оперативной памяти.

возможно


Есть виджеты со статическим расположением, но имеющие возможность перемещения. Есть виджеты которые создаются пользователем в зависимости от параметра(ов) которые нужно отображать (вроде ПЛК).
В EmWin тоже можно поместить структуру во флеш, с параметрами виджета или меню (координаты и некоторые свойства), только всё равно под каждый виджет будет выделятся память в куче GUI, т.к. параметры виджета могут изменятся, и не важно нужно Вам это или нет. Например у меня в сумме наверное порядка 100 виджетов, может и больше не считал, некоторые создаются пользователем, если под них делать всё флеш просто устанешь. А главное зачем, я написал виджет и потом размещаю его где хочу и как хочу, и в любой момент могу изменить его свойства, а если он не создан, то память не расходуется. А если захочу растянуть окно, то и виджет может растянутся вместе с окном, использую такой приём в диалогах со скролом или во всплывающем диалоге графиков. Типы переключения экранов аля Андройд мне не нравятся, привык к классической Винде
Во флеше сидять только начальные координаты и размеры окна, всё остальное через свойство виджета, иногда просто копипастом или написав на часто повторяющиеся объекты функции настройки.

Вот как раз из-за этой главной причины мне не подошел емвин.

ну тут каждому своё, мне он подходит как раз из-за этой причины и не только. Для меня главное производительный драйвер и тут DMA2D должно быть в помощь.

Если не секрет, зачем такие навороты? Я понимаю в случае виджетов listbox и edit, а в остальных зачем?

есть ещё виджеты для которых это необходимо как: график, всякие стрелочные виджеты, прогресс бар и т.п., которые можно изменить в зависимости от того в каком объёме выводить информацию и сколько их одновременно нужно. Или создать матрицу editbox для вывода параметров, но нужно изменить во всех шрифт (а соответственно и размер), или изменить эту матрицу во время работы (либо кол-во строк или столбцов), тоже самое можно создать из поля кнопок при необходимости. Особенно если это всё в разных окнах и пользователь сам выбирает, что ему нужно в этот момент. Применение в системах диагностики.