Eliminating external SDRAM

[manoj]

Hi, i remember I got started with ugfx by using some template project file, But now I am trying to build my own PCB to keep the cost at ultimate low I want to eliminate many external component on STM32f7-Discovery board..

Main concern is I don't know how to make ugfx to only use the internal ram on the MCU it self.

Anyone has any idea how to go about this ?

Edited August 24, 2017 by manoj

[inmarket]

In the board directories for the stm32 boards there is a file called stm32....sdram.c.

This file is responsible for initialisation of the sdram chip and setting the address (in conjunction with the stm32ltdc_board.h file) for the framebuffer. As you are defining your own board the equivalent of these files will obviously be written by you for your board. In those it will be a simple matter to tell it to use in internal ram address for the framebuffer. 

What you will need to watch is the size of the framebuffer required for ltdc. If it is put in internal RAM that may leave you very short for stack, heap and other program data. Framebuffers tend to be big in comparison to embedded processor internal ram.

A few things you can do that will help conserve RAM...

1. Use a 16bit pixel format eg rgb565 rather than rgb888. This will halve the size of the ram framebuffer.

2. Only use the one display surface. The ltdc controller supports 2 surfaces although uGFX only uses one. Don't attempt to change the driver for the 2nd surface - that will double the framebuffer size.

3. Don't use too large a display. A 320x200 display will use a quarter of the ram required for a 640x400 display.

Calculate carefully your ram requirements. Don't forget the stm32 has multiple stacks - both process and interrupt. uGFX also adds its own timer thread stack (typically 2K). You will also need some space for heap.

If you can't make it all fit consider not using the internal stm32 ltdc (or even using a cheaper version of the stm32 processor without the builtin ltdc controller). Instead use a display with its own inbuilt controller and framebuffer eg ILI9341. There are plenty available and they are really cheap - often cheaper than displays without a controller atleast for low count manufacturing runs. It may even save pins. If you are worried about speed just stick with a parallel interface. Particularly using the fmsc bus can make this an easy and fast option.

I hope that helps.

[manoj]

looking at ..._discovery_sdram.c looks like all the codes related to the SD RAM intialiazation, access etc.. So I don't have to write this right ? since I am trying to use the embedded ram. I will look into the stm32ltdc.. am I correct ?

[Joel Bodenmann]

I'm not sure what you mean by "write this". If you don't use external SDRAM then you don't need that code.

[juliandonart]

Hello everyone, 

I'm currently working on the same problem. I want to use the LTDC driver of the uGFX library with RAM framebuffer location on my STM32F7 Discovery board.

I followed all the steps mentioned by @inmarket:

First of all, I've created a global array RGB565_480x272 of type uint32_t and a size of 65280. This array defines my framebuffer in the MCU's memory. 

In the driverCfg struct in file board_STM32LTDC.h, I've changed the frame buffer starting address from SDRAM_DEVICE_ADDR to my array RGB565_480x272 and I've turned off the second layer as you can see in the following code snippet.

...
// board_STM32LTDC.h
#define ALLOW_2ND_LAYER		FALSE // TRUE

static uint32_t RGB565_480x272[65280]; // 480x272 Pixel * 2Byte/Pixel / 4Byte/uint32 = 65280 uint32

static const ltdcConfig driverCfg = {
	480, 272,								// Width, Height (pixels)
	41, 10,									// Horizontal, Vertical sync (pixels)
	13, 2,									// Horizontal, Vertical back porch (pixels)
	32, 2,									// Horizontal, Vertical front porch (pixels)
	0,										// Sync flags
	0x000000,								// Clear color (RGB888)

	{										// Background layer config
		(LLDCOLOR_TYPE *)&RGB565_480x272[0],    // Frame buffer address (LLDCOLOR_TYPE *)SDRAM_DEVICE_ADDR,
		480, 272,							// Width, Height (pixels)
		480 * LTDC_PIXELBYTES,				// Line pitch (bytes)
		LTDC_PIXELFORMAT,					// Pixel format
...

Then, in the gdisp_lld_config.h file, I've set the GDISP_LLD_PIXELFORMAT to GDISP_PIXELFORMAT_RGB565

#define GDISP_LLD_PIXELFORMAT			GDISP_PIXELFORMAT_RGB565

and in the init_board() function, I finally removed the BSP_SDRAM_Init() call at the end of the function.

I think these should be all the required changes to use the internal RAM of the MCU as framebuffer for LTDC. Unfortunately, my display doesn't show anything. Maybe some of you have an idea of what I'm doing wrong ...

I'm using the STM32F7 bare metal demo project provided by uGFX. In my gfx_conf.h file, I've defined my GFX OS heap size as follows:

#define GFX_OS_HEAP_SIZE                           (40960)

Thank you in advance.

[juliandonart]

In the meantime, I have been able to solve the problem.

There is a small bug in the uGFX LTDC driver. It concerns the line in board_STM32LTDC.h where the LCD-TFT clock is activated.

RCC->CR |= RCC_CR_PLLSAION;

After PLLSAI activation, it is necessary to wait until the LTDC clock is ready.

while((RCC->CR & RCC_CR_PLLSAIRDY) == 0); // wait for PLLSAI to lock

The driver only works since inside of the call BSP_SDRAM_Init() there is a gfxSleepMillisecond() call which acts as the above-mentioned missing while() loop.

// BSP_SDRAM_Init();

I recommend taking over the changes for the next LTDC driver release. It would be nice if there will be a preprocessor option, whether internal SRAM or external SDRAM is used as framebuffer.

[inmarket]

We will add that line to the current repository. Thanks for finding it.

Note this is a board level change not a driver change and there is a good chance the same or similar bug exists in other board files that use the same driver. I will check and fix as necessary.

Adding a define to use or not use external sdram is not necessary as a board either does or does not use external ram. It is the board file that encapsulates that. If you change the physical board to remove the external sdram then the board file needs to change too. As the stm32fxxc-discovery boards tend however to be used as examples I will add documentation to the board files to indicate what must be done for that type of physical change.

Thanks for your good work on this.

[inmarket]

The STM32LTDC based board files have been updated in the repository.