Go Down

Topic: MCUFRIEND_kbv Library for Uno 2.4, 2.8, 3.5, 3.6, 3.95 inch mcufriend Shields (Read 128114 times) previous topic - next topic


Your link shows a "better" photo of the Adapter Shield.   I still can't tell whether all the SMD resistors and capacitors are mounted or not.   Your eyes could.

I presume that you bought the LCD+RTP+PCB @ $27.96 with the STM32 Evaluation Board @ $14.99.
There is no indication of which controller is present.   I am guessing SSD1963 ???

The 40-pin pinout is completely different to the regular ILI9341 or SSD1963 40-pin screens.

I am not phased by a STM32 board without documentation.   But I have zero interest in something that is only compatible with that particular LCD.   i.e. I could not plug it into my 800x480 screen.

Hi David

Your interest in this adapter shield seems REALLY intense.
So I disconnected it from my test setup for checking rotation for my GxCTRL_SSD1962 class.
Seems I could not decipher the rotation code of MCUFRIEND_kbv.cpp correctly so far.

Here are the results:

On the left side (towards connector) of the AMS1117 T33 D47HC (nearly undecipherable)
there is a resistor marked 100 measured 11, the resistor connected to the LED pin.
Below is a open solder bridge, left side connected to 5V pin, right side to the output of the regulator.
So the solder bridge allows modification for 5V logic output, for 5V logic display.
The 2 devices on the right side of the regulator seem to be capacitors.

The controller of my 5inch display is a ILI9806.

Do you remember my topic about this display? see




I would guess that if you make the open solder-bridge,  it may route the 3.3V from the regulator output.
I presume that you must open another bridge if 5V is currently routed to pin #2.

Ah-ha.  So you have an ILI9806.   I have never seen one.

It should be easy enough to support with MCUFRIEND_kbv.
Personally,   I would use Due or STM32 which have 3.3V logic.   And connect the RD line.

Most Mega Adapters are write-only.   Which makes the display useless (IMHO).




I re-state that the Vcc pin on the display connector is connected directly to the 5V Arduino pin.

There is no other solder bridge on the adapter shield, the only - open - bridge is for 5V logic to the display.

My display class with my GxCTRL_ILI9806 class and one of several GxIO classes for Tiky works well with my 5inch 480x854 display.

If you are interested in an example for a ILI9806 class with init sequence, you may soon find it on my GitHub entry GxTFT, which is "under construction". The part that I added so far is to show the design; the names of the GxIO subclasses will change, now that I know more about shields and adapter shields.




The story of this shield is very strange.

Here is the picture that shows Elecfreaks, we see on the shield the marking of version v2.2 :

On the selling link of the shield, is written at the top right of the page :

LCD TFT01 Arduino Mega Shield v2.0 SHD10

All this is not very clear.
Picture of the item for sale v2.2, descriptive of the item for sale v2.0 ??

My shield marked v2.2 is in all points identical to the diagram that I have, this diagram and that of version v2.0 ??

We do not find diagram of the v2.2 release ??
Does version v2.2 really exist ??

My CTE TFT LCD /SD Shield for Arduino Due has a Jumper for 3.3V / 5V.

Yes, it appears that the ElecFreaks V2.0 schematic does not seem to have a 3.3V regulator.
But photos show a regulator.

There are photos of v2.2 that also seem to have a regulator.
I can not find a schematic.

I suggest that you trace the Adapter pcb that you have on your desk.
Is there a 3.3V regulator?   Is there a jumper or solder-bridge to select 3.3V / 5V.

I checked the connections and I agree with what Jean-Marc said.

Regulator = AMS1117 3.3v

The 10 ohm resistance ranges from the 3.3 volt output of the regulator to the LED pin for backlighting of the display.
(We see it on the diagram v2.0)

The capacitors around the regulator are the usual filter capacitors.
(Of the side 5 volts only)

The jumper next to the regulator serves as already said Jean-Marc to bypass (shortcircuit) the regulator and switch the power supply from 3,3 volts to 5 volts.

There are 4 of the 5 HC541s that are powered in 3.3 volts.
(For display and SD card)

The fifth HC541 (the one on top of the picture) is powered in 5 volts, this HC541 handles the signals from the touch screen and SD card MISO (SD Out).

Would not it be better to power the HC541 of the touch screen and SD card MISO (SD Out) in 3.3 volts ?
What do you think?

Thank you very much.


To add to the strange story of that shield, I found:

"TFT 3.2 inch Mega Touch LCD Expansion Board Shield IC partial pressure For arduino Mega 2560 R3"


"partial pressure" is strange; I didn't try other languages, but it may mean that the imprint is incomplete.



Maybe this leads back to the roots of this shield:


following the links of this product leads to the same schematics.

I asked Auntie Google for "tft adapter shield Arduino".

The nice thing about the Arduino World is that its based on Open Source, not only software, but also hardware. But this can have strange side-effects, such as "missing pressure" to hide the source.



Hi David, I need your help

My 7inch display with SSD1963 works fine with the modifications applied to MCUFRIEND_kbv; rotation works correctly.

It also works with my GxCTRL_SSD1963 class, except for rotation.
I have not found how to achieve Portrait mode.

I added Serial.print() output to MCUFRIEND_kbv.cpp to see the command sent for rotation.
But the commands 0x33 or 0x20 seem not to be sufficient, something seems missing.
Should I look at the scrolling support; I do not use scrolling for now.

Of course I should look for the SSD1963 specs, but maybe you can give me a hint.

Thank you



You can handle the rotations on a SSD1963 with the FLIP_Vert and FLIP_Horiz bits in reg(0x36).
Leave MX, MY alone.   Unless you want to draw a Font upside down or backwards.

The MCUFRIEND_kbv rotation code is very messy.   Controllers behave differently.   I do intend to simplify it.

Have you implemented RD yet?
I bet that most of your initialisation is setting registers to their Reset default values.
Most MIPI chips only require VCOM and Power settings.   And their default values will generally work pretty well.

If you have the ILI9806 wired to the same interface as the SSD1963,   I will add a case(0x9806) to begin() if you care to test it.



Hi David

Great, your help came very quick!

I will try this soon, after a break.

Read is next on my agenda, and of course I will look how it is done in MCUFRIEND_kbv.
Automatic support for connected controller is not high on my priority list, for this we have your library, but I intend to do a ReadReg variant for GxIO.

Thank you for your support and inspiring communication.



Here is a case for begin()
Code: [Select]

#define SUPPORT_9806
#ifdef SUPPORT_9806
    case 0x9806:
        _lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | MV_AXIS | READ_24BITS;
        // from ZinggJM
        static const uint8_t ILI9806_regValues[] PROGMEM = {
            (0xFF), 3, /* EXTC Command Set enable register*/ 0xFF, 0x98, 0x06,
            (0xBA), 1, /* SPI Interface Setting*/0xE0,
            (0xBC), 21, /* GIP 1*/0x03, 0x0F, 0x63, 0x69, 0x01, 0x01, 0x1B, 0x11, 0x70, 0x73, 0xFF, 0xFF, 0x08, 0x09, 0x05, 0x00, 0xEE, 0xE2, 0x01, 0x00, 0xC1,
            (0xBD), 8, /* GIP 2*/0x01, 0x23, 0x45, 0x67, 0x01, 0x23, 0x45, 0x67,
            (0xBE), 9, /* GIP 3*/0x00, 0x22, 0x27, 0x6A, 0xBC, 0xD8, 0x92, 0x22, 0x22,
            (0xC7), 1, /* Vcom*/0x1E,
            (0xED), 3, /* EN_volt_reg*/0x7F, 0x0F, 0x00,
            (0xC0), 3, /* Power Control 1*/0xE3, 0x0B, 0x00,
            (0xFC), 1, 0x08,
            (0xDF), 6, /* Engineering Setting*/0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
            (0xF3), 1, /* DVDD Voltage Setting*/0x74,
            (0xB4), 3, /* Display Inversion Control*/0x00, 0x00, 0x00,
            (0xF7), 1, /* 480x854*/0x81,
            (0xB1), 3, /* Frame Rate*/0x00, 0x10, 0x14,
            (0xF1), 3, /* Panel Timing Control*/0x29, 0x8A, 0x07,
            (0xF2), 4, /*Panel Timing Control*/0x40, 0xD2, 0x50, 0x28,
            (0xC1), 4, /* Power Control 2*/0x17, 0x85, 0x85, 0x20,
            (0xE0), 16, 0x00, 0x0C, 0x15, 0x0D, 0x0F, 0x0C, 0x07, 0x05, 0x07, 0x0B, 0x10, 0x10, 0x0D, 0x17, 0x0F, 0x00,
            (0xE1), 16, 0x00, 0x0D, 0x15, 0x0E, 0x10, 0x0D, 0x08, 0x06, 0x07, 0x0C, 0x11, 0x11, 0x0E, 0x17, 0x0F, 0x00,
            (0x35), 1, /*Tearing Effect ON*/0x00,
        table8_ads = ILI9806_regValues, table_size = sizeof(ILI9806_regValues);
        p16 = (int16_t *) & HEIGHT;
        *p16 = 480;
        p16 = (int16_t *) & WIDTH;
        *p16 = 854;


If the colours are inverted,  add the REV_SCREEN attribute.


Edit.  I just noticed that EXTC shared the same magic value as TFTLCD_DELAY8.
Code: [Select]

#define TFTLCD_DELAY8 0x7F   //very unlikely to be a valid MIPI register.


Mar 21, 2017, 01:38 pm Last Edit: Mar 21, 2017, 01:47 pm by ZinggJM Reason: added info
You can handle the rotations on a SSD1963 with the FLIP_Vert and FLIP_Horiz bits in reg(0x36).
Leave MX, MY alone.   Unless you want to draw a Font upside down or backwards.


If you have the ILI9806 wired to the same interface as the SSD1963,   I will add a case(0x9806) to begin() if you care to test it.

I tried to understand. FLIP_Vert and FLIP_Horiz are defined in MCUFRIEND_kbv.cpp, but not used there.
Aha - I forgot to look in the include files, there I might find the values to write to reg(0x36).
And here I learn something I was not aware of clearly so far, the value in a command (CD low) is just a register address, therefore the signal line is also called RS.

I still should consult the SSD1963 specs, sometimes to be lazy takes more time than just do it, and I might look in UTFT; UTFT takes PORTRAIT in the begin method, shows portrait mode, but window size is not correct for my SSD1963 tft. But it would also reveal how portrait can be achieved.

I do have a "frozen" wiring for my Tiky display on DUE, DuPont lines fixed with the long tail connectors on both sides, but this nearly parallel connection needs an appropriate softeare wiring, in one of my GxIO subclasses. So I can't check directly with MCUFRIEND_kbv.

Ok, maybe I just need to put the MEGA shield in between.



UTFT swaps parameter in setXY so many times, that my head is still rotating. So maybe I need to switch x and y coordinates, and reverse x0 and x1 and y0 and y1, and subtract from width and height, and...

So there are many combinations to try, to keep me busy.


If your wiring is clear,   I will write the appropriate SPECIAL.
Which AVR,  ARM are you using?


If your wiring is clear,   I will write the appropriate SPECIAL.
Which AVR,  ARM are you using?
Sorry, I just somehow go into overload. My head stopped spinning, but now I need time to search and study SSD1963 specs.

I am used to get into trouble with topology problems, and here I have two.

1. UTFT: this indicates that the display allows start and end coordinates reverted to write in reversed direction.

2. The mega shield remaps pins for the 7inch SSD1963 tft, but I have no wiring from this to my Tiky.

If you want to add software wiring to MCUFRIEND_kbv for one of my wirings for a test, this would be nice.
I will put my GxIO classes for Tiky on GitHub, but need to fix names and do  cleanup, as soon as I am out of overload. I have versions for DUE and 2 STM32 boards, and my BluePill wiring. The pin mapping is documented in the source files.

I you know the values to write to 0x36 for portrait mode of SSD1983, this would help.



I looked t your GxIO_HVGAOnDue.cpp file and your mapping is exactly the same as the Mega.   i.e. my USE_MEGA_16BIT_SHIELD

If you just give me your Due mapping for the ILI9806,  I will write the SPECIAL.


Go Up