[Шаманъ 0]

Вопрос - DMA2D работает ли с flash памятью?

Да.

 

А зачем ему работать с индексированным цветом, если с ним работает сам LCD контроллер? Ему просто надо копировать любые байтовые форматы. Насколько я понимаю.

Просто копировать это слишком просто ;), но даже в этом случае копировать побайтно он не сможет - только по 16бит. Нормальное функционирование DMA2D возможно только при 16битном и выше цвете на выходе.

 

Чтобы Вы понимали, я сейчас "сделал наброски" и DMA2D по всему сможет делать все по части графики - начиная от заливки прямоугольника и заканчивая выводом текста, картинок и даже некоторой специфической для моего проекта графики :) - согласитесь немного больше "просто копирования". Цена этого, как я уже писал бОльшие затраты памяти (хотя и возможности при этом получаются побольше). Осталось сделать плату и проверить все это :rolleyes:

[Шаманъ 0]

Осталось сделать плату и проверить все это :rolleyes:

Сделал, проверил. Запросы правда за это время немного "подросли" - проц. stm32f746, 8М SDRAM и 800х480хRGB565 TFT.

 

В общем нормально DMA2D работает.

 

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

 

Да, может кому будет интересно - рисование битмапа 534х137 с преобразованием из L8 в RGB565 занимает:

1. Через DMA2D для простого рисования 1.29мс (если пересчитать на весь экран, то выходит 150fps однако)

2. Через DMA2D для наложения с прозрачностью

3. Через CPU с выключенным кэшем 12.8мс

4. Через CPU с включенным кэшем 4.2мс

Это для рисования прямо в видеобуфер, параллельно вычитываемый через LTDC, частоте CPU 180МГц, памяти 90МГц, картинка во флеше.

 

Также потестил как поменяется скорость для 1го варианта (см. выше) если картинка лежит не в флеше:

1. Для картинки в SRAM1 скорость такая же как из флеша - 1.29ms.

2. Для картинки в том же банке SDRAM - 5.03мс

3. Для картинки в другом банке SDRAM - 4.10мс

 

Да, на последовательной записи CPU=>SDRAM получается 54Mtps, рандомные чтение/запись 5.6Mtps, в разных банках 6.6Mtps. Это без кэша данных и с работающим LTDC.

 

Можно сказать я почти доволен :) Огорчили китайцы - панель должна была быть с бОльшим углом обзора снизу, поэтому я ее предусмотрительно перевернул, а оказалось, что у нее лучшие углы обзора сверху :laughing: ... надо будет поискать какую-нить панель с более "правильными" углами обзора.

[Aner 1]

Что за панель? Какой интерфейс у неё? И есть ли емкостной мультитач, хотябы на пять?

[kostya-m 0]

Если бы добавили третий канал с фоном (сплошной заливкой) то некоторые вещи было бы намного удобнее делать.

 

Так там есть регистр - цвет бэкграунда. Если у нижнего слоя режим с альфой, то тот бэкграунд просвечивает.

Сам пользуюсь блендированием из двух экранов с индексированными цветами в один RGB565. На двух экранах.

Выяснил проблемы с FMC, на котором у меня висит 16 битная SRAM. При байтной записи часто ошибается. Приходится и блендирование и операции кодом выравнивать до 16 битных.

[Шаманъ 0]

Что за панель?

AT070TN92

Какой интерфейс у неё?

RGB

И есть ли емкостной мультитач, хотябы на пять?

Сама она голая, но у меня есть тачскрин к ней (емкостной) и я сваял контроллер для него на stm32f103. Мне достаточно 2х касаний, в принципе можно и больше сделать. Пять для такой маленькой панели наверное уже перебор.

 

Так там есть регистр - цвет бэкграунда. Если у нижнего слоя режим с альфой, то тот бэкграунд просвечивает.

Это в LTDC, а в DMA2D такого нет, а было бы хорошо, если бы был - я про это.

 

В DMA2D просвечивает только при комбинировании двух слоев, один из которых сплошной фон.

[kostya-m 0]

В DMA2D просвечивает только при комбинировании двух слоев, один из которых сплошной фон.

По описанию да.

У меня реально регистр DMA2D_BGCOLR просвечивает не только в режиме А4 и А8, как в документации, но и в АL44 на fore и back. Возможно это баг и надеяться на это не стоит. Мне это не надо было и я некоторое время потратил на поиски паразитных цветов, а оказалось, что регистр был не черный.

 

[Шаманъ 0]

По описанию да.

У меня реально регистр DMA2D_BGCOLR просвечивает не только в режиме А4 и А8, как в документации, но и в АL44 на fore и back.

Когда экспериментировал, то с RGB565 форматом в background слое DMA2D_BGCOLR у меня не просвечивал. За информацию по AL44 спасибо :)

[Шаманъ 0]

Интересно, рисование через DMA2D занимает не намного больше времени, чем копирование нарисованного участка. Например, рисование 10мс, копирование 13мс, или рисование 3мс, копирование 2.3мс. В итоге получилось, что зачастую проще (а иногда и быстрее) тупо перерисовывать все каждый раз, чем поделить на участки и сохранять промежуточные результаты в разных буферах, чтобы не рисовать одно и то же.

 

И все же DMA2D весьма крут! Признаю, что был не прав, называя его "убогим" в начале темы :rolleyes: (хотя некоторые простые модификации/дополнения были бы ну очень полезны). Опробовал более-менее реальный вывод достаточно динамичного интерфейса - спектр/водопад на 800х330точек, поверх него полупрозрачная сетка со шкалами + остальной интерфейс рядом 800х150 (фон с анимацией+два слоя поверх) + поверх всего этого небольшие (60х480) анимированные части интерфейса с альфа каналом в независимых буферах в форматах ARGB8888 и L8. TFT работает с частотой кадров 29к/с, процессор 216МГц, память соответственно 108МГц. В начале экспериментов немного разочаровался, ибо FPS прорисовки выше 10..14 не подымался, но потом "углубился в проблему" в итоге после "борьбы за FPS" имею рисование варианта интерфейса со спектром за 19.6мс (~51fps), загрузка процессора при 29к/с 25..26%, то же с водопадом рисуется за 17мс (~58fps), загрузка процессора при 29к/с 4.5%. Я немного удивлен цифрами более 50fps :08:

 

Получив такие цифры захотелось большего (не в плане FPS, а нарисовать больше, сохранив FPS прорисовки анимированных областей экрана выше частоты обновления ТФТ - 29к/с). Скорее всего придется рисовать в двух разноприоритетных потоках, можно конечно забить на незначительные "визуальные эффекты", но я не люблю компромиссы :).

 

В этом вопросе мог бы помочь второй слой LTDC, но увы ему полосы памяти на больших экранах маловато. В итоге в два слоя он при частоте обовления ТФТ больше чем 22к/с (один слой RGB565 второй ARGB4444) у меня не пошел, и то даже при такой низкой скорости иногда глюк проскакивают.

 

 

[Hold 0]

Вопросы к знаюшим людям, может что доброе подскажут:

- Плата 4-х слойка

- STM32F429BIT6 180 Мгц

- SDRAM MT48LC16M16A2 (16 бит шина данных)

- экран 800x480 AT070TN9x(4)(подключение 24бит) , драйвер питания TPS65150

- Питание 3.3, 3А, ST1S14

 

 

SDRAM включена на 90 Мгц (проверяли до 105 Мгц), проблем с чтением/записью или долговременным хранением нет, тайминги по ДЩ.

Был написан тестовый драйвер на LTDC, проверили вывод из SDRAM, никаких проблем не было. Частота клока на экран 33.3 МГц, согласно ДШ на экран.

Подключили STemWin, драйвер взяли готовый (использует ARGB), подправили инициализацию и тайминги LTDC, демка запустилась, но с косяками. Начали разбираться, убрали GUI, решили позаполнять экран на максимальной скорости в главном цикле. И тут вылезли проблемы.

Простейший код рисования прямоугольников синим цветом в режиме ARGB8888:

      for (uint32_t i = 0; i < 800*480; i++)
      {
         for (uint32_t y = 0; y < i%480 +1; y++)
         {
            for (uint32_t x = 0; x < i/480 +1; x++)
            {
               LTDC_Lay1_Ram[(y*LCD_HS_SIZE + x)*LCD_BPP] = 0xFF;
               LTDC_Lay1_Ram[(y*LCD_HS_SIZE + x)*LCD_BPP + 1] = 0x00;
               LTDC_Lay1_Ram[(y*LCD_HS_SIZE + x)*LCD_BPP + 2] = 0x00;
               LTDC_Lay1_Ram[(y*LCD_HS_SIZE + x)*LCD_BPP + 3] = 0xFF;
            }
         }
      }

 

В итоге на экране во время рисования цветная каша. Но стоит остановить проц в дебаге, как на экране нужный прямоугольник без всякого шума. Сделали вывод, что проц и LTDC постоянно соревнуются за SDRAM, т.к. шина все же одна, и совместного доступа один фиг не получится. Проверили заполнение через DMA2D - ровно такая же картина. Уменьшили частоту клока до 23 мгц - экран стал отрисовываться без мусора. Поставил режим RGB888, т.е. на 1 байт на пиксель меньше, т.е. LTDC надо выводить ровно на 25% меньше данных. Увеличил частоту до 30.5 Мгц (больше на 25%) - выводится без проблем. Увеличиваем до 31 - опять мусор. Дабы убедиться, сделали второй буфер в другом банке SDRAM, и во время вывода статичного буфера на LTDC писали во второй буфер. В итоге опять мусор, хотя видеобуфер никто не трогал и не менял. Сейчас есть идея воткнуть SDRAM с шиной данных 32бит (либо две по 16 ), что даст теоретический прирост скорости обмена в 2 раза, но быть может я упускаю что-то совсем простое? Может все же SDRAM криво работает, но тогда бы терялись данные, а тут несколько иная картина. Увеличивал тактовую до 210 Мгц, не меняя клок на экран - проблемы уходили, пока не повысить клок на процент увеличения частоты проца.

Изменено 21 апреля, 2017 пользователем Hold

[Шаманъ 0]

В итоге опять мусор, хотя видеобуфер никто не трогал и не менял.

Не хватает полосы памяти. Прикиньте сами - ARGB8888 это 132МБ/сек

 

Сейчас есть идея воткнуть SDRAM с шиной данных 32бит (либо две по 16 ), что даст теоретический прирост скорости обмена в 2 раза, но быть может я упускаю что-то совсем простое?

ИМХО, ничего Вы особенно не упускаете. Есть некоторые приемы работы с SDRAM, которые позволяют поднять производительность по максимуму, но в целом для таких разрешений полосы памяти недостаточно (плюс арбитр шины по всему не без проблем для такого применения). Могу посоветовать перейти на RGB565, тем более Ваш экран 24битный цвет скорее всего не поддерживает.

[SapegoAL 0]

Могу посоветовать перейти на RGB565,

Сразу 2 зайца. И объём вдвое уменьшится и и выборка точки за раз будет осуществлятся. )

тем более Ваш экран 24битный цвет скорее всего не поддерживает.

Ну скорее не "не поддерживает", а "реально не отображает"... )

[Шаманъ 0]

Ну скорее не "не поддерживает", а "реально не отображает"... )

Главное, что меня поняли :)

[Hold 0]

Да, сейчас уже думаю перейти на RGB565, т.е. надо всего 2 байта на пиксель. Но надо тогда переделывать аппаратную часть, т.к. при подключении экрана по RGB565, согласно ДШ:

As an example, in

the case of an LCD-TFT controller interfacing with a RGB565 16-bit display, the LCD display

R[4:0], G[5:0] and B[4:0] data lines pins must be connected to LCD-TFT controller

LCD_R[7:3], LCD_G[7:2] and LCD_B[7:3].

Т.е. Младшие пины экрана подключаются к старшим LTDC.

В режиме ARGB8888, на один пиксель получается 4 байта, т.е. SDRAM, при шине 16 бит должна успеть за 1 клок экрана сделать 2 чтения памяти. А т.к. чтение SDRAM еще и со своими задержками, то выходит что SDRAM должна отдавать данные с частотой в 2 с лишним раза больше чем частота клока. У нас при 33.3 мгц, SDRAM должна работать порядка 70 Мгц. А при общем клоке 90 мгц от канала, получается, ничего толком и не остается.

В чем же смысл тогда включеня по такой "жирной" шине, если SDRAM только и делает что отдает буфер LTDC? Не все экраны умеют работать на пониженных частотах, хотя например мелкий AT050TN33 480х272 работает на 9 Мгц всего. Смысл тогда от LTDC с максимальным разрешением 1024х768, если при режиме ARGB8888 ему даже не хватит канала SDRAM? В основном в TFT все тайминги написаны с учетом частоты перерисовки 60 гц, при экране 1024х768 в режиме ARGB8888 потребуется скармливать LTDC по 180 МБ/с, откуда взять такую пропускную у SDRAM 16 бит? Можно поставить 32 бит, но и то не уверен что STM протащит такой обмен, учитывая задержки SDRAM. Ведь есть и другие процессы, которые будут претендовать на SDRAM в процессе работы, любой их чих будет срывать отрисовку на ЖК. Смущает то, что драйвер для STemWin взяли от платы с экраном 640х480 и памятью 32 бит. И судя по всему, там это работало без проблем, т.е. пропускной способности хватало, на экран уходило около 70МБ/с. Переразведем плату на RGB565, поставим две памяти 16 бит на 32-бит шину.

 

[Шаманъ 0]

Но надо тогда переделывать аппаратную часть, т.к. при подключении экрана по RGB565, согласно ДШ:Т.е. Младшие пины экрана подключаются к старшим LTDC.

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

 

В режиме ARGB8888, на один пиксель получается 4 байта, т.е. SDRAM, при шине 16 бит должна успеть за 1 клок экрана сделать 2 чтения памяти. А т.к. чтение SDRAM еще и со своими задержками, то выходит что SDRAM должна отдавать данные с частотой в 2 с лишним раза больше чем частота клока. У нас при 33.3 мгц, SDRAM должна работать порядка 70 Мгц. А при общем клоке 90 мгц от канала, получается, ничего толком и не остается.

Ну где-то так... В некоторых случаях и похуже может выйти :)

 

В чем же смысл тогда включеня по такой "жирной" шине, если SDRAM только и делает что отдает буфер LTDC? Не все экраны умеют работать на пониженных частотах, хотя например мелкий AT050TN33 480х272 работает на 9 Мгц всего.

Открою секрет AT070TN92 (или TN90, не помню точно) тоже умеет работать при 8МГц :)

 

Смысл тогда от LTDC с максимальным разрешением 1024х768, если при режиме ARGB8888 ему даже не хватит канала SDRAM?

Может кому 1024х768, но L4 достаточно, а другому 320х240, но ARGB8888 и в два слоя :)

 

ARGB8888 бывает очень полезен в DMA2D операциях в качестве промежуточного буфера. А вообще DMA2D весьма шустр - у меня успевает прорисовывать весь кадр (800х480хRGB565) с довольно сложной графикой за 10..15мс (при одновременной работе LTDC с частотой 29к/с). Самое интересное, что загрузка процессора при этом от 4 до 35% в зависимости от кадра.

[Hold 0]

Завтра попробую rgb565, неиспользуемые биты через gpio на землю кину. Поведайде секрет работы от 8 мгц, ведь даже не учитывая front porch и back porch,экран 800х480 на 8 мгц клока будет работать на 20 Гц всего... У себя ставил 20мгц клок, экран белеть начинал. AT070TN9x по таймингам все одинаковы, отличия лишь в наличии подсветки, яркости и углах обзора. По поводу слоев - у вас ltdc настроен на rgb565. Есть промежуточный буфер argb8888, в котором вы собираете кадр из разных виджетов, графиков и прочего с помощью dma2d или как то еще. А потом весь кадр копируете через dma2d в видео буфер с конвертацией в rgb565?