Add support for Adafruit PiTFT 1.14"

[GavinHigham]

I took a stab at adding support for the "Adafruit Mini PiTFT - 135x240 Color TFT Add-on for Raspberry Pi". It took me several evenings of fiddling to even get anything on the screen, and then a few more to determine the offsets / display orientation / figure out how to implement the changes in fbcp-ili9341.

I've tested this on a Raspberry Pi Zero W using the "Hello Teapot" demo from /opt/vc/src/ with a clock divisor of 6 and didn't notice any artifacts (video here).

[juj]

Great work overall, looks like a nice addition! :)

[GavinHigham]

Thanks! I'll have a look at addressing these when I have some free time later this week. This is my first time working with one of these displays, so I'm still developing my understanding. My understanding so far is that the ST7789 is a display controller for a 240x320 display, which happens to be used for smaller displays by sort of "cropping" its memory into a smaller (possibly non-contiguous between rows?) rectangular region. The vertical scroll controls the row where it starts reading (wrapping around to the first row, depending on the total number of rows to be rendered), and then your DISPLAY_COVERED mechanism is a way to define the "crop" done in display controller memory. I was trying to find a way to apply the x/y offsets I found for this display in other libraries, which I accomplished by taking what I assumed to be the full resolution of the display controller, 240x320, and "covering" the first and last 40 rows, and the first 53 and last 52 columns, to write to the 135x240 region that is actually displayed. Does that sound right? I have my HDMI settings set for 240x135, and fbcp comes up with a 240x135 displayable resolution for the SPI display, so it gives a pixel-perfect full-screen image.

[juj]

My understanding so far is that the ST7789 is a display controller for a 240x320 display, which happens to be used for smaller displays by sort of "cropping" its memory into a smaller (possibly non-contiguous between rows?) rectangular region.

That is probably true. I had similar experiences when working on the 240x240 ST7789 display. However that does not mean that the Linux framebuffer on the Pi will need to be 240x320 in size.

your DISPLAY_COVERED mechanism is a way to define the "crop" done in display controller memory.

That is incorrect. The DISPLAY_COVERED mechanism crops away parts of the source framebuffer image. This was implemented for Freeplaytech's gaming device, where part of the display is physically obstructed by the game case.

I was trying to find a way to apply the x/y offsets I found for this display in other libraries, which I accomplished by taking what I assumed to be the full resolution of the display controller, 240x320, and "covering" the first and last 40 rows, and the first 53 and last 52 columns, to write to the 135x240 region that is actually displayed. Does that sound right? I have my HDMI settings set for 240x135, and fbcp comes up with a 240x135 displayable resolution for the SPI display, so it gives a pixel-perfect full-screen image.

If I understood correctly, in this case it does sound then like if you set

#define DISPLAY_NATIVE_COVERED_TOP_SIDE 0
#define DISPLAY_NATIVE_COVERED_BOTTOM_SIDE 0
#define DISPLAY_NATIVE_COVERED_LEFT_SIDE 0
#define DISPLAY_NATIVE_COVERED_RIGHT_SIDE 0
// (or just don't set the above at all)
// and
#define DISPLAY_NATIVE_WIDTH 135
#define DISPLAY_NATIVE_HEIGHT 240

it should give you the appropriate output size. However pay attention to this line

https://github.com/juj/fbcp-ili9341/blob/master/st7735r.cpp#L95

to make sure it gets the right offset.