MCUFRIEND_kbv Library for Uno 2.4, 2.8, 3.5, 3.6, 3.95 inch mcufriend Shields

Other Hardware Displays
1041

david_prentice:
You have a Himax HX8347-I controller.

Make sure that you have library version v2.9.3 or newer.
If you have an old library, delete the existing MCUFRIEND_kbv folder in User libraries.
Install the current version from the IDE.

You should edit the mcufriend_kbv.cpp file:

#define SUPPORT_8347D

Please let me know how you get on.

David.

Hi David, adding "#define SUPPORT_8347D" did do the trick, to get the screen working. But i got some warnings. Just wondering how to fix these? Thank you.

kind regards,
Quinten

mcu.png
mcu.png1680×1050 114 KB

1042

The TFT Shield 3.2inch 9326 sheet

Sheet_9326.jpg
Sheet_9326.jpg998×746 238 KB

1043

The warnings are simply about anonymous string constants. You don't need to worry about them.

You can avoid most of them by adding the const keyword. e.g.

    const char *aspectname[] = {

I intend to tidy up the graphictest_kbv sketch. If I can make it smaller, I can have more "SUPPORT_XXXX" models that work out of the box. Obviously it is important for the examples to run on a Uno. Better if the warnings disappear.

I doubt if I would ever enable the HX8347, HX8352, SSD1289 by default. But it would be nice if ILI9326, SPFD5420 worked by default.

I am pleased that your HX8347-I is working. Member "Governor" has had difficulty with a 16-bit HX8347-I. At least he knows that it is not a library problem now.

David.

1044

The Mcufriend Uno Shields plug into a Uno, Mega, Due, Zero, ... Maple, Nucleo
The Mcufriend Mega Shields only plug into a Mega or Due.

Why did you buy a Display Shield if you don't want to mate as Nature intended?

If you post your full wiring plan, I can advise. I might even write a SPECIAL for you.

David.

sometimes you feel like a nut and sometimes you dont.... :slight_smile: i bought a UNO shield but when i was developing the rocket launcher for my drone i burned out quite a few of them (UNOs) when i got some time off to review another project i realized all i had left was a Mega2560, (so now using the UNO shield on a mega) i dont like the fact that the shield covers up what would otherwise be useable ports, and the display i got for the price i paid was cheaper than the bare display on a breakout, and really a shield is just a device specific break out. in either case, it would be wonderful and probably simple to specify the D0-D7 pins in the event that you did come across a plain lcd on a breakout bearing the same controller as these shields, I must admit after poking a round in the library for a few days it is an amazing thing of beauty. Well done seriously to you and any others who may have code in this tarball, i really didnt read the credits. that being said a plain screen on breakout would benefit from not absorbing all of my natural pwm outputs and instead using pure digital ports (22-42) with exception of course for the analog ports (2 i believe) for the touch screen. as it sits now this screen on a mega blocks up all the ad ports just about, sheild or not they are fast and handy screens that with a little dupont magic look great in any project. btw i have a 2.4 ILI9325

wiring plan as i project it would be

#define LCD_RST 33
#define LCD_CS 32
#define LCD_RS A2
#define LCD_WR A1
#define LCD_RD 31

#define LCD_D0 23
#define LCD_D1 24
#define LCD_D2 25
#define LCD_D3 26
#define LCD_D4 27
#define LCD_D5 28
#define LCD_D6 29
#define LCD_D7 30

TY!!!

1045

It is not difficult. Just take your defines and look up the port pins:

#define LCD_RST 33 //PC4
#define LCD_CS 32 //PC5
#define LCD_RS A2 //PF2
#define LCD_WR A1 //PF1
#define LCD_RD 31 //PC6

#define LCD_D0 23 //PA1
#define LCD_D1 24 //PA2
#define LCD_D2 25 //PA3
#define LCD_D3 26 //PA4
#define LCD_D4 27 //PA5
#define LCD_D5 28 //PA6
#define LCD_D6 29 //PA7
#define LCD_D7 30 //PC7

Put these #defines into the LCD_ID_readreg sketch. You should get the correct report. If not, then your wiring does not agree with the defines.

Add the appropriate SPECIAL:

...
#define USE_SPECIAL_TBILLION
...
#elif defined(__AVR_ATmega2560__) && defined(USE_SPECIAL_TBILLION)
#warning USE_SPECIAL_TBILLION for tbillion
#define RD_PORT PORTC
#define RD_PIN  6        //D31
#define WR_PORT PORTF
#define WR_PIN  1        //A1
#define CD_PORT PORTF
#define CD_PIN  2        //A2
#define CS_PORT PORTC
#define CS_PIN  5        //D32
#define RESET_PORT PORTC
#define RESET_PIN  4     //D33

#define AMASK   0xFE
#define CMASK   0x80
#define write_8(x)   { PORTA = (PORTA & ~AMASK) | (((x)<<1) & AMASK); \
                       PORTC = (PORTC & ~CMASK) | (((x)) & CMASK);}

#define read_8()      (( (PINA & AMASK) >> 1) | (PINC & CMASK))
#define setWriteDir() { DDRA |=  AMASK; DDRC |=  CMASK; }
#define setReadDir()  { DDRA &= ~AMASK; DDRC &= ~CMASK; }
#define write8(x)     { write_8(x); WR_STROBE; }
#define write16(x)    { uint8_t h = (x)>>8, l = x; write8(h); write8(l); }
#define READ_8(dst)   { RD_STROBE; dst = read_8(); RD_IDLE; }
#define READ_16(dst)  { RD_STROBE; dst = read_8(); RD_IDLE; RD_STROBE; dst = (dst<<8) | read_8(); RD_IDLE; }

#define PIN_LOW(p, b)        (p) &= ~(1<<(b))
#define PIN_HIGH(p, b)       (p) |= (1<<(b))
#define PIN_OUTPUT(p, b)     *(&p-1) |= (1<<(b))

Untested. I just typed directly into the Browser. It actually took me 20 minutes to reply.

The real mystery (and typing time) was due to your choice of D23-D30 instead of D22-D29.
Hey-ho, life is great!

David.

1046

david_prentice:
Your JPEG shows

#define LCD_RST A4    //n.c.

#define LCD_CS A3
#define LCD_RS A2
#define LCD_WR A1
#define LCD_RD A0

#define LCD_D0 8
#define LCD_D1 9
#define LCD_D2 10
#define LCD_D3 11
#define LCD_D4 4
#define LCD_D5 13
#define LCD_D6 6
#define LCD_D7 7




If you would care to run LCD_ID_readreg with the correct defines, I am sure that it would report sensible values. (Remove the microSD from the card holder first)

When you have posted the result, I will look at your "SPECIAL"

David.

The result with correct defines and without sdcard:

Read Registers on MCUFRIEND UNO shield
controllers either read as single 16-bit
e.g. the ID is at readReg(0)
or as a sequence of 8-bit values
in special locations (first is dummy)

reg(0x0000) 93 26 ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 00 00 Manufacturer ID
reg(0x0009) 00 00 00 00 00 Status Register
reg(0x000A) 00 00 Get Powsr Mode
reg(0x000C) 00 00 Get Pixel Format
reg(0x0061) 00 00 RDID1 HX8347-G
reg(0x0062) 00 00 RDID2 HX8347-G
reg(0x0063) 00 00 RDID3 HX8347-G
reg(0x0064) 00 00 RDID1 HX8347-A
reg(0x0065) 00 00 RDID2 HX8347-A
reg(0x0066) 00 00 RDID3 HX8347-A
reg(0x0067) 00 00 RDID Himax HX8347-A
reg(0x0070) 00 00 Panel Himax HX8347-A
reg(0x00A1) 00 00 00 00 00 RD_DDB SSD1963
reg(0x00B0) 00 00 RGB Interface Signal Control
reg(0x00B4) 00 00 Inversion Control
reg(0x00B6) 00 00 00 00 00 Display Control
reg(0x00B7) 00 00 Entry Mode Set
reg(0x00BF) 00 00 00 00 00 00 ILI9481, HX8357-B
reg(0x00C0) 00 00 00 00 00 00 00 00 00 Panel Control
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA
reg(0x00CC) 00 00 Panel Control
reg(0x00D0) 00 00 00 Power Control
reg(0x00D2) 00 00 00 00 00 NVM Read
reg(0x00D3) 00 00 00 00 ILI9341, ILI9488
reg(0x00DA) 00 00 RDID1
reg(0x00DB) 00 00 RDID2
reg(0x00DC) 00 00 RDID3
reg(0x00E0) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-P
reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-N
reg(0x00EF) 00 00 00 00 00 00 ILI9327
reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2
reg(0x00F6) 00 00 00 00 Interface Control

Drivers Vendor

1047

I have studied the SPECIAL that you posted earlier. It looks absolutely fine to me.

I would put it in mcufriend_special.h. Your code looks fine, but I would write:

#define USE_OPENSMART_SHIELD_PINOUT
...
#elif defined(__AVR_ATmega328P__) && defined(USE_OPENSMART_SHIELD_PINOUT)
#define RD_PORT PORTC
#define RD_PIN  0
#define WR_PORT PORTC
#define WR_PIN  1
#define CD_PORT PORTC
#define CD_PIN  2
#define CS_PORT PORTC
#define CS_PIN  3
#define RESET_PORT PORTC
#define RESET_PIN  4

#define BMASK         B00101111
#define DMASK         B11010000

#define write_8(x) {                          \
        PORTD = (PORTD & ~DMASK) | ((x) & DMASK); \
        PORTB = (PORTB & ~BMASK) | ((x) & BMASK);} // STROBEs are defined later

#define read_8()   ((PIND & DMASK) | (PINB & BMASK))

#define setWriteDir() { DDRD |=  DMASK; DDRB |=  BMASK; }
#define setReadDir()  { DDRD &= ~DMASK; DDRB &= ~BMASK; }


#define write8(x)     { write_8(x); WR_STROBE; }
#define write16(x)    { uint8_t h = (x)>>8, l = x; write8(h); write8(l); }
#define READ_8(dst)   { RD_STROBE; dst = read_8(); RD_IDLE; }
#define READ_16(dst)  { uint8_t hi; READ_8(hi); READ_8(dst); dst |= (hi << 8); }

#define PIN_LOW(p, b)        (p) &= ~(1<<(b))
#define PIN_HIGH(p, b)       (p) |= (1<<(b))
#define PIN_OUTPUT(p, b)     *(&p-1) |= (1<<(b))

#elif defined(__AVR_ATmega2560__) && defined(USE_OPENSMART_SHIELD_PINOUT)
#define RD_PORT PORTF
#define RD_PIN  0
#define WR_PORT PORTF
#define WR_PIN  1
#define CD_PORT PORTF
#define CD_PIN  2
#define CS_PORT PORTF
#define CS_PIN  3
#define RESET_PORT PORTF
#define RESET_PIN  4

#define BMASK         B10110000 //D13, D11, D10
#define GMASK         0x20      //D4
#define HMASK         0x78      //D6, D7, D8, D9

#define write_8(x) {  \
        PORTH = (PORTH&~HMASK)|(((x)&B11000000)>>3)|(((x)&B00000011)<<5); \
        PORTB = (PORTB&~BMASK)|(((x)&B00101100)<<2); \
        PORTG = (PORTG&~GMASK)|(((x)&B00010000)<<1); \
    }
#define read_8()(\
                 ((PINH & B00011000) << 3) | ((PINB & BMASK) >> 2) | \
                 ((PING & GMASK) >> 1) | ((PINH & B01100000) >> 5) )
#define setWriteDir() { DDRH |=  HMASK; DDRB |=  BMASK; DDRG |=  GMASK; }
#define setReadDir()  { DDRH &= ~HMASK; DDRB &= ~BMASK; DDRG &= ~GMASK; }

#define write8(x)     { write_8(x); WR_STROBE; }
#define write16(x)    { uint8_t h = (x)>>8, l = x; write8(h); write8(l); }
#define READ_8(dst)   { RD_STROBE; dst = read_8(); RD_IDLE; }
#define READ_16(dst)  { uint8_t hi; READ_8(hi); READ_8(dst); dst |= (hi << 8); }

#define PIN_LOW(p, b)        (p) &= ~(1<<(b))
#define PIN_HIGH(p, b)       (p) |= (1<<(b))
#define PIN_OUTPUT(p, b)     *(&p-1) |= (1<<(b))

And enable / disable with mcufriend_shield.h

#define USE_SPECIAL             //check for custom drivers

Untested. I typed into the Browser.

David.

Edit. I have added macros for MEGA2560. This was just typed but Untested.

1048

The real mystery (and typing time) was due to your choice of D23-D30 instead of D22-D29.

22 controls the power on/off of the atx power supply.

ill give that a run hopefully i can understand this Special thing with out much explanation. :slight_smile: THANK you for your 20 mins :slight_smile:

1049

You have got two "whole" ports: PORTA on D22-D29, PORTC on D30-D37.

You are wasting PORTA by mixing bits. If D22 is cast in stone, you could put the data bus onto PORTC instead.

The result of sensible mapping is dramatic. You would also find it easier to understand.
Just look at the SPECIALS for MEGA_8BIT_SHIELDS.

David.

1050

david_prentice:
I am pleased that your HX8347-I is working. Member "Governor" has had difficulty with a 16-bit HX8347-I. At least he knows that it is not a library problem now.

As stated in the thread I was responding in, I've never really suspected your code to be faulty. C++ is not unknown to me, as my past profession was of a developer in a known antivirus company; however I have no previous experience with microcontrollers programming so I didn't really raise any objections to it yet.

Rather, after spending two full days trying my LCD board to get cracking, I've made a correct assumption of it being dead-on-arrival with nothing except the backlight being working on it - besides your amendments to the Adafruit TFT library/MCUFRIEND_kbv I've also tried different other libraries, including a fork of the UTFT library which was meant to support the Hirax HX8347-I and tested by a fellow from the Czech Republic. Since the board made me more woes with my attempt to plug in a SD card, only to be welcomed by the fact that from then on, it was unreadable, I've ruled out the software part of being the cause of the problems.

Nevertheless, after declaring the thing dead, I've bit the bullet and dismantled my whole board, including the panel and the actual liquid crystal display - and found no dedicated chip to drive the TFT LCD, to verify if there really had been a 8347i. I did take note of the AMS 3.3V regulator, the HR2046 touch screen controller and the SMD resistor packs on the PCB, and a few passive components soldered straight on the flex cable that lead to the LCD display itself -- which had, like, one hundred conductive traces on a micrometer scale. The driver might have been hiding under the black epoxy-rubber-gunk on the edge of the display... who knows. I expected it to be a separate surface-mount chip.

At least I've managed the display to make some cool graphics....... after a 20 kilovolt supply was connected straight to it :smiley: Also the actual glass part of the LCD has an interesting filter glued on it: you can view through it, but all LCD screens appear as being completely black, even when turned on.

1051

You have got two "whole" ports: PORTA on D22-D29, PORTC on D30-D37.

You are wasting PORTA by mixing bits. If D22 is cast in stone, you could put the data bus onto PORTC instead.

The result of sensible mapping is dramatic. You would also find it easier to understand.
Just look at the SPECIALS for MEGA_8BIT_SHIELDS.

David.

UT OH; that right there looks like we are getting outside of lazy arduino comfort zone and into the real deal atmega 2560 stuff. lol. i come from Microchip PICs just got so tired of the design process and needing custom pcbs every time to get something popping, actually resisted Arduino until last year when i finally wanted to see what the hype was all about, my 300$ Pic programmer hasnt seen use since the arduino clone arrived from china..lol ... but yes i know what you mean about port mapping, glad i talked to you before i sent this board order off to china, i moved all the atx stuff to PORTC.

Thank you David for the help.

1052

Have you got the SPECIAL working correctly? i.e. was my 20 mins successful?

It would make life simpler and FASTER if you put the Data Bus onto PORTC (or PORTA)
Have you got it working on PORTC now?

God invented the Uno. The most important part being the Shield pluggability.
It means that anyone, anywhere in the world can know the wiring. And a library author does not need to worry about how the punter has connected it.

Arduino Uno, Mega, Due, ... have been very popular. And work pretty well.
I don't know whether the PIC ChipKit boards have sold many boards. And no one has ever asked me to support ChipKit.

If anyone wants to use non-shield wiring, it is their responsibility to write a SPECIAL for their specific project. I don't mind helping for ONE target. I certainly don't want to do it for multiple targets.

The LCD_ID_readreg sketch shows how to write the basic write_8(), read_8(), ... on ANY pins.
A Shield has FIXED wiring. You can achieve the "best" performance.

David.

1053

david_prentice:
I have studied the SPECIAL that you posted earlier. It looks absolutely fine to me.

I would put it in mcufriend_special.h. Your code looks fine, but I would write:

#define USE_OPENSMART_SHIELD_PINOUT

...




And enable / disable with mcufriend_shield.h

#define USE_SPECIAL            //check for custom drivers




Untested. I typed into the Browser.

David.

No, after test the screen is white, the resolution is not good, the reset is not really good.

TFT LCD test
Using OPENSMART 2.8" TFT Breakout Board Pinout
TFT size is 240x320
Serial took 0ms to start
ID = 0x9326

work with the kvb 2.9.1beta and the old mcushield.h

1054

Looking at the current Beta on GitHub:

MCUFRIEND_kbv.cpp:

//#define SUPPORT_0139              //not working +238 bytes
#define SUPPORT_0154              //S6D0154 +320 bytes
//#define SUPPORT_1289              //costs about 408 bytes
#define SUPPORT_1963              //only works with 16BIT bus anyway
//#define SUPPORT_4532              //LGDP4532 +120 bytes.  thanks Leodino
#define SUPPORT_4535              //LGDP4535 +180 bytes
#define SUPPORT_68140             //RM68140 +52 bytes defaults to PIXFMT=0x55
#define SUPPORT_7781              //ST7781 +172 bytes
//#define SUPPORT_8347D             //HX8347-D, HX8347-G, HX8347-I +520 bytes, 0.27s
//#define SUPPORT_8347A             //HX8347-A +500 bytes, 0.27s
//#define SUPPORT_8352A             //HX8352A +486 bytes, 0.27s
//#define SUPPORT_9326_5420         //ILI9326, SPFD5420 +246 bytes
#define SUPPORT_B509_7793         //R61509, ST7793 +244 bytes
#define OFFSET_9327 32            //costs about 103 bytes, 0.08s
...

Clearly the ILI9326 is not enabled. The graphictest_kbv sketch is very tight for Flash memory on a Uno. Hence I have to make a decision about the "less common" controllers.

Several people own R61509V and ST7793 (I have R61509).
I doubt if more than one person owns ILI9326 or SPFD5420.

I suggest that you disable the R61509V and enable ILI9326.

The important lessons are:

  1. Test any "special" wiring with the LCD_ID_readreg.ino sketch
  2. Check whether readID() is detecting the controller. This verifies your wiring.
  3. Check whether a "less common" device is actually enabled.

Sorry for not noticing (3) !!!

David.

1055

i have disable the R61509V and enable ILI9326.
It's good for UNO , not for the Mega(clone), i test the wiring

thanks for your advices ;-))

1056

Look at my post #1059. And compare with other SPECIALs.
The driver for a particular special wiring is different for each target AVR.

I was surprised to see that your suppiler was using my library. If they are selling a commercial product, it would have been wise to ask me ( the author). Then I would have ensured that 9326 was enabled as default.

As you may have noticed, the Uno mapping for the OPENSMART works nicely.
Pin mapping for MEGA2560 (or DUE) is very fiddly.

Do you really want to use a Mega2560?

David.

Edit. I see that they had written SPECIAL macros for the MEGA2560. They "look" ok to me.
I have written them in my style and added to message #1059. Untested. Please tell me if both sets work.

1057

Both work well, I had to forget a piece of the code when I copied it.
Here are screenshots and modified files thanks to you.
I was also surprised to see that it was your drivers that came with the lcd, really no respect. In addition the supplied sheet does not have the right wiring.


MCUFRIEND_kbv.cpp
mcufriend_special.h
mcufriend_shield.h

Really a big thank you for for the support 8) :wink:

1058

Yes, that is the correct way to add your SPECIALs. I suggest you save a copy somewhere. I will add it to the next Release (because it refers to a hardware Shield).

Where are you? It is pretty chilly in Wormshill, England today!!

David.

1059

Yes I already made a copy :grin:
I am in France near Brittany and it is cold but with a beautiful sun.
have a goog day

1060

Michel53.

well done on the hard workץ
I really liked the clock.
Can I get the code?
Thanks.