I got a 3.5 inch touchscreen tft gpio display off of amazon and the drivers it comes with are really trash and I’m getting less than 5 fps and there are scan lines going across it. This type of screen seems to have a lot of clones but could only find a handful of drivers, but they all suck too. And before anyone asks, yes I did try the fbcp-ili9341 drivers, and no they did not work.
The big problem with the ILI948x is that this chip can be connected with many different interfaces (parallel, direct SPI, SPI to parallel 8bit/16bit). Every interface needs a different driver. So the first thing is to try to get a schematic, or the source code of their driver. This will hopefully tell you how the device is connected. Then you can start to google for a suitable driver or write your own.
Now this is not trivial, I spent about a week writing my own driver for an ILI9488 3.5" touchscreen from Waveshare, because all the available ILI9488 drivers did not work.
I don’t really know why they wouldn’t put a schematic because it’s so much easier to use one. I also checked the Amazon product page and got nothing. But I saw you mentioned that I would need to know how the device is connected. Are you talking about if it’s directly sitting in top of the gpio pins, or if there are wires connected to the pins and then those wires are connected to the display? Because in this case, I am using it directly on top of the pins
What you see in the table is the interface side of the display-electronics to the Pi. You can see that it is using 4-wire SPI for the the display and also SPI for the touch. For the driver it does not play a role if the display sits on the GPIOs or not.
The problem is the other side of the interface, i.e. from the electronics to the ILI9486. The SPI-interface could be connected directly to the ILI9486 or via some SIPO (serial in, parallel out) ICs. Without a schematic, this is only guessing.
Yes, this is the first step. If you have a lot of ICs on the back of the display, I would guess that there is some serial-to-parallel conversion going on.
This could well be like the Waveshare screen I have which uses the ILI9486, but to eke out a few more frames per second, they made their own non-standard serial interface that isn’t entirely compatible with SPI, and then they connect this via some shift registers to the parallel interface on the ILI9486.
I seem to remember that the motivation for doing this is that the ILI9486’s parallel interface supports transfers with slightly higher data rates than the serial interface. However, since 16-bit values are being buffered, it introduces non-standard command values in what is supposed to be SPI. The Linux kernel driver actually caters to this kind of design and explains the situation:
One can argue that the ILI9486 is poorly suited to screens above a certain size, and certainly anything in the vicinity of half-VGA resolution, but the aim was evidently to hit a price point and have the customers discover the product’s limitations. By switching to this weird solution, they can possibly deliver 10 frames per second rather than 6 frames per second.
Some drivers, featured in certain YouTube videos, achieve a higher frame rate, but they update every other line in the display at that higher rate. The effect of this is a bit like interlaced video where the two fields are independent and, especially with panning video, exhibit a blurring or tearing effect. The argument made is that for fast-moving arcade games of a certain vintage, the viewer probably won’t notice the difference.
Anyway, all of the above applies to the weird Waveshare design, but I imagine it has been replicated in many low-cost products, so it is worth checking to see if it applies to your screen.
This is not correct. On MCU/SBC side, these displays use the standard SPI protocol. The SPI-protocol as a low-level protocol does not enforce the application level protocol though.
The waveshare screens use 16-bit commands with 16-bit command arguments and 16-bit data. This is still valid (8-bit) SPI, but it is not common on application level. There you typically use 8-bit commands, 8-bit command arguments and 16-bit data to driver the displays.
If you analyse the traffic you will see that the MSB of the commands and command-args are mostly zero, so you actually create overhead with this design. The amount of data bytes sent is the same as for the “normal” protocol.
I don’t really believe it is performance that triggered this design. This is not the Chinese was of doing things. They either build cheap, which in this case with the additional SIPOs is probably not the case, or they just copy. So my guess is that somewhere someone in China came up with this design because he/she did not know that the display also supports a direct SPI connection. And now everybody is copying this design even if it does not make sense.
Here is a discussion of the board’s design. It apparently uses the parallel interface, and although you can pretend that the board uses SPI, it actually isn’t doing so. One can discuss how close it is to SPI, of course.
I think you’re underestimating the board’s designers here. The chipset’s documentation is pretty clear about the four different interfacing options, and although one could imagine someone taking an existing design using the 8080 interface, if you’re a company like Waveshare who makes a bunch of other products to sell internationally and at least pretend to support them, you’re more likely to do the simple thing unless you have a reason to do the complicated thing.
And getting 10 fps instead of 6fps might be that reason. Combining it with tricks like this, and you can let people believe that they have something usable for some applications, whereas they would just reject the product out of hand otherwise.
But anyway, my contribution here was to make people aware of the complications with some of these boards.
I have written a CircuitPython driver for that board, and I can reassure you that I only use normal, standard, 8-bit SPI on the MCU side. I did have to hack the application-level code to get the 16 (command) / 16 (args) /16 (data) protocol working, but that part is above and independent of the transport layer which is pure standard SPI.
