Support for LCD ST7789

[mores]

I currently have 240x240 LCD display ( https://www.adafruit.com/product/3787 ) working on the raspberry pi with python.

Is there any existing library/project that will allow me to control it using pi4j ?

[taartspi]

From Pi4j or the repos referenced from the pi4j web site, no. Nothing you could just load and run. If you were to consider writing the code there are other devices that may assist in the development of this one.
https://www.pi4j.com/examples/components/lcddisplay/ found in https://www.pi4j.com/examples/

and several other types of display controlled by various means on https://github.com/Pi4J/pi4j-example-devices

[mores]

I did read the website ( skimmed is more like it ! ). I don't think I saw any links to https://github.com/Pi4J/pi4j-example-devices
If a link does not exist, can it be added somewhere ?

I will look at https://github.com/Pi4J/pi4j-example-devices/tree/master/src/main/java/com/pi4j/devices/ssd1306 since that appears to be a closer fit to what I am using. I have 240x240 16-bit full color vs 128x64 monochrome.

Any suggestions on what would be a good first milestone to shoot for as I try to create a new device driver ?

[mores]

What would be the pi4j equivalent of the following python:

from board import SCK, MOSI, MISO, CE0, D24, D25
spi = busio.SPI(clock=SCK, MOSI=MOSI, MISO=MISO)

[taartspi]

First, SPI does not presently work on a Pi5, that provider work will be done in the future. The older Pi work fine with the PiGpio SPI provider.
Maybe https://github.com/Pi4J/pi4j-example-devices/blob/master/src/main/java/com/pi4j/devices/bme280/BME280DeviceSPI.java file. And the Readme in that directory explains Parms and wiring. In this device it must remain Selected during several calls. If I used the CS (chip select) for the SPI the chip select would go high between calls and the data lost Not sure if you chip has this quirk
https://github.com/Pi4J/pi4j-example-devices/blob/master/src/main/java/com/pi4j/devices/mcp3008/MCP3008.java is the more customary chip where the SPI CS is used.

I think when I looked at your chip it also supported I2C, I think that connection would be a more simple first job. Change to SPI later.
I didn't find my examples on the WEB, but sure enough they are there under Community Implementation.

[mores]

I only have the Pi5, and the current display is using a EYESPI connector ( I like plug and play ! ).
For now I think I will wait until SPI is supported on the Pi5 - added a watch to #338

At this point I will pivot and work on getting an I2C rotary encoder added to https://github.com/Pi4J/pi4j-example-devices

[hackerjimbo]

I do have some code that will drive that display. It's essentially a port of the Adafruit code to Pi4J. I can send you that if you'd like. However, as SPI isn't ready on the Pi 5 you could see if you can get hold of an earlier model (though not a zero or 1 as there are issues with the v6 architecture).

[mores]

I can send you that if you'd like.

Yes please.

[hackerjimbo]

Here you are!
ST7789.zip

[taartspi]

I see you are going to continue working on the display. I had ordered a rotary encoder and it arrive this weekend. I coded up support using the adafruit python as docs, since this HW company won't release specs on the firmware they have running on the chip.
https://github.com/Pi4J/pi4j-example-devices/blob/master/src/main/java/com/pi4j/devices/rotary_encoder/RotaryEncoderId5880I2C.java

[mores]

You beat me to it !

[mores]

My RP3 finally showed up so I went back to the SPI/ST7789.
I tried to use the ST7789 as written, but it did not work for me.

I then proceeded to log the commands and data the python script is sending when displaying a single pixel:

width: 240
height: 240
write
0: 1
write
0: 17
write
0: 58
1: 55
write
0: 54
1: 08
write
0: 42
1: 000000f0
write
0: 43
1: 00500140
write
0: 33
write
0: 19
write
0: 41
write
0: 54
1: c0
Pixel
_block
write
0: 42
1: 00780078
write
0: 43
1: 00c800c8
write
0: 44
1: f800

I then proceeded to mimic this output in the java code - still no luck.
Each time I execute the java program ( with sudo ) - the display shuts off - then my test python script no longer works and I need to reboot the pi to get it working again.

The only thing I can get working is to turn on/off the backlight.

I think I found the spec: https://www.rhydolabz.com/documents/33/ST7789.pdf

a - when the display fails to respond - is there anyway to clear/fix the device without a reboot ?
b - what is the simplest command to get to work ?
I tried:
dc.off();
spi.write(ST7789_RDDST);
byte[] status = new byte[8];
spi.read(status);
log.info("status: " + org.apache.commons.codec.binary.Hex.encodeHexString(status));
but I think that even froze the display and I needed a reboot.

[mores]

I am now able to display 180x180 pixels of the Display, at 16 bits per pixel that is 64800 bytes.

When I try to go any larger I get the following error:
2024-09-15 17:24:14,179 TRACE [PiGpioNativeImpl:1500] () [SPI::XFER] -> [0]; Serial Transfer [80000 bytes]
2024-09-15 17:24:14,181 TRACE [PiGpioNativeImpl:1508] () [SPI::XFER] <- HANDLE=0; SUCCESS=false; BYTES-READ=-84
2024-09-15 17:24:14,183 WARN [PiGpioNativeImpl:263] () PIGPIO ERROR: PI_BAD_SPI_COUNT; bad SPI count

The python code is working fine when sending 115200 bytes to the display.
Is this a bug or do I need to do something different when sending large amounts of data ?

[mores]

It looks like python breaks this into 4096 size chunks:

I think this is enough evidence to open a bug ticket in pi4j…I will work on a fix.

[mores]

utilize /sys/module/spidev/parameters/bufsiz as a parameter

[mores]

#383

[mores]

I am almost ready to mark this as done!
Here is a video that shows my test output: https://www.youtube.com/watch?v=qrLyAHqCnss

at 0:04 I start updating 1 pixel at a time ( x -> 0 to 240, y -> 0 to 240 )
it completes at 0:06
and you will see that somehow it missed 2 pixels.

While trying to debug this, I change the number of pixels written ( x -> 0 to 120, y -> 0 to 120 ) and the location/number of "dead" pixels changes.

I increased logging output and did not see any issue.
Any idea what the issue may be ( timing ? ) and how to fix it ?

[mores]

It appears the same "dead" pixels occur with the python code.

[FDelporte]

Nice progress! And very strange you have the same problem in python and java. Without diving into the problem myself, could it be the dead pixels are somewhere missed at the beginning or end of a chunk? Just a thought...

[mores]

I was thinking this issue could be at a lower level….os or hardware.
I did try to put in a millisecond delay between each pixel. Still showed up, just took a lot longer to draw.