STM32F429 Discovery / uGFX, работа с LCD 7'' 800x480 Опции

[nanorobot]

Провожу эксперименты на Дискавери 429 . Использую uGFX, при работе с родным LCD все устраивает. Но хочется большего. Подключил внешний LCD 800х480. Очень заметно мерцание. Повысил в два раза частотту тактирования интерфейса LTDC процессора. Мерцание снизилось до приемлемого, но при перерисовке ГУИ появились серьезные артефакты. Далее действовал методом научного тыка, а именно запретил UGFX использовать DMA2D, было интересно узнать насколько все ухудшится. Но, странно, артефакты пропали, хотя скорость перерисовки заметно снизилас. Во всех случаях RGB565 и максимальный уровень оптимизации.

Сообщение отредактировал nanorobot - Sep 23 2018, 12:39

[mantech]

Но, странно, артефакты пропали, хотя скорость перерисовки заметно снизилас.

А что тут странного-то?? Там узкое место скорость памяти, снизили загрузку шины, уменьшилась скорость отрисовки и стало стабильнее изображение - все логично

[nanorobot]

А что тут странного-то?? Там узкое место скорость памяти, снизили загрузку шины, уменьшилась скорость отрисовки и стало стабильнее изображение - все логично

Если свою плату делать с 32 битовой SDRAM то можно ожидать удовлетворительной работы с разрешением 800х480? Или сразу смотреть в сторону STM32F7xx/ STM32H7xx ?

[mantech]

Если свою плату делать с 32 битовой SDRAM то можно ожидать удовлетворительной работы с разрешением 800х480? Или сразу смотреть в сторону STM32F7xx/ STM32H7xx ?

И что вы там увидите? Правильно, ту же сд-рам

32бита это максимум, как можно увеличить скорость, дальше только контроллеры с ДДР, но это уже не к СТМу...

[scifi]

Некоторые делают двойной буфер кадра, чтобы не мерцало.

[Aner]

Если свою плату делать с 32 битовой SDRAM то можно ожидать удовлетворительной работы с разрешением 800х480? Или сразу смотреть в сторону STM32F7xx/ STM32H7xx ?

с разрешением 800х480, ... смотреть только в сторону старших армов с DDR3/4, под линуксами и там где есть нормальный GUI и тп.
C STM32H7xx не все алё.

[mantech]

Некоторые делают двойной буфер кадра, чтобы не мерцало.

Тут не в буферах дело, а пропускной способности шины памяти. Если только отрисовка и работает нормально, то при одновременной интенсивной записи уже идет просадка по скорости и вылезают артефакты.

[scifi]

с разрешением 800х480, ... смотреть только в сторону старших армов с DDR3/4, под линуксами и там где есть нормальный GUI и тп.
C STM32H7xx не все алё.

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

Тут не в буферах дело, а пропускной способности шины памяти. Если только отрисовка и работает нормально, то при одновременной интенсивной записи уже идет просадка по скорости и вылезают артефакты.

Ну как бы надо соотносить желания и возможности, наверное. Кстати, а темп прорисовки контролировать не вариант?

[Arlleex]

Как было уже озвучено - все упирается в пропускную способность шины.
И никакая двойная буферизация не поможет - даже статичная картинка все равно вычитывается из памяти и отрисовывается с отображением прямо на пиксели.
Я поднимал частоту и делал другой формат: не RGB888, а ARGB565. Никаких мерцаний на дисплее 800x480.

[nanorobot]

Как было уже озвучено - все упирается в пропускную способность шины.
И никакая двойная буферизация не поможет - даже статичная картинка все равно вычитывается из памяти и отрисовывается с отображением прямо на пиксели.
Я поднимал частоту и делал другой формат: не RGB888, а ARGB565. Никаких мерцаний на дисплее 800x480.

Картинка близка к статичной, таблицы, менюшки, текстовые поля. Формат у меня тоже 565б Я бы готов и и 8 битный CLUT использовать, но, насколько я понимаю, в этом случае придется попрощаться со сглаживанием шрифтов, что меня не устраивает.
И да, проблема не в мерцании, оно лечится повышением частоты, а в возникающих при этом повышении артефактах.

Сообщение отредактировал nanorobot - Sep 24 2018, 14:50

[Arlleex]

Ну покажите артефакты тогда. У меня артефакты были при некачественом питании SDRAM.

[nanorobot]

Ну покажите артефакты тогда. У меня артефакты были при некачественом питании SDRAM.

Если только завтра. Все дела на работе, а я уже дома. Пока могу описать словами. Артефакты очень серьезные. при перемещении курсора - выделенной цветом строки по таблице, рваное изображение этой же таблицы мелькает в стороне от нее. Как то так. В принципе при отключении DMA2D все почти приемлемо, но оставляет неприятное впечатление начальное прорисовывание экрана, сравнительно медленное. Тем более что картинка пока осталась от прежнего LCD 320x240, после того как я переделаю ее на весь 800х480 это станет еще более заметным

Сообщение отредактировал nanorobot - Sep 24 2018, 16:17

[mantech]

Если только завтра. Все дела на работе, а я уже дома. Пока могу описать словами. Артефакты очень серьезные. при перемещении курсора - выделенной цветом строки по таблице, рваное изображение этой же таблицы мелькает в стороне от нее. Как то так. В принципе при отключении DMA2D все почти приемлемо, но оставляет неприятное впечатление начальное прорисовывание экрана, сравнительно медленное. Тем более что картинка пока осталась от прежнего LCD 320x240, после того как я переделаю ее на весь 800х480 это станет еще более заметным

У меня подобное было, когда кэш был неправильно настроен, но в данном МК его нет, поэтому странно, как-будто что-то с таймингами.

[nanorobot]

Некоторые делают двойной буфер кадра, чтобы не мерцало.

двойной буфер кадра не чтоб не мерцало, а чтоб не было артефактов? То есть имеем две копии экранов, перерисовываем в теневом, а потом переключаем? Интересно, uGFX поддерживает такую технику? Ухожу читать...

Сообщение отредактировал nanorobot - Sep 26 2018, 08:55

[scifi]

двойной буфер кадра не чтоб не мерцало, а чтоб не было артефактов? То есть имеем две копии экранов, перерисовываем в теневом, а потом переключаем? Интересно, uGFX поддерживает такую технику? Ухожу читать...

Двойной буфер, чтобы не раздражала медленная прорисовка. Если артефакты от затыка на шине, двойной буфер не в тему - второй буфер на той же шине, что и первый.

[nanorobot]

Двойной буфер, чтобы не раздражала медленная прорисовка. Если артефакты от затыка на шине, двойной буфер не в тему - второй буфер на той же шине, что и первый.

да, наверное так. Но тогда, возвращаясь назад - 32 битовая SDRAM супротив 16 битовой, даст двойной(плюс минус лапоть) прирост скорости шины? Или только для формата вроде RGB888?

Сообщение отредактировал nanorobot - Sep 26 2018, 10:12

[mantech]

да, наверное так. Но тогда, возвращаясь назад - 32 битовая SDRAM супротив 16 битовой, даст двойной(плюс минус лапоть) прирост скорости шины? Или только для формата вроде RGB888?

Прирост даст, но не двойной. Формат видео большого значения не имеет.

[Integro]

Прирост даст, но не двойной. Формат видео большого значения не имеет.

Не могли бы вы пояснить почему прирост будет, но не двойной?
Так как DMA все ровно будет фетчить по 16бит (для 565) и будет складывать в фифо контроллера по 2байта? Количество обращений к памяти ведь не измениться? За счет чего прирост?
Или DMA возьмет из памяти 4байта положит их в фифо(32бит) и контроллер зная, что это два пикселя 565 выкинет в дисплей (не уверен что LCD контроллер на это способен), в этом случае прирост в два раза.
Для 32битного формата задержка чтения также сократиться в два раза. Или я что-то упускаю?

[mantech]

Не могли бы вы пояснить почему прирост будет, но не двойной?
Так как DMA все ровно будет фетчить по 16бит (для 565) и будет складывать в фифо контроллера по 2байта? Количество обращений к памяти ведь не измениться? За счет чего прирост?
Или DMA возьмет из памяти 4байта положит их в фифо(32бит) и контроллер зная, что это два пикселя 565 выкинет в дисплей (не уверен что LCD контроллер на это способен), в этом случае прирост в два раза.
Для 32битного формата задержка чтения также сократиться в два раза. Или я что-то упускаю?

Ускорение работы с памятью идет в основном за счет burst-транзакций, от ширины шины их кол-во не меняется, поэтому процентов 10-15 потерь в скорости будет. По крайне мере в МК с ДДР памятью такой процент потерь имеется.

[nanorobot]

Не могли бы вы пояснить почему прирост будет, но не двойной?
Так как DMA все ровно будет фетчить по 16бит (для 565) и будет складывать в фифо контроллера по 2байта? Количество обращений к памяти ведь не измениться? За счет чего прирост?
Или DMA возьмет из памяти 4байта положит их в фифо(32бит) и контроллер зная, что это два пикселя 565 выкинет в дисплей (не уверен что LCD контроллер на это способен), в этом случае прирост в два раза.
Для 32битного формата задержка чтения также сократиться в два раза. Или я что-то упускаю?

Так же не вполне себе представляю нюансы работы LCD контроллера. Не исключаю, что прирост будет за счет того, что перерисовка картинки с использованием DMA2D будет юзать 32 битовый доступ к SDRAM, что снизит нагрузку на шину в процессе рисования, и как следствие, уменьшит(возможно до нуля ) появление артефактов. Практика критерий истины (с)

Сообщение отредактировал nanorobot - Sep 27 2018, 10:52

[AVI-crak]

Я не в курсе насколько будет ускорение, потому как F7, 16 бит память, и 800*480 экран.
Но могу точно сказать - свободных ног мк станет значительно меньше.

[nanorobot]

Я не в курсе насколько будет ускорение, потому как F7, 16 бит память, и 800*480 экран.
Но могу точно сказать - свободных ног мк станет значительно меньше.

Про ноги очевидно. Остальное не понял.

[Integro]

Ради интереса решил разобраться как влияет ширина шины и выходной формат на ST'шных контроллерах...
Открываю интернет, а там уже все посчитано



Оригинал

[nanorobot]

Ради интереса решил разобраться как влияет ширина шины и выходной формат на ST'шных контроллерах...
Открываю интернет, а там уже все посчитано

Спасибо! То что нужно! Мои надежды подтверждаются! RTFM!

Сообщение отредактировал nanorobot - Sep 28 2018, 18:11