There is also the thought that the 'pixel' data being 'recovered' didn't get there by accident. What of the command to write the pixel and the data structure that held the information?.It would appear to me that you are trying to use the display for additional storage, I wouldn't but that is more a matter of programming style and personal choice than some 'programming' guide or rule.Where is the 'Tipping Point"?, where storing the data in the program or in processor ram is more difficult that re-reading the graphics device ram?.Whatever it is, if not a local or program variable, the process will require the data to have local (non CG ram) storage... So now we have the additional code to read the graphics ram, the place to store it temporarily and the time to read, store and process the 'recovered' data. In my rather simplistic manner of thinking your method requires more storage and processor use than if you had used the processor ram or flash area for the data storage initially.Or is there an outstanding reason why your only access to the data if by reading the display ram?Whatever, it kind of goes against my initial training and it seems like a great deal of trouble. IMO, a poor method. Do-Able... but certainly "my last choice"

Bob

--> WA7EMS "The solution of every problem is another problem." -Johann Wolfgang von GoetheI do answer technical questions PM'd to me with whatever is in my clipboard

Docedison I don't want to use that RAM as additional memory. I've though about doing this but then it will draw weird things on the display

Indeed I could store in variables what I write to the display, but then it require up to 320*240*16 bits, that is 150 kB... Hence my need to read data back. Hopefully, I won't constantly read from that RAM, only when needed.

And I already have code to read GDDRAM, thanks to the ArduCam library author(s), the only thing missing is an useable RD pin

To avoid unnecessarily tying up an Arduino I/O pin for a capability that is rarely used.

I could agree but that shield is blocking like 6 unused pins on Arduino's 36 pins connector, so they could have used them anyway, also they wasted Arduino's pins 0 and 1, the F_* pins of that shield exists just in case I want to solder a tiny additional Flash chip on the display board. Confusion again, because they wired only 2 of those F_* pins, the 3rd one isn't wired anywhere -_-

Hello pYro, I am lazy! No I didn't do it yet, because I still haven't bought a soldering iron...

But, I'm almost sure it will work, because the guys who did the ArduCam use it to save a .bmp file from the display's GDDRAM (using a very similar display)

As for the Flash chip, I believe we need a SST25VF chip, especially the 16 Mbits version, SST25VF016B (also exist 32 and 64 Mbits versions of this chip, so in theory it could work too!), can be found on ebay for not much I would like to try, but I'm affraid I have no idea how to make it work, I can't really understand datasheets timings etc..

Those flash chips look nice and easy to use. They are fast, with an auto address counter, could be very useful in a separate circuit to speed up sprite drawing. They would be nice on the shield for simple storage also. As I'm writing an 'animation capable' library for the screen, I will definitely look into testing one out.

Regarding the RD pin:How would you connect the pins? Would you connect a digital pin on the 3.3v side or RD side of the resistor? Or maybe disconnect RD completely from 3.3v?I'm thinking maybe an NPN on the RD side to pull RD low, the 3.3v sets the high.

That resistor is only used by the RD pin, so yes I would remove it, and then 2 choices:

1- (Yellow line) Solder a wire from RD pin to pin D42 or whatever (pins D42 to D49 are unused).2 - (Red line) Solder a wire from the pad of the (now removed) resistor to pin D42 or whatever.

I prefer the second solution

But will it work... What I don't understand is, why is there a 10kohm resistor here? And why on 3.3V and not 5V? Maybe the RD pin will not support 5V from D42? I can't find anything about this in SSD1289 datasheet...

Is a pin in HIGH state as soon as it receive voltage (or current?) that is greater than 0 ?

Yes that's correct - the RD line must be wired high in serial mode (SPI) - you can't read except in one of the parallel modes. This isexplained in the datasheet in "Table 2 Pin Function Description".

From what I can see of that adapter it uses the SPI bus - if so then you can't read the graphics memory.

The SPI pins are used only by the SD card reader (on the back of the display, it's completely unrelated to the SSD1289). I believe the display use the mode "MPU Parallel 8080-series Interface" so I think no problem to use the RD pin

Ah good - the 4 highlight traces suggested SPI to me on a quick glance. If the board supports both SPI and parallel modes that could explain the decision to hard-wire the RD line (requirement for serial).

[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]