Hi,
I adopted the ov5640 driver to capture custom data from a FPGA connected to the parallel camera interface of an iMX6.
So far, it works well and the debug logs show that my configuration of width/height is taken into account.
End of mxc_v4l_open: v2f pix widthxheight 16 x 16
End of mxc_v4l_open: crop_bounds widthxheight 16 x 16
End of mxc_v4l_open: crop_defrect widthxheight 16 x 16
End of mxc_v4l_open: crop_current widthxheight 16 x 16
The following configs were choosen:
Format: V4L2_PIX_FMT_RGB565
Wdith: 16
Height: 16
The bus is driven by an 8MHz clock generated within the FPGA, signals were checked by scope.
I am using gstreamer-0.10 libraries and the base plugins are installed.
Now the problem is the following:
When i create the following pipe from my application I am able to capture data, but they are wrong - means that data is not what i expected it to be. For testing purposes we implemented a linear increasing counter that is transfered from FPGA to the mcu.
Pipe: mfw_v4lsrc name=source num-buffers=2 device=/dev/video0 ! appsink name=sink
So, when I capture one buffer and decode my data (MSB,LSB) I got only a frame size of 16 x 12 Pixel containing wrong data.
Someone who has an idea why this happens.
I would also appreciate when someone could take its time to give me a starting point how to get rid of v4l2 overhead and configure the CSI/IPU completely within an own driver.
Regards
Florian
We are also have problem with this. Could you say how did you handle this problem?
Hi Florian,
I don't know what you mean that you use ov5640 driver to capture video data from FPGA. Actually, your application is not in our support range, but I can give some adive , maybe useful to you .
(1)CSI parallel port on i.MX6
For example , you can use CSI0 port( you can find it in the schematic of i.MX6 EVK board) to connect to FPGA, and capture data from FPGA.
(2)CSI driver
In linux BSP , we use a program named mxc_v4l2_capture.c to capture and handle video data from external camera sensor( in you application, it should be FPGA)
(3)CSI timing
For you application, CSI timing is very important for you , so you should tell it to local engineer of FPGA
see attachment , please !
OK, Hope above information can help you !
Regards,
Weidong
Hi,
Thank you very much for the timing document.
Is it correct that data is sampled at the falling clock edge in the IPU/CSI unit?
Weidong Sun schrieb:
I don't know what you mean that you use ov5640 driver to capture video data from FPGA. Actually, your application is not in our support range, but I can give some adive , maybe useful to you .
Sorry for being imprecise, we are simulating a camera interface with the FPGA to transmit custom data.
The FPGA is connected to the IPU0 - CSI0 and pixel clock is at 8MHz.
Since yesterday we are able to receive data. The problem was the HSYNC line. We had just 'short' impulses on hsync, as present on page 1 of your timing document. As we switched to the 'JPEG' mode, holding HSYNC high for the entire frame (page 4), we were able to receive data. How can we modify the driver to go out of JPEG mode? Btw. the data that is received is not fully correct atm but this needs further internal review.
For our goal of transferring data from the FPGA to the uC we modified your v4l stack to support 1 Byte data, as described in this thread.
Our new configuration is:
Format: V4L2_PIX_FMT_GREY
Width: 2048 (single bytes)
Height: 32
This is the gstreamer pipeline that we use to capture data from the interface:
mfw_v4lsrc num-buffers=XX device=/dev/video0 ! appsink
where XX is some positive number atm. and will be removed when everything works fine to receive continuous data.
EDIT:
Forgot to state that we are using IPU/CSI in gated clock mode.
Hello,
I'm working on something similar. I was wandering whether you could fix the issues?
Thank you,
Hi,
yes, we were able to fix this. We modified the V4L stack to provide the functionality to configure the incoming data as a greyscale image.
The timing is a little more diffucult:
We choose the gated mode and we provide new data from the FPGA to the ARM on the falling edge (FPGA changes data lines on falling edge, ARM samples data on rising edge).
Hope this helps.
Regards Florian
I am presently facing a similar problem, it seems that in JPEG mode we get corrupted data.
Can you elaborate on your solution a little more? What changes in the v4l2 driver and device tree were needed? What signal format did you use? I see some indication of "gated clock mode", does this conform to the above posted timing diagrams?
Thanks in advance
For anyone facing a similar problem, I found that the mxc_v4l_open function in the mxc_v4l2_capture module did not properly set the external vsync option for the selected IPU/CSI combination. Testing confirmed that vsync set to internal caused jumbled data.
Hi,
I have also changed the V4L2 stack. Could you please let me know what are the changes you did. Following are the changes I did,
Thank you
I can provide a patch when I am back in my office and there is still the need to do so.
Regards
Flo
Hello , fnairz
If you have resolved your questions , could you help me press "Correct button" or "Helpful button" to close this tickets ?
Thanks!
Regards,
Weidong