Adding Touch Support #33
Comments
|
Thanks for the report, good to hear that Elecrow works as well. Presumably it is a ILI9486 and not a ILI9486L? Unfortunately I do not have current plans to add touch support. If someone is able to contribute, that would be greatly appreciated. (If it is possible to wire and configure the touch controller+its existing driver to operate against Pi's SPI1 or SPI2, that may be an alternative to get both to operate independently) |
|
Hrm - I've had a look I have a number of waveshare clone 3.5 screens which all use the xpt2046 and ads7846 overlay as the driver for the touch panel. It is unfortunately shared using mosi for the lcd on spi0.1 and looking at the board schematic it is near impossible to cut traces and reroute to spi1 pins on the pi. i.e What might be possible is you were to to allow for the spi0 and ads7846 overlay to be loaded whilst fbcp-ili is running - why can't you use the spi0.0 hook rather than not allowing it to be bound? I wonder if I can hack at the dts for spidev and remove the 0x0 register stanza and just leave the 0x1 there that the touch needs... |
|
Good research there, thanks for posting your findings.
Unfortunately the source of fbcp-ili9341s speed comes exactly from the exclusive unshared, unmediated access to the raw SPI0 peripheral registers that can be controlled at instruction level clock cycle precision. That is what enables fbcp-ili9341 to saturate 100% of the SPI hardware bus at all times (on multicore-Pis) without any wasted idle time on the line. At that level, it is not possible to share access to the peripheral with other drivers, as a single kernel-user context switch could mean thousands to tens of thousands lost bits of transfer time. The original fbcp driver with fbtft implements an approach that is compatible with spi0.0, not sure if that architecture could be squeezed further. Implementing touch support to fbcp-ili9341 will need fine grained interleaving of display and touch controller communication in the hot loop of the SPI thread, one that is able to seamlessly juggle between the two devices at idle times when there are no bytes to send to the other device. It is doable, but achieving it without wasting bandwidth on the display it something to look at carefully, otherwise context switching could result in a surprisingly large % loss of transfer bandwidth. |
|
Any way you could map spi0.1 to spi1.0 within fbcp-ili9341 or through up a fake spi as a bitbanged implementation. The touch need not be fast; am just trying to avoid needing to port in a bunch of touch panel stuff into fbcp itself. |
|
There are unfortunately no tricks or shortcuts that I know of. The issue cannot be avoided by remapping device files, but the challenge resides in physical communication out from the hardware. Possible ways to get touch (or any other SPI device, such as an SPI-based SD card reader) working at the same time as fbcp-ili9341 are to implement coordinated touch support to fbcp-ili9341 directly so that the communication interleaves, like mentioned above; or to rewire the device to operate against SPI1 or SPI2 (fbcp-ili9341 only accesses SPI0 peripheral, and does not touch SPI1 and SPI2, unless by accidental bug), so that another driver program can independently drive the communication over SPI1 or SPI2 (but that program should make sure it stays free from touching SPI0, or it would conflict on fbcp-ili9341). To my understanding spi-bcm2708 and spi-bcm2835 drivers have been written from the perspective that they exclusively control SPI0, SPI1 and SPI2 each, so in this mode, one would probably have to modify the kernel driver modules to disable SPI0 access, and only run against SPI1 or SPI2. |
|
The current rpi 4.14 kernel overlays have an sp1-cs3 overlay that loads the spi1 bus; and I can confirm with this loaded and fbcp-ili9431 running I don't hit any conflicts. |
|
Currently looking to add the ili9486 to this project which is kinda a mashup of your approach + fbcp but has touch support https://github.com/bitbank2/BB-CP So far your driver gives the best results tho; just my use case is for fixed smart switch installs for IOT. Having said that the current fbturbo implementation works much better than fbcp does with the waveshares. fbcp is laggy as hell. The other thing as I posted is ideally I want to get these running on the sunxi-h3 boards which are MUCH nicer to work with than the original rpi's (full mainline support, proper blobless early boot seperate serial/uart header, 5v barrel jack, emmc 8gb) |
|
Hello Author I am in the process of adding support for the touchscreen to your driver I can read touchscreen values, but not concurrently with the display at the moment. If interested in adding this to your source code I can contribute to the project, Thanks, |
|
This is cool to hear. If you have the stamina and will to try to get the feature filled in, it would be of great use for many others who have been asking for touch support. It is ok to add support for only one touch device, as long as the support docs identify which touch controller it is, and it is not hardcoded to a specific display, since I think many displays reuse the same touch controller. So people who have a different display with the same XPT2046 controller would be able to try it out if it would work for their display as well. Contribution is welcome, probably the only requirement is that the feature is compartmentalized/categorized in such a way that it is easy to enable/disable conditionally from command line when not used. |
|
Guys, there is now touch support in the driver. I only hooked it into the mpi3501 driver (Kedei 6.3) now as that is all i have. Give it a look and try with others. No re-wiring, ouch! |
Maybe in your fork, but not the master repo. |
|
Dale M.: yes, juj isnt in position to test and merge back etc. Y wanna give it a go? my branch is in need of a tester. |
|
I really appreciate your hard work, @kpishere! 😄 Although I'd really enjoy testing your fork, right now I don't have the MPI3501 or XPT2046, I have the ILI9341 and STMPE811 instead. But if you got the XPT2046 to work, then that must mean it's possible to get the ILI9341 and STMPE811 working as well! I found the drivers for the STMPE in the Linux kernel: |
|
From what i see for this device, the touch controller has its own SPI interface so you should be able to use a separate driver for it. |
|
@kpishere, by own SPI interface, do you mean a seperate SPI bus? I haven't came across a circuit board that has the two controllers (ILI9341 and STMPE811) on their own seperate busses. |
|
Oh, I donno, you have the device. Some have two SPI buses, some have shared one with chip select line. If it is shared, use same approach as I did for Kedei display. If it is separate, it can be solved with configuration and two drivers. I swear, the one I looked at last night had two buses, when I look today, this other one has one SPI bus. http://galvanicloop.com/blog/post/14/setting-up-a-ili9341-display-on-the-raspberry-pi-zero |
|
juj : So, as suspected, when there is no display update, there is no sensing of the touch display. The Kedie display is no doubt with a very poor SPI data path that makes it slow. this however, especially with this driver, is OK for GUI display type stuff (no good for games, video, etc.). Most of the time, the display is 'still'. Any ideas how/where I could inject more calls to sense the touch screen? should there be a software interrupt to call a refresh of say one pixel somewhere? What do you think? I'm thinking a countdown timer somewhere that is refreshed with screen activity but times out and fires a trigger to refresh a dummy pixel somewhere about 30 times / second. |
|
Hmm, I wonder if the display really needs a pixel update command to process a touch cycle, or if any SPI command is enough? The SPI command 0x00 is a no-op command that can be sent at any time, so perhaps when there are no pixels to update, the driver could submit short series 0x00 commands to keep pumping the display. |
|
Hi, and thanks for the great driver. I am able to get the main branch driver to work perfectly using: However, I recently cloned kpishere's fork in order to try to get touch working, and am running into trouble. I used the same options as shown above. the cmake command works as expected. However, when issuing the make -j command, I get a the following output: Any help you could supply with respect to this would be greatly appreciated. Thanks! -Marc |
|
I too would like help setting it up as I managed to set up fbcp-ili9341 but then realised that it doesn't have touch support, my fault for not reading. I cloned the touch version and set up the same but on boot the screen loads up normally but without touch, waveshare 3.5"b-v2. |
|
I integrated the fork for ST7796S into the @kpishere fork. But now I'm wondering where do I need to connect the touchscreen pins to my SPI/GPIO? To have a remote chance that my touchscreen works with @kpishere fork. This my screen and im wondering where to connect the touchscreen stuff: This is currently my build order and pin schematic: |
Hi Juj;
Firstly I'd like to thank you for making this driver; I can confirm that the driver works with the Elecrow 3.5" display by using the Waveshare settings (the board seems to be just a Waveshare clone). I was wondering if you were intending to add touchscreen support in the near future, or if that is something which is on the backburner. (The Elecrow utilises the XPT2046 driver.) Thanks!
The text was updated successfully, but these errors were encountered: