readgram, setAddrWindow, pushColors

Hi,

Would some one please point me to or explain what these routines do in DETAIL please?

I know the first reads graphics memory, the second sets an address window but I am sure there is more to this and the last writes to graphics memory I think :o Are there some 'auto-increments' when they are called such that the next call automatically moves says a screen width of memory?

My google finds were not very useful. These are used for TFT graphics data manipulation and in MCUFRIEND_kbv ( hopefully David P may spot this)?

Thanks

tft.readGRAM(x, y + row, buf, wid, 1);


tft.setAddrWindow(x, y + row, x + wid, y + row);


tft.pushColors(buf + dx, wid - dx, 1);



//buf = refers to an array e.g. buf[480]
//wid is screen width
//dx,dy are any integer steps

Think about it. You plot a single pixel at X, Y with a colour PURPLE.

This simple operation is going to involve about 12 writes. Whether on a parallel or SPI bus.
Do it 76800 times for a typical display. That is 921600 writes just to produce a purple screen.

Most controllers allow you to set the coordinates of a rectangular window. Then you just need to write 153600 bytes to fill the whole screen. i.e. you do not need to send the X, Y for each pixel.

setAddrWindow() sets the rectangular window.
pushColors() writes a block of different pixels.

Obviously fillRect() or drawHLine() is just sending the same color to each pixel in the rectangle. Note that a line is just a thin rectangle. fillScreen() is a big rectangle.

Since you have mentioned readGRAM() it is probably my library that you are asking about. And yes, it is reading ALL the pixels in the rectangle. As opposed to readPixel() which just reads one pixel.

David.

Hi David,

Thank you again - the trick I missed was that setAddrWindow creates a continuous sequence of memory even though physically the memory may be a series of continuous ‘stripes’. Please correct me?

Just one more question - after some deep thoughts :slight_smile: I did nearly work things out, but cannot figure out the following … I am ‘writing’ to TFT in BLUE but not reading back BLUE…

If I run the following extract of code -

   tft.setRotation(1);
            tft.setTextColor(BLUE); 
            tft.setTextSize(2);
            tft.setCursor(0, 0);
            tft.println("WINDOW SCROLL   ");
            Serial.print(" BLUE is ");
            Serial.print(BLUE, HEX);
            Serial.println(" ");
            for (y = 0;  y < 16; y++ )  {
            if (y<10) Serial.print(" ");
            Serial.print(y);
            Serial.print(" ");
            tft.setAddrWindow(0, y, 480,  1);
            tft.readGRAM( 0, y, scrollbuf, 480 , 1);
            for (x = 0;  x <24; x++ )  {
            if (scrollbuf[x] > 0 ) {
            Serial.print(scrollbuf[x],HEX);        ////       either print the HEX  and a space      or an '#'
            Serial.print(" ");
           //Serial.print("#");                        ////       either print the HEX and a space         or an '#'

            }
           else {
           Serial.print("_");
           }
           }
            Serial.println(" "  );
           
           }

and I uncomment the ‘#’ print statement and comment out the HEX print statement. It prints “WINDOW SCROLL”, in BLUE at 0,0 on the TFT and then reads and prints (on Serial Monitor) out 24 pixels wide by 16 pixels deep where NON ZERO with a ‘#’ , hope that makes sense, one can see that ‘WIN’ has been read correctly from graphics memory.

ID = 0x9486
 BLUE is 1F
 0 ##___##__#####__##___##_ 
 1 ##___##__#####__##___##_ 
 2 ##___##____#____##___##_ 
 3 ##___##____#____##___##_ 
 4 ##___##____#____###__##_ 
 5 ##___##____#____###__##_ 
 6 ##_#_##____#____##_#_##_ 
 7 ##_#_##____#____##_#_##_ 
 8 ##_#_##____#____##__###_ 
 9 ##_#_##____#____##__###_ 
10 ##_#_##____#____##___##_ 
11 ##_#_##____#____##___##_ 
12 _##_##___#####__##___##_ 
13 _##_##___#####__##___##_ 
14 ________________________ 
15 ________________________

However if I comment out the ‘#’ print statement and uncomment the HEX print statement I get the following on Serial Monitor.

ID = 0x9486
 BLUE is 1F
 0 E0 1800 ___3 E0 __3 E0 1803 E0 1800 __E0 1800 ___3 E0 _ 
 1 E0 1800 ___3 E0 __3 E0 1803 E0 1800 __E0 1800 ___3 E0 _ 
 2 E0 1800 ___3 E0 ____1803 ____E0 1800 ___3 E0 _ 
 3 E0 1800 ___3 E0 ____1803 ____E0 1800 ___3 E0 _ 
 4 E0 1800 ___3 E0 ____1803 ____E0 1803 E0 __3 E0 _ 
 5 E0 1800 ___3 E0 ____1803 ____E0 1803 E0 __3 E0 _ 
 6 E0 1800 _1803 _3 E0 ____1803 ____E0 1800 _1803 _3 E0 _ 
 7 E0 1800 _1803 _3 E0 ____1803 ____E0 1800 _1803 _3 E0 _ 
 8 E0 1800 _1803 _3 E0 ____1803 ____E0 1800 __E0 1803 E0 _ 
 9 E0 1800 _1803 _3 E0 ____1803 ____E0 1800 __E0 1803 E0 _ 
10 E0 1800 _1803 _3 E0 ____1803 ____E0 1800 ___3 E0 _ 
11 E0 1800 _1803 _3 E0 ____1803 ____E0 1800 ___3 E0 _ 
12 _3 E0 _E0 1800 ___3 E0 1803 E0 1800 __E0 1800 ___3 E0 _ 
13 _3 E0 _E0 1800 ___3 E0 1803 E0 1800 __E0 1800 ___3 E0 _ 
14 ________________________ 
15 ________________________

What I was hoping to see was something like …

ID = 0x9486
 BLUE is 1F
 0 1F 1F ___1F 1F __1F 1F ........

That is I wrote in BLUE which is 1F (in HEX) and expected to read back 1F. but am reading E0 first !!! Could you please explain what’s going wrong, is there a variable size issue or bit reversal ??

Thanks - hope this was not long, tried to make it easy too explain and it became long…

I attached v2.2 of the library to the usual place.

Please run the example. Please report back with the results. It does a little diagnosis for the memory format. And tells you.

Likewise, the readpixel sketch should show what is actually in memory.

Yes, the ILI9320 will read back RED when BLUE was written if you have the BGR bit set.
No other controller does this. But as I said, my 9486 is write-only. So I have no way of knowing.

David.

Hi David, ( very quick update )

I quickly changed code to readPixel and it may be that my TFT is not readable also (this is based on last library I downloaded 5 days ago)

This sets the colour in HEX and reads the first top 12 pixels of the "W" in HEX

I am expecting to see .......

Colour is 1F readPixel = 1F 1F _____ 1F 1F __

but this is what I got ......

Will update to new library next

Thanks

ID = 0x9486
 Colour is 0  readPixel =  ____________ 
 Colour is 1  readPixel =  ____________ 
 Colour is 2  readPixel =  ____________ 
 Colour is 3  readPixel =  ____________ 
 Colour is 4  readPixel =  20 20 ______20 20 __ 
 Colour is 5  readPixel =  20 20 ______20 20 __ 
 Colour is 6  readPixel =  20 20 ______20 20 __ 
 Colour is 7  readPixel =  20 20 ______20 20 __ 
 Colour is 8  readPixel =  40 40 ______40 40 __ 
 Colour is 9  readPixel =  40 40 ______40 40 __ 
 Colour is A  readPixel =  40 40 ______40 40 __ 
 Colour is B  readPixel =  40 40 ______40 40 __ 
 Colour is C  readPixel =  60 60 ______60 60 __ 
 Colour is D  readPixel =  60 60 ______60 60 __ 
 Colour is E  readPixel =  60 60 ______60 60 __ 
 Colour is F  readPixel =  60 60 ______60 60 __ 
 Colour is 10  readPixel =  80 80 ______80 80 __ 
 Colour is 11  readPixel =  80 80 ______80 80 __ 
 Colour is 12  readPixel =  80 80 ______80 80 __ 
 Colour is 13  readPixel =  80 80 ______80 80 __ 
 Colour is 14  readPixel =  A0 A0 ______A0 A0 __ 
 Colour is 15  readPixel =  A0 A0 ______A0 A0 __ 
 Colour is 16  readPixel =  A0 A0 ______A0 A0 __ 
 Colour is 17  readPixel =  A0 A0 ______A0 A0 __ 
 Colour is 18  readPixel =  C0 C0 ______C0 C0 __ 
 Colour is 19  readPixel =  C0 C0 ______C0 C0 __ 
 Colour is 1A  readPixel =  C0 C0 ______C0 C0 __ 
 Colour is 1B  readPixel =  C0 C0 ______C0 C0 __ 
 Colour is 1C  readPixel =  E0 E0 ______E0 E0 __ 
 Colour is 1D  readPixel =  E0 E0 ______E0 E0 __ 
 Colour is 1E  readPixel =  E0 E0 ______E0 E0 __ 
 Colour is 1F  readPixel =  E0 E0 ______E0 E0 __ 
 Colour is 20  readPixel =  100 100 ______100 100 __ 
 Colour is 21  readPixel =  100 100 ______100 100 __ 
 Colour is 22  readPixel =  100 100 ______100 100 __ 
 Colour is 23  readPixel =  100 100 ______100 100 __ 
 Colour is 24  readPixel =  120 120 ______120 120 __ 
 Colour is 25  readPixel =  120 120 ______120 120 __ 
 Colour is 26  readPixel =  120 120 ______120 120 __ 
 Colour is 27  readPixel =  120 120 ______120 120 __ 
 Colour is 28  readPixel =  140 140 ______140 140 __ 
 Colour is 29  readPixel =  140 140 ______140 140 __ 
 Colour is 2A  readPixel =  140 140 ______140 140 __ 
 Colour is 2B  readPixel =  140 140 ______140 140 __ 
 Colour is 2C  readPixel =  160 160 ______160 160 __ 
 Colour is 2D  readPixel =  160 160 ______160 160 __ 
 Colour is 2E  readPixel =  160 160 ______160 160 __ 
 Colour is 2F  readPixel =  160 160 ______160 160 __ 
 Colour is 30  readPixel =  180 180 ______180 180 __ 
 Colour is 31  readPixel =  180 180 ______180 180 __ 
 Colour is 32  readPixel =  180 180 ______180 180 _

I went to some effort to produce a simple Demo that shows up readPixel() anomolies, without the User needing to know how things work.

Please download MCUFRIEND_kbv v2.2 and run the examples.

If the Software Scroll does not work, please say.

I possess several Shields but can never have every one that pops up on Ebay. I can only rely on reports from helpful readers like yourself.

David.

Hi David,

I updated to MCUfriend_kbv 2.2 from 2.1

Ran the scroll_kbv as is and then set rotation to 1 and ran again. Please see attached videos.

Apologies for quality of video, there is a protective film holding my screen together and had to get below 1M.

..... ooops please wait 10 mins, site does not allow mp4

Please run the new graphictest_kbv sketch. This will show up most problems.

Yes, the scroll_kbv sketch is interesting but different for some controllers.

Hi David,

BTW - the ‘ebay’ spec for my TFT shows Controller as ili9488, and GLUE_demo_480_320 runs perfectly on it.

Tftlcd 3.6-inch touch screen with uno r3
•3.6-inch LCD touch screen
•
•Resolution : 480x320
•Controller : ili9488
•Test code:
•ILI9327:

Output of graphicstest … but my TFT is 480 x 320, may explain Scroll_kbv results

TFT LCD test
Using Adafruit 2.8" TFT Breakout Board Pinout
TFT size is 240x320
Unknown LCD driver chip: 9486
If using the Adafruit 2.8" TFT Arduino shield, the line:
  #define USE_ADAFRUIT_SHIELD_PINOUT
should appear in the library header (Adafruit_TFT.h).
If using the breakout board, it should NOT be #defined!
Also if using the breakout, double-check that all wiring
matches the tutorial.

Output of my readpixel tests … :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: , your change in 2.2 has worked.

ID = 0x9486
 Colour is 0  readPixel =  ____________ 
 Colour is 1  readPixel =  1 1 ______1 1 __ 
 Colour is 2  readPixel =  2 2 ______2 2 __ 
 Colour is 3  readPixel =  3 3 ______3 3 __ 
 Colour is 4  readPixel =  4 4 ______4 4 __ 
 Colour is 5  readPixel =  5 5 ______5 5 __ 
 Colour is 6  readPixel =  6 6 ______6 6 __ 
 Colour is 7  readPixel =  7 7 ______7 7 __ 
 Colour is 8  readPixel =  8 8 ______8 8 __ 
 Colour is 9  readPixel =  9 9 ______9 9 __ 
 Colour is A  readPixel =  A A ______A A __ 
 Colour is B  readPixel =  B B ______B B __ 
 Colour is C  readPixel =  C C ______C C __ 
 Colour is D  readPixel =  D D ______D D __ 
 Colour is E  readPixel =  E E ______E E __ 
 Colour is F  readPixel =  F F ______F F __ 
 Colour is 10  readPixel =  10 10 ______10 10 __ 
 Colour is 11  readPixel =  11 11 ______11 11 __ 
 Colour is 12  readPixel =  12 12 ______12 12 __ 
 Colour is 13  readPixel =  13 13 ______13 13 __ 
 Colour is 14  readPixel =  14 14 ______14 14 __ 
 Colour is 15  readPixel =  15 15 ______15 15 __ 
 Colour is 16  readPixel =  16 16 ______16 16 __ 
 Colour is 17  readPixel =  17 17 ______17 17 __ 
 Colour is 18  readPixel =  18 18 ______18 18 __ 
 Colour is 19  readPixel =  19 19 ______19 19 __ 
 Colour is 1A  readPixel =  1A 1A ______1A 1A __ 
 Colour is 1B  readPixel =  1B 1B ______1B 1B __ 
 Colour is 1C  readPixel =  1C 1C ______1C 1C __ 
 Colour is 1D  readPixel =  1D 1D ______1D 1D __ 
 Colour is 1E  readPixel =  1E 1E ______1E 1E __ 
 Colour is 1F  readPixel =  1F 1F ______1F 1F __ 
 Colour is 20  readPixel =  20 20 ______20 20 __ 
 Colour is 21  readPixel =  21 21 ______21 21 __

Scroll_kbv as is in example zipped video

scroll_kbv.zip (790 KB)

Hi David

should have added Graphics_test_kbv also works PERFECTLY (also in 2.1) , Vertical scroll works, software scroll in sub window seems to be working (new in 2.2) . It is readable.

However, what I am trying to do is to scroll from BOTTOM to TOP in Landscape (Rotation = 1).

There is sufficient coding in your libraries to do everything I need, I only lack understanding of the input parameters and 'behaviour'.

Thanks again so much

I tried the "Software Scroll" of the whole screen. It is easy enough to see how to scroll a different size "subwindow" from the example. Just make the window 320x480.

Even on a Due with the data bus mapped directly to a PORT, software scrolling is slow. (I hand-wired a UNO to Due shield)

Just operate in LANDSCAPE mode. Then the hardware scrolling is in the horizontal direction. And in case you did not realise from the scroll_kbv sketch, your controller can "Vertical Scroll" a sub window.

It is intentional that there is an unscrolled top and bottom area in the demonstration.
Not all controllers can do this.

Oh, and your video is unreadable. I just observed the general movement of white and guessed that it was displaying correctly. I could not see a single number.

David.