DM642 and Raw Data Capture Mode
Started by ●April 26, 2005
Hello All,
I am trying to interface the DM642 with a CMOS sensor using Video Port 0. I have been following the example in SPRU629 and for the most part I have the video capture working. The problem is that my data is not being synchronized properly. The sensor I am working with outputs line valid and frame valid synchronization signals. I use the line valid signal for the synchronization signal to the video port. The TI website has an example with a different CMOS sensor. My sensor does not allow for the two line valid and frame valid to be operated the same way as the example. This is not a problem for my application. The problem is that each captured line does not start at the first pixel of that line. The data is skewed. Every time I run the program the data seems to be skewed by a different offset. I am wondering if it could be my video capture setup or possibly my Edma setup. I am working with a 640x480 image. So the corresponding threshold and Edma count values should be 160 and 320 assuming 10 bit data non dense format padded with 0's. As for the other settings, they are pretty much the same as the capture example in spru629. I did leave out some of the register settings that did not pertain to raw capture mode, Since they have no effect on this mode I don't see how this could be a problem. Edma is set up to trigger of the Yevent of my video port handle. These settings are also almost the same as the example. If any body has any idea what could be causing this capture to be out of sync that would be greatly appreciated.
Thank You,
Alex Sanville
Sanville@Sanv...
Reply by ●April 27, 20052005-04-27
Hi,
I have a little bit a different setup (without raw mode...) but maybe some
ideas..:
I think you are reffering to spraa52.pdf (Interfacing a CMOS Sensor to the
TMS320DM642 Using Raw Capture Mode)?
In my case I found it helpful to remove the 2D DMA. I used a 1DDma that
copied every line to the same memory. In the transferComplete ISR, I copied
it to the destination memory. Additionaly, I had the possibility to log
every linenumber etc.
in what memory is your EDMA copy destination? Is it sure that you operate
the L2 cache correctly (writeback / invalidate)?
What about your FIFO thresholds? It seems a little like you get an
EDMA-event and EDMA starts to copy and overtakes the other end of the fifo
capturing new data. This could cause such effects from my point of view
bye,
Thomas
>
>
> Hello All,
> I am trying to interface the DM642 with a CMOS sensor using Video Port
> 0. I have been following the example in SPRU629 and for the most part I
> have the video capture working. The problem is that my data is not being
> synchronized properly. The sensor I am working with outputs line valid
and
> frame valid synchronization signals. I use the line valid signal for the
> synchronization signal to the video port. The TI website has an example
with
> a different CMOS sensor. My sensor does not allow for the two line valid
> and frame valid to be operated the same way as the example. This is not a
> problem for my application. The problem is that each captured line does
not
> start at the first pixel of that line. The data is skewed. Every time I
> run the program the data seems to be skewed by a different offset. I am
> wondering if it could be my video capture setup or possibly my Edma setup.
I
> am working with a 640x480 image. So the corresponding threshold and Edma
> count values should be 160 and 320 assuming 10 bit data non dense format
> padded with 0's. As for the other settings, they are pretty much the same
as
> the capture example in spru629. I did leave out some of the register
> settings that did not pertain to raw capture mode, Since they have no
effect on
> this mode I don't see how this could be a problem. Edma is set up to
> trigger of the Yevent of my video port handle. These settings are also
almost
> the same as the example. If any body has any idea what could be causing
> this capture to be out of sync that would be greatly appreciated.
>
> Thank You,
>
> Alex Sanville
> Sanville@Sanv... >
>
--
+++ Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
