kedei 3.5 inch tft lcd display spi with touch screen manufacturer

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 successfully installed KeDei 3.5 inch 480x320 TFT LCD on a Raspberry Pi Zero with Raspbian Buster. It works nicely as text console, especially when I use lens to magnify the view. :-)

However, I want to use it for another purpose: I would like to keep the regular screen & console output at HDMI port and use the LCD as a special-purpose peripheral.

Is there any tutorial how to set up this kind of device (TFT LCD with SPI interface) either as a serial port, or some other kind of device that would allow it to be used by a single application for special prupose, such as control panel for some communication equipment?

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!

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.

I am working on simulators of point of sale devices using Arduino Uno and ATmega 2560. This application would be fine with this touch screen display as what I need is some way of simple data entry to change settings, display settings to the user, and provide a way to trigger some events.

Unfortunately when using this display with an Arduino Uno and the original KeDei TFT library, there is very little memory available for storing data due to the small amount of memory on the Arduino and the large character font array in the KeDei library in file KeDei_font.cpp. However the touch interface seems to work with the Arduino.

The ATmega 2560 has much more memory and I was planning to use an ATmega 2560 instead of an Arduino Uno however I have run into a problem with the touch interface providing incorrect touch points when using the TFT display with the ATmega 2560. I have set the jumpers on the back of the display to 2560 however I"m still seeing incorrect touch points returned.

I have cloned the Osoyoo KeDei TFT library into my GitHub repository and have been working with the library. I have made a change to the 16x16 bitmap font table const unsigned char font16_B[95][16] in file KeDei_font.cpp of the KeDei TFT library to use an 8x8 bitmap font and to also eliminate lower case letters. This change has made a significant improvement by reducing the amount of memory consumed by the KeDei TFT library.

I have since found a font with smaller, 5x7 bitmaps, so the font table is now const unsigned char font_table[59][5] which requires me to use upper case only but really improves the amount of memory I have available. I"ve also modified the library to do scaling of the font to double wide or high or to triple wide or high.

The 3.5 inch RPI lcd display TFT Capacitive Touch Screen is a display module can be applied to Raspberry pi 3 B+ Pi Zero etc. It can be used as raspberry pi x window display terminals.

The RPI LCD Display TFT Capacity Touch Screen Modules used 28 pins out of raspberry pi 40 pin. When installing the module attention to align the first leg of the raspberry pi and LCD module.

The first approach I looked into was to use some kind of compression on the bitmap font table such as run length encoding as so many entries were binary zero. I tested this approach and it did reduce the amount of memory while adding a bit of complexity. However the amount of memory saved was around 200 bytes with the simple approach I tested.

However changing the size of the table from const unsigned char font16_B[96][16] to const unsigned char font16_B[96][8] means that the characters displayed on the TFT screen will be smaller.

So there is a tradeoff between the amount of memory used and the character display size. Larger displayed characters requires more memory for the description of the glyphs.

A quick search for "8 bitmap font" finds this GitHub repository of Daniel Hepper, https://github.com/dhepper/font8x8, with an 8x8 size font and the license is Public Domain.

Using Preprocessor directives to select the font table to use and selecting a subsection of the file font8x8_basic.h from Hepper"s GitHub repository, I added the following to the KeDei TFT library.

I have forked the KeDei TFT library source code from Osoyoo"s GitHub and have begun modifications to the source. The fork is located at https://github.com/RichardChambers/driver/tree/master/KeDeiTFT

In order to support the number of buttons, I rewrote the Button class so that I could have buttons which share some data thus saving about 11 bytes per button. So this GUI with eight buttons that are using the data sharing feature saves some 77 bytes of memory, a significant saving for an Arduino.

The Button class is now derived from a ButtonShared class. The ButtonShared class is used to declare groups of related buttons which will have the same style. The ButtonShared class contains all the button mechanics and a Button object is a ButtonShared object with its own ButtonData member rather than a shared ButtonData member.

unsigned char penDownFlag; // set by successful istouch() call or when the pendown() function is called. cleared when the penup() function is called.

I had in plans to create a custom driver but I decided this is not worth my time. I"m going to "re-interface" this lcd to be supported by fbtft. I have a prototype pcb with fbtft-spi interface ready (I have to send this project to pcb prototype service).

Unfortunatly, because of my "spider-circuit" I"ve broken my lcd (I"ve made a some short