MementoMori

Только непонятка странная.... раньше я указывал частоты для Pixelclock 40-65 Мгц. Не узнаю уже, какими они были на самом деле. Сейчас указываю частоты 25-35 МГц - выше не тянет. Ниже мерцает. Я бы мог списать снижение этих цифр на правильное тактирование, но по даташиту дисплей требует 40-65 Мгц. У меня на 40 даже не заводится. Именно дисплей, именно развертка. На VSync при частоте пиксельклока, указанной как 30 МГц, ловлю 35 Герц. А 1024х600*35=21МГц... Что-то я не пойму этих математических взаимосвязей между разрешением, частотой кадров и пиксельклоком. Точнее принцип ясен, но цифры немного не сходятся. В общем, если подытожить - удалось получить стабильную картинку (под стабильной картинкой я имею в виду стабильное обновление информации из SDRAM) с частотой 35 кадров в секунду, разрешением 1024х600 и 24 битным цветом. Есть слааааабое мерцание. Кстати, если включать в RGB565, результат не лучше. Полагаю, что когда буду рисовать, то SDRAM поднагрузится и будут артефакты. Но, надеюсь с DMA2D и двойной буферизацией это удастся победить. В крайнем

Не работал кварц. Думал, плохо припаял - оказалось нет. Поставил новый - и тактирование и SDRAM все заработало как надо. Подбираю теперь пока режимы экрана, ибо какие-то глюки проскакивают, но это точно не SDRAM - ее я прогнал тестами полчаса - все нормально. Черт... неделя убитого времени из-за того, что не догадался проверить тактирование. Никаких серьезных задач контроллер не выполнял, вот я и не заметил, что он работает на 16 Мгц.... P.S. С CAS Latency=2 что-то не пошло. Некоторые пиксели стали плавать.

Так и есть Функция uint32_t HAL_RCC_GetSysClockFreq(void) { uint32_t pllm = 0, pllvco = 0, pllp = 0; uint32_t sysclockfreq = 0; /* Get SYSCLK source -------------------------------------------------------*/ switch (RCC->CFGR & RCC_CFGR_SWS) { case RCC_SYSCLKSOURCE_STATUS_HSI: /* HSI used as system clock source */ { sysclockfreq = HSI_VALUE; break; } case RCC_SYSCLKSOURCE_STATUS_HSE: /* HSE used as system clock source */ { sysclockfreq = HSE_VALUE; break; } .............................. сообщила мне, что источник тактирования у меня HSI, а SYSCLK=16 МГц)

Не знаю даже что и сказать. Ваш код виснет на последней строке приведенного ниже фрагмента /* Enable HSE */ RCC->CR |= RCC_CR_HSEON; while(!(RCC->CR & RCC_CR_HSERDY)); Наверное все-таки мое предположение верно - не работает HSE, система переключается на HSI 16 МГц- как раз получающиеся частоты этому и соответствуют: 1. SDRAM - HCLK/2 =16/2=8 МГц 2. В 12,5 раз медленнее работает таймер 3. Systick выдает правильные интервалы. Осталось проверить, так ли это...

Не совсем понял, о чем вы... Ну тот факт, что если поставить делитель HSE на величину,равную частоте кварца, то какими бы ни были остальные множители, ltdc clock перестает работать (то ли не генерируется, то ли частота не подходящая)уже говорит о том что ошибки есть. Лично я в прошлом году нашел ошибку в одной из версий, благодаря которой не настраивались cs на qspi, написал в ST, думал, что я дурак, а они ответили, мол, ошибка, исправим Но с вами согласен, такая вещь, как тактирование - давно бы уже нашли ошибку, если б она там была. Лично мне кажется подозрительно странным соотношение должной частоты клока (100 мгц) и реальной (8 мгц). Это как 200 и 16 и напоминает ситуацию, когда срабатывает CSS. Вернусь домой и если код, предложенный выше, не сработает, то попробую посмотреть на прерывания от css. Еще есть мысль - оказывается tim11 можно подключить к HSE в режиме input capture. То есть хотя бы это звено проверить. И кстати... я изначально видел проблему так - проект куба под дискавери и touchgfx работает из коробки, куб сам настраивает периферию, узнав что у меня дискавери, мой же проект, сделанный ручками, не работает. И я потратил уйму времени, пытаясь найти разницу между двумя проектами. По факту же, на дискавери, на настройках, предлагаемых кубом, та же самая проблема. Там скорость SDRAM еще меньше. Но на разрешении 480х272 и пиксельклоке 9.6 мгц, проблем с буфером не возникает.

Начну для начала с картинки для наглядности Вот как это выглядит в коде RCC_OscInitTypeDef RCC_OscInitStruct = {0}; RCC_ClkInitTypeDef RCC_ClkInitStruct = {0}; RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0}; /** Configure the main internal regulator output voltage */ __HAL_RCC_PWR_CLK_ENABLE(); __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1); /** Initializes the CPU, AHB and APB busses clocks */ RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLM = 25; RCC_OscInitStruct.PLL.PLLN = 400; RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; RCC_OscInitStruct.PLL.PLLQ = 2; if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) { Error_Handler(); } /** Activate the Over-Drive mode */ if (HAL_PWREx_EnableOverDrive() != HAL_OK) { Error_Handler(); } /** Initializes the CPU, AHB and APB busses clocks */ RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2; RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1; RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4; RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2; if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_6) != HAL_OK) { Error_Handler(); } Хочу я к примеру, понять - соответствует ли HCLK истинному. От него тактируется FMC и core. Поскольку HAL_Delay(1000) дает правильную задержку в 1 секунду, считаю, что ядро тактируется правильно. Смущает только то, что если настроить HCLK на 100 МГц, то библиотека не пересчитывает это и имею задержку в 2 секунды. От 200 МГц core тактируется правильно. Но вот SDRAM_CLK, который настроен на половину HCLK, получается меньше 10 МГц. Захожу с другой стороны. Настраиваю таймер TIM4. Он тактируется от APB1, 100МГц. Настраиваю его переполнение на 100 мсек htim4.Instance = TIM4; htim4.Init.Prescaler = 10000; htim4.Init.CounterMode = TIM_COUNTERMODE_UP; htim4.Init.Period = 1000; htim4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim4.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE; if (HAL_TIM_Base_Init(&htim4) != HAL_OK) { Error_Handler(); } sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL; if (HAL_TIM_ConfigClockSource(&htim4, &sClockSourceConfig) != HAL_OK) { Error_Handler(); } Я правильно указал Prescaler и Period? Тогда должно быть 100000000/10000/1000 = 10 переполнений в секунду. А по факту - переполнение ровно за 5 секунд. Как бы APB1 не имеет никакого отношения к FMC, но сам факт неправильной работы таймера беспокоит. В чем подвох? Чем еще можно проверить HCLK?

......

Когда начинаешь понимать, где загвоздка, RTFM - весьма приятное занятие. Но вчера бы мне это не помогло.

Тихо сам с собою... Прочитал отладчиком состояние регистра FMC SDCR1 - получил 2, что соответствует HCLK/2. А вот в SDCR2 - 0 - отключено. У меня задействован SDRAM_bank2, то есть SDCKE1 и SDNE1. То есть у меня тактирование отключено? А откуда тогда клок на SDRAM? Сначала я решил что в коде от куба ошибка - SDCLockPeriod для банка 2 в нем неправильно настраивается. В даташите написано SDCLK[1:0]: SDRAM clock configuration These bits define the SDRAM clock period for both SDRAM banks and allow disabling the clock before changing the frequency. In this case the SDRAM must be re-initialized. Это как понимать? То есть SDCLK для банка 2 устанавливать не нужно - он один общий и читается из регистра настройки первого банка что ли? Судя по коду так и есть else /* FMC_Bank2_SDRAM */ { tmpr1 = Device->SDCR[FMC_SDRAM_BANK1]; /* Clear SDCLK, RBURST, and RPIPE bits */ tmpr1 &= ((uint32_t)~(FMC_SDCR1_SDCLK | FMC_SDCR1_RBURST | FMC_SDCR1_RPIPE)); tmpr1 |= (uint32_t)(Init->SDClockPeriod |\ Init->ReadBurst |\ Init->ReadPipeDelay); tmpr2 = Device->SDCR[FMC_SDRAM_BANK2]; /* Clear NC, NR, MWID, NB, CAS, WP, SDCLK, RBURST, and RPIPE bits */ tmpr2 &= ((uint32_t)~(FMC_SDCR1_NC | FMC_SDCR1_NR | FMC_SDCR1_MWID | \ FMC_SDCR1_NB | FMC_SDCR1_CAS | FMC_SDCR1_WP | \ FMC_SDCR1_SDCLK | FMC_SDCR1_RBURST | FMC_SDCR1_RPIPE)); tmpr2 |= (uint32_t)(Init->ColumnBitsNumber |\ Init->RowBitsNumber |\ Init->MemoryDataWidth |\ Init->InternalBankNumber |\ Init->CASLatency |\ Init->WriteProtection ); Device->SDCR[FMC_SDRAM_BANK1] = tmpr1; Device->SDCR[FMC_SDRAM_BANK2] = tmpr2; } Да и попытка при отладке в Кейле изменить SDCLK банка в регистре FMC SDCR2 ни к чему не приводит... Я перенастроил SDRAM на банк 1, проверил клок - он все также при делении на 512 равен 15 кГц. А что еще тогда в FMC отвечает за тактирование SDRAM? Я не нашел ничего..

Я поделил SYSCLK на 512, должен был получить HLCK 0.39 МГЦ Но на SD_CLK получил такую осциллограмму Этим осциллографом, в силу его примитивности, я ловлю максимум 100 кГц. Более высокие частоты у меня просто сглаживаются в линию на уровне 2-2.5 вольт. Но, судя по картинке, его пропускной способности хватает, и сигнал именно 15 кГц, Это показывает счетчик, и измерение ручками по 10 импульсам. Частота клока на SDRAM - 15,6 КГц. То есть, когда я ее не делю - она по факту 8 МГц. (У меня уже мозги плывут, вчера до 3 ночи сидел, и сегодня весь день. Не исключаю, что мог элементарно ошибиться) А должна быть равна HCLK/2, так ведь? Что посоветуете сделать, чтобы понять, кто своровал мегагерцы? Повторюсь, программный код до включения деления на 512 выдавал правильные задержки через функцию HAL_Delay. То есть в SYSCLK и в HCLK я могу быть уверен, а вот что происходит дальше по цепочке....

Куб ругается, если она меньше 25 МГЦ. У меня идея..... сейчас приду...

А что вы хотите вывести? Тактирование FMC? Самое близкое к нему, что выводится на MCO, это PLLCLK. После него до FMC всего два делителя. Логика понятна, но у меня есть функция HAL_Delay - она выдает правильные задержки, пропорциональные SYSCLK. Так что тут все ровно. ЕДинственное - что - посмотрите на тактирование Я не могу сделать по человечески - поделить HSE на 25 и дальше плясать от 1 МГЦ - у меня в этом случае почему-то не заводится пиксельклок, хотя куб показывает допустимые значения.

В даташите написано что поддерживает 1,2,3, во всех примерах в сети на эту микру и в примере для куба от ST - стоит 3 Я поставил 2 - не скорость не повлияло. Даташит говорит "the Burst Length (BL) of 1 must be selected by configuring the M[2:0] bits to 000 in the mode register. Refer to SDRAM device datasheet." Больше о нем ни слова. Я перебрал все значения - на скорость не влияет. Нет пока такой реальной возможности. Осциллограф у меня слабенький. Сужу по факту низкого обмена данными. Я кстати, не писал что именно SDRAM так работает, она так работает в связке с LTDC. Но без него, при простом обращении по адресу в памяти скорость чтения тоже невысока, повторюсь, я не знаю точной скорости, но мне очевидно, что она в десятки раз ниже.

Я пока ничего не рисую. То есть я нарисовал один раз, а потом LTDC просто перерисовывает экран, я ему не мешаю

Зачем, если и так понятно, что отличия в десятки раз... мне это ничего не даст. Вас не затруднит глянуть мой проект?

в асме писали код или на C? Тот код, что у меня выше - может там дофига лишних команд. Но ведь я и на железном уровне работал, c LTDC - та же петрушка. Около 3,3 мб/сек. Чтение приведенным выше кодом - 5 мб/сек (измерения неточные).

MPU_Config(); SCB_EnableICache(); SCB_EnableDCache(); Если отключаю это - то еще медленнее.... Господа.... Неловко просить, но вдруг у кого будет время - можете глянуть проект. Там только настройки периферии, никакого кода. Посмотрите, может кто увидит где у меня косяк и почему так медленно работает SDRAM..... https://cloud.mail.ru/public/2XX8/4nDNie3iu

Запредельно медленно - с точки зрения возможностей SDRAM - да. Запредельно медленно исходя из хотелок - да. ЗАпредельно ли медленно исходя из возможностей SDRAM+FMC конкретного контроллера? Можете ответить? P.S. что-то не получилось у меня пока с DMA измерить. Заполнение работает, а вот прерывания transfer complete не ловятся, хотя установлены.

Кошмар... на дискавери, где такая же микросхема, но в ней задействованы лишь 16 бит, сканируется за 8 секунд... Надо бы попробовать через DMA...

Как? В цикле вызывать a=*(__IO uint32_t*)(SDRAM_BANK_ADDR + 4*(uwIndex) ? Я в ассемблере полный ноль, боюсь, что такой код на С сформирует много ненужных тактов. У меня память 32 бит* 1 Meg* 4 банка. Нижеследующий код for (uwIndex = 0; uwIndex < 4194304; uwIndex++) { ADDRESS=*(__IO uint32_t*)(SDRAM_BANK_ADDR + 4*(uwIndex)); } Выполняется примерно за 3 секунды. Получается что около 5,5 мегабайт в секунду. Попробую ка я его запустить на дискавери....

Итак. Результаты экспериментов. Во всех случаях буфер в 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 - грубую прикидку цифр вы видели. Это абсурд.... У меня 1 слой. Господа, уж очень неадекватные скорости чтения SDRAM....

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

Хотя..... в режиме RGB888 дисплей работает с разрешением 1024х600 лишь на частоте 43.75.... с внутренней SRAM. Но ведь не на вдвое меньшей же частоте. Значит если я неправ, то лишь отчасти... Вот об этом я и спрашивал выше (или в другой теме, на которую есть ссылка) Сколько FMC способен выдать с 32битной памятью?

Повторно процитирую Юрия Поставил 8 битный формат - L8. Установил разрешение слоя 1024х600. Дисплей завелся на 57,2 МГц. Господа, я пытаюсь мыслить системно, может где в чем ошибаюсь, но все же... Смотрите, согласно даташиту, каков бы ни был формат данных - контроллер LTDC преобразует их во внутренний формат ARGB8888 и в таком виде клеит слои для вывода на дисплей. И для взаимодействия LTDC с дисплеем уже не важно, в каком виде они пришли. Поясню: У нас есть 32 битный FIFO. Если я включаю 32 битный режим то в контроллер зайдет 0x000000FF - и в FIFO будет записано 0x000000FF Если я включу 8 битный режим, то в контроллер зайдет 0xFF а в FIFO будет 0x000000FF. Если я не прав, то поправьте. Далее То есть физически связка LTDC и дисплея способна работать на разрешении 1024х600 с пиксельклоком 57,2 МГц Посмотрите на картинку Господа, вы согласны, что обведенный пунктиром регион Pixel clock Domain работает в режиме 32 битного цвета, а на дисплей передаются 24 битные данные независимо от входных данных? Пиксельклоки они ведь не зависят от битности цвета? Для дисплея пиксель всегда 24 битный. Значит, если я запустил его в режиме 1024х600 х 57 МГц, то он работает с этим разрешением и с 32 битным цветом? Или я не прав? Если прав, то вопрос в том, как запихнуть в контроллер столько пикселей в 32 битном формате.

Умеет. Проверил на 45 МГц. На зеленом фоне рисую пустое черное окно - дрожания границ окна нет. ТО есть внутри LTDC картинка формируется правильно (бывает только, что при различной комбинации делителей, когда считалка куба вроде бы показывает один и тот же пиксельклок, дисплей не запускается вообще). ПО факту дрожат читаемые из SDRAM данные. Другое дело, что невозможно почему-то работать с кадром более 200х200 пикселей. И это не времянки контроллера - на указанном разрешении все работает, снижаю HCLK меньше 200 МГц - начинаются глюки. Понимаете, вы обрисовали ситуацию как несовместимость такого дисплея, как я привел, с таким контроллером LTDC, какой имеется в STM32F7. Но это не вяжется с тем фактом, что при работе с внутренней SRAM все идеально. Вот скажите, если бы была проблема в указанной вами вилке взаимодействия контроллера и дисплея, то картинка, полученная из SRAM, нормально отображалась бы? Скажите, если я укажу в настройках 800х480 пикселей, а разницу компенсирую таймингами, это будет равноценная имитация дисплея 800х480? Я экспериментировал с 16-ю. Попробую на 8.