Go Down

Topic: Fast library for Due and low cost HX8357B/C and ILI9481 480 x 320 displays (Read 13070 times) previous topic - next topic

rowboteer

I have posted a brand new TFT_HX8357_Due library for the Due on my GitHub repository.  The display supported by the library is 16 bit with 480 x 320 pixels and is available at low cost from a number of sources for example from Banggood:

You will have to select, copy and paste these next two links into your browser as the normal forum embedded link method does not work for some reason:

Code: [Select]
http://www.banggood.com/3_2-Inch-320-X-480-TFT-LCD-Display-Module-Support-Arduino-Mega2560-p-963574.html

Code: [Select]
http://www.banggood.com/3_0-Inch-320-X-480-TFT-LCD-Display-Module-Support-Arduino-Mega2560-p-963573.html


Or from AliExpress

The main features are:

  • Good performance (480 x 320 screen clears in 12ms, 72 pixel high numeral drawn in 0.8ms)
  • 48 different Free Fonts from the new Adafruit_GFX library
  • 5 native fonts encoded for fast rendering
  • support for ILI9481 controller


Features also include justification options to centre, left, right, top, bottom and baseline justify text and numbers. See the example sketches.

Performance is quite good (320x240 UTFT demo completes in less than 1.4s) despite the fact that the 16 bit bus to the TFT is mapped to 4 different ports and pretty random processor register bits, so a lot of register bit juggling has to be performed that wastes time.

The library only supports the Due.  A library to use the Mega with these displays is here.

Sometimes the vendors supply a different controller, probably an ILI9481, even though the advert states HX8357B, so the library also supports that controller by selecting the ILI9481 driver in the User_Setup.h file within the library.




This is an inital release, please report any bugs via GitHub by raising an "issue".

Okio

Looks like it could be interesting if it were not for the port mapping calamity us Due owners must contend with.
Have you considered constructing a small adapter cable to fix (remap) the port mapping? Doing so at the hardware level will surely unhinder the driver. We then might actually get to see what the Due can actually do.

Just as a reference: With the 2.2" 320x240 display I'm using here on the Due, it can perform full screen clear in 14ms, via SPI.

rowboteer

@Okio

I'm OK with the port mapping because the Due still has plenty of processing power in reserve between display updates and it does not hamper the display update timing very much (for example the UTFT 480x320 sketch with delay() removed completes in 1.6s (it runs so fast you don't even see some test screens being drawn!), with a better 16 bit port mapping this would only improve to 1.2s at best, so an adapter cable is hardly worth the effort. In "real use" situations the speed difference would not be noticed.

I will have to report you to the Society for Prevention of Cruelty to Registers (SPCR) for running the SPI at 84MHz.  I am impressed that the display can take it, but not surprised that the Due can deliver it.  Typically the 2.2" displays have an ILI9341 rated at 10MHz or 15MHz maximum depending on which data sheet you read.

The poor SPI shift register transistors are probably getting the hinges ripped off their gates, their drains blocked by an overload of bits and their sources running hotter than a Jamaican scotch bonnet pepper. :)

rowboteer

The HX8357_Due library has been updated so that there is no longer a restriction on sketch size when using the Adafruit Free fonts. Latest version is here.

Unfortunately Adafruit chose to use a Struct to pass font parameters and the 32bit pointers were getting converted into 16 bit ones!  The solution (as I did not want to change their font file format) was to pass array pointers directly to the library.

There is also a companion library available that decodes JPEG images on the Due, these can be stored in program memory (enough room for maybe 20 off 480x320 images on the Due) or retrieved from SD Card.  The example with the library works with the HX8357_Due library and has been tested on the HX8357B+HX8357C+ILI9481 16bit parallel 480x320 TFTs.


rowboteer

A bug has been found and fixed in the TFT_HX8357_Due library. The bug caused loss of contrast in ILI9481 displays.

Furthermore, a new example called "All_Free_Fonts_Demo" has been added to the library.  This loads and displays all 48 Free Font files (12 fonts, each in 4 different sizes).

The sketch size is large but only occupies half the Due's program memory:

Sketch uses 252,744 bytes (48%) of program storage space. Maximum is 524,288 bytes.


So there is still room for ~10 compressed full screen (480 x 320) jpeg images  :)

The JPEGDecoder library has had some minor updates so now a 480x320 pixel image stored in program memory can be decoded and displayed in less that 1s.  Considering the complexity of the maths involved this shows the real processing capability of the Due.

jasperachtbaan

Hello,

I have bought this screen from banggood:
http://www.banggood.com/3_5-Inch-TFT-Color-Screen-Module-320-X-480-Support-Arduino-UNO-Mega2560-p-1022298.html

I want to drive it from an arduino DUE. Is this possible with your library (without re-wiring it) or should I buy one of the screens you suggested?

Thanks in advance,

Jasper

jasperachtbaan

Hi,

I've just tried rewiring the screen to work with your library, but I notices that your lib works with 16 data pins one the screen, and mine only has 8. Any fixes for this??

Jasper

rowboteer

I want to drive it from an arduino DUE. Is this possible with your library (without re-wiring it) or should I buy one of the screens you suggested?

The library could be changed to work with that display. I have a couple of those screens on order and they should be with me soon so if you are patient I will be updating the Due+Mega libraries to drive them. I bought them as I want to read back the screen graphics to get nice images for an online library user manual.

If you get one of the Mega displays then go for a HC8357C or ILI9481 type as the HX8357B appears to have a timing bug in the silicon device which causes spurious pixels to appear on the screen if the write to SGRAM clashes with the TFT pixel refresh read access (perhaps this is why there are version C and D of that driver).

jasperachtbaan

Okay sounds good!
Could you please provider me with wiring instructions so I can use it now with extra wiring?

Thanks in advance,

Jasper

rowboteer

Could you please provider me with wiring instructions so I can use it now with extra wiring?
The display cannot be rewired to work with the existing library. The library will have to be udpated.

Since it has to be updated to work with that display I would make changes that use the pins that are already connected to the Arduino headers, then no rewiring is needed.

I could make some changes that might work but I would want to test these changes myself before the updated library is released.

In the meantime you may find David Prentice's library works and suits your need, but you would need to check this yourself as I have only tried it once with a different setup. Leave a message on the thread and he may be able to help you.

rowboteer

Using large font files and program memory JPEG images with the Due is great and means images and fonts are quickly available but it then takes a long time to upload new sketches to the Due and then to verify them.


However I found and updated this thread to stop the verification of the upload. Now the upload time is halved  :)  :)  (and I have never seen a verify error anyway).

david_prentice

Hello,

I have bought this screen from banggood:
http://www.banggood.com/3_5-Inch-TFT-Color-Screen-Module-320-X-480-Support-Arduino-UNO-Mega2560-p-1022298.html

I want to drive it from an arduino DUE. Is this possible with your library (without re-wiring it) or should I buy one of the screens you suggested?

Thanks in advance,

Jasper
Your link is "Access denied" for me.    I am guessing that this display is what you have because it has the same URL.

It looks as if it is a standard "Blue mcufriend for Uno" shield.    It should work 100% with my library.

Note that Rowboteer's displays are 16-bit with "sensible Mega pins".    Your display is designed for a Uno.    It will work on Mega, Leonardo, Zero, Due, ... but all the pins have to be mangled to match.    This makes it much slower than the 16-bit displays.

Incidentally,   it looks as if your display does not have a resistive Touch screen.     You can verify this by checking the resistance between pin A2 (LCD_RS) and D6, D7, D8, D9.   A resistive Touch panel will have a resistance of 300-500 ohms.   

David.

rowboteer

Embedded Banggood links do not always work on this forum so you need to select, copy (Ctrl+C in Windows) and then paste the link into a browser >:(

This is the display Jasper has:

Code: [Select]

http://www.banggood.com/3_5-Inch-TFT-Color-Screen-Module-320-X-480-Support-Arduino-UNO-Mega2560-p-1022298.html

rowboteer

Price has dropped even lower (£2.14 each) for the HX8357B displays here. (Ignore the claim they are ILI9341!)

Better be quick they only have 35,000+ in stock  :)

I have found for very intensive display graphics update rates you can get spurious pixels being activated. But if you clear the screen periodically (clears almost "instantly" when using a Due) they are fine good and cheap.

zoomx

Just looked now, I got
Sorry, this item is no longer available!
Anyway it seems that some vendors sell batch of these modules and sometimes the controller changes without any notify. Sometimes it is different from te photo.

Go Up