headless Pi using small LCD with touch GUI, separate from HDMI main

[mwrich4]

Has anyone found a method for developing and using the common 3.5 inch waveshare board (LCD, touchscreen via SPI) ?

I would like to see it used as a separate device for GUI, not cloning the main screen. Any language and/or platform is fine. I think it would be worth a post a blog with a simple project if anyone has one.

I've tried looking for a way to do this with JavaFX or anything else for a while now. It doesn't need to be fast just a reliable alternate interface presenting an application that is created to look for it and run on it. "Hello world" and 2 buttons would be enough for me to see the skeleton.

Thanks

[mwrich4]

Additional thoughts.

I've written and implemented a touch LCD on a bare metal project before. There are a lot of pieces to craft and it was tedious. In an effort to avoid reinventing the wheel, I had hoped that the rich development environment of *nix would have widgets already built for these tasks.

It seems that the touch controller would already have a driver in place that would allow me to collect interaction data.

Next, I would want to find a double-buffered dot level interface to an SPI/I2C based LCD screen driver that supports the one offered by the WaveShare board.

At this point, I could use my own windowing package, but this would block me from using existing (hopefully) windowing tool-chain offerings. I'd prefer using(learning) TCL/TK or equivalent. I mentioned JavaFX above, but anything would work.

With low-level layers in place, it'd be nice to have a software touch hardware interface that is directly usable by a mature, rich windowing touch/GUI development package.

To oversimplify, it seems this should be very similar to the pieces needed to write an app for a Logitech keyboard display module. Nothing speedy, just functionality.

Mark

[mwrich4]

After some digging ...

There are a couple of notable Git projects:
1) https://github.com/notro/fbtft
2) https://github.com/juj/fbcp-ili9341

#1 mentions that it is now part of the kernel build tree.
#2 is a customized implementation similar to #1 but offers optimizations for SPI/display data bandwidth improvement.
#2 also offers it's own framebuffer copy routine to feed an image from the built-in GPU to the add-on board.
#1 requires an external module to copy GPU image data to the add-on board.

Both of these support many common LCD controller chips. Dig into the project specs to see if your display controller is included. Many of them are almost clones except for pixel dimensions, color depth, and built-in memory differences.

At this point, because I'm interested in starting with a standard Pi image, I plan to directly talk to the Framebuffer of the device driver that interfaces the controller chip for the LCD panel. This turns out to be very similar to the bare metal layers I used for projects on another MCU series.

Ultimately, I'd like to think there is a way to use a toolkit like PyQT to paint directly to the memory image associated with the small LCD hat. I prefer this because it provides a way for novices to use a library file in their project for the dedicated LCD hat and not disturb a healthy installation on a Pi. My goal is to use the LCD screen for a low bandwidth GUI presentation with touchscreen support that will remain independent of the Raspberry Linux installation choices. However, there will be trade-offs necessary for commonly reused SPI bus.

If I can plow through this I'll share a hello world sample. I was hoping to find someone who's been there already. -sigh-

PS: I changed the subject title slightly on the original post.