Go Down

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

bodmer

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

Back in stock but price is now £4.76, good value and easy to get going with a Mega or Due, no messy wiring needed.
Formerly Rowboteer (now a broken user profile!)

bodmer

I have added support for 8 bit ILI9481 displays here (cut and paste link as forum does not support banggood links):

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


Also I have added outline/filled ellipse drawing member functions plus an example sketch.

Latest library is available here.
Formerly Rowboteer (now a broken user profile!)

Five33

Hello,
Thanks for your contribution, so far the only one I could run on the DUE. I am running a DUE, 8 bit ILI9488.
On the UTFT Demo and graphics test 320x480 in your examples, some fonts do not print well. The DEAD BEEF lettering has sporadic color dots in the small fonts, and some graphics lines are sort of fused as if the display does not have full resolution to render individual lines.

Is this a known problem or maybe some slight difference between ILI9481 and 9488 ?

bodmer

@Five3

The library does not intentionally support the ILI9488.

It sounds like the control lines are being toggled too fast for the driver or the display is using resistors inline with the control signals.  Can you provide a link to the display sales page?

What setting in the library User_Setup.h file have you used?
Formerly Rowboteer (now a broken user profile!)

Five33

The buss is straight to the DP74HC245 buffers, and they are powered by the 3.3v pin, voltage checks ok.
The display does work on some of the UNO libraries. The video setup in your library is making a much better brightness and contrast setting than the UNO package. The print in some places and not others. I'll get a photo , hopefully this afternoon but I have to do some chores first. Off to do them now.
UserSetup.H :


// ##################################################################################

//#define HX8357B
//#define HX8357C
//#define ILI9481

#define ILI9481_8BIT

// ##################################################################################


I didn't pay $129.88, I paid $12.98, the seller ran out of stock and held the ad in place by posting a ridiculous price.





http://www.ebay.com/itm/182008313057?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

bodmer

@Five33

OK, the spurious pixels suggest the write strobe is too fast for the ILI9488 chip.

Replace the TFT_HX8357_Due.h in the library with the one attached and see if that fixes the problem. I have slowed down the write strobe a little.

Formerly Rowboteer (now a broken user profile!)

Five33

I just came by to say enabling hold WR\ low caused even more problems. That way, it clips portions out of the graphics shapes in the UTFT demo. Thanks, I'll try that.

Five33

That fixed it. Now it looks great. Can't say I see any slowing of the operation. Still MUCH faster than a UNO, that good old workhorse board.

Now I plan to make a sort of extended VT100 type monitor. I looked for any standard extended commands to make graphics blocks with text etc, FF will clear the screen. More as I see need. Gonna use it with GRBL CNC mainly. Tested on a UNO at 9600 baud, GRBL now likes 115200k. If DUE can manage the transfers at that rate, great, and if not, I won't be able to use verbose mode as it runs G Code. Tragic loss ha ha, but at least I can use it for what I need, a portable display to enter commands, and an SD card to load them.

Thanks for the help.

Five33

FF is Form Feed, and the extended commands will be entered by something like :
ESC NN command data

As in ESC 50 print at X 60 Y 16 string

String would be something like X 12.345

I suppose now the race is on the make a portable GRBL monitor. Very surprised I haven't seen one. I am not up to doing any production work, I was hurt in a lifting accident and now sulk around on disability. I lifted my last 150 lb machine assembly at just over 45 years old. Be careful at that age.

bodmer

That fixed it. Now it looks great. Can't say I see any slowing of the operation. Still MUCH faster than a UNO, that good old workhorse board.

Thanks for letting me know it is working. This means I can easily adapt the library for the 8bit ILI9488 displays.

The performance reduction will probably only be 1 or 2% so is hardly noticable.

Good luck with your project.
Formerly Rowboteer (now a broken user profile!)

Five33

There is a little difference between the ili9481 and ili9488. In the graphicstest_320x480, in the portrait orientations, the text is mirror imaged, backwards. Landscape mode is correct. Also, it only does the same portrait and landscape screens. The vertical and horizontal flips do not show. The loop is written correctly.

void loop(void) {
  for (uint8_t rotation = 0; rotation < 4; rotation++) {
    tft.setRotation(rotation);
    testText();
    delay(1000);
  }

I'm pecking at it, after awakening from a 15 year vacation from C programming. Ever hear of Borland C++ ? On floppies ! Hit me with the hardware.

bodmer

OK, it looks like the ILI9488 needs different control register 0x36 settings for the rotations.

You could experiment with the sketch attached to find the right bit combinations for the control register.

For some reason it is necessary to write to the register twice.

It is a case of noting the codes that give a blue background with the text in the right order. Then you can set the orientation with that code direct from your sketch.


Formerly Rowboteer (now a broken user profile!)

Five33

Problem solved.
Sorry but thanks for the wasted work, as I gain knowledge in these libraries, I thought to first look in MCUfriend_kbv.cpp and found the iLi9488 screen orientation commands .


I took the bytes and directly inserted them for the 9488. Portrait +90 = 0x28 and no need to change. The ones I changed have the boolean commented out and over to the side.
So, in the TFT_HX8357.cpp file of yours, I did as below and now orientation is correct in all four orientations.


void TFT_HX8357_Due::setRotation(uint8_t m) // Modified for ili9488
{
  writecommand(HX8357_MADCTL);
  rotation = m % 4;
  switch (rotation) {
   case 0: // Portrait
     writedata (0x48);                      //(MADCTL_BGR | MADCTL_SS);
     _width  = HX8357_TFTWIDTH;
     _height = HX8357_TFTHEIGHT;
     break;
   case 1: // Landscape (Portrait + 90)
     writedata(MADCTL_MV | MADCTL_BGR);
     _width  = HX8357_TFTHEIGHT;
     _height = HX8357_TFTWIDTH;
     break;
   case 2: // Inverter portrait
     writedata (0x98);                    //( MADCTL_BGR | MADCTL_GS);
     _width  = HX8357_TFTWIDTH;
     _height = HX8357_TFTHEIGHT;
     break;
   case 3: // Inverted landscape
     writedata (0xF8);                   //(MADCTL_MV | MADCTL_BGR | MADCTL_SS | MADCTL_GS);
     _width  = HX8357_TFTHEIGHT;
     _height = HX8357_TFTWIDTH;
     break;
  }
}

Also in the .ino file, I found the need to insert a rotation command after tft.begin, as below.

  tft.begin();
  tft.setRotation(1); //Set to 0,1,2,3 as needed

Snout

I have added support for 8 bit ILI9481 displays here (cut and paste link as forum does not support banggood links):

Neat, 8-bit support! Does this mean I have a chance of making this run on an Uno? (Though when trying to compile it, it gives a lot of Due-specific (I guess) errors like "error: 'REG_PIOA_SODR' was not declared in this scope". I'm assuming here, that for it to work, those kinds of pins would need translating, and perhaps the library trimmed down to fit in the small Uno memory?)

david_prentice

There are two libraries.    One for Mega and one for Due.

You would need to do a lot of changes for a Uno version.   For a start,   you would have to scrap all the 16-bit bus code.

Try your screen with a Mega2560.    I suspect you have a hardware problem with your "blue only".

Go Up