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

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

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

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


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

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

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

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


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

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

Сухие цифры: самый не оптимальный режим - 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 восмиметровых чипов.

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

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

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

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

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

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


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


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

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

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

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



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

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

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