Please try 0x9341, 0x9338, 0x9302, 0x7789
With luck, one might match your controller. I suspect you will get inverted colours with most of them.
Yes, you have chosen a good screen to photograph. When you find the "best" ID match, post another photo.
David.
0x9341 white screen
0x9338, 0x9302, 0x7789 now the text is properly oriented but with inverted colours (identity mapping)
Don't worry about the inverted colours. Just add this line to the start of loop()
tft.invertDisplay(1);
Just watch the scrolling.
Does the screen do Vertical Scroll, Band Scroll, Software Scroll?
If none of them Software Scroll, please say what the problem is i.e. readPixel()= ????
David.
David thank you so much for your assistance.
Now it seems perfect text orientation, alignment and colours are OK, Vertical Scroll, Band Scroll, Software Scroll works fine as well. The next step will be touch screen test.
Viliam
So would 0x9338 be the "best" ID ?
If you tell me, I can add your controller with correct attributes. Then it will work 100% via readID().
I guess that your shop will be selling this "stone" display to other customers.
DAvid.
It seems that each of ID 0x9338, 0x9302, 0x7789 gives the equal good results.
Another interesting thing is TouchScreen_Calibr_kbv brings white screen despite of changed ID to the correct value.
You are absolutely right probability that the "stone" was the last in line approaching zero, proper ID helps another people.
Viliam
0x9338, 7789 mght give correct Software Scroll.
I would expect 0x9302 to give a readPixel() error.
Please confirm this.
Then we can see about the Touchscreen. Have you identified XM, XP, YM, YP pins correctly?
David.
Correct, 0x9338, 0x7789 give readPixel() value "BGR" against what 0x9302 gives value "0xFC".
Regarding XM, XP, YM, YP pins TouchScreen_Calibr_kbv talking about UNO shield sharing pins with the TFT
ST7789V but I am not sure if my TFT shield exactly uses mentioned ID/controler and following assignment
is correct: YP A2, YM 7, XM A1, XP 6.
Viliam
David,
i've been trying to load some UTFT created RGB565 raw images on my SSD1963, i studied the whole drawbmp example, though the code is somewhat complex for my needs since it covers bmps of different formats.
so right now i try to read a buffer directly and pushColor it to the tft. is this the way to do it? right now all i get on the screen is some purplish colors while it should be a really dark grey (27,27,27). the bytes in the file are correct as their 16bit value is 0x18C3
this is a test code so i don't handle any misaligned buffers etc. my tft size is 480x272 so i try to load a line length buffer at a time.
void loadRaw(char *nm, int x, int y, int w, int h, int bufferSize){
File rawFile;
rawFile = SD.open(nm);
bool first = true;
uint16_t lcdbuffer[bufferSize];
//if ((x + w) >= tft.width()) w = tft.width() - x;
//if ((y + h) >= tft.height()) h = tft.height() - y;
int numBlocks = (w*h)/bufferSize;
int leftoverPixels = (w*h)%numBlocks;
tft.setAddrWindow(0, 0, tft.width() - 1, tft.height() - 1);
for (int i=0; i<numBlocks; i++) {
rawFile.read(lcdbuffer, bufferSize);
tft.pushColors(lcdbuffer, i, first);
first = false;
}
rawFile.close();
}
and i call it like this:
loadRaw("main/main.raw", 0, 0, 480, 272, 480);
apparently i don't know how pushColors works, even though i got a hunch about how setAddrWindow works (it just sets the bounds where pushColors takes place?)
so are there any hints how to make this work? i can supply the .raw file if needed for testing... this is what i get after running it (i set the color to red before loading so i can clearly see the loaded lines)
thank you!
I have updated the Beta on GitHub
If anyone knows a reliable supplier of a 0x1511 display, please let me know.
I would like to buy a 0x1511 display.
David.
void loadRaw(char *nm, int x, int y, int w, int h, int bufferSize){
File rawFile;
rawFile = SD.open(nm);
bool first = true;
uint16_t lcdbuffer[bufferSize];
int numBlocks = (w*h)/bufferSize;
int leftoverPixels = (w*h)%numBlocks;
tft.setAddrWindow(x, y, x + w - 1, y + h - 1); //only you know your dimensions
for (int i=0; i<numBlocks; i++) {
rawFile.read(lcdbuffer, bufferSize);
tft.pushColors(lcdbuffer, bufferSize, first);
first = false;
}
rawFile.read(lcdbuffer, leftoverPixels);
tft.pushColors(lcdbuffer, leftoverPixels, first);
rawFile.close();
}
You must check whether the File.read() function can read uint16_t or whether it expects bytes.
You must also check whether rawFile is not NULL from the open().
Personally, I would use a different loop structure.
David.
Hi, this library is suitable for this 3.97 display?
It looks like a 240x400 display. At 3.97" the pixels will be visible.
A 320x480 3.5" display will have a higher resolution.
Yes, I am 99% confident that the 240x400 is already supported:
ILI9326, ILI9327, R61509, ST7793, SPFD5420
Likewise, I already support many 320x480 controllers.
David.
Okay, but I can not find 3.5 inch display. This 3.6 inch better than 3.97?
It will work on the Arduino Mega?
Look at the main photo in your Ebay link.
It shows a UTFT sketch running on a 320x480 display on the left.
It shows a 240x400 screen on the bottom right.
Now look at the other five photos in the group. They all show a 240x400 display.
Now look at the text.
Tftlcd 3.6-inch touch screen with uno r3
3.6-inch LCD touch screen
Resolution : 480x320
Controller : ili9488
Test code:
ILI9327:
There are several Ebay and AliExpress vendors that use exactly the same mendacious description.
I would not trust any vendor that lies like this.
Find a vendor that has consistent information. e.g. photos of a screen of the correct shape.
Ask on this site. You may find a customer that can recommend your vendor.
Be wary of the "Positive feedback" from Ebay. Never believe the "customer rating" from Aliexpress.
David.
David you were right, it was a uint16_t read problem. i also had a mistake about the "remaining pixels" so it's now all fixed.
So if anyone has an up and running sdFat and wants to load RAW images created from the UTFT tool (or any other online RGB565 conversion tool) here is my function to do it:
void loadRaw(char *nm, int x, int y, int w, int h, int bufferSize){
File rawFile = SD.open(nm);
if(rawFile){
bool first = true;
if (bufferSize>w*h) bufferSize = w*h; //clamp buffer size if bigger than total pixels
int numBlocks = (w*h)/bufferSize; //calculate number of blocks
int leftoverPixels = (w*h)%(numBlocks*bufferSize); //calculate remaining pixels to read
byte lcdbuffer[2*bufferSize];
tft.setAddrWindow(x, y, x+w-1, y+h-1); //set action area
for (int i=0; i<numBlocks; i++) { //loop trough number of blocks
rawFile.read(lcdbuffer, 2*bufferSize);
tft.pushColors(lcdbuffer, bufferSize, first);
first = false;
}
rawFile.read(lcdbuffer, 2*leftoverPixels); //read and...
tft.pushColors(lcdbuffer, leftoverPixels, first); //...write rest of pixels
rawFile.close();
}
}
and you can easily call it like this:
loadRaw("patchEdit/spill9off.raw", 240, 100, 70, 27, 16);
arguments are in the order: filename, X and Y coords to draw bitmap, width and height of bitmap, buffer size (number of pixels). buffer size can be set to do the trick between small available memory and big available memory (DUE beasts) 
for example, a 480x272 raw file loads on my screen (hardware SPI and DUE) in 430ms when buffer size is 960, but in just 250 ms when buffer size is 3840 (twice as fast!) always think about your free memory when loading files
Vangelis
david_prentice:
You have a R61581 which has a Software Reset command. So you do not need the hardware LCD_RESET pin.
snip off LCD_RESET pin (A4). Solder a 10k pullup between the top of the snipped pin and 5V pin.
You can use A4, A5 for I2C bus
You can use D10-D13 for SPI bus (if you do not use the microSD)
If you have a TQFP-32 mcu, you also have A6, A7 Analog pins.
In practice, you have to choose between I2C or SPI. If you want more than one SPI slave, you have to use A4, A5 pins for Chip-Selects. The Library will still shake the A4 pin but only at begin() or reset(). So you should call tft.begin() before Wire.begin()
The Uno clones with SMD give you a very good platform.
David.
Thanks! Is there a way to turn off backlight or put the entire TFT to sleep (to be awaken by touch)?
Most of the Uno shields Use:
No. You would need to cut the pcb trace to the LEDs. Hand-wire a transistor or MOSFET to switch the 5V line.
You can send the controller to sleep, saving 20mA or so.
If you could switch the Backlight, you would save 100mA-300mA.
Arduinos are not intended for low-power operation. TFT backlights are power hungry.
David.
david_prentice:
I have no idea what the WeMos D1 does or what pins it has available.The TFT uses 8 pins for its data bus and 5 control pins. You don't have many spare pins on a Uno.
Yes, you can rearrange the pins on a Uno. Just add your custom wiring to the mcufriend_special.h file. You can see how this is done for different hardware e.g. Due, Zero, Xmega, Teensy3.2, ...
If you have enough fingers and toes you should be able to see how practical this might be on your strange hardware.
David.
I spent part of the weekend to figure this out, but I struggle to understand the variables in the special.h file and I don't see how this library is called from the MCUFRIEND_kbv.cpp...?
I know I need to define the MCU somewhere. It's found in the ESP8266 package and is called with
#ifdef ARDUINO_ESP8266_WEMOS_D1MINI
There is a nice overview of the board here: https://www.youtube.com/watch?v=IQVKGAU8jcA
I think we should be able to remap A1, A2 and A3 to 3 of the 4 remaining digital pins, and then attach A4/RST to the RST of the MCU board...
Could you give me some tips regarding this?
Thanks in advance, really appreciate it!
Well, it looks fun. I can buy this from Amazon UK for £10
or this from UK Ebay seller for £9
I might just as well buy one for myself.
If there are ports and data direction registers, it should be straightforward to support it. I just want direct access to the pins. I really do not want to use digitalWrite().
It is probably easier for me to buy the WeMos or LinkNode and implement it myself.
David.
p.s. if A1-A3 pins are not available, you can't plug the Shield into the WeMos board. There is little point in messing with a shield that can't be plugged in. (modern controllers can work without the LCD_RESET pin)
