"Arduino UNO can provide only 50mA on 3.3V" 150mA, Mega also. May not be enough for ESP8266 tho.
I know nothing about the ESP8266. Looking at the data sheet, it certainly can draw a lot of current during TX.
We still have not received a schematic or accurate explanation of rahulmr's wiring. Life can get complicated with different logic levels and power supplies.
It looks as if you need the external power supply for the ESP8266. It seems an awful waste to drop 12V to 3.3V.
CrossRoads: "Arduino UNO can provide only 50mA on 3.3V" 150mA, Mega also. May not be enough for ESP8266 tho.
DC Current for 3.3V Pin
Mega is the same.
I ran the graphicstest_kbv sketch on an uno with a 2.4" mcufriend (marked st7789v)
The graphics appear, and scrolls and rotates and all that… however, looking in the serial monitor just prints out
ID = 0x0
Not sure what’s going on, or how to fix this. I’ve attempted to contact MCUFriend through their website, but have not heard back from them, since i ordered this on schmeeeebay, i contacted the seller, and haven’t heard from them either.
I’ve tried several libraries, some get the graphics working, but the touch doesn’t, other can’t get anything to work.
I’m seriously at a loss with this thing.
Attached is a picture of the device
Any advice on how to proceed would be phenomenal, as I’m really at a loss on this.
I have never seen “st7789v”. Please run the LCD_ID_readreg.ino sketch and copy-paste the result from the Serial terminal.
If you get a response from either Mcufriend or your Ebay vendor, you deserve a medal.
As stated, i have already tried that, and it shows me 0x0, or C0C0 depending on which “identifyer” sketch is used.
The really odd thing is, i can run the device with the 9341 drivers, but there are “some” issues.
the touch pins aren’t the same as on other boards / examples i’ve seen… on this board it appears they are:
#define YP A1
#define YM 6
#define XM A2
#define XP 7
Also, according to ramtex.dk, the st7789 has similar internal configuration and graphic rendering features as the following driver IC’s
HX8325, HX8347, HX8352, HX8353, HX8367, HX8369, ILI9340, ILI9341, ILI9163, NT39122, SPFD54126, SSD1355, ST7715, ST7628, ST7735, ST7773.
The driver IC appears to be made by Sitronix Technology, i’ve put in a request for datasheets etc from them, so hopefully that will give us some better idea of the IC, how it works etc, and we maybe able to go from there… i wasn’t able to find the device on their site, but there is listed another version (st7789S) http://www.sitronix.com.tw/en/index.html
I just find it odd, that there are so many variations of these mcufriend devices showing up everywhere, and no real rhyme or reason as to why each is almost unique in how it functions…
So currently i’m tinkering around with getting it to actually function… i can get display, and touch to function, as i said, using the ILI9341 driver, but i’ve had to change the pin assignments within sketeches for the touch to work.
Truth be told… i’m kind of stabbing at this thing in the dark, as i know very little about tft / display drivers etc…
If you need any specific information, i’ll try to get it for you.
Also, when i recieved the device, the double-sided tape that holds down the screen to the shield was lifting up, i gently lifted the screen, and replaced the tape, while doing so i did manage to write down all the numbers etc i could see…
On the ribbon:
On the Screen Itself:
Here are some serial monitor outputs from various sketches… I’ve seen that some people see C0C0 is something to do with broken solder, or trace on a pin, but i’ve not been able to locate any such issue on the board, so i’m not sure what’s going on there…
TFT Test Sketch info:
TFT LCD test
TFT size is 240x320
Unknown LCD driver chip: C0C0
I try use ILI9341 LCD driver If using the Adafruit 2.8" TFT Arduino shield, the line:
should appear in the library header (Adafruit_TFT.h).
If using the breakout board, it should NOT be #defined!
Also if using the breakout, double-check that all wiring
matches the tutorial.
Benchmark Time (microseconds)
Screen fill 1787080
Horiz/Vert Lines 220308
Rectangles (outline) 168556
Rectangles (filled) 4680132
Circles (filled) 2412900
Circles (outline) 3400776
Triangles (outline) 2469012
Triangles (filled) 2712324
Rounded rects (outline) 1113784
Rounded rects (filled) 5641876
TFT Sketch 2 Info (graphixtest_kbv)
ID = 0x0
Also… the device was cheap as all…
I got it here: www.ebay.com/itm/-/261688643631
Seller however, has automated message saying he’s away from computer whenever you try to contact them.
Still waiting on reply from MCUFriend.com i’ve sent them an email with all the information i could find on the board / lcd / ribbon, as well as image of the board… so here’s to hoping they have a clue.
After reading your earlier post, I downloaded the ST7789 data sheet and "added support" to (my private copy of) the library.
If you are not prepared to copy-paste the result from LCD_ID_readreg.ino, I will wait until there is a cooperative reader.
thought I did paste the result of LCD_ID_readreg.ino
Here's the complete result that shows up in serial monitor:
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) C0 C0 ILI9320, ILI9325, ILI9335, ... reg(0x0004) C4 85 85 52 Manufacturer ID reg(0x0009) C9 00 61 00 00 Status Register reg(0x00BF) FF 00 00 00 06 0C ILI9481 reg(0x00D0) D0 A4 HX8357 reg(0x00D2) D2 00 00 NVM Read reg(0x00D3) D3 00 00 00 ILI9341, ILI9488 reg(0x00DA) DA 85 00 RDID1 reg(0x00DB) DB 85 00 RDID2 reg(0x00DC) DC 52 00 RDID3 reg(0x00EF) EF 00 00 00 00 00 ILI9327 reg(0x00B0) F0 RGB Interface Signal Control reg(0x00B4) F4 Inversion Control reg(0x00B6) F6 00 00 00 Display Control reg(0x00B7) F7 Entry Mode Set reg(0x00F6) F6 FF FF Interface Control
Nothing else gets printed to serial monitor
Yes, you have a ST7789V controller.
I am a little surprised by the "dummy" byte in your output. e.g. C0 85 85 52 Since the sketch resets the controller in hardware, I would expect to see 0x00 with a correctly inserted shield.
Are you sure that you have not edited the sketch?
If you PM me with your email, I could email you an updated ZIP. l would hope that you could report back with the results.
per request, i've pm'd you my email address. No, i've not attempted to alter the sketch.
I have now got a 3.5" mcufriend display with an ili9481 driver as a replacement for a bad display with ili9486.
However, I see that the ili9481 is not in the list of supported displays.
But as the display is marked www.mcufriend.com, for info here are the results of a few tests.
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) 00 00 ILI9320, ILI9325, ILI9335, ... reg(0x0004) 00 00 00 00 Manufacturer ID reg(0x0009) 00 00 00 00 00 Status Register reg(0x00BF) 00 02 04 94 81 FF ILI9481 reg(0x00D0) 00 00 HX8357 reg(0x00D2) 00 01 22 NVM Read reg(0x00D3) 00 01 22 00 ILI9341, ILI9488 reg(0x00DA) 00 00 00 RDID1 reg(0x00DB) 00 00 00 RDID2 reg(0x00DC) 00 00 00 RDID3 reg(0x00EF) 00 00 00 00 00 00 ILI9327 reg(0x00B0) 00 RGB Interface Signal Control reg(0x00B4) 00 Inversion Control reg(0x00B6) 00 00 00 00 Display Control reg(0x00B7) 00 Entry Mode Set reg(0x00F6) 00 80 80 Interface Control
Testing with a modified tftbmp ( adding #include <MCUFRIEND_kbv.h>), it returns an ID of 2200.
The tftbmp is also modified to show a still image (for photos to the supplier ).
Forcing the id to 0x9341 it does show an overexposed woof.bmp image on a white background.
The image is aligned to the right, not left as on other diplays.
I have searched for an Arduino library, but have only found UTFT and libraries for Mega and STM32.
Guess I have to look deeper into the datasheet for the ili9481 to set it up for 8-bit mode.
And using TouchScreen_Calibr_kbv blindfolded on a white screen reveals through the serial output that the touch panel is working.
Other example sketches also only show a white screen.
No problem. I have had a ILI9481 write-only target for a while. So I just need some testing on a read-write display. PM me with your email, and I will email you the ZIP.
I am hoping to receive an ILI9327 read-write display soon. I will release v2.5 when I have tested ILI9327.
How portable is your Gamma_Adjust sketch? Do you have a "testcard" image to do the adjusting on?
Is it possible to get this display into serial mode? I'm trying to figure out if we have access to the IM register pins and put it into 3 or 4 wire mode so I can send it 16bit color.
My display has the ili9341 driver.
BTW, thanks for the hard work I thought the display was junk till I found this thread.
The library is designed for MCUFRIEND UNO shields.
What display do you have?
Very few have access to the IMn pins.
Which Arduino do you want to use?
For an AVR: 3-wire mode can only be done by bit-bashing.
4-wire mode can use SPI hardware and work very well. Look at Marek’s “ILI9341_due” library
I have just posted version 2.5 of the MCUFRIEND_kbv library at message #1 of this thread.
The new test sketch should illustrate features (and problems).
I would appreciate feedback for the following controllers:
ILI9335 240x320 ID=0x9335 new ----- Edit ----- ok ILI9481 320x480 ID=0x9481 new ----- Edit ---- ok LGDP4535 240x320 ID=0x4535 new Untested RM68090 240x320 ID=0x6809 new Untested S6D0139 240x320 ID=0x0139 new Untested ST7789V 240x320 ID=0x7789 new ----- Edit ---- ok
but any suggestions are welcome.
Corrected Version of 2.5 works perfectly with ST7789v!
Thanks again, thats the only way to use this display. Im so happy right now xD
With version 2.5 my ili9481 equipped display passes all tests without problems. Great.
I see the LCD_ID_readreg output has changed, here is the result:
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) 00 00 ILI9320, ILI9325, ILI9335, ... reg(0x0004) 00 00 00 00 Manufacturer ID reg(0x0009) 00 00 00 00 00 Status Register reg(0x00BF) 00 02 04 94 81 FF ILI9481, HX8357-B reg(0x00D0) 00 00 Power Control reg(0x00D2) 00 01 22 NVM Read reg(0x00D3) 00 01 22 00 ILI9341, ILI9488 reg(0x00DA) 00 00 00 RDID1 reg(0x00DB) 00 00 00 RDID2 reg(0x00DC) 00 00 00 RDID3 reg(0x00EF) 00 00 00 00 00 00 ILI9327 reg(0x00B0) 00 RGB Interface Signal Control reg(0x00B4) 00 Inversion Control reg(0x00B6) 00 00 00 00 Display Control reg(0x00B7) 00 Entry Mode Set reg(0x00F2) 00 00 33 00 00 00 00 00 00 00 00 00 Adjust Control 2 reg(0x00F6) 00 80 80 Interface Control
Thanks for the feedback.
The readreg has changed slightly. The rightmost "description" field is nothing more than a hint.
The "operational" registers tend to be the same for the "8-bit parameter" style of controllers. But the "configuration" registers vary greatly for different models and manufacturers.
e.g. the controller ID register and format varies. e.g. the "Manufacturer ID" is not always filled in.
Hi, thank you for your work with the library, it is really appreciated!
I have a ILI9335, reported ID is 0x9335. I’ve been have to run “GLUE_Demo_320x240” but screen was inverted (not color wise, but mirrored).
I edited file “MCUFRIEND_kbv.cpp”
in “begin” function, I changed the GS bit for the scan line (at line 1182, for version 2.5 of the files):
this: 0x60, 0xA700,
became : 0x60, 0x2700,
But it didn’t work. After some snooping around, I found GS gets changed in setRotation too.
so, I changed the following:
case 0x9335: // MOVING THIS A LITTLE LOWER
val ^= 0x80; //.kbv ILI9320 has NOT inverted logic on GS (MY)
val ^= 0x80; //.kbv ILI9320 has NOT inverted logic on GS (MY)
case 0x9335: // <<-- THIS IS LINE 280
… so GS won’t get XOR’ed and will be set properly.
And it worked!
I’ve attached my version, search for STHIY for my modifications. Probably you should only keep my setRotation modification.
MCUFRIEND_kbv.cpp (52.4 KB)
Thanks for the feedback. As I do not possess an ILI9335, I have to rely on users.
Please run the "graphictest_kbv" sketch. This should demonstrate every method. The GLUE demos show the typical UTFT operation. They do not exercise the hardware at all !!
Now that you have corrected the GS behaviour, all the tests should work except for the "COLOR BAND SCROLL" The whole screen will scroll when the modern controllers can scroll a variable number of rows.
Yes, as you have seen, I manipulate SS, GS, ORG and do not touch I/D or AM. This makes the setRotation() complicated but means the "normal" operations work efficiently.
I will wait until I hear from you about the "graphictest_kbv" sketch. Then I can update the "Untested" status.