DMA2D в stm32f4хх, реально такой убогий, или я что-то не понимаю? Опции

[Шаманъ]

Приветствую всех!

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

Спасибо!
P.S. Даже древний s1d13a04 и то умел намного больше...

[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, 10:13

[Шаманъ]

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

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

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

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