3.5" Display Resolution vs reported resolution

I have a 3.5 inch tft/lcd display with 28 pin UNO pin configuration, on a blue PCB.

It only says '3.5" TFT LCD Shield' on the board, and accepts a micro SD card.

The display ID's itself as a "9481" with a width & height of 240 X 320.

Here is a link to the one I purchased...

Has anyone bought one of these and does yours also report the same ID and screen resolution.

I am wondering why it is supposed be 320 X 480 and only reporting 240 X 320.

I am using the MCUFriend_kbv libraries.

readID() should return 0x9481
geometry should be 320x480

Where did you get the library from?

I would expect even the oldest versions of the library to give 320x480 for ILI9481
If version is older than v2.9.3, leave IDE, delete the MCUFRIEND_kbv library folder.

Install/Upgrade MCUFRIEND_kbv library with the Library Manager to current v2.9.6.

David.

I am using the "MCUFRIEND_kbv-2.9.6" that I downloaded from your GIT.

The following code:

Serial.println(tft.width());
Serial.println(tft.height());
Serial.println(g_identifier,HEX);

Returns this:
240
320
9481

Please paste your setup() function e.g. with the statements from #2.

Do all of the examples work?

David.

I have several of these 3.5 inch TFT's purchased via AliExpress.
graphicstest_kbv reports ID = 0x9481.
resolution 320x480
they work great, I love 'em.

I've got a 3.5" display similar looking to the one in the OP and I also had a problem with a difference between the reported and the actual resolution. (actually mine looks identical, does not however claim to br a touch screen)

It turned out that attempts to get the resolution before the call to tft.begin( ID ) from the example code yielded the wrong results.

Its all here (post #4) http://forum.arduino.cc/index.php?topic=485391.0

photoncatcher:
I have several of these 3.5 inch TFT's purchased via AliExpress.
graphicstest_kbv reports ID = 0x9481.
resolution 320x480
they work great, I love 'em.

These are "OK" if you don't mind that fact that they use up most of the pins, run very hot and the backlight is not controllable (or requires a hack to the board). Further, as a shield, the pin spacing is such that they cannot be used easily on a 0.1" matrix solder board without a hack.. The price is OK though.

These are “OK” if you don’t mind that fact that they use up most of the pins, run very hot and the backlight is not controllable (or requires a hack to the board). Further, as a shield, the pin spacing is such that they cannot be used easily on a 0.1" matrix solder board without a hack… The price is OK though.

Indeed I had to cut a rectangular hole in such a matrix soldering board to fit part of the female pin header supporting my 3.5 inch 320x480 TFT display. The result is shown in the picture. I am measuring 10 temperatures in floor heatiung loops with DS18B20 sensors that, fortunately, need only one wire (one-bus protocol - great stuff). I am quite happy although I want to communicate via i2c and only pin A5 is left free by the TFT - need A4!

320x480_3-5_inch_TFT_working.jpg

God invented Shields. So that you can plug the display straight into a Uno.

I have described how to modify the shield to access A4. This gives you I2C bus.
If you are not using the microSD, you have D10-D13
I suggest that you always leave D0-D1 for Serial comms through the USB cable.
The Uno clones with SMD AVR have got A6, A7 pins.

Although these display shields use most of the pins, they are still practical for many projects.

Sometimes I put Arduino headers on matrix protoboard. You need to crank the pins by 0.05" because the D8-D13 header is not on an 0.1" grid.

Recently, I just buy a green Protoshield pcb which already has the correct footprint for the Arduino headers. Then mount a STM32 or ESP32 module on the matrix. This is easier than cranking the pins of a stackable 8-pin header.

David.

I'm pleased that this thread now provides the opportunity to ask about pin re-assignment, for example to free up some analog pins and use instead pins which would have been used by the SD card (assuming of course the SD card is not required for the project) and also that the shield is attached by jumper wires and not directly inserted into the host Uno etc.

I understood from a previous thread here that the pin definitions in the constructor:

MCUFRIEND_kbv tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD, LCD_RESET);

are simply "dummy" definitions.

I had a look around and found that I could hack the library file mcufriend_shield.h to achieve this, but I am not sure that there is not a nicer way of achieving the same thing.

6v6gt:
....These are "OK" if you don't mind that fact that they use up most of the pins, run very hot and the backlight is not controllable (or requires a hack to the board).......

My nameless 3.5" TFT's do not get hot. I Also have a 3.95" 320x480 MCU Friend TFT display that does not get hot either (it has a dsiappontingly weird controller, though). I recently bought via Aliexpress a 2.4 inch TFt that gets awfully warm after half an hour off operation while a similar fomat TFT from another source (Adafruit) stays cool. Could energy efficiency be manufacturer dependent ?

Most heat comes from the backlight LEDs.
The actual TFT controller does not take much current even with high Frame rates.

The Mcufriend shields tend to supply the backlight via an on-pcb 3.3V regulator but are unlikely to put any extra series limit resistor. So if the panel light was designed for 2.8V or for PWM control, you get a large current.

It is similar with 16x2 and 20x4 modules. Some have onboard series resistors. Others do not.
Just observe your USB current. You can buy plug-in USB current monitors but a DMM is more accurate.

All the ILI9481 panels that I have seen get hot.
Other panels run cool. Some 2.4" panels get warm.

What is your weird controller? I like a challenge.

David.

david_prentice:
...... What is your weird controller? I like a challenge......

Hi David, I bought in December 2015 a mcufriend 3.95 TFT shield for the Uno. When it arrived the glass was broken. I filed for a replacement but got a refund instead. This display - albeit damaged - doer run the graphicstest_kbv correctly and completely. It has a ILI9488 controller (ID=0x9488)

One year later I decided to try again. I ordered again a 3.95 TFT mcufriend Uno shield. This one arrived undamaged. However, in landscape rotation mode it performs graphictest_kbv fine, while in portrait mode the text is mirror image. See picture. The controller of this device (the ''weird' device) is reported to be a ILI6814 (ID=0x6814).
That's it in a nutshell. I can use the 6814 display in landscape but not in portrait orientation.

Here is the picture of the two 3.95 displays running graphisctest_kbv. The 6814 is the ‘weirdo’

I am gobsmacked. I post on this site regularly. Surely you would have reported the problem immediately.

It is always wise to check the Library Manager for Updates. Current Release is v2.9.6
Do not install Beta versions unless there is a good reason.

Life is much easier when you post screenshots of a known program. e.g. a BLUE BAND screen and a GREEN BAND screen. But an "Adafruit Results" screen gives me version number, speeds, size, ID, and a pretty good idea what Arduino it is running on.

I do not own a readable RM68140 screen. I can only rely on reports from users.
Seriously. Correcting mirror is trivial. But only when I get a clear report (or video).

David.

Hi David, now it is me who is gobsmacked ! This 0x6814 mcufriend.com 3.95 TFY display (aka 'weird) I reported on yesterday has been haunting me for 6 months or so. Running graphisctest_kbv it displayed normal text in portrait orientation while mirrored text in landscape.

Now I did all the testing of 'weirdo' on a prototype board of my test bench (see Arduino test bench with a 3.5 inch TFT displaying in analog fashion – thesolaruniverse

The test bench has a 3.5 inch ILI 9481 controller and works perfect.

Back to the prototype board: yesterday I removed one of the the female pin headers (the one that fits the pins LCD_D2-LCD_D3-LCD_D4-LCD_D5-LCD_D6-LCD-D7) and replaced it for a new and hopefullybetter one (the soldering points had come loose). Next I tested the repaired prototype board with my 3.5 inch ILI 89481 and with graphicstest_kbv - worked perfect. Next I took a deep breadth and mounted the 3.95 inch mcufriend (aka 'weirdo'). All tests perfect. That left me gobsmacked, I can tell you.

I never cease to be amazed. God invented Shields and they were good.

One Shield plugged into a Uno clone is cheap, neat and tidy. The Uno clones often have holes for extra headers or connectors. The whole construction is mechanically robust and electrically reliable.

When a ready-made Shield is not available, I make one with a Protoshield pcb or regular Proto matrix board.
So I can mount any external electronics and plug this "shield" into a standard Arduino, Nucleo, FRDM, LPC, ... board.

Likewise, I add Arduino headers to Xmega, STM32, Teensy, ... modules. So the same shields can be swapped from different targets.

So I look at your website. Your technique is ideal for an STM32 BluePill. It just seems pointless for a Nano. Especiially when Uno clones are so cheap. The cost of protoboard, header sockets, wire, ... is probably more expensive.

Anyway, I am pleased that your RM68140 is working 100% now. If you do have a problem, please describe or post photo of the standard example.

David.