MCUfriend_kbv not working with R61505W and R61505V LCD Driver Chip

Yes, After changing the ID to 0x9320.
I got response.

Code has given below for this.

Serial.begin(115200);
uint32_t when = millis();
// while (!Serial) ; //hangs a Leonardo until you connect a Serial
if (!Serial) delay(5000); //allow some time for Leonardo
Serial.println("Serial took " + String((millis() - when)) + "ms to start");
tft.reset(); //hardware reset
uint16_t ID = tft.readID(); //
Serial.print("ID = 0x");
Serial.println(ID, HEX);
if (ID == 0xD3D3) ID = 0x9481; // write-only shield
if(ID=0x1505) ID=0x9320;
//ID = 0x9320; // force ID
tft.begin(ID);

The Screen is displaying all colors. So only thing to check it with Bluepill.

Let me check and update you.

Hi David,

I have downloaded and install the lib from test_1505. It is working partially until I commented the following line in mcushield_friend.h file.

//#define SSD1289_JUMPERS 2

After commented this the whole test was working fine.

The other thing is:-

With ILI9340 I found some color problem. Color is not displaying correctly. for example blue display as yellow. red display as light blue.

Please check the attached zip file which contains screenshot as displayed during gfx demo.

vlcsnap-2017-09-10-18h50m21s801.zip (921 KB)

Ravi_kanchan2004:
Hi David,

I have downloaded and install the lib from test_1505. It is working partially until I commented the following line in mcushield_friend.h file.

//#define SSD1289_JUMPERS 2

After commented this the whole test was working fine.

The SSD1289 macro should not make any difference to anything unless you #define USE_SSD1289_SHIELD_UNO.
Does tft.begin(0x1505); work properly?
Are the colours correct?
Is the SoftwareScroll correct?
Note that Band Scroll moves the whole screen on a ILI9320 class of controller.

The ILI9340 is just showing "Inverted Colours". Either call tft.invertDisplay(1); at the bginning of loop() or edit MCUFRIEND_kbv.cpp

    case 0x9340:
        _lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | MV_AXIS | READ_24BITS | REV_SCREEN;
        goto common_9341;
    case 0x9341:
        _lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | MV_AXIS | READ_24BITS;
      common_9341:

I will add this to the Master Branch for the next Release. I wish that other users would report things like "Inverted Colours"

David.

All the colors on 0x1505 are displaying correct.
SoftwareScroll is working fine. but faster then Arduino.


All the thigs are working fine with ILI9320 class of controller except color.
So let me check and update you.

Please be more accurate.

  1. does tft.begin(0x1505) work 100% ? i.e. with no changes from my GitHub test_1505 branch.
  2. does tft.begin(0x9320) work 100% ? i.e. edit setup() in graphictest_kbv.ino
  3. is 0x1505 better than 0x9320 ?

Yes, of course the STM32 will be faster than a Uno.

If 0x9320 works as well as 0x1505, I will simply move the case 0x1505: to the 0x9320 block.

Did you see how I added the USE_RAVI code to the SPECIALs ?
What had you done differently?

David.

Bump. Please answer those two questions. Or ask if you don't understand.

I would like to resolve any remaining R61505 problems and close this Branch.
Then I can merge into the Master Branch for a new Release.

David.

Sorry for delay response.

During the testing I observe the given below results.in both cases: (with 0x1505 and 0x9320)
i) Graphics demo is working perfect.
ii) All the slides are working fine.
iii) Scrolling is working.
iv) color grades are displaying properly.

results are similar in both cases.

I saw USE_RAVI_KANCHAN_BLUEPILL in mcufriend_special.h file.

But I found during scroll, the font shape is going to disturb, may be possibly some optimization in code require .

and other thing I want to know that how to I can use touch.

You have an ILI9340 and a R61505U. The Software Scroll should look exactly the same i.e. yellow text moving sideways across the screen.

Band Scroll on the ILI9340 will just scroll the small Band.
Band Scroll on a R61505 (or any other ILI9320 style) will move the whole screen by 64 rows.

I am not at a PC. You should find that the TouchScreen_Calibr_new example from your test_1505 Branch should diagnose your Touch Pins, Calibrate and report to both TFT and Serial Terminal.

You should find that the TouchScreen_Calibr_native example from your test_1505 Branch should diagnose your Touch Pins, Calibrate and report to both TFT and Serial Terminal.

If you have a problem, copy-paste the Serial Terminal to your message.

Thanks very much for your feedback. It makes all the difference. (previous 9340 and 1505 users went silent)

David.

Edit. I have updated your "test_1505" Branch on GitHub. And merged your R61505U and ILI9340 changes to the Master Branch. Also added the Beta TouchScreen_Calibr_native sketch to the examples.

Hi David,

I have tested various example of touch screen. I observe the given below results.

i) touch is working fine.

ii) The return X and Y co-ordinate value is not accurate.I think reason of behind is 10 bit and 12 bit ADC .Arduino have 10bit and STM32 have 12 bit ADC.

iii) Can you please suggest me that the voltage which is I am using with LCD in current is 3.3 v (I am not using 5 v with Arduino) will change the behaviour of touch screen output.

iv) while I am not touching the Touch it is also returning some random value.

The Pin sketch has given below:-

#define XM PA2
#define YP PA1
#define XP PB14
#define YM PB15

I am using the given below touch_screen_lib:

in source code I found that LIB already have 12bit ADC aware code. But I am not understanding why accurate co-ordinate is not return while reading.So need some advise regarding this. if you know any other Lib which I can use with mcufriend_kbv please suggest me.

My apologies. The TouchScreen_Calibr_native example was not tested when I put it on your Branch.
I have just updated your "test_1505" Branch with the corrected sketch.

Note that it is not really possible to diagnose the Touch Pins on an ARM. So you will need to do it manually.

Both TouchScreen_Calibr_native and TouchScreen_Calibr_new examples should work on your STM32.

I have never tried SteveStrong's Touch library. Steve uses the Maple Core which returns the wrong ADC resolution. The STMicroelectroncs Core returns the correct 10-bit ADC result. My example should work with both Cores.

Please let me know how you get on. I am happy to test Screens plugged into proper Shield headers like the Nucleo.
I have no intention of choosing some custom SPECIAL wiring.

David.

Sorry to late reply,

I tested the ino example. but found these example have Arduino setup. one of them using UTFT lib.So not possible it to compile with STM32F.

Need again some of your help to calibrate Touch.

Thanks in advance.

The TouchScreen_Calibr_native example in the Release should work on STM32, Teensy, ..., LogicGreen

Note that you will have to diagnose your Touch pins with a Uno. You can even Calibrate with the Uno.

You must use the STM32 pin names in the TouchScreen constructor. Obviously if you use the Nucleo with ST Core, it understands pin names like 6 or A1. The Maple Core does not.

I am going out with my dog. I will test it on a STM32 later with both ST and Maple Core.

David.

Well, it works out of the box on a Nucleo and ST Core.

The Maple Core has no concept of Arduino headers and pin names. And the Serial Terminal does not work as transparently with the USB Serial as with proper Arduino boards.

So you have to make some edits to suit your BluePill:

// MCUFRIEND UNO shield shares pins with the TFT.
#if defined(ESP32)
int XP = 27, YP = 4, XM = 15, YM = 14;  //most common configuration
#elif defined(ARDUINO_GENERIC_STM32F103C)
#define A0 0
#define A4 0
#define A5 0
int XP = PA2, YP = PB0, XM = PA7, YM = PA3;  //edit for YOUR BluePill
#else
int XP = 6, YP = A1, XM = A2, YM = 7;  //most common configuration
//int XP = 7, YP = A2, XM = A1, YM = 6;  //most common configuration
#endif
...
char *Aval(int pin)
{
    static char buf[2][10], cnt;
    cnt = !cnt;
#if defined(ESP32) || defined(ARDUINO_GENERIC_STM32F103C)
    sprintf(buf[cnt], "%d", pin);
#else
    sprintf(buf[cnt], "A%d", pin - A0);
#endif
    return buf[cnt];
}
...
void setup()
{
    Serial.begin(9600);
#if defined(ARDUINO_GENERIC_STM32F103C)
    while (Serial.isConnected() == false) ;
#endif
    Serial.println(TITLE);
...

I got this result on my Serial Terminal:

TouchScreen.h GFX Calibration
Not possible to diagnose Touch pins on ARM or ESP32
ID = 0x7783

cx=915 cy=815 cz=528
cx=523 cy=797 cz=405
cx=152 cy=788 cz=218
cx=917 cy=504 cz=575
cx=153 cy=474 cz=347
cx=906 cy=168 cz=623
cx=531 cy=156 cz=545
cx=151 cy=158 cz=438
MCUFRIEND_kbv ID=0x7783  240 x 320
PORTRAIT CALIBRATION     240 x 320
x = map(p.x, LEFT=829, RT=130, 0, 240)
y = map(p.y, TOP=937, BOT=126, 0, 320)
Touch Pin Wiring XP=2 XM=7 YP=16 YM=3
LANDSCAPE CALIBRATION    320 x 240
x = map(p.y, LEFT=937, RT=126, 0, 320)
y = map(p.x, TOP=130, BOT=829, 0, 240)

Note that you have to close any Serial Terminal before you compile.
Once the program has compiled and Uploaded, it will hang until you open the Serial Terminal.

David.

@Ravi,

Please can you Upgrade to the current Release of the library.

I would like to know whether the ILI9340 and the R61505U work 100% on the Uno.
i.e with both graphictest_kbv and the TouchScreen_Calibr_native sketches.

Note that you will have to add your SPECIAL manually for your BluePill. i.e.
add the USE_RAVI_KANCHAN define and conditional code block. define USE_SPECIAL

Then test ILI9340, R61505U on the BluePill.
i.e with both graphictest_kbv and the TouchScreen_Calibr_native sketches.

Please ask if you are unsure of implementing your SPECIAL.
I can do it for you if there is a problem.

David.

Hi David,

Thank for your reply. For two days I will not available due to some personnel reason. So need two-three days time to share you result. On coming Friday I will update my lib with latest release then I will start to check result and will share you.

I will take care for SPECIAL keywords.

Thank you

Hi David,

Greeting, your New release library is working fine with modified code for USE_SPECIAL & USE_RAVI_KANCHAN_BLUEPILL. All colors, direction, scrolling is working fine. I have tested with ILI9340 & MCUfriend R61505.

I am facing problem with TouchScreen_Calibr_native sketches.
My configuration for pins has below. and I apply this change into sketch.(given details below)

#define YP PA1 // must be an analog pin
#define XM PA2 // must be an analog pin
#define YM PB15 // can be a digital pin
#define XP PB14 // can be a digital pin

My error is coming from under given codes:-


boolean diagnose_pins()
{
int i, j, value, Apins[2], Dpins[2], Values[2], found = 0;
Serial.println(F("Making all control and bus pins INPUT_PULLUP"));
Serial.println(F("Typical 30k Analog pullup with corresponding pin"));
Serial.println(F("would read low when digital is written LOW"));
Serial.println(F("e.g. reads ~25 for 300R X direction"));
Serial.println(F("e.g. reads ~30 for 500R Y direction"));
Serial.println(F(""));
for (i = A0; i < A5; i++) pinMode(i, INPUT_PULLUP);
for (i = 2; i < 10; i++) pinMode(i, INPUT_PULLUP);
for (i = A0; i < A4; i++) {
pinMode(i, INPUT_PULLUP);
for (j = 5; j < 10; j++) {
pinMode(j, OUTPUT);
digitalWrite(j, LOW);
value = analogRead(i); // ignore first reading
value = analogRead(i);
if (value < 100 && value > 0) {
showpins(i, j, value, "Testing :");
if (found < 2) {
Apins[found] = i;
Dpins[found] = j;
Values[found] = value;
}
found++;
}
pinMode(j, INPUT_PULLUP);
}
pinMode(i, INPUT_PULLUP);
}
if (found == 2) {
Serial.println(F("Diagnosing as:-"));
int idx = Values[0] < Values[1];
for (i = 0; i < 2; i++) {
showpins(Apins, Dpins_, Values*,
(Values < Values[!i]) ? "XM,XP: " : "YP,YM: ");
}
XM = Apins[!idx]; XP = Dpins[!idx]; YP = Apins[idx]; YM = Dpins[idx];
// ts = TouchScreen(XP, YP, XM, YM, 300); //re-initialise with pins*

* ts = TouchScreen_kbv(XP, YP, XM, YM, 300); //re-initialise with pins*
* return true; //success*
* }
Serial.println(F("BROKEN TOUCHSCREEN"));
return false;
}
------------------------------------------------------------------------------------------*

I don't know how to handle this part. please share me if you have any hint for this._

You can't diagnose the Touch pins on an ARM.
Do the calibration with a Uno.

Then it is simply a question of using the equivalent pins on the STM32.

You should find that the TouchScreen_Calibr_native sketch will work 100% on the Uno.
i.e. report the correct pins and calibration values for both Portrait and Landscape.

Either copy the value from the TFT screen or Copy-Paste from the Serial Terminal.

From memory, I tested this on "MY BLUEPILL" as well as on regular NUCLEO
Both with the MapleCore and the ST Core.

Life is always easier on Uno or Nucleo. Develop and test your project first. Then re-build for the BluePill.

David.

I did this test and found the same result for Pins. I found some difference results between 9340 and R61505 Touch controller. R61505 Controller touch is working smooth and in same way as I feel with professional touch screen really a nice experience. I create my own sketch program to test this. and it was working fine.

But problem with 0x9340Touch. it is generating most of the time duplicate value for touch and some time generate random value. I used delay as well but result is not satisfy. I think touch have some issue. I have checked with Arduino UNO and and STM32F.

I am attaching my sketch with it so any one can take benefit.

grf-test.ino (2.64 KB)

First off. Please format your code with ctrl-T. It takes zero effort. It makes your code readable.
Personally, I always choose spaces instead of tabs. (you can configure the formatter)
You should choose what you are happiest with. Just press ctrl-T.

I strongly recommend that you use names like TS_LEFT and TS_RIGHT for your calibration values.
I am not familiar with TouchScreen_STM. I presume it returns 12-bit ADC values.
TS_LEFT and TS_RIGHT will just be 12-bit. The map() function can produce the screen coordinate X, Y.

Please tidy your example. And attach it again.

David.

You are true, that TouchScreen_STM.h is for STM32. which have 12bit ADC. Arduino have 10bit ADC so any one can replace it with TouchScreen.h.

the new formatted ino attached with this post.

grf-test.ino (3.29 KB)