LTDC + ChromART в STM, Проконсультируйте, кто работал. Опции

[SasaVitebsk]

Наконец, дошли руки до нового проекта. Изучил, насколько мозгов хватает. Мне непонятны некоторые моменты.
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.
===
Если есть кто реализовывал аналогичные варианты - откликнитесь. Любопытно кто как делал.

[Шаманъ]

Короче буду думать пока. Наверное склоняюсь к варианту 2.

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

[SasaVitebsk]

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

[DrGluck]

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



Сообщение отредактировал DrGluck - Mar 2 2016, 17:56

[Rash]

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

[adnega]

В дискавери-429 все смотрится замечательно, ибо "четверть-VGA" и видеобуфер можно разместить в SRAM.

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

[NaughtyFreak]

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

[Obam]

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

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

[NaughtyFreak]

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

[Obam]

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

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

[NaughtyFreak]

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

[aaarrr]

На форуме микрочипа проскакивало якобы LSB0...2 подключить к LSB3, кто-то советует посадить неиспользуемые пины на землю. Кто в курсе, как правильно?

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

[NaughtyFreak]

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

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

[Obam]

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

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

Сообщение отредактировал Obam - Mar 3 2016, 14:55

[DrGluck]

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

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

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

Сообщение отредактировал DrGluck - Mar 3 2016, 15:02

[NaughtyFreak]

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

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

[SasaVitebsk]

Тут лучше начать с "конца" - какая нужна итоговая графика ... т.е. X*Y*Color ?

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

Есть дисплей RGB 24 бит c aliexpress, можно ли его подключить в режиме 16 бит?

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

[NaughtyFreak]

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

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

[Obam]

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

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

[NaughtyFreak]

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

Сообщение отредактировал NaughtyFreak - Mar 4 2016, 11:37

[SasaVitebsk]

Да, интерфейс здесь RGB - без вариантов, а вот выбор разрядности цвета в соответствующем регистре (а может и не в одном) наверняка есть.

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

[Obam]

Не загружайте человека ерундой. Какие регистры? Как вы их программировать собрались? Где вы видите линии команд?

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

[SasaVitebsk]

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

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

[skripach]

LPC2478 - это вообще ARM7 100MHz.

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

[SasaVitebsk]

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

CODE

static void DMA2D_ConvertColor(void * pSrc, void * pDst, uint32_t PixelFormatSrc, uint32_t PixelFormatDst, uint32_t NumItems)
{
/* Set up mode */
DMA2D->CR = 0x00010000UL | (1 << 9); /* Control Register (Memory to memory with pixel format conversion and TCIE) */
/* Set up pointers */
DMA2D->FGMAR = (uint32_t)pSrc; /* Foreground Memory Address Register (Source address) */
DMA2D->OMAR = (uint32_t)pDst; /* Output Memory Address Register (Destination address) */
/* Set up offsets */
DMA2D->FGOR = 0; /* Foreground Offset Register (Source line offset) */
DMA2D->OOR = 0; /* Output Offset Register (Destination line offset) */
/* Set up pixel format */
DMA2D->FGPFCCR = PixelFormatSrc; /* Foreground PFC Control Register (Defines the input pixel format) */
DMA2D->OPFCCR = PixelFormatDst; /* Output PFC Control Register (Defines the output pixel format) */
/* Set up size */
DMA2D->NLR = (uint32_t)(NumItems << 16) | 1; /* Number of Line Register (Size configuration of area to be transfered) */
/* Execute operation */
DMA2D->CR |= DMA2D_CR_START;

while (DMA2D->CR & DMA2D_CR_START)
{
}
}

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

Код

void HAL_DMA2D_MspInit(DMA2D_HandleTypeDef *hdma2d)
{  
  /* Enable peripheral */
  __HAL_RCC_DMA2D_CLK_ENABLE();  
}

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

Код

void HAL_LTDC_MspInit(LTDC_HandleTypeDef *hltdc)
{  
  GPIO_InitTypeDef GPIO_Init_Structure;
  
  /* Enable peripherals and GPIO Clocks */  
  /* Enable the LTDC Clock */
  __HAL_RCC_LTDC_CLK_ENABLE();
....
  /* Set LTDC Interrupt to the lowest priority */
  HAL_NVIC_SetPriority(LTDC_IRQn, 0xF, 0);
  
  /* Enable LTDC Interrupt */
  HAL_NVIC_EnableIRQ(LTDC_IRQn);
}

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

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

[SasaVitebsk]

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

[lleeloo]

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

[SasaVitebsk]

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

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

[Rash]

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

[AleksBak]

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

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

[scifi]

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

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

[lleeloo]

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

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

[scifi]

Ляпаете здесь Вы, я говорю исходя из опыта большого числа людей.

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

[lleeloo]

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

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

Всё просто и понятно. Просто нужно взять и сделать

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

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

Сообщение отредактировал lleeloo - Apr 1 2016, 20:21

[scifi]

В таком случае библиотеку С и компилятор ARM Вы обязаны переписать с нуля.

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

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

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

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

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

[lleeloo]

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


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


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

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

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

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

Сообщение отредактировал lleeloo - Apr 1 2016, 20:56

[mantech]

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

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

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

[Огурцов]

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

[Rash]

Например? Где "хороший и разный" гуй взять?

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

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

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

[SasaVitebsk]

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

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

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

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

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

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

[Rash]

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

[SasaVitebsk]

Про работу DMA я ни чего не писал, так что не пойму к чему это.

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

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

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

Код

// @@ 261.
MenuItem_t  mnuitDc[MNUDCMAX] =        // Меню "Каналы управления"/ Пункты меню
{
  {&imResult,                            // 2611 Мгновенное значение
  0,DCResultView,&DCdin,SetDCType},
  {&imTypDc,                            // 2612. Тип канала управления
  (struct Menu_t *)&txlTypDc,(void(*)(void))TextListCh,&DCdin,SetDCmnuViewAndHlp},
  {&imPortIntelChan,                    // 2613 Порт связи для интелектуального канала
  (struct Menu_t *)&rbtPortLink,RadioBtnCh,&DCdin,SetDCmnuViewAndHlp},
  {&imNMO,                                // 2614 № вых.канала.
  (struct Menu_t *)&dgeNChan,EditIntCh,&DCdin,EditIntHlp},
  {&imNetAdr,                            // 2615 Сетевой адрес для интелектуального канала
  (struct Menu_t *)&dgeNetAdrSlave,EditIntCh,&DCdin,EditIntHlp},
  {&imTeleParam,                        // 2616 Параметр
  0,TeleControlEdit,&DCdin,TeleControlHlp},
  {&imPolar,                            // 2617 Полярность, +/-
  (struct Menu_t *)&rbtPolar,RadioBtnCh,&DCdin,RadioBtnHlp},

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

Код

// @@ 261С.
RadioBtn_t rbtTelesignlgh =            // Меню "Световая индикац."
{
  0,                                        // непрямое
  2,                                        // Всего 2 пункта
  offsetof(ControlChannel_t,light),            // light
  PRGEDIT, 0,                                // Редактировать по паролю, не сохранять (сохранять по выходу из PRG)
  rbtsSwitch
};

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

Код

// Состояния графических объектов (Общие)
enum
{
  // состояния
  FOCUSED            = 0x0001,        // фокус на объекте
  DISABLED            = 0x0002,        // объект заблокирован
  DRAWN                = 0x0004,        // объект отрисован
  // действия
  DRAW_FOCUS        = 0x2000,        // навести фокус
  DRAW                = 0x4000,        // перерисовать
  HIDE                = 0x8000;        // погасить
};

[Rash]

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

[mantech]

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

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

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

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

Кучу у меня использует, в том числе Ethernet. У меня как HTTP сервер, так и TCP Modbus. Мне что потом искать почему это всё падает раз в месяц? Причём часть в закрытых библиотеках?

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

[SasaVitebsk]

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

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

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

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

[Rash]

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

возможно

...

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

[mantech]

Динамические объекты нужны только если вы на этапе компиляции не знаете как будет выглядеть ваш экран. Например, если вы делаете дисплей для ПЛК, и поставляете программу редактирования, то целесообразнее делать динамическую гуи. Статическая будет больше ресурсов забирать.

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

[Rash]

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

[mantech]

А если захочу растянуть окно, то и виджет может растянутся вместе с окном,

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

[Rash]

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

[картошка]

Делал на 429 . Запускал режим LUT8, дисплей 800x600. 40 мегабайт видеопотока, заметьте !!! однобайтовый, не перепутал ! Сожрал весь трафик к SDRAM. Осталось там для 3-4 мбайта в секунду, для программы (это из учета что частота SDRAM с максимально скоростной конфигурации получилась то-ли 75 то-ли 85 Мгц в 16-ти битном режиме памяти).
Как по мне - это медленно. Попутно запустил камеру на OV - чипе, настроил на внутреннюю оперативку, а так как ее мало было для полного растра пришлось весь кадр перегружать за 3-4 физических кадра + еще и каждую точку с 565 режима камеры в 8бит переделывал .

729 - много не выправит. С такими потребностями и хваткой надо на ALLWINER-ы переходить. Но там одна только загвоздка и она ключевая, надо изучить команды MALI архитекруты .

[Шаманъ]

Делал на 429 . Запускал режим LUT8, дисплей 800x600. 40 мегабайт видеопотока, заметьте !!! однобайтовый, не перепутал !

40*2^20/(800*600)=87.38 к/с - зачем столько?

729 - много не выправит.

479й с 32битной SDRAM будет намного полезнее в этом плане

[SpyBot]

40*2^20/(800*600)=87.38 к/с - зачем столько?

Какие то дисплеи на небольшой частоте подмерцывают, что крайне отрицательно сказывается на усталости глаз.
Я пробовал разгонять правда 320х240 до 150 и более фпс, от этого восприятие картинки только улучшалось.
Но это мерцание не все видят. У меня вот какое то обостренное чувство к мерцанию подсветки и матрицы любых дисплеев. А коллеги замечают мерцание только наверное на 25 фпс

479й с 32битной SDRAM будет намного полезнее в этом плане

А при 1 байтном цвете, будет ли чтение одновременно 4 точек из сдрам?
Также и при например записи с ацп. Сможет ли он записывать в сдрам одновременно 4 отсчета?

[niXto]

Какие то дисплеи на небольшой частоте подмерцывают, что крайне отрицательно сказывается на усталости глаз.
Я пробовал разгонять правда 320х240 до 150 и более фпс, от этого восприятие картинки только улучшалось.

Почитайте про tearing effect и два способа минимизации последствий

Достаточно 25...30 кадров в секунду, но синхронизированных с развёрткой

[Шаманъ]

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

Очень часто мерцание возникает из-за ШИМ управления подсветкой. Если частоты неудачно выбраны, то может получаться форменная порнография. Потому у себя всегда управляю подсветкой регулировкой преобразователя, а не низкочастотным ШИМом.

Если же речь о мерцании из-за перерисовки экрана, то стоит прислушаться к совету в предыдущем сообщении.

А при 1 байтном цвете, будет ли чтение одновременно 4 точек из сдрам?
Также и при например записи с ацп. Сможет ли он записывать в сдрам одновременно 4 отсчета?

Ну если память 32бита, то читать и записывать 4байта за раз это как бы ее прямое назначение

LTDC тоже должен работать с памятью 32битными словами. К сожалению 479е у нас не продаются, потому что-то более определенное сказать не смогу.

[SpyBot]

Очень часто мерцание возникает из-за ШИМ управления подсветкой. Если частоты неудачно выбраны, то может получаться форменная порнография. Потому у себя всегда управляю подсветкой регулировкой преобразователя, а не низкочастотным ШИМом.

Если же речь о мерцании из-за перерисовки экрана, то стоит прислушаться к совету в предыдущем сообщении.

Подсветка всегда питается постоянным напряжением, шим я категорически неприемлю.
Речь идет о полностью статической картинке.
Попробуйте постепенно снижать частоту LTDC и на каком то этапе станет видно, что картинка немного мерцает и к тому же сильно напрягаются глаза.
Еще один момент, что на углах обзора градусов так 45 видно, как особенно сильно мерцают горизонтальные темные линии.
У меня частота LTDC при которой картинка становится более менее комфортной - не менее 50 МГц для 320х240.

[aaarrr]

Еще один момент, что на углах обзора градусов так 45 видно, как особенно сильно мерцают горизонтальные темные линии.

Судя по описанию, это похоже на неправильно выставленный или шумный источник VCOM. Характерно для дешевых индикаторов.

У меня частота LTDC при которой картинка становится более менее комфортной - не менее 50 МГц для 320х240.

А у индикатора какая максимальная допустимая частота PCLK?

[SpyBot]

А у индикатора какая максимальная допустимая частота PCLK?

30 MHz, но он на удивление работает и с гораздо большей частотой. Да, это очень дешевый дисплей
При больших фпс начинают даже плыть цвета, но синхронизацию он не теряет.

[SasaVitebsk]

Подсветка всегда питается постоянным напряжением, шим я категорически неприемлю.

Почему? Поясните, пожалуйста.

А при 1 байтном цвете, будет ли чтение одновременно 4 точек из сдрам?
Также и при например записи с ацп. Сможет ли он записывать в сдрам одновременно 4 отсчета?

С точки зрения CPU, вы будете читать 32 бита. То есть 4 отсчёта/ точки. Как будет обеспечиваться ваше чтение, зависит от схемотехники.
На найболее распростанённых схемах, применена 16 битная SDRAM (дешёвая и легко разводится). В этом случае ваше обращение к 32-ух битному слову выльется в 2 обращения к ОЗУ. В каждом случае будут вставлены определённые такты ожидания. Иными словами, с точки зрения CPU обращение к внешней памяти осуществляется также как к внутренней, но операции чтения/ записи выполняются медленнее.
Есть ещё регенерация. Насколько прозрачно она выполняется я не смотрел. Думаю, что сейчас контроллеры динамической памяти уже вполне отработаны, и регенерация осуществляется прозрачно (то есть процессор значимо не тормозится, при выполнении регенерации).

[Шаманъ]

У меня частота LTDC при которой картинка становится более менее комфортной - не менее 50 МГц для 320х240.

Ого! У меня на 320х240 6.4МГц помнится и все абсолютно нормально. Притом вначале ошибся и он также нормально довольно долго работал на частоте в два раза меньше. Экран правда не из самых дешевых.

Почему? Поясните, пожалуйста.

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

[SasaVitebsk]

Спасибо.
Но вроде как для светодиодов глубоко по барабану частота. Они от этого не умирают. То есть можно частоту ШИМ и 100 и 200 кГц применить. Таймер с такой ерундой вполне справится. В чём подвох?

[aaarrr]

В чём подвох?

На EN источника такую частоту подать не получится.

[SpyBot]

Почему? Поясните, пожалуйста.

У меня видимо какие то слабоватые глаза и я очень мучаюсь с разными мониторами. А со временем в мониторы ставят все более и более мощные диоды и ситуация становится просто невыносимой Я как то купил ноут, несколько дней посмотрел в него на минимальной яркости и потом какое то время мог только читать электронную книгу.
Ну и по логике, даже если сознание человека этого почти не фиксирует, как то глупо пыхать в глаза с полностью открытым зрачком (вечером) всей дурью сверхярких светодиодов.

С точки зрения CPU, вы будете читать 32 бита. То есть 4 отсчёта/ точки. Как будет обеспечиваться ваше чтение, зависит от схемотехники.
На найболее распростанённых схемах, применена 16 битная SDRAM (дешёвая и легко разводится). В этом случае ваше обращение к 32-ух битному слову выльется в 2 обращения к ОЗУ. В каждом случае будут вставлены определённые такты ожидания. Иными словами, с точки зрения CPU обращение к внешней памяти осуществляется также как к внутренней, но операции чтения/ записи выполняются медленнее.
Есть ещё регенерация. Насколько прозрачно она выполняется я не смотрел. Думаю, что сейчас контроллеры динамической памяти уже вполне отработаны, и регенерация осуществляется прозрачно (то есть процессор значимо не тормозится, при выполнении регенерации).

В теории это все понятно, но вот как будет работать конкретный МК, пока не ясно. В идеале конечно же хотелось бы, чтобы МК умел использовать burst как для чтения так и для записи. Даже если изначальный поток например с ацп идет 8 бит...

[AVI-crak]

Вся разница в 16 и 32 бита шины sdram на st чипе - буквально 2 тика.
Латетность совершенно одинаковая, и составляет в лучших вариантах 10 тик + 2 тика первое чтение. Попав на потоковое чтение выбранной страницы - чтение/запись будет без выборки адреса.
У ускорителя st производится непрерывная предвыборка в половину буфера - это 8/16 32d слов. По сему разница в скорости от ширины памяти не столь заметна.
Максимальная скорость достигается при использовании внешней sram памяти, очень желательно на 10nc.
У st есть макетки с использованием такой памяти, но чего-то они не прижились - ценник ломовой.

[Шаманъ]

У ускорителя st производится непрерывная предвыборка в половину буфера - это 8/16 32d слов. По сему разница в скорости от ширины памяти не столь заметна.

По сему как раз разница между 16 и 32 битными шинами будет очень приличной Или Вы про что-то другое?

Передача адреса со всеми "попутными" расходами времени будет производится один раз на блок, затем данные в пределах блока будут вычитываться каждый такт SDRAM. Соответственно если вариант с 16битной SDRAM требует t1+t2 времени, где t1 - время требуемое для выборки, t2 собственно для чтения данных, то в случае с 32бит SDRAM потребуется t1+t2/2. Как по мне это весьма существенно.

как то глупо пыхать в глаза с полностью открытым зрачком (вечером) всей дурью сверхярких светодиодов.

Да, поддерживаю Вас в этом плане, но в данном случае все намного проще. С высокой частотой ШИМа импульсный стабилизатор тока светодиодов просто не будет успевать нормально стартовать

[SpyBot]

У st есть макетки с использованием такой памяти, но чего-то они не прижились - ценник ломовой.

Это и понятно. Грубо говоря, быстрая малопотребляющая (относительно других) SRAM нормального объема стоит как дискавери с 4-5" экранчиком...

[AVI-crak]

По сему как раз разница между 16 и 32 битными шинами будет очень приличной Или Вы про что-то другое?

Сухие цифры: самый не оптимальный режим - 2 слоя, запись в буфер, и его-же отображение на rgb выхлопе - пред выборка по 8 32b слов.
8 бит: адрес 10 тиков + 64 тика на чтение = 72 тика на заполнение буфера.
16 бит: адрес 10 тиков + 32 тика на чтение = 42 тика на заполнение буфера.
32бит: адрес 10 тиков + 16 тиков на чтение = 26 тика на заполнение буфера.
32бит sram 10nc: 2 тика на чтение = 16 тиков на буфер из восьми выборок.

Разница в скорости между 16b и 32b - 1,6, до двойки не дотягивает - зато освобождает сражу 16 линий мк.
А вот для sram уже не жалко все 32b выделить, и даже махнуть рукой на прожорливость системы. Потому как скорость чтения/записи практически равна скорости выборки из внутренней sram (необходимость каждый раз качать права на шине арбитра - 1 такт).

Но вот из всего многообразия современной и быстрой sram памяти 10nc - самая дешёвая на 8 метров имеет ценник в 3 бакса, и не совсем гуманный бга корпус.
А ценник на 64 метра - просто улетают в космос, получается в сто раз дешевле поставить 8 восмиметровых чипов.

[mantech]

Сухие цифры: самый не оптимальный режим - 2 слоя, запись в буфер, и его-же отображение на rgb выхлопе - пред выборка по 8 32b слов.
8 бит: адрес 10 тиков + 64 тика на чтение = 72 тика на заполнение буфера.
16 бит: адрес 10 тиков + 32 тика на чтение = 42 тика на заполнение буфера.
32бит: адрес 10 тиков + 16 тиков на чтение = 26 тика на заполнение буфера.
32бит sram 10nc: 2 тика на чтение = 16 тиков на буфер из восьми выборок.
овых чипов.

Вы какое хоть разрешение экрана используете? Проверял на 2х ядерном LPC(не помню номер его) до 640х480 все работало без тормозов, а выше при использовании сд-рам - это все равно, что эзернет программный делать

[AVI-crak]

Вы какое хоть разрешение экрана используете? Проверял на 2х ядерном LPC(не помню номер его) ...

Внешняя sdram с безграничным презрением смотрит на любой чип рядом с собой - она не будет работать быстрее чем записано в её доке.
Для описания скорости "работы" nad памяти - у меня не хватит ругательных слов.

Лично я жду доступную оптическую память на кристаллах. Уже наверное скоро изобретут.

Сообщение отредактировал AVI-crak - Apr 14 2016, 18:52

[Огурцов]

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

[Шаманъ]

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

Какой смысл что-то ставить снаружи и как-то это синхронизировать с записью/чтением данных от МК (типа арбитр городить), если все уже изобретено и есть в МК?

Разница в скорости между 16b и 32b - 1,6, до двойки не дотягивает - зато освобождает сражу 16 линий мк.

469й позволяет подключать дисплей по последовательной шине - там столько пинов освобождается, что можно и память до 32х бит нарастить и еще останется А в 1.6раза согласитесь, это не мало.

А вот для sram уже не жалко все 32b выделить, и даже махнуть рукой на прожорливость системы.

Кто б спорил, но цена/потребление, да и доступность больших чипов SRAM сразу делает такое решение неприемлемым, ну или как минимум не привлекательным...

Сообщение отредактировал Шаманъ - Apr 15 2016, 07:54

[mantech]

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

Если считаете, что там все так просто - берите ПЛИСу и делайте

[Огурцов]

не надо плиску, с плиской может и стм не потребоваться

469й позволяет подключать дисплей по последовательной шине

а вот это мегаинтересно

[SpyBot]

Кто б спорил, но цена/потребление, да и доступность больших чипов SRAM сразу делает такое решение неприемлемым, ну или как минимум не привлекательным...

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

[Огурцов]

а сколько надо ? внутренней уже вполне хватает на кое-что

[SpyBot]

Нет, ну внутренней... Внутренней хватает всего на 320х240. А хочется Размаха! 1024х768 и несколько буферов.

[Огурцов]

на 720*575 хватает

[Шаманъ]

а сколько надо ? внутренней уже вполне хватает на кое-что

Мне нужно 1.5МБ на фреймбуффер минимум. Если поиграться с прозрачностью, то еще столько же

на 720*575 хватает

Это в каком STM есть 400кБ памяти? Да и то при восьмибитном цвете и если в памяти больше ничего кроме видеобуфера нет.

[Огурцов]

семисотые посмотрите
более 800*600 на встраиваемых, зачем ?
на писюках как-то вполне 640*480*4 перебивались, а 800*600*8 появились - вообще праздник, так что не жадничайте

[Шаманъ]

семисотые посмотрите

Те, что реально доступны имеют 320кБ на борту.

более 800*600 на встраиваемых, зачем ?

Нет, не более, а 800х480х16бит + двойная буферизация. А если еще в два слоя то 3МБ и набегает, правда последнее в общем-то не самая нужная вещь, но кое-что в интерфейсе позволяет сделать красиво без лишних усилий.

на писюках как-то вполне 640*480*4 перебивались, а 800*600*8 появились - вообще праздник, так что не жадничайте

Во-первых у меня задача требует минимум 8битного цвета, но лучше выглядит в 16битном. Некоторую информацию удобно/необходимо отображать в виде двух координат X-Y, а третья координата это цвет (думаю я не уникален в этом).
Во-вторых эффективно использовать DMA2D можно только с 16битным фреймбуффером.

Сообщение отредактировал Шаманъ - Apr 17 2016, 04:39

[AVI-crak]

Кстати, у чипов st их ускоритель имеет всего две полезные функции: заливка цветом и копирование памяти с прозрачностью. Именно для последней функции требуется огромное количество памяти, иначе теряется смысл dma2d.
Тут встроенной памятью не обойтись.

[Шаманъ]

Кстати, у чипов st их ускоритель имеет всего две полезные функции: заливка цветом и копирование памяти с прозрачностью.

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

Сообщение отредактировал Шаманъ - Apr 17 2016, 07:43

[Огурцов]

двойная буферизация

ну поставьте два процыка
или подождите пару лет, до какой-нибудь 9xx

Сообщение отредактировал Огурцов - Apr 17 2016, 08:35

[Шаманъ]

ну поставьте два процыка
или подождите пару лет, до какой-нибудь 9xx

Зачем? Два процессора для двойной буферизации вывода графики У Вас какие-то нездоровые идеи, то от LTDC отказаться, то от SDRAM... Если полосы SDRAM хватает, то пусть себе стоИт - стОит копейки, памяти много...

[Огурцов]

у меня разные идеи - а вы выбираете

[Шаманъ]

у меня разные идеи - а вы выбираете

Не, спасибо, у меня своих достаточно...

[adrvyho]

Добрый день, дорогие форумчане.
Тоже решил идти в ногу со временем и пересесть с AVR на STM32.
Подключил сенсорный дисплей 800х480 по интерфейсу RGB24 к STM32F429IIT.
Но от того, что поспешил и не предусмотрел в своей схеме SDRAM, теперь мучаюсь.
Настроил тайминги, залил задний фон, активировал слой и окно на нём, но никак не выходит корректно залить область внутри окна.
Получается примерно следующее:



Заливать пробую через DMA2D Register to memory.
Краями, конечно, понимаю, что что-то неверно с адресом заливаемой области, но от неграмотности не могу совладать с DMA2D
Прошу помощи у тех, кто может совладать с DMA2D без SDRAM
Вот кусок кода для заливки

Код

static void _DMA_Fill(void * pDst, int xSize, int ySize, int OffLine, uint32_t ColorIndex) {

  DMA2D->CR      = 0x00030000UL | (1 << 9);         // Register to memory and TCIE
  DMA2D->OCOLR   = ColorIndex;                      // Color to be used
  DMA2D->OMAR    = (uint32_t)pDst;                       // Destination address
  DMA2D->OOR     = OffLine;                         // Destination line offset
  DMA2D->OPFCCR  = 4;                     // Defines the number of pixels to be transfered
  DMA2D->NLR     = ((uint32_t)xSize << 16) | ySize; // Size configuration of area to be transfered
  DMA2D->CR     |= 1;                               // Start operation
  //
  // Wait until transfer is done
  //
  while (DMA2D->CR & DMA2D_CR_START) {}
}
uint32_t aBufferResult[5000];

int main (void)
    

{
          SystemInit();
      HAL_Init();
          SystemClock_Config();
      DMA2D_Config();
      Screen_Init();
          _DMA_Fill(aBufferResult+10, 50, 1, 0, 0x1F0A);
          _DMA_Fill(aBufferResult+150, 30, 2, 0, 0x1C01);
      _DMA_Fill(aBufferResult+300, 5, 20, 0, 0xF0F0);
          while(1) {}
}

[Шаманъ]

Подключил сенсорный дисплей 800х480 по интерфейсу RGB24 к STM32F429IIT.
Но от того, что поспешил и не предусмотрел в своей схеме SDRAM, теперь мучаюсь.

Так а видеобуфер где поместился?

Заливать пробую через DMA2D Register to memory.

Я бы вначале убедился, что без DMA2D все работает правильно, а потом уже подключал DMA2D.

[adrvyho]

В видеобуфере, так подозреваю, моя проблема и кроется, только от того, что я самоучка и много не знаю, пока не могу понять, где именно.
Я так понял, что адрес буфера, при отсутствии внешней ОЗУ - адрес массива aBufferResult, но это только мои мутные догадки.
Без DMA2D я менял цвет заднего фона, поигрался со слоями, залил на слое 1 окно нужного размера - предположил, что экран рабочий и подключен правильно
Активировал DMA2D (проверил в отладчике регистры), нашёл удобоваримый пример для режима Register-To_memory, пытаюсь вывести три разных прямоугольника, а получается то, что видим на фотографии ((

[Шаманъ]

Я так понял, что адрес буфера, при отсутствии внешней ОЗУ - адрес массива aBufferResult, но это только мои мутные догадки.

Ищите где производится инициализация LTDC и смотрите где находится видеобуфер - для меня из Вашего куска кода совсем не очевидно, что aBufferResult это видеобуфер (его размер как бы должен быть побольше раз в двадцать как минимум), короче "Use the source luke"

[Rash]

без SDRAM или SRAM нужного размера под видео буфер не имеет практического смысла запускать

[adrvyho]

без SDRAM или SRAM нужного размера под видео буфер не имеет практического смысла запускать

Необходимо выводить только примитивы в виде кнопок и текст. Хотя убийственная мысль, что на каждый пиксель экрана необходимо минимум два байта постоянно перезаписываемой памяти, всё больше проникает в мозг. Может есть какие-то уловки с FLASH или SD картой, или ещё какие-то заклинания?!

Ищите где производится инициализация LTDC и смотрите где находится видеобуфер

Единственное указание на видеобуфер находится в инициализации слоя 1, пока что-то делать с ним боюсь, только расширил массив до 45000,но это - мёртвому припарки.

Код

   displayLayer1.WindowX0 = 10;
   displayLayer1.WindowX1 = 790;
   displayLayer1.WindowY0 = 10;
   displayLayer1.WindowY1 = 470;
   displayLayer1.PixelFormat = LTDC_PIXEL_FORMAT_ARGB4444;
   displayLayer1.Alpha = 255;
   displayLayer1.Alpha0 = 250;
   displayLayer1.BlendingFactor1 = LTDC_BLENDING_FACTOR1_CA;
   displayLayer1.BlendingFactor2 = LTDC_BLENDING_FACTOR2_CA;
   displayLayer1.FBStartAdress = (uint32_t)&aBufferResult;
   displayLayer1.ImageWidth = 0;
   displayLayer1.ImageHeight = 0;
   displayLayer1.Backcolor.Blue = 250;
   displayLayer1.Backcolor.Green = 0;
   displayLayer1.Backcolor.Red = 200;

   HAL_LTDC_ConfigLayer(&displayTypeDef, &displayLayer1, 0);

[Rash]

под ваш LCD нужен видео буфер 800*480*2 иначе просто нет смысла возится (ИМХО). Или переходите на маленький экран, что бы разместить видео буфер во внутреннем ОЗУ. Самый менее затратный вариант взять 429Disco, отпаять родной LCD и сделать переходную плату под нужный LCD, а потом уже разводить свою, при рабочем программе (или готовый DevKit).

[SasaVitebsk]

Необходимо выводить только примитивы в виде кнопок и текст. Хотя убийственная мысль, что на каждый пиксель экрана необходимо минимум два байта постоянно перезаписываемой памяти, всё больше проникает в мозг. Может есть какие-то уловки с FLASH или SD картой, или ещё какие-то заклинания?!

Вы бы почитали мой пост предварительно. Тогда бы поняли что DMA2D целесообразен только в режиме 16 или 24-битного цвета.
...
Давайте поясню на пальцах. В МК есть 2 совершенно независимых узла: LTDC (контроллер дисплея) и DMA2D (ускоритель, но фактически контроллер прямого доступа к памяти позволяющий работать с прямоугольными областями памяти).
LTDC фактически отображает область памяти (видеобуфер) на экран. А с помощью DMA2D вы можете модифицировать ваш видеобуфер. То есть сам DMA2D к дисплею никакого отношения не имеет. Поскольку в экране у вас ничего не хранится, то видеобуфер должен быть обязательно. Там находится то, что отображается на дисплее.
Самый экономный режим для вашего МК - 8 бит (L8 - 256 цветов из палитры 16 бит или аналогичный AL44 - палитра 16 цветов с 16 градациями яркости). Для реализации потребуется 800*480 = 384 кб. У Вашего контроллера лишь 256.
Выхода 3.
1) Добавить память внешнюю. Но на проводах не запаяешь. Работать не будет. Придётся переразводить плату.
2) Применить дисплей с меньшим разрешением. Например 4.3" 480*272 = 130кб. Качество картинки будет описанное выше. DMA2D будет использоваться ограниченно (только копирование и заливка).
3) Применить дисплей с собственным контроллером типа 1963 или другим. Там память находится на самом дисплее. DMA2D в этом случае теряет смысл.

[adrvyho]

Всем спасибо большое за ответ!!!
Понял всю фатальность ситуации, что запуск моей платы снова отодвинут на этап создания паттернов в PCAD.
Для себя на пальцах представил ОЗУ, как участок земли определённой площади, которым я обладаю (в моём случае - 256 кв. м).
Видеобуфер - это полотно, которое я могу расстелить в пределах моего участка. Полотно, зараза, большое.
Пиксели - это кубики с площадью основания >= 2 кв.м.
И чтобы мне расстелить полотно, нужно купить участок побольше, можно и в другом районе, дабы курьерская служба DMA2D может доставить кубики-пиксели куда угодно)
Уважаемый SasaVitebsk, я ведь в случае варианта 2 могу не брать другой экран, а на своём задать область размером, допустим 400х300 на слое 1? Или нужно вначале инициализировать экран конкретно под это разрешение?
Пока не выходит, хотя создал uint16_t aBufferResult[95000] (больше не создаётся). Может нужно как-то по-другому задавать видеобуфер? Тут мои знания уже конкретно плывут(

[SasaVitebsk]

В доке на МК имеется достаточно детальное описание как программируется дисплей.
Вы сможете слегка уменьшить отображаемое поле. Но в целом, TFT дисплей это всё же не телевизор и поля с краёв будут небольшими.
То есть я думаю вас это не спасёт. Хотя я не пробовал, честно скажу.

[adnega]

а на своём задать область размером, допустим 400х300 на слое 1? Или нужно вначале инициализировать экран конкретно под это разрешение?

Нужно проинициализировать экран со всеми таймингами под полное разрешение,
но при инициализации слоев (а именно они используют видеопамять) можно указать буфера меньшего размера.
Границы будут залиты цветом фона, который можно выбрать.
Можно один из слоев натравить на ПЗУ, тогда будет выводится статический логотип к примеру.
Можно попробовать анимировать этот логотип, перезависывая адрес начала видеобуфера синхронно с ходом луча

PS. Я так делал - работает, но при определенных соотношениях размеров.

[adrvyho]

Нужно проинициализировать экран со всеми таймингами под полное разрешение,
но при инициализации слоев (а именно они используют видеопамять) можно указать буфера меньшего размера.
Границы будут залиты цветом фона, который можно выбрать.

Именно так и сделал - задал массив aBufferResult при инициализации слоя 1, сделал заполнение 2х областей. Дык, всё равно заливаются линии, а не области!


Видимо, прокладка между рулём и сиденьем износилась)
Подскажите, пожалуйста, как корректно задать видеобуфер - видимо я это совсем через пень-колоду делаю.

[adnega]

Именно так и сделал

Кусок кода покажете?

[adrvyho]

Кусок кода покажете?

CODE

#define PIXELWIDHT 2

#define LCD_WIDTH 800
#define LCD_HEIGHT 480

#define HFP 40
#define HSYNC 48
#define HBP 40

#define VFP 13
#define VSYNC 3
#define VBP 29



#define ACTIVE_W (HSYNC + LCD_WIDTH + HBP - 1)
#define ACTIVE_H (VSYNC + LCD_HEIGHT + VBP - 1)
#define DISP_ACCUM_HORIZ_BACKPORCH (HSYNC + HBP - 1)
#define DISP_ACCUM_VERT_BACKPORCH (VSYNC + VBP - 1)
#define TOTAL_WIDTH (HSYNC + HBP + LCD_WIDTH + HFP - 1)
#define TOTAL_HEIGHT (VSYNC + VBP + LCD_HEIGHT + VFP - 1)

uint16_t aBufferResult[95000];

void Screen_Init(void)
{
LTDC_HandleTypeDef displayTypeDef;
LTDC_LayerCfgTypeDef displayLayer1;
LTDC_LayerCfgTypeDef displayLayer2;

GPIO_InitStruct.Pin = GPIO_PIN_4|GPIO_PIN_5| GPIO_PIN_6|GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_14|GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
GPIO_InitStruct.Alternate = 14;

HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_10| GPIO_PIN_11;

HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1| GPIO_PIN_2|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7|GPIO_PIN_9|GPIO_PIN_10;

HAL_GPIO_Init(GPIOI, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_2|GPIO_PIN_3| GPIO_PIN_8|GPIO_PIN_9|GPIO_PIN_10|GPIO_PIN_11|GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_1
4|GPIO_PIN_15;

HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;

HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, 1);

__LTDC_CLK_ENABLE();

// PLL

/* LCD clock configuration */
/* PLLSAI_VCO Input = HSE_VALUE/PLL_M = 1 MHz */
/* PLLSAI_VCO Output = PLLSAI_VCO Input * PLLSAIN = 192 MHz */
/* PLLLCDCLK = PLLSAI_VCO Output/PLLSAIR = 192/5 = 38.4 MHz */
/* LTDC clock frequency = PLLLCDCLK / LTDC_PLLSAI_DIVR_4 = 38.4/4 = 9.6MHz */
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;
PeriphClkInitStruct.PLLSAI.PLLSAIN = 192;
PeriphClkInitStruct.PLLSAI.PLLSAIR = 5;
PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_4;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);

// enable clock for LTDC
RCC->APB2ENR |= RCC_APB2ENR_LTDCEN;

// LTDC
HAL_LTDC_Init(&displayTypeDef);
displayTypeDef.Instance = LTDC;
displayTypeDef.Init.HSPolarity = LTDC_HSPOLARITY_AL;
displayTypeDef.Init.VSPolarity = LTDC_VSPOLARITY_AL;
displayTypeDef.Init.DEPolarity = LTDC_DEPOLARITY_AL;
displayTypeDef.Init.PCPolarity = LTDC_PCPOLARITY_IPC;
displayTypeDef.Init.HorizontalSync = HSYNC-1;
displayTypeDef.Init.VerticalSync = VSYNC-1;
displayTypeDef.Init.AccumulatedHBP = DISP_ACCUM_HORIZ_BACKPORCH;
displayTypeDef.Init.AccumulatedVBP = DISP_ACCUM_VERT_BACKPORCH;
displayTypeDef.Init.AccumulatedActiveW = ACTIVE_W;
displayTypeDef.Init.AccumulatedActiveH = ACTIVE_H;
displayTypeDef.Init.TotalWidth = TOTAL_WIDTH;
displayTypeDef.Init.TotalHeigh = TOTAL_HEIGHT;
displayTypeDef.Init.Backcolor.Blue = 200;
displayTypeDef.Init.Backcolor.Green = 0;
displayTypeDef.Init.Backcolor.Red = 200;

HAL_LTDC_Init(&displayTypeDef);

// Layer 1
displayLayer1.WindowX0 = 210;
displayLayer1.WindowX1 = 590;
displayLayer1.WindowY0 = 100;
displayLayer1.WindowY1 = 380;
displayLayer1.PixelFormat = LTDC_PIXEL_FORMAT_ARGB4444;
displayLayer1.Alpha = 255;
displayLayer1.Alpha0 = 250;
displayLayer1.BlendingFactor1 = LTDC_BLENDING_FACTOR1_CA;
displayLayer1.BlendingFactor2 = LTDC_BLENDING_FACTOR2_CA;
displayLayer1.FBStartAdress = (uint32_t)&aBufferResult;
displayLayer1.ImageWidth = 0;
displayLayer1.ImageHeight = 0;
displayLayer1.Backcolor.Blue = 250;
displayLayer1.Backcolor.Green = 0;
displayLayer1.Backcolor.Red = 200;

HAL_LTDC_ConfigLayer(&displayTypeDef, &displayLayer1, 0);

}

static void DMA2D_Config(void)
{
__HAL_RCC_DMA2D_CLK_ENABLE();
/* Register to memory mode with ARGB4444 as colorMode */
Dma2dHandle.Init.Mode = DMA2D_R2M;
Dma2dHandle.Init.ColorMode = DMA2D_ARGB4444;
Dma2dHandle.Init.OutputOffset = 0x0;

Dma2dHandle.XferCpltCallback = TransferComplete;
Dma2dHandle.XferErrorCallback = TransferError;
Dma2dHandle.Instance = DMA2D;

/* DMA2D Initialization */
if(HAL_DMA2D_Init(&Dma2dHandle) != HAL_OK)
{

}
}

static void _DMA_Fill(void * pDst, int xSize, int ySize, int OffLine, uint32_t ColorIndex) {

DMA2D->CR = 0x00030000UL | (1 << 9); // Register to memory and TCIE
DMA2D->OCOLR = ColorIndex; // Color to be used
DMA2D->OMAR = (uint32_t)pDst; // Destination address
DMA2D->OOR = OffLine; // Destination line offset
DMA2D->OPFCCR = 4; // Defines the number of pixels to be transfered
DMA2D->NLR = ((uint32_t)xSize << 16) | ySize; // Size configuration of area to be transfered
DMA2D->CR |= 1; // Start operation
//
// Wait until transfer is done
//
while (DMA2D->CR & DMA2D_CR_START) {
//__WFI(); // Sleep until next interrupt
}

Код

_DMA_Fill(aBufferResult+10, 10, 10, 0, 0x1F0A);
_DMA_Fill(aBufferResult+200, 20, 2, 0, 0x1C01);
_DMA_Fill(aBufferResult+300, 50, 20, 0, 0xF0F0);

Сообщение отредактировал IgorKossak - Aug 25 2016, 17:20

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!