It looks like I never actually mentioned that I was able to communicate with the display and draw to it. The only way it appears you can do this is by actually writing to the display RAM. You can still pick your starting and ending columns and rows and writing to the RAM still auto-increments the address pointer. I have not yet found a status byte though. Maybe I just missed it in the documentation. I’ll take a look at the old SSD1339 doc and see what you needed to do to read it there, though I doubt it will work on the new SSD1351.
Two issues I have found with the documentation for the SSD1351 are as follows.
First, it states that you can use an 8-bit color mode, though this does not seem to work at all. It still just seems to wait for two bytes for the full 16 bit color.
Second, and this actually seems like more of a hardware issue, has to do with the bits you set for the colors in 16 bit parallel mode. In section 8.3.2 (page 22) of the currently available datasheet (v0.10) for the SSD1351, it shows, for the 8 bits/Serial (which I assume to mean 8 bit parallel or serial), 65k color, that the first 5 MSBs of the first Byte being sent are for the 5-bit Red (maybe Magenta) color, then the last 3 LSBs of the first Byte and the first 3 MSBs of the second Byte combine to determine a 6-bit Green color, and finally, the last 5 LSBs of the second Byte make up the 5-bit Blue (maybe Cyan) color. This follows a standard 5-6-5 16-bit color schema. There are some anomalies it seems though. First, the red and blue seem to be switched even though I have set it to read as RGB in the “Set Re-map / Color Depth (0xA0)” command, not BGR. Second, it seems that if the first MSB of the second Byte is set (1), the display gets screwed up. It does this on two different boards.
here is a (bad) picture of the board.
http://i28.photobucket.com/albums/c206/ … 44-900.jpg
What I am displaying here is a small string and then all of the 95 standard displayable ascii characters.
Two things I feel I should mention here is that if I left CS or R/W floating instead of tying them to ground, I got unpredictable results. Also, when the board is powered up, it should be held in reset (RES = 0) for a few uS else the results again become unpredictable.