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

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

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

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

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

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

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


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

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

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

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

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

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

Действительно, согласно 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)

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

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


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

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

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

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