Jump to content

    

Не могу подружить SDRAM и LTDC

было бы интересно посмотреть код

 

Share this post


Link to post
Share on other sites
On 1/24/2020 at 1:12 PM, golf2109 said:

было бы интересно посмотреть код

 

Хех... подружить-то я подружил, но они живут как кошка с собакой. Подробности здесь 

 

Share this post


Link to post
Share on other sites

Господа, может я пытаюсь совместить несовместимое? 

У меня дисплей 1024х600.  Цвет RGB888.   Размер кадра    получается 1 843 200 байт

1 слой, планируется использовать DMA2D (контроллер STM32F746BG)

Память SDRAM 32 бит.

 

Пиксельклок дисплея - не менее 40 МГц (реально он стабильно но с мерцанием работает на 30 МГц) но не более 65 МГц

 

Согласно Аппноуту максимальный пиксельклок для этих параметров 52 МГц.  Я пока экспериментирую с RGB565 и без DMA2D - то есть 83 МГц

 

oVjFLeSq.png

 

Способна ли эта связка, исходя из указанных параметров работать или нет?

 

У меня пока результаты неутешительны Стабильную картинку удалось получить только  на пиксельклоке 30 МГц и объеме кадра 200х200 пикселей.

С внутренней SRAM таких проблем нет. А вот со SDRAM или встроенной FLASH - картинка дергается и изображение корежит.

Тактирование вот такое

HK2cBTNq.png

 

Share this post


Link to post
Share on other sites
2 часа назад, MementoMori сказал:

Господа, может я пытаюсь совместить несовместимое? 

У меня дисплей 1024х600.  Цвет RGB888.   Размер кадра    получается 1 843 200 байт

Пиксельклок дисплея - не менее 40 МГц (реально он стабильно но с мерцанием работает на 30 МГц) но не более 65 МГц

Согласно Аппноуту максимальный пиксельклок для этих параметров 52 МГц.  Я пока экспериментирую с RGB565 и без DMA2D - то есть 83 МГц

очень похоже на несовместимое, т.к. экрану надо 51.2МГц, а контроллер вашего stm32 может не более 45, см аттач

т.е. у вас "вилка" от 40.8 (минимум для дисплея) до 45 (максимум для контроллера)

и еще не факт, что контроллер умеет правильно генерить развертки и времянки для "нестандартных" разрешений

у вас варианты:

- поискать экран с меньшим разрешением и прикрутить с положительным исходом

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

- искать блох дальше, между зазорами по режимам lcd и контроллера

ЗЫ надеюсь все ваши цифры это от осцилла, а не теоретические выкладки

fclk.jpg

Share this post


Link to post
Share on other sites

800*480 еше взлетело бы... Там пиксельклок вокруг 30 МГц

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

Edited by GenaSPB

Share this post


Link to post
Share on other sites
32 minutes ago, Jury093 said:

т.е. у вас "вилка" от 40.8 (минимум для дисплея) до 45 (максимум для контроллера)

и еще не факт, что контроллер умеет правильно генерить развертки и времянки для "нестандартных" разрешений

Умеет. Проверил на 45 МГц. На зеленом фоне рисую пустое черное окно - дрожания границ окна нет. ТО есть внутри LTDC картинка формируется правильно (бывает только, что при различной комбинации делителей, когда считалка куба вроде бы показывает один и тот же пиксельклок, дисплей не запускается вообще). ПО факту дрожат читаемые из SDRAM данные.

 

Другое дело, что невозможно почему-то работать с кадром более 200х200 пикселей. И это не времянки контроллера - на указанном разрешении все работает, снижаю HCLK меньше 200 МГц - начинаются глюки. 

 

Понимаете, вы обрисовали ситуацию как несовместимость такого дисплея, как я привел, с таким контроллером LTDC, какой имеется в STM32F7. Но это не вяжется с тем фактом, что при работе с внутренней SRAM все идеально. Вот скажите, если бы была проблема в указанной вами вилке взаимодействия контроллера и дисплея, то картинка, полученная из SRAM, нормально отображалась бы?

 

Скажите, если я укажу в настройках 800х480 пикселей, а разницу компенсирую таймингами, это будет равноценная имитация дисплея 800х480?

19 minutes ago, GenaSPB said:

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

Я экспериментировал с 16-ю. Попробую на 8.

Share this post


Link to post
Share on other sites

Повторно процитирую Юрия

1 hour ago, Jury093 said:

.к. экрану надо 51.2МГц, а контроллер вашего stm32 может не более 45, см аттач

т.е. у вас "вилка" от 40.8 (минимум для дисплея) до 45 (максимум для контроллера)

и еще не факт, что контроллер умеет правильно генерить развертки и времянки для "нестандартных" разрешений

 Поставил 8 битный формат - L8. Установил разрешение слоя 1024х600.   Дисплей завелся на 57,2 МГц.

Господа, я пытаюсь мыслить системно, может где в чем ошибаюсь, но все же...

Смотрите,  согласно даташиту, каков бы ни был формат данных - контроллер LTDC преобразует их во внутренний формат ARGB8888 и в таком виде клеит слои для вывода на дисплей.  И для взаимодействия LTDC с дисплеем уже не важно, в каком виде они пришли.     

Поясню:

У нас есть 32 битный FIFO. 

Если я включаю 32 битный режим то в контроллер зайдет 0x000000FF - и в FIFO будет записано 0x000000FF

Если я включу 8 битный режим, то в контроллер зайдет 0xFF а в FIFO будет 0x000000FF. Если я не прав, то поправьте.

Далее

То есть физически связка LTDC и дисплея способна работать на разрешении 1024х600 с пиксельклоком 57,2 МГц

Посмотрите на картинку

E42LLa1m.png

 

Господа, вы согласны, что обведенный пунктиром регион Pixel clock Domain работает в режиме 32 битного цвета, а на дисплей передаются 24 битные данные независимо от входных данных?

Пиксельклоки они ведь не зависят от битности цвета? Для дисплея пиксель всегда 24 битный.

Значит, если я запустил его в режиме 1024х600 х 57 МГц, то он работает с этим разрешением и с 32 битным цветом?

Или я не прав?

 

Если прав, то вопрос в том, как запихнуть в контроллер столько пикселей в 32 битном формате.

 

Share this post


Link to post
Share on other sites

Что-то много всего написано, но ограничение очень простое - скорость интерфейса FMC.

Share this post


Link to post
Share on other sites

Хотя.....  в режиме RGB888 дисплей работает с разрешением 1024х600 лишь на частоте 43.75.... с внутренней SRAM.   Но ведь не на вдвое меньшей же частоте. Значит если я неправ, то лишь отчасти...

 

 

6 minutes ago, AVI-crak said:

Что-то много всего написано, но ограничение очень простое - скорость интерфейса FMC.

Вот об этом я и спрашивал выше (или в другой теме, на которую есть ссылка)  Сколько FMC способен выдать с 32битной памятью?

 

Share this post


Link to post
Share on other sites
9 minutes ago, AVI-crak said:

Что-то много всего написано, но ограничение очень простое - скорость интерфейса FMC.

 

У топикстартера LTDC :)

Share this post


Link to post
Share on other sites
1 minute ago, __inline__ said:

У топикстартера LTDC :)

Топикстартер подключил к FMC SDRAM, являющуюся буфером. Скорость которого не дает нормально выводить картинку

 

 

Share this post


Link to post
Share on other sites
11 minutes ago, MementoMori said:

Сколько FMC способен выдать с 32битной памятью?

Не совсем корректный вопрос. Выдавать может много, всё зависит от того как к ней обращаются.

Начнём с того что sdram бодро читается/пишется линейными блоками, равными размеру одной страницы. Максимальная скорость - чтение всей страницы. А вот на границе страниц, FMC уже спотыкается. Там есть небольшая задержка, которая в идеале полностью поглощается собственным FIFO. В реальности задержка накапливается, и обязательно проявится. При обращении к другому банку - задержка ещё выше. Те самые cas ras. К этим задержкам добавляется до четырёх тактов работы арбитра, он решает кого подключать/отключать от шины. Ещё - FIFO автоматически догоняется после чтения/записи, и если попадает на границу банка - то арбитр не в состоянии быстро подключить новый интерфейс связи. Всё вместе роняет скорость рандомного чтения до уровня плинтуса.

Самая дикая задержка может быть следствием "оптимизации" программного обращения к sdram, когда читают линейно в сторону уменьшения адреса. Так умеет только кеш, и быстрая sram. Но GCC упорно "оптимизирует" на обратное чтение/запись вообще весь код, даже там где нельзя.   

Share this post


Link to post
Share on other sites

 

59 minutes ago, MementoMori said:

Значит, если я запустил его в режиме 1024х600 х 57 МГц, то он работает с этим разрешением и с 32 битным цветом?

Или я не прав?

Как уже написали все упрется в пропускную способность FMC. То, что Вы хотите не для реального применения. Урежьте "осетра" до одного слоя LTDC, 16битного цвета и частоту кадров до 30..40к/с (правда, не все панели будут нормально работать на такой частоте), тогда более менее нормально будет. 

Share this post


Link to post
Share on other sites

Итак. Результаты экспериментов. Во всех случаях буфер в SRAM.

1. 1024x600, 16 битный цвет.  Максимальная работоспособность на частоте пиксельклок до 57,2 Мгц, дальше дрожание содержимого буфера.   

2. 1024x600, 8 битный цвет - поднимаю пиксельклок до 65.625 МГц, а дальше плохеет дисплею. То есть сам дисплей не заводится, либо картинка есть, сильно страдает развертка. Но буфер до последнего момента цельный.

3. 1024x600, 24 битный цвет.  Максимальная работоспособность на частоте пиксельклок до 43,75 Мгц, дальше дрожание содержимого буфера

4. 800x480, 24 битный цвет.  Максимальная работоспособность на частоте пиксельклок до 44,9 Мгц.

5. 1024х600  32битный цвет - максимальный пиксельклок 32,29 МГц.

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

Развертка дисплея работоспособна на частотах от 28,64 МГц до 65.625 Мгц, работоспособность при увеличении и уменьшении частоты пропадает постепенно.

 

А теперь, господа - БИНГО!!! Переключаемся на SDRAM 100 МГц!

1. 1024x600, 8 битный цвет.  Максимальная работоспособность на частоте пиксельклок до 57,8 Мгц.

2. 1024x600, 16 битный цвет - опускал пиксельклок до 28,64 Мгц - буфер дрожит. Установить, на каком же пиксельклоке заработает буфер нельзя - ниже не работает развертка. 

3. В режиме 16 битного цвета заработало лишь на разрешении  200х200, на пиксельклоке 30 МГц. Не знаю, правильно ли я считаю пропускную способность - 30 МГц/ (1024х600) = 48 кадров. 48 кадров *200*200*2=3 906 250 байт/сек.

4. 24 битный цвет.  заработало лишь на разрешении  95х95, на пиксельклоке 30 МГц  Не знаю, правильно ли я считаю пропускную способность - 30 МГц/ (1024х600) = 48 кадров. 48 кадров *95*95*3=1 299 600 байт/сек.

5. 32битный цвет не стал проверять.

 

Резюме.  в SRAM пропускная способность обеспечивает около 100 мбайт/сек. SDRAM - грубую прикидку цифр вы видели. Это абсурд....

 

21 hours ago, Шаманъ said:

Урежьте "осетра" до одного слоя LTDC,

У меня 1 слой.

Господа, уж очень неадекватные скорости чтения SDRAM....

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this