Is there any working project RGB TFT 1024 x 600

[MNapi]

Is there any working project maybe on github 1024 x 600 RGB TFT ? Those screens are very popular all over the place.

There is STM32F746G-DISCO with 480x272 TFT RGB. I have no problem to get it working.

 For bigger sizes since there is no working example from STM. I have a few custom boards and I cannot get them working.

I followed the example for STM32F746G-DISCO with 480x272 to connect 1024x600 on a few chips which support LTDC (24 bit).

I wonder what I might be missing.

[MNapi]

Here is the display

https://www.buydisplay.com/7-inch-1024x600-ips-tft-lcd-display-high-brightness-full-viewing-angle

there are links to all data sheets

it is using HX8282-A14 driver

I do have custom board so there will be no problem to add some external RAM. A lot of those DISCO boards have external RAM and schematics to use as example.

Each chip which has LTDC support has also FMC, it is done for reason so you can attach external RAM for frame buffer. But I guess STM left it for customers to guess since I do not see any guide lines how much RAM you would need for 1024 x 600

I do not see any code how buffer frame is calculated and assigned based on the size of display you choose in CubeMX. It must be somewhere in their library.

MX_FMC_Init();
MX_LTDC_Init();

I think the frame buffer was the whole problem I could never get it working so far.

[Tesla DeLorean]

It's not a guessing thing, as the relationships are pretty straight forward. I think you've missed some background in bitmap images, raster displays, and drawing lines/fonts into frame buffers.

pLayerCfg.FBStartAdress = 0xC0000000; // Base Address in memory, here SDRAM BANK1. You want it to be aligned, but you can allocate it anywhere in the memory space.

1024 x 600 x 2 bytes for 16-bit colour depth

1024 x 600 x 3 bytes for 24-bit colour depth

The frame buffer the contains all the lines in sequence, as it rasters the display.

line123start = framebuffer + ((linewidth * 123) * 2); // for 16-bit colour depth

[MNapi]

It would explain why STM32F746G-DISCO worked without enabling external RAM

it has 320 KB

480 x 272 x 2 = 261KB

The sample I tried is using RGB565 pixel format so 2 bytes

That it is 1024 x 600 matrix I already know, you can have 2 layers so double the RAM buffer

So 4 MB RAM should do the job. I think maybe 16MB chip to be safe. I do not know what else is going on inside.

Maybe it needs a little more for something else. You have also this DMA2D, chrom art accelerator controller. So I do not know what you need for this, double the RAM ? The info in nowhere to be found.

[Tesla DeLorean]

PLLSAI-R should be 51.2MHz, or so to clock the LTDC (perhaps from 256 MHz)

Where as the the STM32F746G-DISCO board is typically at 9.6 MHz

https://mikrocontroller.bplaced.net/wordpress/wp-content/uploads/2018/01/RK043FN48H-CT672B-V1.0.pdf

void InitLCD(void) // STM32F746G-DISCO panel RK043FN48H-CT672B
{
  RCC_PeriphCLKInitTypeDef  PeriphClkInitStruct = {0};

  /*## LTDC Clock Configuration ###########################################*/
  /* LCD clock configuration */
  /* PLLSAI_VCO Input = HSE_VALUE/PLL_M = 1 Mhz */
  /* PLLSAI_VCO Output = PLLSAI_VCO Input * PLLSAIN = 192 Mhz */
  /* PLLLCDCLK = PLLSAI_VCO Output/PLLSAIR = 192/5 = 38.4 Mhz */
  /* LTDC clock frequency = PLLLCDCLK / LTDC_PLLSAI_DIVR_4 = 38.4/4 = 9.6Mhz */
  PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;
  PeriphClkInitStruct.PLLSAI.PLLSAIN = 192;
  PeriphClkInitStruct.PLLSAI.PLLSAIR = 5;
  PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_4;
  HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);
}

[MNapi]

somebody just emailed me link

https://community.st.com/t5/stm32-mcus/how-to-set-up-the-fmc-peripheral-to-interface-with-the-sdram/ta-p/49457

so they are talking about the RAM buffer for display, I wish I knew this before

It takes time to learn, next time you know.

also the Color Frame Buffer address in examples is 0xC0000000

This is also the address of external SDRAM 1

so come slowly clear what the problem is and what is missing

[Tesla DeLorean]

Building off the SD Card demo I have for the STM32F746G-DISCO, adjusted for 52 MHz 1024x600 24-bpp panel, reporting info via VCP USART @ 115200 8N1

Y:\STM32\Cube\STM32Cube_FW_F7_V1.8.0\Projects\STM32746G-Discovery\Applications\Display\SDMMC-TEST001-2024

The .HEX didn't attach, .ZIP not allowed, .RAR seemed to be accepted

[MNapi]

I tried to download your file but after downloading it says that it is damaged. I do not see how to use 1024x600 on STM32F746G-DISCO, the old original display cannot be detached.

Unless making custom board using STM32F746G-DISCO as template with some changes. The power supplies for bigger display would have to be adjusted.

I spoke to somebody from STM they do not have any working examples with 1024x600 they refer to third party.

[MNapi]

here is small update if you are interested.

bigger buffer RAM was not the problem, you can still do some graphics on smaller resources.

it is always something simple and basic.

I knew it was not the hardware wrong or missing something on custom board after checking it over and over again.

the initialization in CubeMX is so simple so what can be wrong ?

the problem was with initialization pins for LTDC ( the display clock has to be around 48Mhz, so LCD_TFT in CubeMX must be 48 Mhz)

instead

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

it has to be changed to:

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;

Though STM32F746G-DISCO works with GPIO_SPEED_FREQ_LOW, it has older slower display.

After that I had the screen finally working the next step was to display something

then this code and it finally displayed small picture.

/* USER CODE BEGIN LTDC_Init 2 */

pLayerCfg.WindowX0 = 0;

pLayerCfg.WindowX1 = 512;

pLayerCfg.WindowY0 = 0;

pLayerCfg.WindowY1 = 300;

pLayerCfg.PixelFormat = LTDC_PIXEL_FORMAT_RGB565;

pLayerCfg.Alpha = 255;

pLayerCfg.Alpha0 = 255;

pLayerCfg.BlendingFactor1 = LTDC_BLENDING_FACTOR1_CA;

pLayerCfg.BlendingFactor2 = LTDC_BLENDING_FACTOR2_CA;

pLayerCfg.FBStartAdress = (uint32_t)ℑ

pLayerCfg.ImageWidth = 512;

pLayerCfg.ImageHeight = 300;

pLayerCfg.Backcolor.Blue = 0;

pLayerCfg.Backcolor.Green = 0;

pLayerCfg.Backcolor.Red = 0;

if (HAL_LTDC_ConfigLayer(&hltdc, &pLayerCfg, 0) != HAL_OK)

{

Error_Handler();

}

/* USER CODE END LTDC_Init 2 */

the conversion of bitmap picture to HEX was done by

lcd image converter 20161022 beta

[Tesla DeLorean]

Well arguably the screen and connector could be removed, but I agree it would be a challenge, and need a translation board or interposer.

I was working under the premise that you have something close, or had connectorized a panel.

Not really looking to create a build for another board with all the pins and SDRAM connectivity that would involve. The F7 should permit 48 MHz to be derived from PLLs and taps. The LTDC can be driven via the PLLSAI-R tap. This would need to be some multiple as there is a DIV 2,4,8,16 divider there. But sill possibility of 104 MHz DIV2 to yield 52 MHz at the panel, and get 48 MHz from the primary PLL

The ART-Pi allows for connectivity of a 1024x600 panel via it's 40-pin FPC connector. 24-bit parallel RGB channels

https://www.dfrobot.com/product-2497.html

https://community.st.com/t5/stm32-mcus-products/art-pi-dev-board-stm32h750-fmc-ltdc-rgb888-display/m-p/629007#M232702

[MNapi]

I do have this board from the link you show. it already has built in power supply (about 8.4V) for back light and to drive the display matrix (-7V, 4V, 10V, 17V)

I tried the board but it did not work, now I know what the problem was.

Later I did my own custom board for 50 pin connector with power supplies, those 50 pin displays do not have power supplies attached.