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.
===
Если есть кто реализовывал аналогичные варианты - откликнитесь. Любопытно кто как делал.

[Огурцов]

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

[Шаманъ]

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

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

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

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

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

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

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

[SpyBot]

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

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