OV9712 CMOS based JZ4775 Debug (iii)

The newly-obtained hardware is either good or bad, or there is no careless or detailed error, and of course the driver is required and combined with some electrical tools such as (oscilloscope) to detect.

1.SCCB:

This is, of course, the first test that must be detected. Here I am using the Iic-tools tool (Linux platform supports user-space-driven projects that require kernel compilation-related support). The source code can search for the transplant on the Web. The following will provide me with a simplified iic-tools source code. Iic-tools is a tool for debugging IIC devices on Linux platforms. Altogether there are i2cdetect,i2cset,i2cget,i2cdump four tools, You can traverse the device on the IIC bus. Its specific usage can be searched online. OV9712 identifies its SCCB device address as 0x60, and if I2cdetect comes out with a discrepancy between its device address, you need to check the hardware.

Of course, the pre-iic-tools tool can be generally detected, if there is a special interface API requirements, you need specific API programming. For example, here is the function that I get the PID of OV9712:

unsigned short Ov9712getid (int. iic_fd)
{
        unsigned short pid = 0;
        unsigned char tmp = 0;

        IIC_SET_ADDR (IIC_FD,OV9712ADDR);

        TMP = Iic_read (IIC_FD,PIDHADDR);
        PID = tmp;
        PID = pid << 8;

        TMP = Iic_read (IIC_FD,PIDLADDR);
        PID = PID | TMP;

        if (0x9711 = = pid)
                printf ("Found Sensor OV9712. So lucky!\n ");
        else
                printf ("Oops:miss ov9712.\n");

        return PID;
}

0X9711 is the product ID of OV9712 and can be viewed in its data sheet.

Here has encountered a problem, is SCCB communication failure, the reason is that OV9712 must have MCLK to SCCB communication.

2. Initialize the OV9712:

Confirm SCCB Communication is no problem, go directly to the OV9712 heap sample code bar. The initialization code provided by the factory is SCCB through the protocol and plugs into it. After the register is stuffed, the MCLK, VSYNC, HSYNC, PCLK, and data pins are roughly Both have a signal output and are normal. Intercepted a portion of the original data spread on the screen with only a few colored bars in a mess. This was the case when I thought about it in two directions:

One is the polarity problem; the second is the problem of direct overlay (RGB565) of the image data.

2-1. Polarity matching:

The code provided by the manufacturer does not reconfigure the polarity of the VSync, HSYNC, and PCLK, which is the default. Then find the OV9712 data sheet to find the polarity control registers for VSync, HSYNC, and PCLK. as follows:

Visible, the OV9712 vsync, hsync the default polarity is positive, that is, the rising edge is valid.

Note that here is not the Register pit, HSYNC default is indeed positive, but the premise is that you selected HSYNC mode. OV9712 supports three modes: href, HSYNC, CCIR565. The default is Herf mode instead of HSync mode. Herf and HSync are the same pin pin, unlike herf mode, Herf pin is low when vsync pin output is valid. See the time series diagram of the OV9712 data sheet, as follows:

　　

Therefore, in href mode, the falling edge is valid. In this mode the master side needs to configure the HSync pin to be valid for the falling edge. I can not get the picture when I configure the JZ4776 master to be effective on the rising edge. Now that the HSync line is obsolete, Then will the row synchronization inconsistent and lead to the master refused to receive data? Personally, there is vsync enough, it triggered the interruption, it means that a frame of the image transmission, the main terminal can be processed data, HSync can be ignored. If you encounter some platforms that are more rigorous, Also need to deal with HSync synchronization, the specific treatment.

The polarity of the PCLK is as follows:

Therefore, we can determine the polarity of pin pin vsync, href (HSYNC), pclk in href mode, respectively:

VSync: rising edge;
Herf (HSYNC): Falling Edge;
PCLK: Rising edge.

Therefore, the corresponding polarity of the main control terminal is then configured according to the device:

The default Vsyn and PCLK polarity are consistent, mainly by configuring HSP to be 1 (i.e. the descent Edge is valid).

2-2. Order of receiving images:

The CIM controller of the general CPU has the data received from the sensor end to be reorganized and sorted. Generally speaking, the sensor end of the output is YUV or raw RGB, in general, the data sheet can be found in clear its clear format, For example, OV9712 's image Output format is one of Bayer (raw data). From its data sheet you can see the following words:

The color filters is arranged in a Bayer pattern. The primary color bg/gr array is arranged in line-alternating fashion.

"Little tricks:" Whether it is YUV or raw DATA, if the receiving order is reversed, there is usually a contour. You can try the other byte reorganization order appropriately.

JZ4775 4 bytes received from the sensor to spell 32-bit words, there are 8 ways:

　　　

Here's the fifth way, 3 ' b100. The way of the high and low position.

Check out the above two points, the image still does not see the integrity of the image. The configuration may still be problematic, the lens is not adjusted to focus, There may be problems with the upper-level conversion function. These three factors are likely to lead to the same phenomenon. So I think there is no better and more direct shortcut. By consulting the OV9712 data sheet, it is shown that it provides a test pattern pattern. Enter this mode to display a 8-segment color bar.

Another "application Programming Manual" provided by OV9712 is known to enter test pattern mode via the following register settings:

Of course, also set the register 0XCA into testpattern mode. The code is as follows:

void Ov9712testpattern (int iic_fd)
{
        iic_write (iic_fd,0xca,0x24);
        Iic_write (iic_fd,0x12,0x02);
        Iic_write (iic_fd,0x97,0x88);
}

Then the sensor end of the data transferred to RGB565 preservation, found that the picture has a fault condition. Later, it was found that the BMP head of the conversion function was constructed with a problem. After the fix, the effect is consistent with test pattern. For debugging convenience, decide to convert the RGB565 (x 800 ) is displayed on the 2.8-inch screen (240). The skip is implemented by a hop column. The code is as follows:

/* Function: Skip one Row and one
        Column.    
Date:
        2014-3-29
Author:
        se7en
*
/void skipPiexl1 (const u16 *INBUF,U16 *outbuf,const u32 width, Const U32 height,u32 div)
{
        assert ((inbuf && outbuf && (0 = = (width% 4) && (0 = = (height % 4)) && (0 = = (div% 4))));

        Const u16 *PINW = INBUF;
        U16 *pout = outbuf;
        U32 i = 0,j = 0,k = 0,sum = 0,aver = 0;

        for (i = 0, i < height; i+=2)
        {for
                (j = 0; J < width; j+=2)
                {
                        *pout = *pinw;
                        pout++;
                        PINW +=2;
                }

                PINW = pinw + width;
        }
}

Because my is a vertical screen, so also need to two times scaled pixel buf rotation 90 degrees, the code is as follows:

/* Function:
        operation for RGB.
Date:
        2014-3-29
Author:
        se7en
*

/#include "skippiexl.h"
void Rgb565_rotate90 (const U16 * Input, U16 *output,u32 width_in,u32 height_in)
{        
        const U16 *pin=input;
        U16 *pout=output;

        int i,j;

        For (i=0, i
 

 

 
3. Summary:

Sensor is a very complicated thing, a lot of the concepts involved in the concept is only a general concept. Here is a recording, follow up also need to debug image quality, this can only rely on technical support.