Hey there,
I bought a 3.5 inches 320x480 from here
I tried various libraries, I have both the arduino uno and the arduino mega 2560, I plugged the module directly onto the the board and all I see is a white screen no matter which sketch/ library I use.
It should contain an ILI9481 controller.
It should work with MCUFRIEND_kbv library since v2.5 released on 11 January 2016.
It is possible that the controller has been changed. (this happens frequently with the Red shields)
Please run the LCD_ID_readreg sketch and paste the output from your Serial Terminal.
Hey David,
I did as you asked, here is the Serial Monitor data feed-
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)
Thanks for your report. You have a genuine Ilitek ILI9481 controller. I would expect the display Panel would be 320x480. Re-reading your link, everything looks fine.
Having said that, I was running my Blue display on an ARM board just now. And it has just gone white. So this particular Panel seems to be very sensitive to the Power settings.
Place your wrist on the bottom of your Panel. Does it seem hot?
It will be warm but should not be hot.
Hey David,
I did as you said, it does not seem to be hot now, but I recall feeling its hot in another time. Currently its just warm, also you are right, thats the resolution.
Well, if it is not hot, I guess that all the MCUFRIEND_kbv examples will work out of the box (from cold).
It does seem that the initialisatìon could be "better". I have run a Seeeduino for days. Yet a NUCLEO-F401 or a regular Uno clone goes "white" after a while.
Hey David,
What if I could create the library for it? I mean, if we have the datasheet, I can code it to work right? I did it with the 16x2 Hitachi LCD because it pissed me off it used 6 pins, so I took a shift register(74HC595 if I recall right), and programmed an entire sketch for the lcd to work fine with the shift register, meaning I converted it to I2C.
So if you want I can also send you that thing.
it would be awesome if both of us could work on a library for that TFT I got.
I am new to this platform, so its not the most convenient for me, but perheps we could skype about the code?
my email is itamar.y98@gmail.com so I would appreciate if you could contact me there, since I was stupid to take 3 subjects in this semester and a job.... so I don't have a lot of time to go on my pc.
I have a big project I am working on that uses this TFT and it would be cool if you could help me with it.
I am really not too sure about this particular Blue Uno shield.
I can run it for days on some targets. Other targets only run for minutes / hours.
I can reduce the Power via register 0xD2. Even to the extent of losing the crisp colours and good contrast. But this does not stop it overheating on some targets.
I can alter the Voltages generated via 0xD0 and VCOM values via 0xD1.
Perhaps Bodmer may have some ideas. I am sure that it is a simple configuration problem.
The library itself is very straightforward. Bodmer's library is faster than mine with an ILI9481.
david_prentice:
I can run it for days on some targets. Other targets only run for minutes / hours.
Perhaps Bodmer may have some ideas.
This is suggestive of a timing problem when writing to the display. I suspect the data is not settling for long enough before the rising edge of the write strobe ("data setup time" not being met). Due to manufacturing tolerances this setup time varies and also with temperature it changes on different display, so if the timing is marginal on one display it will be worse at temperature and on another display.
The "display off" command is 0x28 and the commonly used "Set Column Address" command is 0x2A, so only bit 2 is different thus if a 0x2A command gets interpreted by the display as 0x28 the the display will go white.
Test this theory on a screen that goes white with a the sketch that periodically sends the "display on" command 0x29.
The display tend to run quite warm as the LEDs consume about 200mA and at 5V that means 1 Watt is being dissipated on just one edge of the display, the display should tolerate this and there is not much that can be done about it. The LEDs appear to have their own current limit circuit as the current is constant at 200mA from 4.2V to 6V (on the 5V VCC line of the shield).
to an UNO, so I could see the screen is sort of initialized since the uniform white goes to all pixels in white apart from the last columb.
I really don't understand what to do next nor how to send the commands you mentioned.
I have 2 arduino Unos and one Arduino Mega2560.
Itamar_Yehezkel:
Hey there,
I have no idea what to do now..
I have on the shield itself pins D0-D7 and LCD_RST,LCD_CS,LCD_RS,LCD_WR,LCD_RD, GND, 5V and 3.3V
to an UNO, so I could see the screen is sort of initialized since the uniform white goes to all pixels in white apart from the last columb.
I really don't understand what to do next nor how to send the commands you mentioned.
I have 2 arduino Unos and one Arduino Mega2560.
I have an identical looking screen that gives an identical print out that you list in post #2 when plugged into a Mega and running David's Mcufriend_kbv library at version 2.9. This indicates that the interface connections to the display are OK as both writes (register address) and reads (returned data) are happening in this sketch.
Then running the Mcufriend_kbv example "graphictest_kbv" I find the the display correctly shows graphics.
If you go through exactly the same process (i.e run "LCD_ID_readreg", see the output in post #2, then run the "graphictest_kbv") and the display does not operate then it looks like the display has a fault.
I've setup a test sketch that produces write strobes that are too short. This does produce spurious pixels at random places on the screen. I will run for a few hours and see if I get a white screen.
I doubt if timing is a problem. A Uno is relatively slow. I can run sketches for days sometimes.
I have never seen stray pixels with a Uno or even a Nucleo. However an Xmega or Due are a lot faster for GPIO.
I am tired. I will post a test sketch tomorrow.
I will simply put in a regular test to read reg(0x0A) "get power mode" and reg(0x0F) "get diagnostic result"
If these return unusual values, e.g. Sleep, I can report to Serial.
i.e. drive bit low twice and then high. If I try this:
#define WR_STB PORTG&=~_BV(2);PORTG|=_BV(2);
i.e. drive bit low once then high I get spurious pixels appearing on the display in random places and a small part of the screen remains white (i.e "screen clear" does not clear all pixels) when I run this in an infinite loop:
void loop() {
for (int x = 5; x<475; x+=10)
{
for (int y = 0; y<315; y+=10)
{
tft.drawFastHLine(x,y,5,random(0xFFFF));
}
}
}
So for a 16 bit display the Mega can indeed generate write strobes that are too short, of course these timing results may not translate to an 8 bit interface.
I've looked more closely at the bus timings with an oscilloscope and you are right the write strobe on the UNO is well within the data sheet timings at 125ns wide, however the 16 bit Mega ILI9481 board I have does not reliably work with a 125ns pulse every 250ns for some reason.
An UNO running the kbv library and the 8 bit board that is the subject of this thread has run reliably for 2 hours now without problems or stray pixels, so it looks good to me.
Having said that it would be worth checking if your display is going into power down mode as you propose.
I just added the following lines to the graphictest_kbv sketch. But you could add it to any sketch with a Serial Terminal. I suggest that it gets called once in every loop()
uint8_t power_status = tft.readReg(0x0B);
uint8_t diag_status = tft.readReg(0x0F);
if (power_status != 0x08 || diag_status != 0x00) {
Serial.print("Power Status = 0x");
Serial.print(power_status, HEX);
Serial.print(" diag Status = 0x");
Serial.print(diag_status, HEX);
Serial.print(" at ");
Serial.println(millis() / 1000);
Serial.println("sending Display On command");
tft.pushCommand(0x29, NULL, 0);
}
I will post a complete sketch later.
It is currently running on the Blue shield mounted on a Uno clone.
Of course it will probably run ok for days now !!!
David.
Edit. Woo-hoo. The display went white when I was out on my bicycle. The Arduino + shield is drawing 300mA.
However, the diagnostic was not hit. I will let it cool down and try again. When cold, the UNO + shield takes about 150mA. i.e. the backlight is drawing about 120mA.
Looks like the display is overheating or internally "latching up".
My display takes 200mA and has run for 24 hours with no problem, the ribbon end where the LEDs and COG driver are does run quite hot (55 deg.C according to a thermocouple taped to the hotspot.) The LEDs to appear to be much brighter on that display too compared to my other TFTs.