3.97" 240x400 ST7793 - static/old mem when scrolling?

Other Hardware Displays
1

Hello everyone! First time here, apologies in advance for the verbosity. I did search around the forum here and while I did find some useful information I am still a little stuck on something.

So, first off I am messing with a 3.97 inch microyum TFT display, returning ID=0x7793, and am using MCUFRIEND_kbv. When running some example sketches I noticed when scrolling and when using reverse orientation that there seems to be a strip of 32px of static, and also reverse orientations are seemingly offset by this such that the screen is outside the display boundaries.

I looked at the setRotation function in the MCUFRIEND_kbv class, and on line 461 I changed NL = ((432 / 8) - 1) << 9; to NL = ((400 / 8) - 1) << 9; and reverse orientations are where they should be. I'm not really sure what this line actually does, though as I'm not really certain where WriteCmdData is writing to or what it it is writing later on line 463. I can see it calls WriteCmd and WriteData, and those are defined to write16(). But I don't know what 0x400, GS, and NL are supposed to represent here. I'm assuming that 0x400 is the memory address and GS | NL is flagging something true or false, but that's all I could figure in the few hours I was messing with it.

The static was still present though, and I noticed after running calibrate and then switching back to graphictest without a full power down, I noticed that the static actually seemed to be old/junk memory, as whatever was on the screen in the previous sketch would be the noise area. However from a fresh start it's just static.

So at first I tried changing *p16 = 400 to 432 and while this did get rid of the noise it screwed up everything else such that now the screen is too long for the display and the coordinates became skewed, which I think is because p16 is assigned the address of HEIGHT from Adafruit_GFX.h, the raw height of the display, and then *p16 changes that value... Right?

Thinking a little more on it now, the noise might have something to do with the readGRAM function? That doesn't really make sense to me though, but considering that what's in that space seems to be junk it doesn't actually look like it's setting aside more screen than there is display.

Could anyone weigh in on what the first change actually did, and what could be causing the junk? I feel like I am missing something really obvious. I suppose I don't see myself really needing to scroll if I didn't have a screen area larger than the display, and I assume that vertical scroll is for such instances. This actually makes me wonder if it's an issue with the coordinates? If I were to increase *p16 and then figure out how to get the coordinates to correspond with display size vs screen area for calibrate or anything that centers things. Is there a distinction between display size and screen area?

Thank you!
mkylman

2

The ST7793 controller is 240x432 but your panel is 240x400. The NL parameter sets the number of scan lines e.g. 432 or 400.

This is why you see a black band when you do a vertical scroll. It just means that the missing 32 rows is coming into view.

I have never owned a ST7793 and I no longer have the R61509.
From memory, I had both ST7793 and R61509 displaying correctly in all 4 rotations. But the vertical scroll will look wrong.

If you are on GitHub we can run tests. You can provide feedback.
Failing GitHub, you could post a video of graphictest_kbv.ino running on a freshly installed v2.9.8 Release.
e.g. Penguin screens.

David.

3

Ah thank you for confirming that! I had thought it was something to do with the display ram being larger than the picture area, but I didn't really understand the memory locations at first. However, finding the SiTronix datasheet with the register list and read/write procedures helped me understand better. It's kind of weird that it's a 240x432 controller yet it only seems to be used with 240x400 displays.

Also, no criticisms from me here. I just wondered why the display was spitting out gibberish at the edge? I just wondered if there was some way to get a clean wrap around by...somehow not assigning/accessing those display RAM addresses or something? Or even if I could figure out how to fill that space I'd be happier, but I can't seem to figure that out either.

It was honestly more a curiosity, more than anything, especially considering that one would most likely be scrolling an area larger than the physical screen size.

I copied in a clean 2.9.9 install from github. I did recently make an account on there as well, although I'm not really familiar with it yet.

In the meantime I just went ahead and took some not-so-great videos with my phone.
Original, reverse orientations are around 1:20

Altered(although I guess this one doesn't really matter)

4

You can set NL for 432 scan lines. And HEIGHT to 432.
This will let you write anywhere on the screen.
It should make vertical scrolling "look ok"
This controller can only scroll the whole screen.
There is no Band scroll.

You will have to ensure that you keep to the visible area.
Look for any code that reads the tft->height() (or tft->width() in Landscape modes)

If you clone or Fork the library code from GitHib please tell me. Then I will create a test Branch for you.

It is not uncommon for controllers to be "bigger" than the target panel.
e.g. RM68140 320x480 on a 272x480 panel
e.g. SSD1963 864x480 on a 800x480 panel
e.g. ST7735 132x162 on a 128x160 panel
e.g. ST7735 132x162 on a 128x128 panel

David.

5

david_prentice:
It is not uncommon for controllers to be "bigger" than the target panel.

Yeah, I was thinking too simplistically and conflating the driver and panel.

david_prentice:
You can set NL for 432 scan lines.

Oh, I hadn't thought (or figured out how) to increase NL, instead of HEIGHT. For some reason trying to change it last night I kept ending up shifted by 1 digit, but after some sleep that didn't happen.

static const uint16_t R61509V_regValues[] PROGMEM = {
...
0x0400, 0x6200, //NL=0x31 (49) i.e. 400 rows

0x62 as binary would be: 01**10 0010
I need to increase it to 0x35 so: 0110 101**0 or 0x6A

And that did it. Thank you for explaining that, David.

mkyl