hx8357b vs ili9325

OK I got my hx8357b working in 16 bit parallel using the FSMC peripheral.

I am now trying to use a ili9325 in the same way.

I used my same FSMC initialization function but of course used a different function to initialize the ili9325 screen. I just cut and paste the LcdRegistersInit(void) from here https://github.com/PiotrCzCc/Arduino-LC … LI9325.cpp

but all I get is a blank white screen. I usually find this means that the screen hasn’t started because usually if the screen starts it displays a heap of random colored pixels like a rainbow. I have tried both pulling the rest pin to high and to low but both give same result.

Does anyone here have experience with using both screens and know if they had to change their FSMC setup between the 2 screens???

OK I have switched from using FSMC to bit bang to rule out there being a problem with FSMC setup.

The screen does change from a full blank white screen to a stripped screen where every second line is now black. So it seems there is some problem with the setup code for the ili9325 screen.

HX8357-B is a MIPI-style controller.
ILI9325 is an ILI9320 style controller.

They use different User registers e.g. write to GRAM memory.
Manufacturer registers vary greatly between Himax and Ilitek.

Himax have a completely random scheme for part numbering.

Just look at any library that supports different controllers. Hint. HX8357-B is similar to ILI9481. It is very different to HX8357-C or -D

FSMC is nothing more than the low level hardware interface.
The high level software is exactly the same for low level SPI, 8080-16, 8080-8, 6800-16, … hardware interface.

David.

I have been doing more playing trying to work out what is wrong.

I am just using bit bang for the moment so I know it isn’t a problem with FSMC.

I have tried a number of other people init() code to start my ili9325 screen but they all produce the same result. The screen with white before start up and after executing startup code the screen becomes tripped white and black.

I have checked my wiring a few times and my solder job appears to be good by with 0.8mm pitch it is a little hard to see good.

I am wondering if maybe the screen isn’t so good. This will be the first screen that I haven’t been able to get to work.

MCUFRIEND_kbv supports over 40 different controllers including ILI9325 and HX8357-B. With 8080-8 parallel interface. But it also supports 8080-16 as a SPECIAL.
I have never bothered with FSMC because Nucleo-64 boards do not have the pins. And Mcufriend Uno shields are 8080-8.

Mind you, I believe you can use FSMC in 8-bit mode. I have never investigated.

But I am pretty certain that stevestrong has a library that will support ILI9325 and ILI9481.

If you want comments or assistance, post a link to your GitHub (or other) repository.

David.

Have look here https://github.com/stevstrong/Adafruit_ … 8bit_STM32

[stevestrong – Tue Aug 07, 2018 2:54 pm] –
Have look here https://github.com/stevstrong/Adafruit_ … 8bit_STM32

I have the IM0 pin connected to GND to make sure it is in 16 bit mode.

Thanks Steve I had already tried the code in ili932x.cpp with the header ili932x.h with my own bit bang writeRegister16() and it produces the same result of changing the screen from white to stripped white and black.

Here’s my big band write Register16() fuction. I even tried adding some delay in case it was too fast.
void TFT_write_cmd(uint16_t command){
GPIOD->ODR &= ~RS;
GPIOD->ODR &= ~CS;
GPIOD->ODR &= ~WR;
GPIOE->ODR = command;
HAL_Delay(1);
GPIOD->ODR |= WR;
HAL_Delay(1);
GPIOD->ODR |= CS;
GPIOD->ODR |= RS;
HAL_Delay(1);
}

void TFT_write_data(uint16_t data){
GPIOD->ODR &= ~CS;
GPIOD->ODR &= ~WR;
GPIOE->ODR = data;
HAL_Delay(1);
GPIOD->ODR |= WR;
HAL_Delay(1);
GPIOD->ODR |= CS;
HAL_Delay(1);
}

void writeRegister16(uint16_t reg, uint16_t data){
TFT_write_cmd(reg);
TFT_write_data(data);

}

God gave you steering registers for GPIO e.g. BSRR
These work far faster than RMW operations on ODR

Your functions “look” ok. The timing is excessive. tWC is 100ns. Using 1000000ns seems unnecessary.

Note that IM# for 8080-16 is 0b0010 and 8080-8 is 0b0011
Are you sure that all the IM# bits are correct.

Are you using the correct registers for GRAM addressing and write/read e.g. 0x20, 0x21, 0x22
Window area with 0x50-0x53

David.

God gave you steering registers for GPIO e.g. BSRR
These work far faster than RMW operations on ODR

From what I have read the using BSRR is slower. A number of people have put it on the scope and shown this. Most people just find using BSRR easier.

Your functions “look” ok. The timing is excessive. tWC is 100ns. Using 1000000ns seems unnecessary.

Yep very slow but it was just an easy way to make sure it wasn’t too fast. when I get it to work I can speed things up but more likely will go back to using FSMC, I just wanted a way to be able to rule out FSMC or speed as the problem.

Are you using the correct registers for GRAM addressing and write/read e.g. 0x20, 0x21, 0x22
Window area with 0x50-0x53

So far I have been just using other people code for this, I have done a quick look over the code and the registers/data seem to be what would be expected.

I will triple check my wiring.

I have tried ordering another screen from another supplier to see if maybe the screen is a dude.

A common strategy with unknown hardware is:

1. read any “known value” register. e.g. ID register
2. write a known value to a documented read/write register.
3. read back from this register to verify.

I always do this with a new I2C chip or SPI chip. Likewise with an 8080-16 interface parallel chip.

You can use the LCD_ID_readreg sketch as-is for any 8080-8 interface ILI9320 style chip.
Or modify the sketch for 8080-16 interface.

Note that MIPI-style controllers always have 8-bit commands and arguments even if the databus is wider.
An ILI9320 type has 8-bit commands with 16-bit arguments.
An ILI9326 type has 16-bit commands with 16-bit arguments.

There is little point in pursuing any display problems until you have verified your wiring.

David.

Ok lots of great advice there.

1. read any “known value” register. e.g. ID register
2. write a known value to a documented read/write register.
3. read back from this register to verify.

I will try this first.

An ILI9320 type has 8-bit commands with 16-bit arguments.
An ILI9326 type has 16-bit commands with 16-bit arguments.

The aliexpress seller quoted ili9325 (not that means anything). I am currently using 16 bit writes for commands and arguments. It might pay for me first to try pulling IM0 to high to put it into 8 bit mode and try using the TFT in just 8 bit instead of 16 bit.

That sounds a good idea. Select IM# for 0b0011. Edit LCD_ID_readreg to match your pin #defines. It should work on ANY Arduino.

When I said ILI9320 has 8-bit commands, they still get sent as 16-bit.

I am now thinking that maybe there is a problem with the screen.

I pulled IM0 to high to put it in 8 bit mode and connected the top 8 data pins on TFT to pins PE0- PE8 on the STM32F4 and tried to read the ID register 0x0 and just get random garbage each time I read it.

from the ili9325 data for 8 bit read

read.JPG (28.54 KiB) Viewed 183 times