Driving 16bit parallel LCD

[3dgeo]

Hello there,

I have a 16bit parallel LCD (3.5inch, 480x320) and try to pick optimal MCU to drive it. Looking at STM32 MCUs, specifically STM32F103VET6, in it's datasheet, on page 16 it says:
"2.3.6 LCD parallel interface:
The FSMC can be configured to interface seamlessly with most graphic LCD controllers. It supports the Intel 8080 and Motorola 6800 modes, and is flexible enough to adapt to specific LCD interfaces."

What is FSMC? I assume it's some kind of memory access peripheral similar to DMA? It seems I'm too dumb to find info about it myself.
Speed differences using FSMC vs simple port manipulation?


BTW, is there dedicated STM32 forum where I can nag things like this? (don't mention official ST community....).
I try to get in to STM32 ecosystem, but lack of information and help makes it very hard. Or maybe I'm too dumb, I don't know    

[mikerj]

FMSC = Flexible Static Memory Controller

It's a data and address buss with control signals that can be attached to most types of static memory, both Flash and SRAM.

[Siwastaja]

You need to download the reference manual, it will explain the peripherals such as the FSMC. Read the relevant sections carefully.

[3dgeo]

You need to download the reference manual, it will explain the peripherals such as the FSMC. Read the relevant sections carefully.

Read – I can, understand – thats a different thing... 

[newbrain]

You need to download the reference manual, it will explain the peripherals such as the FSMC. Read the relevant sections carefully.

Read – I can, understand – thats a different thing... 

First thing to know is that STM32 documentation, as Gaius Iulius Caesar would put it, "est omnis divisa in partes tres" (is all divided in three parts):

• The data sheet: pin assignments on the various packages, electrical characteristics, generic info on the peripherals and their availability on various models
• The reference manual: detailed information on the peripherals, and their register maps.
• The programmer's manual: more or less a 1 to 1 copy of Arm reference, description of generic Arm peripherals.

Siwastaja is correctly pointing you to the reference manual for detailed FSMC info.
Shortly, as mikerj said, that peripheral allows to connect external memories.
The external memory is mapped to Cortex address space, so it can be easily accessed e.g. via a pointer.

To address your display, the FSMC needs to be set up with the appropriate RD and WR lines, a CS, 16 bit of data and a single address line (for the command or data selection).
A regular GPIO pin for the Reset line can be useful, too.

As an example, a routine to set the addressable window and write a pixel, taken from my code to drive a probably very similar display:

Code: [Select]

volatile uint16_t *pData = (uint16_t *)0x60020000;
volatile uint16_t *pCmd  = (uint16_t *)0x60000000;

inline void WindowLCD( uint16_t xl, uint16_t yl, uint16_t xh, uint16_t yh )
{
  *pCmd = lcd.ILI_SETYADDR;
  *pData = yl >> 8;
  *pData = yl;
  *pData = yh >> 8;
  *pData = yh;

  *pCmd = lcd.ILI_SETXADDR;
  *pData = xl >> 8;
  *pData = xl;
  *pData = xh >> 8;
  *pData = xh;
}

void Pixel(uint16_t x, uint16_t y, uint16_t color)
{
  if( (x>=lcd.width) || (y>=lcd.height)) return;
  WindowLCD( x, y, x, y );
  *pCmd = ILI_RAMWRITE;
  *pData = color;
}



The FSMC maps to 0x60000000, and I have used A17 (for ease of pin assignment, IIRC) to address command or data registers.

As you can see, once the FSMC is set up, the display can be easily (and efficiently) controlled by your C program.

[ajb]

Two crucial things to note with using an external memory interface to drive an MCU:

1) The LCD accesses must be via volatile pointers, as newbrain shows.  Otherwise the compiler is free to optimize these accesses away.

2) On more advanced MCU cores, the LCD address space may need to be configured in the MPU to ensure that it is not cached and will be accessed in the exact way that the program indicates.  (On the Cortex M7, for example, it should be tagged as 'device' memory.)  Otherwise the cache may eat the writes to the LCD, or the writes may happen in a different order than what the program requires.