summaryrefslogtreecommitdiff
path: root/wiki/GMSL_Configuration.wiki
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/GMSL_Configuration.wiki')
-rw-r--r--wiki/GMSL_Configuration.wiki29
1 files changed, 16 insertions, 13 deletions
diff --git a/wiki/GMSL_Configuration.wiki b/wiki/GMSL_Configuration.wiki
index f9f3426..d0f2b4b 100644
--- a/wiki/GMSL_Configuration.wiki
+++ b/wiki/GMSL_Configuration.wiki
@@ -6,7 +6,7 @@ Their configurations and operating modes are below summarized, along with some p
h2. OV10635
-*Relevant Pins and Configuration Parameters*
+h3. Relevant Pins and Configuration Parameters
|_. PIN |_. Function|
|FSIN | frame sync input|
@@ -15,7 +15,7 @@ h2. OV10635
|D [9:0]| data pins|
|SIOD-SIOC | SCCB interface|
-*VSYNC/HREF Polarities*
+h3. VSYNC/HREF Polarities
Register 0x4708 = 0x00
@@ -28,12 +28,12 @@ _The sensor datasheet does not report what bit value corresponds to what; Applic
As default value of 0x4708 register is 0x01, we may assume what is reported in timing diagrams in the sensor manual is respected with inverted pixel clock edge (rising instead of default falling).
As the serializer is configured to latch data on the falling PCLK edge, this seems correct, as timing diagram of serializer operations show data are latched on the edge opposite to the one where pixel are emitted by the sensor)
-*Format configuration*
+h3. Format configuration
0x4300 = 0x3a = UYVY components ordering
0x4605 = 0x08 = 8-bit YUV422 mode
-*Timing diagram*
+h3. Timing diagram
!GMSL_Configuration/ov10635_timings.png!
@@ -44,7 +44,7 @@ VSYNC pulses at beginning of a new sensor scanout and stays low during the whole
h2. MAX9271 Serializer
-*Relevant Pin and Configuration Parameters*
+h3. Relevant Pin and Configuration Parameters
_LCCEN_: Enable/disable local control channel pins
When LCCEN pin is high the serializer operating parameters are configured through register 0x07. Alternatively if LCCEN is low, pin 14/15/22 and 23 values are used to configure the serializer
@@ -65,7 +65,8 @@ _EDC_: Error correction enable/disable
_ES_: Specifies if data are latched on rising/falling PCLK edge. 1 = falling edge; 0 = rising edge
-*RDACM20 Configuration*
+h3. RDACM20 Configuration
+
|_. Parameter |_. Value|
|DBL | 1|
|BWS | 0|
@@ -85,7 +86,7 @@ The 24 bit encoded on the GMSL serial link are:
*Note* see Table 2 (input map) because it reports HS and VS signals in DIN-A and DIN-B but they're not part of the data sent on serial link.
-*Serial link data output*
+h3. Serial link data output
!GMSL_Configuration/IMG_20170822_214808.jpg!
From the serializer manual, same image
@@ -133,7 +134,7 @@ The above quote from the serializer manual may be interpreted simply as the conf
It is legit to assume the encoded HS/VS signals are sent recording transactions of falling and rising edges
-*Synchronism signal timings*
+h3. Synchronism signal timings
To be verified in image sensor configuration if the following constraints are respected
With DBL=1:
@@ -143,15 +144,16 @@ With DBL=1:
h2. MAX9286 De-Serializer
-*De-serializer Configuration Parameters*
+h3. De-serializer Configuration Parameters
+
+h3. general configuration
-*general configuration*
Register 0x12
|DBL | 1|
|EDC | 0|
|BWS |0 (pull down to ground)|
-*FSYNC and VSYNC signal configuration*
+h3. FSYNC and VSYNC signal configuration
The de-serializer run by default with inverted VSYNC
Register 0x0c
@@ -185,7 +187,7 @@ The previously values determinate how frame synchronization is performed
!GMSL_Configuration/fsync.png!
-*HS/VS location*/
+h3. HS/VS location
HVSRC parameter description in register 0x0c (page 66) reports that the de-serializer expects HS/VS in bit 14:15
@@ -201,7 +203,8 @@ The following image describing the input map expected by deserializer for yuv8 f
This seems pretty different from what the serializer sends on the serial link, as bit 0:21 are reserved for two 11bit pixel data word, and there is no mention of HS/VS encoding in bits 14:15 (or 16:17).
So, HS/VS are either encoded in special packets with no pixel data (something like CSI-2 short packets) or their bits part of the data sent on the serial link along with pixel data (but in that case, it seems all the 24 bits used by the serializer are actually used by two pixel data word)
-*VSYNC inversion*
+h3. VSYNC inversion
+
The deserializer is configured to run with inverted VSYNC output on CSI bus.
See below what it can possibly mean (inversion of short packet vertical synchronization codes?)