STM32F4 uKeil ILI9320 SPI GLCD HY28A

[romancorba]

Posted on January 30, 2013 at 02:19

Hello,

i need connect HY28A with ILI9320 to my STM32F4 Discovery, but i didn�t find any examples on whole internet.

I spended many days to try start SPI connection and connect GLCD, but

without any success

.And havent Osciloscope for debug output signal.

Please can anyone help me with this issue?

I will be grateful for any piece of working code (SPI3 init, ILI9320 ported driver, ...)

#spi-glcd-ili9320-stm32f4-hy28a

[M0NKA]

Posted on January 31, 2013 at 10:29

Hi,

Check the STM3240G-Eval board and all schematics and examples - this controller/lcd

is supported by LCD routines with supplied firmware. For example LCD init is in:

...stm32f2-f4_demobuild\STM32F2-F4_Demonstration_Builder_V1.0.1\Utilities\STM32_EVAL\STM3240_41_G_EVAL\stm324xg_eval_lcd.c

BR, Chris

[frankmeyer9]

Posted on January 31, 2013 at 11:45

Check the STM3240G-Eval board and all schematics and examples - this controller/lcd is supported by LCD routines with supplied firmware. For example LCD init is in: ...

 

I guess one of us misunderstood the OP.

He wants to connect the HY28A with his F4-discovery via SPI. This is IMHO not covered by the STM3240G firmware, as it uses FSMC.

Getting the SPI right without scope could be difficult.

There are several SPI examples around, but you will need to compare the SPI mode of your HY28A, if they apply to any of those examples. That means checking some datasheets.

But the STM3240G firmware does cover the initialization sequence and timing, which would be rather tedious to do from scratch.

[M0NKA]

Posted on January 31, 2013 at 13:32

Yes, in stm324xg_eval_lcd.c:

void LCD_WriteReg(uint8_t LCD_Reg, uint16_t LCD_RegValue)

{

  /* Write 16-bit Index, then Write Reg */

  LCD->LCD_REG = LCD_Reg;

  /* Write 16-bit Reg */

  LCD->LCD_RAM = LCD_RegValue;

}

but in lcd.c:

void GL_LCD_WriteReg(uint8_t LCD_Reg, uint16_t LCD_RegValue)

{

  if (pLcdHwParam.LCD_Connection_Mode == GL_SPI)

  {

    /* Write 16-bit Index (then Write Reg) */

    GL_LCD_WriteRegIndex(LCD_Reg);

    /* Write 16-bit Reg */

    /* Reset LCD control line(/CS) and Send Start-Byte */

    GL_LCD_nCS_StartByte(START_BYTE | LCD_WRITE_REG);

    SPI_I2S_SendData(pLcdHwParam.LCD_Bus_Port, LCD_RegValue >> 8);

    while (SPI_I2S_GetFlagStatus(pLcdHwParam.LCD_Bus_Port, SPI_I2S_FLAG_BSY) != RESET)

    {}

    SPI_I2S_SendData(pLcdHwParam.LCD_Bus_Port, (LCD_RegValue & 0xFF));

    while (SPI_I2S_GetFlagStatus(pLcdHwParam.LCD_Bus_Port, SPI_I2S_FLAG_BSY) != RESET)

    {}

    GL_LCD_CtrlLinesWrite(pLcdHwParam.LCD_Ctrl_Port_NCS, pLcdHwParam.LCD_Ctrl_Pin_NCS, GL_HIGH);

  }

  else

  {

    /* Write 16-bit Index, then Write Reg */

    LCD->LCD_REG = LCD_Reg;

    /* Write 16-bit Reg */

    LCD->LCD_RAM = LCD_RegValue;

  }

}

(...stm32f2-f4_demobuild\STM32F2-F4_Demonstration_Builder_V1.0.1\Libraries\Embedded_GUI_HAL\src)

I agree the ST example code is complete mess, but if one is really determent - it is possible to extract useful info from the noise.

BR

[frankmeyer9]

Posted on January 31, 2013 at 14:06

I had looked at this example a few days ago briefly (or, correctly, on an example derived from the stm3240g example code).

And I had the impression that SPI is for the touch control, and not for the display driver.

As I said, I might be wrong here, too ...

Not having a stm3240g board, I didn't study it in detail.

This is a suggested task for the OP, to start with.

[M0NKA]

Posted on January 31, 2013 at 15:18

No problem. I replied because few months ago i had to do the same crazy digging to

make this same LCD working and remembered where i found the most detailed source to

talk to it. I am also using the SPI as my PHY chip takes most of the pins on the mcu.

Here it is in action:

http://www.youtube.com/watch?v=BDHvn47k0k0

[frankmeyer9]

Posted on January 31, 2013 at 16:13

Here it is in action:

 

http://www.youtube.com/watch?v=BDHvn47k0k0

 

I do this a soon as I'm back from behind this selective company proxy ...

I wonder if it achieves some decent speed, i.e. frame rate.

I had been ''hacking'' some of such TFT boards to F1and F4 discovery boards, and the lpcxpresso1769. Least common denominator was a 8 bit interface, where the achieved performance disqualifies for anything associated with ''motion picture''.

I came across the EMBEST BaseBoard and LCD board for the stm32f4-discovery, which seem to be ''copied'' from the STM3240G board. Even the software is almost identical - that is the one I mean with ''derived''. And this board uses FSMC, with SPI for touch control.

[M0NKA]

Posted on January 31, 2013 at 16:21

Hi,

This LCD seems to be the cheapest (12 USD), also the company in Shenzhen that makes

it has stable supply of them.

The most difficult was to make the spectrum display update without lag via SPI, also

i have a grid behind that needs repaint. But simple hack in the driver that keeps track

of old and new values + mapping of the grid fixes that, with the expense of little bit

of RAM. Also i had to re-code all drawing routines from scratch.

BR, Chris

[frankmeyer9]

Posted on February 01, 2013 at 10:17

I believe your SPI interface faster than my bit/byte-banging 8-bit interface, and much less of an ressource hog. SPI can use DMA, and thus consumes much less core performance, compared to a 8-bit protocoll emulation. Unfortunately I got the current hardware wired up this way - a MikroMedia M4 board. And because the vendor even encrypts the driver libraries for his board, I had to rewrite the graphics an touch driver from scratch.

That leads me back to the OP.

First task is to establish the physical connection. Get the datasheets and compare the TFT requirements with the MCU capabilities. Set up the MCU, and verify the physical link. Bit-banging interfaces can be stopped anywhere for debugging, so a voltmeter is sufficient. For a peripheral unit like SPI, one will have a hard time without scope. All TFT driver chips I came across have some ID register. If one can read it back properly, that step is basically done.

Next thing is the TFT initialization. This is highly dependant on the specific chip, albeit most are pretty similiar. Quickest way is to find some example for exactly the same chip, and replace only the low layer code (i.e. physical connection). So this example code does not have to be for STM - I used LPCXpresso and PIC18 examples here.

And once this is done, you can tackle the graphics primitives, like setting pixels and lines.

That kind of project is rather challenging for a beginner, and more so without good tools (say, a scope). A MCU board with TFT and working example code is more recommendable in this case. But that depends on how one values his time.

[M0NKA]

Posted on February 01, 2013 at 10:52

Hi,

Yes it might looks is fast, but actually is mostly tricks. What i do is selectively update

very small portions of the screen very fast, and keep track of LCD current state in RAM

so i don't have to do unnecessary refreshes. To be honest i have never worked on a project

where some real time stuff was displayed - like video. I would assume some very wide

and fast bus is needed - probably 16 bits is the absolute minimum.

To the OP, if i can give bit of advice, when making the LCD work, start with the slowest

possible SPI speed, when all is working, then increase to highest possible.

BR

[frankmeyer9]

Posted on February 01, 2013 at 12:06

Yes it might looks is fast, but actually is mostly tricks. What i do is selectively update

 

very small portions of the screen very fast, and keep track of LCD current state in RAM so i don't have to do unnecessary refreshes.

 

I try something similiar with the MM4 board.

While the calculation of a full 1024 points spectre takes about 10ms (including some post processing), it takes about 200ms to put to screen, covering less than 1/3 of the area.

That seems far too much, and as there is no DMA support, that is hardly workable.

Reducing the screen area that requires update is the only solution.

To be honest i have never worked on a project

 

where some real time stuff was displayed - like video. I would assume some very wide

 

and fast bus is needed - probably 16 bits is the absolute minimum.

 

They have specialized logic to deal with that. Either it is explicitly a microcontroller, or similiar on-purpose logic. This remembers me on the old days, where PC's had character displays, which worked the same way. The processor wrote the ASCII characters to a (shared) RAM, and a independant logic cyclically read it out, passed it through a character ROM, and serialized the ROM output stream to the screen. This concept has not changed too much for modern GFX cards, but became much more sophisticated and complex...

To something completely different: this forum software sucks !