Проблема с отображением на TFT LCD Опции

[Magazeev]

Доброго времени суток, хочется задать такой вопрос: пытаюсь на LPC1788 с самодельной платой показывать картинки (что-то типо цифровой фоторамки), для чего использую SDRAM. Картинка отображается четко и без искажений, даже не одна, однако, в случае когда я пытаюсь делать что-то с памятью SDRAM, например записать какие-то данные в другую часть памяти, то на время работы с ней на дисплее вместо изображения появляется рябь, а после того как запись в память закончена, изображение возвращается. Не могу разобраться от чего это происходит и как с этим бороться(( Спасибо)

[sherr]

Доброго времени суток, хочется задать такой вопрос: пытаюсь на LPC1788 с самодельной платой показывать картинки (что-то типо цифровой фоторамки), для чего использую SDRAM. Картинка отображается четко и без искажений, даже не одна, однако, в случае когда я пытаюсь делать что-то с памятью SDRAM, например записать какие-то данные в другую часть памяти, то на время работы с ней на дисплее вместо изображения появляется рябь, а после того как запись в память закончена, изображение возвращается. Не могу разобраться от чего это происходит и как с этим бороться(( Спасибо)

Наверное, не хватает полосы пропускания шины памяти, на сайте NXP есть экселевский файл для расчетов, если загрузка шины более
40-50 % - могут быть такие проблемы, тогда снижайте частоту кадров или глубину цвета. А вообще надо было сразу привести пара-
метры - пиксельную частоту, глубину цвета, ширину шины SDRAM, частоту самого контроллера ?

[aaarrr]

Посмотрите в мануале приоритеты AHB-мастеров. У LCD он, кажется, изначально задавлен.

[ViKo]

Не конкретно к данному железу, но обычно у контроллера ЖКИ между кадрами и строками имеется "мертвое время", которое можно выловить, и записывать в ОЗУ только в эти моменты.

[SII]

Как уже намекнули, надо настроить приоритеты мастеров шины: у контроллера дисплея должен быть высший, затем могут идти другие устройства (например, USB и Ethernet), затем -- канал данных процессора и в самом конце -- канал инструкций. Всего у LPC177x/8x, помнится, четыре уровня приоритета было.

Кроме того, обычно нельзя писать в буфер кадра в то время, как идёт его отображение. Т.е., если надо изменить отображение, следует сначала сформировать его в другом месте памяти, а потом просто переключить отображение на новый буфер.

Сообщение отредактировал SII - Aug 14 2012, 07:29

[Magazeev]

Наверное, не хватает полосы пропускания шины памяти, на сайте NXP есть экселевский файл для расчетов, если загрузка шины более
40-50 % - могут быть такие проблемы, тогда снижайте частоту кадров или глубину цвета. А вообще надо было сразу привести пара-
метры - пиксельную частоту, глубину цвета, ширину шины SDRAM, частоту самого контроллера ?

Спасибо, воспользовася и проверил, с моими параметрами загрузка шины меньше 40%. у меня дисплей разрешением 800x600, c 24bpp глубиной, сам контроллер работает на скорости 120 Mhz, на такой же скорости контроллер общается с SDRAM. LCD контроллер работает на скорости 40 Mhz. попробовал менять частоту, это не помогло)

Посмотрите в мануале приоритеты AHB-мастеров. У LCD он, кажется, изначально задавлен.

Как уже намекнули, надо настроить приоритеты мастеров шины: у контроллера дисплея должен быть высший, затем могут идти другие устройства (например, USB и Ethernet), затем -- канал данных процессора и в самом конце -- канал инструкций. Всего у LPC177x/8x, помнится, четыре уровня приоритета было.

Действительно, я этого не сделал. Изменил приоритет LCD DMA на самый высокий в Matrix Arbitration register на самый высокий:

Код

#define MATRIX_ARB         0x400FC188

и в функции инициализации LCD контроллера:

Код

uint32_t* matrix_arb = (uint32_t*)MATRIX_ARB;
*matrix_arb = 0xC09;
/* The highest priority to LCD DMA
1:0 PRI_ICODE I-Code bus priority. Should be lower than PRI_DCODE for proper operation. ->0x1
3:2 PRI_DCODE D-Code bus priority. ->0x2
5:4 PRI_SYS System bus priority. ->0
7:6 PRI_GPDMA General Purpose DMA controller priority.-> 0
9:8 PRI_ETH Ethernet DMA priority. ->0
11:10 PRI_LCD LCD DMA priority. -> 0x3
13:12 PRI_USB USB DMA priority. ->0
15:14 - Reserved. Read value is undefined, only zero should be written. NA
16 ROM_LAT ROM latency select. Should always be 0. ->0
31:17 - Reserved. Read value is undefined, only zero should be written. NA
*/

Однако и это не помоголо. Рябь при работе с памятью осталась.

Кроме того, обычно нельзя писать в буфер кадра в то время, как идёт его отображение. Т.е., если надо изменить отображение, следует сначала сформировать его в другом месте памяти, а потом просто переключить отображение на новый буфер.

Я собственно так и делал. Однако моя проблема вознакает не только когда я пытаюсь менять данные в буфере отображаемого изображения, но и когда работаю с другой областью памяти.

[SII]

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

Можно ещё на пробу перейти на 16-разрядный цвет -- снизит загрузку памяти наполовину (24-битный цвет кодируется же 32 разрядами, если не ошибаюсь, просто старший байт не используется).

[Magazeev]

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

Действительно, согласно UserManual, это можно настроить в регистре LCD_CTRL: бит 16 - WATERMARK (LCD DMA FIFO watermark level).
Controls when DMA requests are generated:
0 = An LCD DMA request is generated when either of the DMA FIFOs have four or more empty locations.
1 = An LCD DMA request is generated when either of the DMA FIFOs have eight or more empty locations.
у меня стоит 0)

Можно ещё на пробу перейти на 16-разрядный цвет -- снизит загрузку памяти наполовину (24-битный цвет кодируется же 32 разрядами, если не ошибаюсь, просто старший байт не используется).

Это мне не представляется возможным, так как у меня дисплей с 24 разрядной шиной данных. А переходе на 16 разрядный цвет, сигналы будут идти через другие пины.

[aaarrr]

Это мне не представляется возможным, так как у меня дисплей с 24 разрядной шиной данных. А переходе на 16 разрядный цвет, сигналы будут идти через другие пины.

Если верить мануалу, пины одни и те же.

uint32_t* matrix_arb = (uint32_t*)MATRIX_ARB;
*matrix_arb = 0xC09;
...
Однако и это не помоголо.

А запись-то реально производится? Тип должен быть volatile uint32_t.

[Magazeev]

Прошу прощения, я неправильно Вас понял. При переходе на 16 разрядов проблема исчезла. Это означает, что проблема была действительно в перегрузке шины данных. На 24 разрядном цвете снижение скорости контроллера LCD в 4 раза решило мою проблему. Выходит для работы на максимальной скорости дисплея необходимо менять оперативную память с 16 на 32 разряда. Спасибо всем большое за ваши ответы!)

[aaarrr]

Это означает, что проблема была действительно в перегрузке шины данных.

В покое экран показывает нормально, следовательно полосы достаточно. При параллельной работе с памятью со стороны процессора, последний должен отсекаться в нужные моменты коммутатором, как имеющий более низкий приоритет. Проверьте все же MATRIX_ARB.

[Magazeev]

Проверил на большой скорости, однако изменение типа с uint32_t на volatile uint32_t проблему не решили. Но регистр по адресу MATRIX_ARB изменяется.