Jump to content

    
AleksBak

STM32H743 LTDC - Frame buffer line length and pitch

Recommended Posts

Добрый день.

Разбираюсь с работой LTDC - без использования CubeMX кода. Заработало нормально - использую только 2-ой слой (самый верхний) и т.д. Показывает.

Просто решил спросить по поводу настройки регистра CFBLR слоя. В RM по поводу его настройки написано следующее:

Цитата

This register defines the color frame buffer line length and pitch.
Address offset: 0xB0 + 0x80 * (x - 1), (x = 1 to 2)
Reset value: 0x0000 0000

    Bits 31:29 Reserved, must be kept at reset value.
    Bits 28:16 CFBP[12:0]: color frame buffer pitch in bytes
                          These bits define the pitch that is the increment from the start of one line of pixels to the start
                          of the next line in bytes.
    Bits 15:13 Reserved, must be kept at reset value.

    Bits 12:0 CFBLL[12:0]: color frame buffer line length
                          These bits define the length of one line of pixels in bytes + 3.
                          The line length is computed as follows:
                          active high width * number of bytes per pixel + 3.

Example:
    • A frame buffer having the format RGB565 (2 bytes per pixel) and a width of 256 pixels
      (total number of bytes per line is 256 * 2 = 512), where pitch = line length requires a
      value of 0x02000203 to be written into this register.
    • A frame buffer having the format RGB888 (3 bytes per pixel) and a width of 320 pixels
      (total number of bytes per line is 320 * 3 = 960), where pitch = line length requires a
      value of 0x03C003C3 to be written into this register.

Я тогда пишу так:

	/* Frame buffer line length and pitch:
	 * В RM0385 (на стр. 537) указано, что тут младшее слово должны такое содержать:
	 * Bits 12:0 CFBLL[12:0]: color frame buffer line length
	 * These bits define the length of one line of pixels in bytes + 3.
	 * The line length is computed as follows:
	 * active high width * number of bytes per pixel + 3. */
	LTDC_Layer2->CFBLR &= ~(LTDC_LxCFBLR_CFBLL | LTDC_LxCFBLR_CFBP);
	LTDC_Layer2->CFBLR |= (((PIXEL_SIZE * DISPLAY_WIDTH) << 16) | (PIXEL_SIZE * DISPLAY_WIDTH + 3U));

Т.е. добавляю '3' в конце. Здесь 'PIXEL_SIZE' == 4U т.к. формат у меня ARGB8888, а вначале обнуляю регистр CFBLR, а потом пишу указанное в RM значение.

Однако в CubeMX HAL, при настройке этого регистра, пишется другое значение:


	if (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_ARGB8888)
	{
		tmp = 4U;
	}
	else if (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_RGB888)
	{
		tmp = 3U;
	}
	else if ((pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_ARGB4444) ||
			(pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_RGB565) ||
			(pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_ARGB1555) ||
			(pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_AL88))
	{
		tmp = 2U;
	}
	else
	{
		tmp = 1U;
	}

	/* Configure the color frame buffer pitch in byte */
	LTDC_LAYER(hltdc, LayerIdx)->CFBLR &= ~(LTDC_LxCFBLR_CFBLL | LTDC_LxCFBLR_CFBP);
	LTDC_LAYER(hltdc, LayerIdx)->CFBLR = (((pLayerCfg->ImageWidth * tmp) << 16U)
			| (((pLayerCfg->WindowX1 - pLayerCfg->WindowX0) * tmp) + 7U));

т.е. тут прибавляется '7' в конце. Здесь 'tmp' как видите, это PIXEL_SIZE, что выше. А (pLayerCfg->WindowX1 - pLayerCfg->WindowX0) это просто (DISPLAY_WIDTH - 0). Т.е. так в итоге если привести к 1-му куску кода:

LTDC_Layer2->CFBLR = ((DISPLAY_WIDTH * PIXEL_SIZE) << 16U) | ((DISPLAY_WIDTH * PIXEL_SIZE) + 7U);

Если это я применю у себя (вместо '3' напишу '7'), то тоже показывает совершенно одинаково, что и до этого. (а если ничего сюда не писать, то не покажет изображение).

Поэтому решил спросить, что это за настройка и почему в CubeMX так делают.

Share this post


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

Про добавление 3 или 7 в даташитах на разные процессоры разные значения. У вас точно ref manual  последний?

Спасибо большое! Посмотрел - да сейчас они (STM) его поменяли (7-ая версия сейчас). Но пока не нашел в каком документе эти изменения отражены. Вот так теперь там:

Цитата

Bits 12:0 CFBLL[12:0]: color frame buffer line length
These bits define the length of one line of pixels in bytes + 7.
The line length is computed as follows:
active high width * number of bytes per pixel + 7.
Example:
• A frame buffer having the format RGB565 (2 bytes per pixel) and a width of 256 pixels
(total number of bytes per line is 256 * 2 = 512), where pitch = line length requires a
value of 0x02000207 to be written into this register.
• A frame buffer having the format RGB888 (3 bytes per pixel) and a width of 320 pixels
(total number of bytes per line is 320 * 3 = 960), where pitch = line length requires a
value of 0x03C003C7 to be written into this register.

Значит нужно '7' прибавлять все-таки. 

Еще добавлю - эти изменения ('3' или '7) у меня никак не отражались на изображении дисплея (в 1-ом посту написал), но может потому, что пока я только успел с одним слоем сделать что-то в программе, а потом забросил работу с LTDC т.к. другие проблемы вышли.

Share this post


Link to post
Share on other sites

Значение 3 похоже унаследовалось от RM на F7 и F429...

Возможно, влияние 3/7 отличается для внутренней или внешней памяти?

У меня только со внутренней макеты.

Edited by GenaSPB

Share this post


Link to post
Share on other sites
19 часов назад, GenaSPB сказал:

Значение 3 похоже унаследовалось от RM на F7 и F429..

Я никак покамест не нашел ту старую версию RM (еще в одном компе вроде должна быть, но туда пока не скоро добраться смогу). В Кубе открываю всегда эти RM и в этот раз получается обновился он т.к. не с потолка же я взял эту цитату оттуда.

19 часов назад, GenaSPB сказал:

Возможно, влияние 3/7 отличается для внутренней или внешней памяти?

У меня только со внутренней макеты.

На внешней SDRAM Winbond-овской. Я пока забросил с горя ту плату т.к. на ней никак не хочет работать QUADSPI память Spansion. Как заколдованная не хочет. Пока разбираюсь на совсем другой готовой плате (там тоже STM32H743 только 100-пиновый) с работой QUADSPI.

Share this post


Link to post
Share on other sites

Здравствуйте. Я тоже разбираюсь с LTDC.

 

Я пытаюсь выводить картинку на дисплей через LTDC.
Контроллер STM32H743IIT6, дисплей UG-6028GDEBF02. Дисплей имеет разрешение 160x128. Цвет каждого пикселя определяется данными, которые поступают за три такта пиксельной частоты — по такту на цвет (R, G, B). Я хочу выводить Ч/Б изображение используя пиксельный формат L8. Для этого каждый пиксель буду определять тремя одинаковыми значениями по цветам (R=G=B). Раз каждый пиксель определяется тремя тактами пиксельной частоты, то в одной строке должно быть 160х3 = 480 тактов — или 480 пикселей. Таким образом для LTDC мое изображение преобразуется в 480х128. Дисплей можно настроить на режим работы 160х120 (с помощью встроенного в дисплей контроллера), что я и сделал. Попробовал вывести на дисплей изображение формата 160х120 с помощью встроенного в дисплей контроллера — все получилось как и должно быть.

Теперь пытаюсь выводить на дисплей картинку по интерфейсу RGB используя LTDC. Настроил все на регистрах и по ДШ. Сформировал массив на 57600 пикселей (160х120х3). В массиве закрасил первый пиксель в первой строке (нулевой пиксель в нулевой строке), первый пиксель в третьей строке (нулевой пиксель во второй строке) и последний пиксель в кадре 57600 (57599). Вывожу на дисплей — вижу картинку как на картинке.

 

20210108_202151.thumb.jpg.738b3beaed00dda29781191dfba1493a.jpg

 

Первый пиксель в первой строке горит не в начале дисплея, он смещен вправо, также как и первый пиксель в третьей строке. Последний горит слева от первого. Картинка отобразилась не до конца, почему то LTDC не отобразил весь буфер, а не дождавшись конца начал отображать первый пиксель, хотя адрес для нового кадра взял не первый в буфере, а тот с которого он прекратил отображать.
Пробовал поиграться с настройками — проблему не победил. Не подскажите что-нибудь дельное? С какими регистрами поиграть и как?

LTDC настраиваю православными регистрами. Вся настройка в функции LTDC_Init(). Надеюсь на помощь.

lar_ltdc.c lar_ltdc.h

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.