Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: DMA2D в stm32f4хх
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
Мусатов Константин
Цитата(Шаманъ @ Feb 5 2017, 23:39) *
В DMA2D просвечивает только при комбинировании двух слоев, один из которых сплошной фон.

По описанию да.
У меня реально регистр DMA2D_BGCOLR просвечивает не только в режиме А4 и А8, как в документации, но и в АL44 на fore и back. Возможно это баг и надеяться на это не стоит. Мне это не надо было и я некоторое время потратил на поиски паразитных цветов, а оказалось, что регистр был не черный.
Шаманъ
Цитата(Мусатов Константин @ Feb 6 2017, 01:35) *
По описанию да.
У меня реально регистр DMA2D_BGCOLR просвечивает не только в режиме А4 и А8, как в документации, но и в АL44 на fore и back.

Когда экспериментировал, то с RGB565 форматом в background слое DMA2D_BGCOLR у меня не просвечивал. За информацию по AL44 спасибо sm.gif
Шаманъ
Интересно, рисование через DMA2D занимает не намного больше времени, чем копирование нарисованного участка. Например, рисование 10мс, копирование 13мс, или рисование 3мс, копирование 2.3мс. В итоге получилось, что зачастую проще (а иногда и быстрее) тупо перерисовывать все каждый раз, чем поделить на участки и сохранять промежуточные результаты в разных буферах, чтобы не рисовать одно и то же.

И все же DMA2D весьма крут! Признаю, что был не прав, называя его "убогим" в начале темы rolleyes.gif (хотя некоторые простые модификации/дополнения были бы ну очень полезны). Опробовал более-менее реальный вывод достаточно динамичного интерфейса - спектр/водопад на 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.gif

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

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

Hold
Вопросы к знаюшим людям, может что доброе подскажут:
- Плата 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 Мгц, не меняя клок на экран - проблемы уходили, пока не повысить клок на процент увеличения частоты проца.
Шаманъ
Цитата(Hold @ Apr 21 2017, 13:12) *
В итоге опять мусор, хотя видеобуфер никто не трогал и не менял.

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

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

ИМХО, ничего Вы особенно не упускаете. Есть некоторые приемы работы с SDRAM, которые позволяют поднять производительность по максимуму, но в целом для таких разрешений полосы памяти недостаточно (плюс арбитр шины по всему не без проблем для такого применения). Могу посоветовать перейти на RGB565, тем более Ваш экран 24битный цвет скорее всего не поддерживает.
SasaVitebsk
Цитата(Шаманъ @ Apr 21 2017, 13:26) *
Могу посоветовать перейти на RGB565,

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

Ну скорее не "не поддерживает", а "реально не отображает"... )
Шаманъ
Цитата(SasaVitebsk @ Apr 21 2017, 13:58) *
Ну скорее не "не поддерживает", а "реально не отображает"... )

Главное, что меня поняли sm.gif
Hold
Да, сейчас уже думаю перейти на 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-бит шину.
Шаманъ
Цитата(Hold @ Apr 21 2017, 14:42) *
Но надо тогда переделывать аппаратную часть, т.к. при подключении экрана по RGB565, согласно ДШ:Т.е. Младшие пины экрана подключаются к старшим LTDC.

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

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

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

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

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

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

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

ARGB8888 бывает очень полезен в DMA2D операциях в качестве промежуточного буфера. А вообще DMA2D весьма шустр - у меня успевает прорисовывать весь кадр (800х480хRGB565) с довольно сложной графикой за 10..15мс (при одновременной работе LTDC с частотой 29к/с). Самое интересное, что загрузка процессора при этом от 4 до 35% в зависимости от кадра.
Hold
Завтра попробую rgb565, неиспользуемые биты через gpio на землю кину. Поведайде секрет работы от 8 мгц, ведь даже не учитывая front porch и back porch,экран 800х480 на 8 мгц клока будет работать на 20 Гц всего... У себя ставил 20мгц клок, экран белеть начинал. AT070TN9x по таймингам все одинаковы, отличия лишь в наличии подсветки, яркости и углах обзора. По поводу слоев - у вас ltdc настроен на rgb565. Есть промежуточный буфер argb8888, в котором вы собираете кадр из разных виджетов, графиков и прочего с помощью dma2d или как то еще. А потом весь кадр копируете через dma2d в видео буфер с конвертацией в rgb565?
Шаманъ
Цитата(Hold @ Apr 21 2017, 17:53) *
Поведайде секрет работы от 8 мгц, ведь даже не учитывая front porch и back porch,экран 800х480 на 8 мгц клока будет работать на 20 Гц всего...

В реальности, когда я экспериментировал он работал нормально и на 15fps. Никаких бросающихся в глаза проблем не наблюдалось. Если сильно присматриваться, то на градиентах (а может и просто на определенных цветах) было заметно слабое мерцание, эффект минимизировался правильным выбором напряжения Vcom.

Цитата
У себя ставил 20мгц клок, экран белеть начинал. AT070TN9x по таймингам все одинаковы, отличия лишь в наличии подсветки, яркости и углах обзора.

Не, с этим было все ок. Даже если отключить LTDC, то он "белеет" до пропадания изображения в течении нескольких секунд, начиная с 20fps изображение невозможно отличить от 30 или более fps. Остановился на 29fps по одной причине - при более низком анимации в интерфейсе выглядели хуже.

Цитата
По поводу слоев - у вас ltdc настроен на rgb565. Есть промежуточный буфер argb8888, в котором вы собираете кадр из разных виджетов, графиков и прочего с помощью dma2d или как то еще. А потом весь кадр копируете через dma2d в видео буфер с конвертацией в rgb565?

Нет, так будет тормозно - рисуется в одном буфере, показывается другой, потом буфера переключаются. Промежуточная буферизация иногда используется в анимациях и спец. эффектах. У меня в некоторых случаях накладывается очень много слоев (до 6 слоев) и некоторые части могут рисоваться не в основном потоке. Ваш вариант очень сильно просадит производительность.
Hold
Попробую на 29 Гц, покручу Vcom, подстроечник есть. Если скинете ваши тайминги экрана буду благодарен. По буферу, не совсем уловил мысль, как правильно и оптимально.
Шаманъ
Цитата(Hold @ Apr 21 2017, 18:34) *
Попробую на 29 Гц, покручу Vcom, подстроечник есть. Если скинете ваши тайминги экрана буду благодарен.


Код
#define TFT_HSW 40     //Horizontal Sync Width
#define TFT_HBL 46    //Horizontal Blanking Width
#define TFT_AW  800   //Active Area Width
#define TFT_TW  863  //Total Width

#define TFT_VSH 20     //Vertical Sync Width
#define TFT_VBL 23     //Vertical Blanking Width
#define TFT_AH  480   //Active Area Height
#define TFT_TH  649   //Total Height


Тайминги немного отличаются от общепринятых, но все в рамках допустимого (по датащиту). Сделано так, чтобы было больше времени между кадрами и меньше между строками (можно выиграть немного в производительности), но внешний вид не меняется если использовать стандартные 1056точек на горизонтальную линию и 525 строк на кадр.

Цитата
По буферу, не совсем уловил мысль, как правильно и оптимально.

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

Оптимальный Vcom у меня был помнится в районе 3.4В. Если интересно могу померять точно.
Hold
Рассчетное выходит 16.2 Мгц... тайминги почти такие же, только ширина синхры у вас поболее и вертикальная задержка в конце кадра прямо таки гигантская - 146 строк. Vcom интересен, у себя подстроечник дает диапазон допустимых значений по ДШ, но можно выкрутить в самый минимум. 1056 и 525 - это на клок 33.3, что дает как раз таки 60фпс. Такой конфиг конечно меньше грузит sdram - на пиксель одно чтение sdram, клок всего 16 мгц, канал fmc даже на половину не загружен, всего 32МБ/с. Попробую.
Genadi Zawidowski
Когда-то, втискивая 272*480 во внутреннюю память ST32F429, я пробовал для хранения использовать формат RRRGGGBB - который распаковывался LUT:

Код
static void
fillLUT_L8(
    LTDC_Layer_TypeDef* LTDC_Layerx
    )
{
    unsigned color;

    for (color = 0; color < 256; ++ color)
    {
#define XRGB(zr,zg,zb) do { r = (zr), g = (zg), b = (zb); } while (0)
        uint_fast8_t r, g, b;

        switch (color)
        {
        case TFTRGB(0, 0, 0)            /*COLOR_BLACK*/:        XRGB(0, 0, 0);            break;    // 0x00 черный
        case TFTRGB(255, 0, 0)            /*COLOR_RED*/:            XRGB(255, 0, 0);        break;     // 0xE0 красный
        case TFTRGB(0, 255, 0)            /*COLOR_GREEN*/:        XRGB(0, 255, 0);        break;     // 0x1C зеленый
        case TFTRGB(0, 0, 255)            /*COLOR_BLUE*/:            XRGB(0, 0, 255);        break;     // 0x03 синий
        case TFTRGB(128, 0, 0)            /*COLOR_DARKRED*/:        XRGB(128, 0, 0);        break;     //
        case TFTRGB(0, 128, 0)            /*COLOR_DARKGREEN*/:    XRGB(0, 128, 0);        break;     //
        case TFTRGB(0, 0, 128)            /*COLOR_DARKBLUE*/:        XRGB(0, 0, 128);        break;     //
        case TFTRGB(255, 255, 0)        /*COLOR_YELLOW*/:        XRGB(255, 255, 0);        break;     // 0xFC желтый
        case TFTRGB(255, 0, 255)        /*COLOR_MAGENTA*/:        XRGB(255, 0, 255);        break;     // 0x83 пурпурный
        case TFTRGB(0, 255, 255)        /*COLOR_CYAN*/:            XRGB(0, 255, 255);        break;     // 0x1F голубой
        case TFTRGB(255, 255, 255)        /*COLOR_WHITE*/:        XRGB(255, 255, 255);    break;  // 0xff    белый
        case TFTRGB(128, 128, 128)        /*COLOR_GRAY*/:            XRGB(128, 128, 128);    break;     // серый
        case TFTRGB(0xa5, 0x2a, 0x2a)    /*COLOR_BROWN*/:        XRGB(0xa5, 0x2a, 0x2a);    break;     // 0x64 коричневый
        case TFTRGB(0xff, 0xd7, 0x00)    /*COLOR_GOLD*/:            XRGB(0xff, 0xd7, 0x00);    break;     // 0xF4 золото
        case TFTRGB(0xd1, 0xe2, 0x31)    /*COLOR_PEAR*/:            XRGB(0xd1, 0xe2, 0x31);    break;     // 0xDC грушевый
#undef XRGB
        default:
            r = ((color & 0xe0) << 0) | ((color & 0x80) ? 0x1f : 0);    // red
            g = ((color & 0x1c) << 3) | ((color & 0x10) ? 0x1f : 0);    // green
            b = ((color & 0x03) << 6) | ((color & 0x02) ? 0x3f : 0);    // blue
            break;
        }
        /* запись значений в регистры палитры */
        LTDC_Layerx->CLUTWR =
            ((color << 24) & LTDC_LxCLUTWR_CLUTADD) |
            ((r << 16) & LTDC_LxCLUTWR_RED) |
            ((g << 8) & LTDC_LxCLUTWR_GREEN) |
            ((b << 0) & LTDC_LxCLUTWR_BLUE);
    }

    LTDC_Layerx->CR |= LTDC_LxCR_CLUTEN;
}
Шаманъ
Цитата(Genadi Zawidowski @ Apr 21 2017, 20:48) *
Когда-то, втискивая 272*480 во внутреннюю память ST32F429, я пробовал для хранения использовать формат RRRGGGBB - который распаковывался LUT

Геннадий приветствую. Такой формат не позволит использовать DMA2D в полную силу. Ну и внутренняя память намного быстрее SDRAM, особенно при random write/read

Цитата(Hold @ Apr 21 2017, 19:09) *
Рассчетное выходит 16.2 Мгц..

Да, в реальности там 16.104МГц
Hold
Вбил ваши параметры, Vcom выкрученный в минус показывает 3.65. RGB565 запустился, но отчего-то цвет фона LTDC всегда синий. Надо разобраться. Но поверх рисует уже нужный цвет, прогнал каждый из 3-х.
UPD: насчет синего сам накосячил. При инициализации LTDC, чтобы не было мусора прогонял всю память через memset левым значением 0x11. На RGB было пофиг, просто серый цвет.
UPD2: решил глянуть производительность в Мпикс/с в штатном тесте STemWin. Поднялась в 4 с лишним раза, показывает 71мпикс/с на RGB565, против 13мпикс/с на ARGB8888, т.е. протягивает 142 МБайт/с.
Шаманъ
Цитата(Hold @ Apr 22 2017, 07:53) *
Vcom выкрученный в минус показывает 3.65

Я вас немного дезинформировал про Vcom - померял у себя Vgh=16.49В, Vgl=-7.44В, Vcom=3.819В. Оптимальное значение Vcom зависит от Vgh/Vgl и от конкретной панели.
Hold
Нашел где косяк с отрисовкой шрифтов в STemWin.
Что-то не так с аппаратным смешением цветов у 1 пикселя в функции, которая используется при выводе сглаженного текста:
Код
/**
  * @brief  Function for mixing up 2 colors with the given intensity.
  *         If the background color is completely transparent the
  *         foreground color should be used unchanged.
  * @param  Color
  * @param  BkColor
  * @param  Intens
  * @retval LCD_COLOR
  */
static LCD_COLOR DMA_MixColors(LCD_COLOR Color, LCD_COLOR BkColor, U8 Intens)
{
  uint32_t ColorFG, ColorBG, ColorDst;

  if ((BkColor & 0xFF000000) == 0xFF000000)
  {
    return Color;
  }
  ColorFG = Color   ^ 0xFF000000;
  ColorBG = BkColor ^ 0xFF000000;

  /* Set up mode */
  DMA2D->CR      = 0x00020000UL | (1 << 9);         /* Control Register (Memory to memory with blending of FG and BG and TCIE) */

  /* Set up pointers */
  DMA2D->FGMAR   = (uint32_t)&ColorFG;                   /* Foreground Memory Address Register */
  DMA2D->BGMAR   = (uint32_t)&ColorBG;                   /* Background Memory Address Register */
  DMA2D->OMAR    = (uint32_t)&ColorDst;                  /* Output Memory Address Register (Destination address) */

  /* Set up pixel format */
  DMA2D->FGPFCCR = LTDC_Pixelformat_ARGB8888
                 | (1UL << 16)
                 | ((uint32_t)Intens << 24);
  DMA2D->BGPFCCR = LTDC_Pixelformat_ARGB8888
                 | (0UL << 16)
                 | ((uint32_t)(255 - Intens) << 24);
  DMA2D->OPFCCR  = LTDC_Pixelformat_ARGB8888;

  /* Set up size */
  DMA2D->NLR     = (uint32_t)(1 << 16) | 1;              /* Number of Line Register (Size configuration of area to be transfered) */

  /* Execute operation */
  DMA2D->CR     |= DMA2D_CR_START;                       /* Control Register (Start operation) */

  /* Wait until transfer is done */
  while (DMA2D->CR & DMA2D_CR_START)
  {
  }

  return (ColorDst ^ 0xFF000000);
}

Криво работающее смешение:

Если закоментить привязку этой функции к GUI, то GUI, видимо, начинает использовать софтовое смешение, и тогда все хорошо:

jcxz
Вопросик может не в тему (лень читать даташит wink.gif :
DMA2D может быть полезен не для вывода на LTDC, а для ускорения отрисовки картинки в обычном ОЗУ?
Причём картинки не в формате этого LTDC, а если пиксели хранятся скажем в формате - 1байт/пиксель или 1байт/2пикселя?
Думаю - можно-ли его использовать для ускорения программной отрисовки в ОЗУ?
Шаманъ
Цитата(jcxz @ Apr 22 2017, 14:59) *
DMA2D может быть полезен не для вывода на LTDC, а для ускорения отрисовки картинки в обычном ОЗУ?

Он так и работает - это абсолютно отдельный блок.

Цитата
Причём картинки не в формате этого LTDC, а если пиксели хранятся скажем в формате - 1байт/пиксель или 1байт/2пикселя?

Формат обрабатываемых картинок можно выбрать из:
ARGB8888, ARGB4444, ARGB1555, RGB888, RGB565, L8, L4, A8, A4

Источник данных может быть в любом из этих форматов, приемник (выходной буфер) только в ARGB8888, ARGB4444, ARGB1555, RGB888, RGB565

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

Цитата
Думаю - можно-ли его использовать для ускорения программной отрисовки в ОЗУ?

Он для этого и предназначен sm.gif
jcxz
Цитата(Шаманъ @ Apr 22 2017, 14:19) *
Источник данных может быть в любом из этих форматов, приемник (выходной буфер) только в ARGB8888, ARGB4444, ARGB1555, RGB888, RGB565

Понятно. спасибо sm.gif
У меня граф.библиотека формирует картинку в формате 2пиксела/байт. Каждый пиксел - это индекс в таблице цветов на 16 элементов.
Потом, перед передачей в LCD, эта картинка по частям перекодируется в RGB565. Похоже - можно хотя-бы эту операцию делать с помощью DMA2D.
Шаманъ
Цитата(jcxz @ Apr 22 2017, 15:24) *
Понятно. спасибо sm.gif
У меня граф.библиотека формирует картинку в формате 2пиксела/байт. Каждый пиксел - это индекс в таблице цветов на 16 элементов.

Это формат L4 (с точки зрения STM wink.gif)
Цитата
Потом, перед передачей в LCD, эта картинка по частям перекодируется в RGB565. Похоже - можно хотя-бы эту операцию делать с помощью DMA2D.

Да это можно сделать без проблем.
SasaVitebsk
Там можно было бы многое, но нет отрицательного смещения, нет дробного смещения. Иначе можно было бы выводить произвольные линии. А так только вертикальные и горизонтальные.
Шаманъ
Цитата(SasaVitebsk @ Apr 22 2017, 20:25) *
Там можно было бы многое, но нет отрицательного смещения, нет дробного смещения. Иначе можно было бы выводить произвольные линии. А так только вертикальные и горизонтальные.

Кроме любых линий (что зачастую не так уж и нужно), отсутствие отрицательного смещения делает невозможным скроллинг/копирование с перекрытием в одном из направлений, а также вывод всяких паттернов. Второй косяк - DMA2D блендер должен дополнительно работать с цветом фона, ибо в нынешнем виде background alpha фактически бесполезная штука. Короче инженеры STMа могли бы посмотреть мануал на какой-ить древний Epson, да на тот же S1D13A04 или что-то подобное, прежде чем ваять DMA2D. Хотя нужно отдать им должное - в нынешнем виде DMA2D весьма неплохо справляется с тем, что может.
jcxz
Цитата(Шаманъ @ Apr 22 2017, 14:38) *
Это формат L4 (с точки зрения STM wink.gif)

Ясно. Спасибо wink.gif
zombi
Цитата(Шаманъ @ Apr 22 2017, 21:05) *
Второй косяк - DMA2D блендер должен дополнительно работать с цветом фона

А с чем работает DMA2D блендер?
Цитата(Шаманъ @ Apr 22 2017, 21:05) *
в нынешнем виде background alpha фактически бесполезная штука.

Можете объяснить как работает background alpha в нынешнем виде?
Rash
А кто-нибудь менял функции или добавлял функционал использование DMA2D в стандартном драйвере от ST при использовании emWin?

Сам emWin работает нормально, то, что не нормально научился подправлять. Единственное, что не устраивает - это при масштабировании больших окон или их перетаскивании, изображение лагает, т.е. заметны перерисовки определённых кусочков виджетов. В кишки его пока сильно не лез, но есть предположение, что он где то на ожидании флагов подвязан.

Разрешение 800х480, RGB565, плата 429Discovey, SDRAM по 16-битной шине, тактовая CPU 168МГц. Стек GUI также лежит в SDRAM. Сейчас в проекте плата с SDRAM по 32-битной шине, думаю раза в 1.5. должно поднять производительность.
Ещё вопрос, тактирование экрана LTDC лучше сторону уменьшения частоты?

Шаманъ
Цитата(zombi @ Apr 23 2017, 15:38) *
А с чем работает DMA2D блендер?

Блендер накладывает два полноценных слоя - передний план и фон. Если к двум полноценным слоям добавить еще один фоновый со сплошной заливкой (так, как это сделано в LTDC), то background_alpha станет реально полезной фичей.

Цитата
Можете объяснить как работает background alpha в нынешнем виде?

А он практически никак не работает. Смотрите сами - слои комбинируются по формулам из раздела 9.3.6. Если формулы преобразовать и немного изменить (принять, что 0 <= alpha <= 1.0), то основная формула примет такой вид:

Cout = (Cfg * Afg + Cbg*Abg*(1.0 - Afg)) / (Afg + Abg*(1 - Afg))

Нетрудно заметить, что при полностью прозрачном переднем плане (Afg = 0) формула становится такой:

Cout = Cbg*Abg / Abg = Cbg

Т.е. Abg (прозрачность фона) никак эту прозрачность не изменяет laughing.gif (за исключением Abg=0, в этом случае Cbg = 255) . Для промежуточных значений Afg, Abg оказывает влияние на конечное изображение, но совсем не так, как ожидается. Найти какое-либо полезное применение для Abg я у себя найти не смог.

Цитата(Rash @ Apr 23 2017, 15:55) *
Ещё вопрос, тактирование экрана LTDC лучше сторону уменьшения частоты?

Лучше для чего? Анимации нормально выглядеть начинают от 20..25к/с, при дальнейшем повышении я никакой разницы не замечал (может на другом контенте потребуется и больше, хотя в кино вроде всем хватает). В общем случае, чем выше частота LTDC, тем больше пропускной способности SDRAM он "отъедает", как результат производительность падает. Т.е. оптимально выбирать минимально достаточную для нормальной работы TFT и нормального вида анимированных элементов (если они есть).

По поводу emWin и прочего подсказать не могу - у меня все самописное.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.