i.MX6Q CSI Parallel Generic Data

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX6Q CSI Parallel Generic Data

ソリューションへジャンプ
1,024件の閲覧回数
curtis1
Contributor II

Hello,

We have been unsuccessfully trying to collect generic data supplied by an FPGA over the IPU parallel interface. We have patched the kernel and device tree to enable greyscale/generic data and can receive data into the i.MX6 memory. However, the data is striped with repeated erroneous values.

Consider the following logic analyzer capture,
FPGA_Par_Bus.png

 
 
 



This results in the following pattern in the i.MX6 memory,
iMX6_Bad_Pattern.png

 

According to the CSI_Timing.pdf from this post we are using so-called JPEG mode. Does this imply that the data is to be formatted as a JPEG?

Can someone further elaborate on the timings specified in that document, and which timing is appropriate for parallel generic data?

Thank you,

Curtis

 

Edit:

Additional confusion arises from the IMXQRM.pdf, consider figure 37-18
imx6_csi_nongated.png

 

 

 

 

 

This agrees with the so-called "non-gated mode" described in CSI_Timing.pdf.

However, figure 37-17
imx6_csi_gated.png

 

 

 

 

 

 

is called "JPEG mode" in CSI_Timing.pdf.

 

Where does CSI_Timing.pdf come from, and are those timings to be trusted?

ラベル(1)
0 件の賞賛
返信
1 解決策
1,000件の閲覧回数
curtis1
Contributor II

We found that the mxc_v4l_open function in the mxc_v4l2_capture module did not properly set the external vsync option. Testing confirms that internal vsync causes the data corruption we see.

元の投稿で解決策を見る

0 件の賞賛
返信
1 返信
1,001件の閲覧回数
curtis1
Contributor II

We found that the mxc_v4l_open function in the mxc_v4l2_capture module did not properly set the external vsync option. Testing confirms that internal vsync causes the data corruption we see.

0 件の賞賛
返信