Eureka! Here at last is the uOLED-96-PROP SSD1331
Mark Swann
Posts: 124
All,
Attila at 4D was gracious enough to provide us with with the long-sought, difinitive, documentation on the core graphics module of the uOLED-96-PROP.
http://www.4dsystems.com.au/downloads/micro-OLED/uOLED-96-PROP/Docs/Pdf/SSD1331.pdf
Additionally he stated:
Post Edited (lucidman) : 11/3/2007 4:11:18 AM GMT
Attila at 4D was gracious enough to provide us with with the long-sought, difinitive, documentation on the core graphics module of the uOLED-96-PROP.
http://www.4dsystems.com.au/downloads/micro-OLED/uOLED-96-PROP/Docs/Pdf/SSD1331.pdf
Additionally he stated:
LucidmanI like to point out that we came across bugs in a similar driver IC in the older version of the OLED-96 display and we're not 100% sure those bugs have been resolved in the SSD1331. 4D is not the manufacturer of the SSD1331 and we are not in a position to offer support when it comes to directly driving the IC and any issues you may come across.
Post Edited (lucidman) : 11/3/2007 4:11:18 AM GMT
Comments
A quick review of the document ... some initial observations:
1) Bus interface type ?
2) /CS, /WR timing clarified ?
3) FR output unavailable ? Video not an option ?
Table 3 - Bus Interface selection
=====================
BS[noparse][[/noparse]3:0] Bus Interface Selection - set by 4 input pins.
0000 SPI
0100 8-bit 6800 parallel
0101 16-bit 6800 parallel
0110 8-bit 8080 parallel - I'm assuming this is the selected bus interface ?
(based on the earlier GIF timing diagram supplied by 4D)
0111 16-bit 8080 parallel
1100 9-bit 6800 parallel
1110 9-bit 8080 parallel - Could it be this ? Unlikely.
7.1.2 8080-series Parallel Interface
=======================
A low in D/C# indicates COMMAND read/write and high in D/C# indicates DATA read/write.
A rising edge of RD# input serves as a data READ latch signal while CS# is kept low.
A rising edge of WR# input serves as a data/command WRITE latch signal while CS# is kept low.
In order to match the operating frequency of display RAM with that of the microprocessor, some pipeline processing is internally performed which requires the insertion of a dummy read before the first actual display data read.
@@@@@@@@@@@@@@@@@@@@@@@@
Alternatively, E(RD#) and R/W#(WR#) can be keep stable while CS# is serve as the data/command latch signal.
@@@@@@@@@@@@@@@@@@@@@@@@
This makes sense of the timing diagrams ... I could not understand why the max time before data is guaranteed on the Data[noparse][[/noparse]7:0] bus was referenced to the falling edge of /CS. This seemed independent of the state of the /RD and /WR lines ! Now I see, internally the /CS, /RD, and /WR lines are all 'ANDed' together so that the exact order in which they are driven low or high does not really matter.....either the rising of /RD or /WR or /CS may serve to gate data in or out of the controller. This means a MUXC instruction which clears multiple pins at once could be used in the low level logic, with /WR and /CS brought low simultaneously at the same time with a single instruction.
======================================
The Frame Frequency seems to be about 116 Hz, but the FR output pin will not be available for use by the Propeller to determine when best to begin writing new data to the graphics controller chip to avoid a 'tearing effect'.
It would seem that the absence of the FR signal will limit the propeller's capacity to deliver high quality video. Thoughts ?
I agree on the need for the FR signal. If you look at the datasheet, you will see several places where it states that you can read the status, whatever that is, but the datasheet does not describe what is in the status. I am hoping that FR is included in the status, so that we can avoid the tearing. I left a question at the 4D forum regarding the contents of the status.
Lucidman
Regarding frame rate and the FR signal, here is a quote from Atilla at 4D.
Lucidman
I'm glad I wasn't the only one confused by the earlier datasheet drawings !
Lucidman