Reading display memory
I've been using an NHD-2.4-240320SF-CTXI-1 in a product for a few years now. I can write to the display using a 16-bit parallel bus without any problem. The display shows what it should. However, I've never been able to read the memory correctly. This hasn't been critical for us, but I decided to dig into it a bit today.
It appears when I write 16-bits, I read the data back in a 24-bit format. For example, if I write:
0001 fffe
I read back:
0000 08fc fcf4
It looks like RGB 565 packing:
Write (binary):
rrrrrggggggbbbbb rrrrrggggggbbbbb
Read (binary):
rrrrrXXXggggggXX bbbbbXXXrrrrrXXX ggggggXXbbbbbXXX
The X's are typically 0, but not always. Sometimes the highest order X bit in the R and B values is a 1. I'm not sure what the pattern is.
Does anyone have any ideas why I'm getting this asymmetric read/write behavior?
Thanks,
mike
-
I believe for this display the way the pixel data is stored in the controller's RAM will be 24bpp format, regardless of the format that is chosen for the writes. Changing the color depth to 16bpp reduces the amount of time it takes to write an image to the display, which is its primary benefit. However, the data is still arranged in the RAM as 24-bit, so when reading from the RAM this should be taken into consideration.
0 -
Thanks. It's nice to know I'm not crazy.
I've been over the ILI9340 manual from your site a few times, but I can't find anything that would suggest this sort of behavior is possible. Can you point me to some documentation that shows how the 16-bit input data is expanded to 24-bits before being stored in memory? Maybe there is a similar setting that will instruct the controller to squeeze the pixel data back down to 16-bits when read.
mike0
Please sign in to leave a comment.
Comments
2 comments