Jump to content

ILI9481 + 8bit

phofman

By phofman
in Support

 Share

Recommended Posts

phofman

phofman

Posted
Posted (edited)

Hi,

I am working on integration of ILI9481-based LCD in 8bit with maple mini and chibios. IIUC, according to the driver datasheet http://www.ncsys.co.jp/webshop/GTV350MPZI04(ILI9481).pdf registers should be called in a sequence register ID + 1st parameter + 2nd parameter etc. Each parameter is only 8bit and takes only one transfer in both 16bit and 8bit modes. But the used write_data method used in the write_reg and write_reg2x16 methods https://git.ugfx.io/Tectu/uGFX/src/master/drivers/gdisp/ILI9481/gdisp_lld_ILI9481.c#L50 defined in my specific board_ili9481.h must make two transfers to transfer the 16bit parameter in 8bit mode. As a result the controller will send twice as many parameters which IMO is incorrect.

I have not tested the code yet, perhaps it actually works. But I think the methods called after write_index should be something like write_byte, sending only single byte, allowing for the specific implementation in board_ili9481.h to distinguish between 16bit (write_data) and 8bit transfers (write_byte). I can modify the code and send a patch, just would like to know if it makes sense.

Another question concerns the configuration parameters. According to the datasheet the C0h "Panel Driving Settings" param (page 103) is supposed to accept 6 parameters. However the ugfx driver sets 8 parameters https://git.ugfx.io/Tectu/uGFX/src/master/drivers/gdisp/ILI9481/gdisp_lld_ILI9481.c#L106 while the first 0x03 does not seem to fit the datasheet at all (zeros on position D1/D0), while other drivers usually specify 0x10 there https://github.com/MajenkoLibraries/DisplayCore/blob/master/Drivers/ILI9481/ILI9481.cpp#L232 or the UTFT library for ILI9481 specifies https://github.com/dgolda/UTFT/blob/master/tft_drivers/ili9481/initlcd.h#L18

This is my first project in STM32/ugfx/chibios and there are many unknown variables at stake. I would love to cut down on this one :-)

Thank you very much for any suggestion or help.

 

Best regards,


Pavel.

Edited by phofman
Link to comment
Share on other sites
inmarket

inmarket

Posted
Posted

It looks to me that this driver has been written with written with a 16 bit bus. The only time a 16bit bus is actually treated as a 16bit bus is after the 0x2C command and the one place that would need to be changed for an 8 bit bus (other than perhaps some initialisation sequence) is line 280.

Change line 280 to 

		write_word(g, gdispColor2Native(g->p.color));

 

write_word() would then be defined as write_data() for a 16 bit bus and as two write_data() calls for an 8 bit bus.

 

eg... 

#ifdef GDISP_ILI9481_8BITBUS
	#define write_word(g, data)		{ write_data(g, (data)>>8); write_data(g, (uint8_t)(data)); }
#else
	#define write_word(g, data)		write_data(g, (data))
#endif

 

If you want to make a patch and test that it works we can incorporate that into the repository.

 

Link to comment
Share on other sites
phofman

phofman

Posted
  • Author
Posted (edited)

Hi inmarket, thanks a lot for your reply. How about making clear distinction between the 8bit and 16bit write functions similar to that  arduino library (write8, write16)? write_byte would accept 8bit argument (uint8_t) and write_word would accept the current uint16_t. It is up to the board_driver.h implementation if the write_word sends 16bits parallel, 2 x 8bits parallel (i.e. twice write_byte) or uses serial SPI.

All register functions use the 8bit parameters, write_word/read_word  would be used only in the 16bit (RGB565) hardware streaming (write_color, read_color).

Please can you comment on the initialization parameters? I will test the parameters from the other libraries first as they seem "more correct" to me, based on the datasheet description.

Edited by phofman
Link to comment
Share on other sites
inmarket

inmarket

Posted
Posted

I have no idea with the driver initialisation as this is not a driver I wrote or a display I currently own. I could check against the datasheet but we all know that has little meaning as the datasheets are often incorrect or incomplete or the silicone has bugs etc.

To date each driver has defined its own routines that the board file has to implement. Whilst many drivers are similar there is no real standard. This particular driver writer obviously didn't handle/debug the 8 bit bus case.

This inconsistency is part of why the uGFX v3 gdisp driver interface is changing. A lot of these issues will be fixed. That doesn't mean however that a deiver won't have bugs when used in a situation that hasn't yet been tested. Unfortunately that just naturally happens.

Link to comment
Share on other sites
phofman

phofman

Posted
  • Author
Posted

I am OK with the existing design of the drivers, the source code is self-explaining. I like the structure, no case statements for the individual TFT controllers as found in other less universal libraries. Since I have no prior experience with this LCD, I just needed to know how much I can "trust" the driver compared to other sources (esp. the widely-used UTFT). I will send a patch once I make it work (hopefully :-) ). Since my LCD resolution 480x272 is different to the default 480x320, I will try to incorporate this setup into the initialization sequence too. Thanks a lot for your help.

Link to comment
Share on other sites
phofman

phofman

Posted
  • Author
Posted

ep.hobbyiest: The vendor has confirmed to me several times the display is actually using ILI9481. I asked him to fix the description, to no avail... He sent some code examples, presumably code for displaying the photos as shown on the product page. This time the driver file was called ILI9325.c, in directory called ILI9328 :-) But the init sequence in the file seemed to fit ILI9481 datasheet so he kind of convinced me it was ILI9481. Plus there is another seller with https://www.aliexpress.com/item/4-6-inch-HD-TFT-LCD-Touch-Screen-with-Adapter-Board-ILI9481-Drive-IC-480-272/32669045798.html which looks identical to me, for the same price.

I want to implement reading registers to the driver and read the Device Code Read register 0xbh to see if it outputs correct ILI9481 device ID from the datasheet. Perhaps tonight...

Link to comment
Share on other sites
inmarket

inmarket

Posted
Posted

Good idea for testing but it shouldn't be left in the production driver as some busses (or bus hookups) don't support reading eg SPI with the DI pin not connected.

A suitable solution is to add an #if macro to enable or disable the id reading.

Link to comment
Share on other sites
ep.hobbyiest

ep.hobbyiest

Posted
Posted
8 hours ago, phofman said:

ep.hobbyiest: The vendor has confirmed to me several times the display is actually using ILI9481. I asked him to fix the description, to no avail... He sent some code examples, presumably code for displaying the photos as shown on the product page. This time the driver file was called ILI9325.c, in directory called ILI9328 :-) But the init sequence in the file seemed to fit ILI9481 datasheet so he kind of convinced me it was ILI9481. Plus there is another seller with https://www.aliexpress.com/item/4-6-inch-HD-TFT-LCD-Touch-Screen-with-Adapter-Board-ILI9481-Drive-IC-480-272/32669045798.html which looks identical to me, for the same price.

I guess he don't know, what he is selling. 

That's really great way to recognize correct way. 

Can you please share some details here. 

Link to comment
Share on other sites
phofman

phofman

Posted
  • Author
Posted (edited)

Finally I managed to read the registers. The d3h reg reads 9487 which means ILI9487 - something between ILI9486 and ILI9488 with no datasheet available. According to discussion in https://forum.arduino.cc/index.php?topic=366304.msg3113020#msg3113020 the arduino ili9488 driver works just fine for this controller. I checked a few other registers, e.g. the complex Negative Gamma Control e1h and first 6 bytes are equal to default values of 9488 in the datasheet.

Therefore I will modify the existing ugfx ILI9488 driver which also does not allow for 8bit mode (almost same as the existing ILI9481 driver).

 

Edited by phofman
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...