kedei 3.5 inch tft lcd display spi with touch screen price

While googling for any info about lcd controller I came across this page: http://heikki.virekunnas.fi/2015/raspberry-pi-tft/, author managed to get from manufacturer patch file for kernel sources and tested it with 4.1.y - on which lcd worked. But still LCD replace HDMI, but I want to use this screen as additional for user interaction, while the bigger on HDMI as presentation monitor.

Since, fbtft has been merged with rpi kernel, so the fb drivers (including ili9341.c) was moved to fbtft_device driver (so the author of page can"t compile latest kernel with driver+patch).

So something about hardware, which I reverse engineered by the "hard way" - "grab multimeter and run through all LCD FPC pins and shift register pins"

Now I noticed there is "9486L" which can suggest that LCD screen is controlled by ILI9486L, I found this LCD on taobao too but I can"t contact seller.

I"m pretty sure about D/C (Pin 37 on LCD) and Reset (Pin 19 on LCD) pins by looking into driver code, but I can"t identify other signals (WR/RD/CS/etc...)

[ 4.838806] input: MOSART Semi. Rapoo 2.4G Wireless Touch Desktop as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:24AE:1000.0001/input/input1

[ 4.862704] hid-generic 0003:24AE:1000.0001: input,hidraw0: USB HID v1.10 Keyboard [MOSART Semi. Rapoo 2.4G Wireless Touch Desktop ] on usb-bcm2708_usb-1.3/input0

[ 4.902783] input: MOSART Semi. Rapoo 2.4G Wireless Touch Desktop as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:24AE:1000.0002/input/input2

[ 4.926400] hid-generic 0003:24AE:1000.0002: input,hiddev0,hidraw1: USB HID v1.10 Mouse [MOSART Semi. Rapoo 2.4G Wireless Touch Desktop ] on usb-bcm2708_usb-1.3/input1

- Controller is not ILI9341/ILI9325 - those are for smaller displays (320x240, etc...), I guess this might be ILI9486/9488 because they are for 480x320 displays. But when I compared init with DS it does not fit right so LCD can have a clone of ILI9486/9488 ...

- Module use only SPI interface and two CE signals (CE0 for touch controller, CE1 for LCD shift registers - compared to others lcd modules, in KeDei module this is swapped),

I got a Raspberry Pi for my birthday and I have no idea how to set up the touchscreen. I have looked at other tutorials to set the touchscreen up but none of the ones I found support my touchscreen. Please help me figure this out I"m a complete noob to the Raspberry Pi world.

This is a modified version of the official PJRC ILI9341_t3 library (https://github.com/PaulStoffregen/ILI9341_t3) to work with KeDei Raspberry Pi displays.

And it is always a Work In Progress. Also using a lot of work from the the Raspberry Pi implementation: https://github.com/cnkz111/RaspberryPi_KeDei_35_lcd_v62

This library was created to allow extended use on the KeDei Raspberry Pi display and supports T3.5, t3.6 T4 and beyond. It also has support for other T3.x boards as well as TLC.

As we have found in several other places on the Web, this board is very much different than most of the other display boards, and it is still unclear what the underlying display controller actually is.

Your SPI communications on this board does not go directly to display but instead go to three shift registers. There are also two SPI Chip select pins, one labeled, which looks like it is for the Display and the other looks like it is for the touch controller. This is partially true.

That is if the Touch CS is low (asserted) and the other CS is high (not asserted) than the communications are processed by the XPT2046. And our updated example sketch touchpaint uses the standard teensy library https://github.com/PaulStoffregen/XPT2046_Touchscreen to process the presses.

However the SPI communications with the display are a lot different than any other I have seen. For example there are no reset pins, nor a Data/Command(DC) pin. Instead this information is encoded into the SPI data that you send to the display.

That is for each thing you want to send to the display, you typically send a 4 byte transfers. A few of these are to reset the display, some are commands and others are data. Example in a capture I did from starting up

We figured it out, as the RPI startup code, did several strange SPI transfers at the beginning, which appeared like they were directed to the XPT2046 Touch controller.

You will find that these devices (XPT2046) have a pin on them marked AUX, which on these display appear to be connected to a potential Resistor Divider made up of R1 and R2.

So if you send the byte E7 to the display with Touch CS asserted, it starts a AtoD conversion on that AUX pin, and transfer of two more zeros, will return you the AtoD value from AUX,

This library borrows some concepts and functionality from another ILI9341 library, https://github.com/KurtE/ILI9341_t3n. It also incorporates functionality from the TFT_ILI9341_ESP, https://github.com/Bodmer/TFT_ILI9341_ESP, for additional functions:

The teensy 3.6 and now 3.5 have a lot more memory than previous Teensy processors, so on these boards, I borrowed some ideas from the ILI9341_t3DMA library and added code to be able to use a logical Frame Buffer. To enable this I added a couple of API"s

In addition, this library now has some of the API"s and functionality that has been requested in a pull request. In particular it now supports, the ability to set a clipping rectangle as well as setting an origin that is used with the drawing primitives. These new API"s include:

Thanks for donating the display @Vvvsebastar . Got it now to work, uploaded first working version of code up at a backup branch https://github.com/juj/fbcp-ili9341/tree/kedei_v6_3_mpi3501 - that gets pixels showing on screen, although far from ready.

It looks like according to https://github.com/goodtft/LCD-show the display is a "MPI3501" controller. That is a new one, have not encountered this before. The implementation was done by by sniffing the data bus from the working binary driver.

Unable to find a datasheet pdf for MPI3501, so poking at the protocol in dark. Protocol commands are partially same as commands in other displays (the industry seems to have copied ad hoc standards/conventions for much of this - 0x2A & 0x2B are pixel rectangle coordinates, 0x2C is pixel submit). Color data is updated in 16bpp, and the command to adjust color mode seems to be similar to other controllers.

The display is a 3-wire display, like was observed above. Initial guess was that it would have been a 1-bit command+16-bits data interleaving framed ILI9486 (which is why the branch implemented it on top of ili9486.cpp), but that is not the case. It is effectively a 24-bits command+8-bits data interleaving framed protocol. As result, the hardware protocol is extremely wasteful, to send over one byte, it needs to be framed in a 32-bit package. This means that -75% of the bandwidth is lost from the framing (in other words, +300% overhead). Pixel data is slightly better, it is actually 16-bit/16-bit command+data framing so only incurs a 50% wastage (or +100% overhead).

Something that took two nights of debugging to figure out, is that there is a peculiar interplay of the touch controller and the LCD display in play. The two pieces are not separate, i.e. it is not possible to just initialize the display, but one must initialize both, they communicate internally somehow. Another head scratcher is that the T_CS and L_CS lines have some kind of interaction as well. After sending each 32-bit frame to the LCD display, one must do a dummy "pump" the Chip Select line of the Touch Controller to be enabled for a fraction of a microsecond (with no actual communication taking place), after which the LCD display CS line needs to be disabled likewise for a ~50ns period. That is, one cannot ignore the T_CS line if touch is not in use, but the LCD display is unable to receive/process commands if the Touch Controller is not flipped after each sent 32-bit frame. This hurts bandwidth and CPU usage, and also prevents use of DMA, because it would mean that the DMA controller should write to three data lines simultaneously in a synchronized manner, instead of just pumping bytes out the SPI MOSI bus, something that the DMA controller on the Pi cannot do (without resorting to bit banging). It is not yet certain if pixel color data writes have the same requirement as well, or if this peculiar LCD+Touch pumping is only needed for initialization and/or bus commands though.

Brief speed testing suggests that the controller can reliably handle a 33.333MHz SPI bus speed, but it was not able to do 40MHz. Because of the CS line juggling, effective bus speed remains lower, about 22mbps (22/33 ~ 67% utilization). Tallying up the above protocol framing with -75% / -50% wastage, the effective pixel bandwidth is something around 5.5mbps - 11mbps. The design choices lose around ~66%-85% of the bandwidth they could have had.

Overall with all the above hindrances accumulated, frame rates in Quake run at around 15 interlaced frames per second (~7.5fps). The hardware design of this MPI3501 is out of this world in comparison with any of the other display controllers out there. I am pondering if I should even bother polishing and merging the above branch in, or just drop it. Even if the redundant CS line pumping turns out to be avoidable for pixel data uploads, the wasteful protocol framing design will hurt performance noticeably.

When surfing for information on 3.5 ” TFT touchscreens for the Raspberry Pi,to improve the TinyLCD experience, I stumbled upon AliExpress where several shops offer a 3.5″ LCD TFT Touch Screen Display for incredible low prices.

Here my experiences with the screen: quite slow refresh, not too high contrast, crisp screen, touch works, software works but is already outdated, but considering the price this screen is well worth the money! If I compare it to the NeoSec screen it is a better deal for applications with a high contrast theme and no demand on smooth video.

So now for the test. On the sellers page an URL is placed to get the software, on a Google drive. Not a clickable url, but an image with a long filename to type over …. Oh well, I got the archive.

Update June 2016: There is now a download/information page at http://osoyoo.com/driver/rpiscreen.php. Images for more versions (mine i 2.0, latest is 6.2)  are available there. Alternative ishttp://kedei.net/raspberry/raspberry.html with Kali Ubuntu drivers too for version 3.0 and up.

The archive contains an image of Raspbian with the LCD driver installed. The image is quite current, and fit for B, B+ or 2 B. When I bought the screen an older image, build in augustus 2015,  was downloadable, the kernel is quite fresh built, early October 2015.

The image supplied is wheezy,  3.18.9-v7 #27 SMP PREEMPT Sun Oct 4 23:57:41 CST 2015 armv7l. So quite a recent system! Also the Model 1 B and B+ kernel is present, also just current wheezy.

Now the bad news: no word how these kernels were build. So we are stuck with wheezy for now until the Chinese supply a more current build, hopefully based upon jessie. Until then: be careful updating the system by holding back on kernel updates.

The system uses SPI to copy the screen contents to the LCD screen, and some GPIO’s for the touchscreen. Other GPIOs are free, and the connector construction  leaves these pins indeed accessible!