Hi,

>I can't explain it I'm afraid, because it just worked! I have made no
>modifications to the decoder part of the driver at all, apart from to
>make some changes to the AGC settings and input selection registers.

Thank you Mark anyway.

Is there anybody else who could help us ? Thanks in advance.

Jerome
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

jerome wrote:
> 
> I'm sorry but i can't see how you can reset VCOUNT thanks to SAV/EAV codes
> if these codes aren't included during the vertical blanking period?! Maybe
> you found a way to add them ? Could you explain how you do it ? Thanks.

I can't explain it I'm afraid, because it just worked! I have made no
modifications to the decoder part of the driver at all, apart from to
make some changes to the AGC settings and input selection registers.

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

Hi,

>Correct. When there are VCATHRLD dwords in the FIFO, an EDMA event
>occurs and the EDMA controller reads VCATHRLD dwords from the port into
>user memory. The EDMA operates in fixed-source, increment-destination
>mode, so it always reads the same address (the YSRCA register) but
>places the samples linearly in user memory. VCATHRLD is usually set to
>be a line's worth of samples, but doesn't have to be. Also, there are
>2 VCATHRLD registers (VCATHRLD1 and VCATHRLD2) for odd and even fields.

Thanks for this explanation. It becomes more understandable for me.

>> How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ?
>> Do you think our problem comes from this ?

>I use SAV/EAV, and it works fine with the SAA7115. I don't think that
>the 7118 would be all that different, but I've never used it.
I'm sorry but i can't see how you can reset VCOUNT thanks to SAV/EAV codes
if these codes aren't included during the vertical blanking period?! Maybe
you found a way to add them ? Could you explain how you do it ? Thanks. 

>To be honest, I still think your best bet is to port the vport mini
>driver to your board, if only to prove your hardware. If you have
>the 7115 and 7118 data sheets side-by-side, you should be able to
>create a register structure for your part, then it should pretty
>much just work. If you don't have a display port (the vport app
>assumes an SAA7105 on port 2), you'll need to validate your images
>somehow, but at least you'll know the port is working.

Yes you're surely right but the fact is that i spent a lot of time typing
a .h file with all the SAA7118 registers values and above all the part
that concerns the video decoder is totaly validated. All the registers
have the good values, the output signals are right too. I don't want to do
it once again.

Thanks for your help.

Jerome


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

jerome wrote:
> 
> Ok. So, please tell me if I'm right or wrong : the incoming video data
> samples come to the Y FIFO by 8-bits packets. When the FIFO reaches the
> user defined thresholds an EDMA event is generated, the first (or last)
> 64-bit pack Y samples are latched in YSRCA, the EDMA controller reads the
> data in YSRCA and copy them in a user defined memory space ?

Correct. When there are VCATHRLD dwords in the FIFO, an EDMA event
occurs and the EDMA controller reads VCATHRLD dwords from the port into
user memory. The EDMA operates in fixed-source, increment-destination
mode, so it always reads the same address (the YSRCA register) but
places the samples linearly in user memory. VCATHRLD is usually set to
be a line's worth of samples, but doesn't have to be. Also, there are
2 VCATHRLD registers (VCATHRLD1 and VCATHRLD2) for odd and even fields.

This process continues until the EDMA has transferred all the bytes it
has been asked for (usually a field's worth), then it stops and fires
its TCC event if it has one. The program must reconfigure the EDMA in
time for the next field (or, alternatively, use Reloads to do it
automatically, as the vport driver does).

> How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ?
> Do you think our problem comes from this ?

I use SAV/EAV, and it works fine with the SAA7115. I don't think that
the 7118 would be all that different, but I've never used it.

To be honest, I still think your best bet is to port the vport mini
driver to your board, if only to prove your hardware. If you have
the 7115 and 7118 data sheets side-by-side, you should be able to
create a register structure for your part, then it should pretty
much just work. If you don't have a display port (the vport app
assumes an SAA7105 on port 2), you'll need to validate your images
somehow, but at least you'll know the port is working.

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

Hi,

>YSRCA is the output of the Y capture FIFO, so yes, it will always
>contain the oldest unread Y sample.

Ok. So, please tell me if I'm right or wrong : the incoming video data
samples come to the Y FIFO by 8-bits packets. When the FIFO reaches the
user defined thresholds an EDMA event is generated, the first (or last)
64-bit pack Y samples are latched in YSRCA, the EDMA controller reads the
data in YSRCA and copy them in a user defined memory space ?

>I don't know why the address of YSRCA changes - as far as I know, it
>should be a fixed address, as returned by the Chip Support Library
>when the port is opened.

I think I wasn't clear last time : the address of YSRCA never changes,
it's always 0x7C000000, but what changes are the data in YSRCA. So
apparently, from what you said, if YSRCA is the output of the FIFO it's
normal that the data always change.

Maybe we found the reason why the capture doesn't work. In the
documentation SPRU629D, on page 3-20, it's said that VCOUNT can be reset
either by a change on EAV (bit V notifying if we are in the vertical
blanking period or not) or either by using the VCTL1 input. In our card,
VCTL1 is not connected. So we don't have the choice, VCOUNT must be reset
when there is a change on EAV. The issue is that the video decoder SAA7118
doesn't add SAV and EAV codes when we are in the vertical blanking period.
As a consequence, the DSP can never see a change on EAV and then VCOUNT is
never reset !!

How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ? 
Do you think our problem comes from this ?

Thanks a lot.

Jerome


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

Hi,

>YSRCA is the output of the Y capture FIFO, so yes, it will always
>contain the oldest unread Y sample.

Ok. So, please tell me if I'm right or wrong : the incoming video data
samples come to the Y FIFO by 8-bits packets. When the FIFO reaches the
user defined thresholds an EDMA event is generated, the first (or last)
64-bit pack Y samples are latched in YSRCA, the EDMA controller reads the
data in YSRCA and copy them in a user defined memory space ?

>I don't know why the address of YSRCA changes - as far as I know, it
>should be a fixed address, as returned by the Chip Support Library
>when the port is opened.

I think I wasn't clear last time : the address of YSRCA never changes,
it's always 0x7C000000, but what changes are the data in YSRCA. So
apparently, from what you said, if YSRCA is the output of the FIFO it's
normal that the data always change.

Maybe we found the reason why the capture doesn't work. In the
documentation SPRU629D, on page 3-20, it's said that VCOUNT can be reset
either by a change on EAV (bit V notifying if we are in the vertical
blanking period or not) or either by using the VCTL1 input. In our card,
VCTL1 is not connected. So we don't have the choice, VCOUNT must be reset
when there is a change on EAV. The issue is that the video decoder SAA7118
doesn't add SAV and EAV codes when we are in the vertical blanking period.
As a consequence, the DSP can never see a change on EAV and then VCOUNT is
never reset !!

How do you reset VCOUNT ? Thanks to EAV or by VCTL1 ? 
Do you think our problem comes from this ?

Thanks a lot.

Jerome


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

jerome wrote:
> 
> Could you tell me if I'm wrong : in YSRCA there are data and these data
> are simply the address where the Y samples are stored ?! Idem for CBSRC
> and CRSRC ?! Why is this address equal to 0x7BDEC5C5 (just after the VP
> module has been validated in PERCFG, 'cause this value changes many times
> after) ?? Why isn't this address in the VP2 Channel A data space ?!!

YSRCA is the output of the Y capture FIFO, so yes, it will always
contain the oldest unread Y sample. This is used as the source address
for the Y channel EDMA transfer. Note that the video port is tightly
coupled to the EDMA controller - you would never read YSRCA directly.

I don't know why the address of YSRCA changes - as far as I know, it
should be a fixed address, as returned by the Chip Support Library
when the port is opened.

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

Hi,

In fact, after reading the documentation SPRA918A about the mini-port
driver, I think this won't really help us. The reason is what is done by
creating this driver is not far from what we are doing in our codes.

Moreover, I must notify that the video decoder is a SAA7118 and that it's
well configured since the output video data are as expected.

Could you tell me if I'm wrong : in YSRCA there are data and these data
are simply the address where the Y samples are stored ?! Idem for CBSRC
and CRSRC ?! Why is this address equal to 0x7BDEC5C5 (just after the VP
module has been validated in PERCFG, 'cause this value changes many times
after) ?? Why isn't this address in the VP2 Channel A data space ?!!

Thanks for the answer.

Jerome  

>jerome wrote:
>> 
>> For the mini-driver I guess that will be hard to start from it since
we
>> don't have the EVM card. How can we start from this ?
>
>At the moment, I'm still using the EVM, so the issue of porting to
>production hardware hasn't arisen yet. But the driver code is well
>structured so it shouldn't be too difficult.
>
>The amount of work needed clearly depends on how close your video
>hardware is to the EVM. If you're using SAA7115 and SAA7105 (or the
>TI decoder as supplied on the newer EVMs), and are happy to capture
>BT.656, then the changes should be minimal.
>
>If you're using a different decoder, you'll need to rewrite the driver
>for this, but this should be limited to changing the structure that
>holds the registers, and the I2C addresses.
>
>Good luck!
>
>Cheers
>
>mark-r
>
>-- 
>"Let's meet the panel. You couldn't ask for four finer comedians -
>so that answers your next question..."
> -- Humphrey Lyttleton
>


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

jerome wrote:
> 
> For the mini-driver I guess that will be hard to start from it since we
> don't have the EVM card. How can we start from this ?

At the moment, I'm still using the EVM, so the issue of porting to
production hardware hasn't arisen yet. But the driver code is well
structured so it shouldn't be too difficult.

The amount of work needed clearly depends on how close your video
hardware is to the EVM. If you're using SAA7115 and SAA7105 (or the
TI decoder as supplied on the newer EVMs), and are happy to capture
BT.656, then the changes should be minimal.

If you're using a different decoder, you'll need to rewrite the driver
for this, but this should be limited to changing the structure that
holds the registers, and the I2C addresses.

Good luck!

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

Thanks for your answer. 

Glad to see we're not the only ones who aren't able to make those examples
to work! 

For the mini-driver I guess that will be hard to start from it since we
don't have the EVM card. How can we start from this ?

Anybody else has an idea to help us ?

Thanks.


>jerome wrote:
>> 
>> To capture these video data we've been using an example code given by
TI
>> in a datasheet (SPRU629 if i remember well but I can be wrong).
>> Unfortunately we don't succeed in making it work!
>
>I don't know if there's a newer version, but I didn't get the examples
>in SPRU629d to work.
>
>Your best bet, IMO, is to start from the vport mini driver example.
>
>Cheers
>
>mark-r
>
>-- 
>"Let's meet the panel. You couldn't ask for four finer comedians -
>so that answers your next question..."
> -- Humphrey Lyttleton
>


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com