kedei 3.5 inch spi tft lcd version 3 pricelist

The scaler chip don"t accept as proper HDMI signal when this one have around 12MHz (this is a pixel clock frequency for 480x320RGB - I think the scaler have lower-limit around 20-few MHz) and this exact frequency is calculated by xrandr .

But WHY it works with hdmi_cvt, well hdmi_cvt actually make the hardware to generate 47MHz pixel clock with 4-pixels-data per one physical pixel, the scaler chip detect this and display only every 4th pixel... (so the transferred image have actually 1920x320 resolution / 4x480=1920! )

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.

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.

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!

So I just purchased a KeDei 3.5" TFT Display (v6.3) for my Raspberry Pi 3, and I have found out that the display only works with premade Raspbian / Ubuntu / Kali images. This wouldn"t be a problem, but those modified images don"t seem to work with HDMI. What I want is to be able to use HDMI with my TV/Monitor, and when I take my Pi to go, I"d like to just be able to plug the display into the Pi. I installed the drivers on Raspbian Pixel, when booting up the Pi with the KeDei display after installing the drivers, it just froze on the console. I plugged in an HDMI monitor (while the display was still plugged in) and rebooted my Pi, and it went past the console and booted to the Desktop on the HDMI monitor, but not on the LCD Display.

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.

Note: Raspberry Pi OS Bullseye branch system, since dtoverlay=vc4-kms-v3d is loaded by default, it is invalid to modify the resolution in /boot/config.txt. If you need to modify the resolution, you need to change it to dtoverlay=vc4-fkms -v3d.

3. After reboot, touch will work normally under normal circumstances. But for different resistance screens, the accuracy of using the default calibration parameters may not be very suitable.