OV9712 CMOS based JZ4775 debug (i)

A few days ago in the JZ4775 platform (LK3.0 core) Toss ov9712coms. Make notes, on the one hand, on the other hand, share to the needs of users reference.

1. Problems encountered during the debugging process:

The following is an overview of the main issues encountered during the debugging process:

1-1. DVP interface: The official hardware reference schematic is 10 data line DVP, and this side of the hardware is 8 data line DVP. And the official datasheet did not find a register for the DVP configuration. OV has a lot of things to keep, and some register data manuals are written to be reserved,
But the sample code that comes from it is configured. It was later verified that the sample code it provided was support for 8bit DVP; 1-2. SCCB Communication failure: SCCB-compliant IIC protocol, so this side directly through the IIC bus operation. The reason why the SCCB communication failed, my side mainly because OV9712 SCCB operation before MCLK, and MCLK is by the CIM (CAMERA Controller)
provided. The MCLK clock of the CIM output on this side is controlled, enabling the output to be MCLK when open. The MCLK output is enabled by the SCCB operation OV9712. Basically, you need to perform the MCLK output before the CMOS operation, such as Gokovi GC0308; 1-3. It is difficult to determine whether the correct plot: The OV9712 output here is WXGA (1280x800), and the hardware is new cloth, no lens zoom, and only 2.8 inch screen (resolution of the photo), direct overlay Although the hand on the CMOS to shake LCD reaction, But can not be used as the basis for the correct figure, and the DVP interface shield off the lower two bits, the image of the integrity of the more impossible to talk about. The latter is converted into 8-bit bitmaps, RGB565, and OV9712 through software programming, respectively. RGB888 Save the picture and convert the Bayer to RGB565 data through a two-time skip jump to show that the integrity of the image is verified on the 320X240LCD. Related code reference online, but are more or less problematic and there is a compatibility portability problem, this side has been improved repair,
Subsequent provision of the revised relevant source code; 1-4.herf mode: Generally more complex equipment is through the two major components and master control to complete the communication. A component is a functional unit within the operating device, such as an internal register, which is accomplished through a certain protocol. such as OV9712 to configure its image effect through SCCB,
Sound card UDA1341 through the L3 protocol to adjust the volume, and the other part is the interaction of effective data, such as CMOS through VSync, HSYNC, PCLK, data port to complete the image data, sound card The UDA1341 completes the transmission of audio data via the IIS bus. The OV9712 default is to use the Herf mode (see Datasheet), in the process of a frame image transmission, Herf foot is low, and not like hsync (line sync signal) in a frameThere is a level change in the image transmission (of course, a frame image is composed of multiple rows of data). In Herf mode, the main control side needs to configure the HSync foot for the falling edge is valid; 1-5. Awkward datasheet: Gokovi's datasheet is relatively straightforward, for example, to configure the width height of the image the DVP has a definite register. And OV9712, is a direct "bit" operation. For example, configuring WXGA (1280x800) registers,
According to datasheet description as follows:   0x58 is vertical Size MSBs high 8 bit, here write 0xc8, there are low two bit in 0x57 Register bit[1:0] (value 0), altogether 10 bits, 10bit is 1100100000b,
Conversion into 10 is 800;   0x59output Horizontal Size MSBs, here write 0xa0, there are low three bits in 0x57 register Bit[4:2] (value 0), 11 bits is 10100000000b, converted to 10 is 1280. aside,
 More complex is the MI367 of the beauty Light, which provides two kinds of address access.

2. Key points in the commissioning:

There are a few key points to be aware of when debugging CMOS, whether it's bare metal or OS, because it's a hardware protocol layer, unrelated to software (except, of course, the so-called Configuration Register Code).

2-1. Image Output Format:
CMOS has image output format, such as Bayer (BGGR), YUV422 (tile) and so on. This may involve the sequence of receiving data from the CIM end of the master platform and programming of the upper layer for CMOS image format processing. If a
CMOS output Image format is the YUV422 packaging format, we can set the CIM end FIFO to the data receive order control, so that the FIFO end of the YUV422 packaging format to the DMA layer into the YUV422 tile format, this step is
hardware completion, The image data that arrives in the user space at this time must be YUV422 tiled. This image format needs to be converted to RGB565 or RGB888 by a programmatic implementation. Therefore, the user-space program handles the explicit format of the image data you are dealing with
, otherwise it is a messy image display ( This can be self-complementary to the image-related knowledge);
2-2. Polarity matching: The polarity of the
VSync, HSync, and PCLK of the CMOS and the main control end is consistent, For example, whether the vsync is a rising edge or a falling edge. The reference master platform and the CMOS data sheet can be configured to achieve the same polarity. Otherwise
, image loss data or pigment deviations can not even get the image (DMA count does not reach the expected number);
2-3. Image data Receive order: In general
, if the CPU has the support of data packaging, that is, the sensor end received 4 8 bytes of a word to spell 32 bits of the sort, you need to choose or try a variety of stitching methods.