I want to send only one Frame Sync signal on McBSP

Hi,

I'm using 6418 DSP and I want to configure McBSP in such a way that it sends "only one" frame sync signal when sending a frame (lets say frame length:100 and word length:8-bit) and only if there is data.

When I configure FSGM as DXR2XSR it sends a frame sync signal on every byte, so I get 100 Frame sync signals. When I configure FSGM as INTERNAL, it sends frame sync signals periodically which I do not want.

Thanks for your help,
Best regards.

_____________________________________ Start a New Thread

scinel,

On Thu, Aug 20, 2009 at 4:17 AM, wrote:
> Hi,
>
> I'm using 6418 DSP and I want to configure McBSP in such a way that it sends
> "only one" frame sync signal when sending a frame (lets say frame length:100
> and word length:8-bit) and only if there is data.
>
> When I configure FSGM as DXR2XSR it sends a frame sync signal on every byte,


I believe this is correct behavior.

> so I get 100 Frame sync signals. When I configure FSGM as INTERNAL, it sends
> frame sync signals periodically which I do not want.


I am not McBSP expert, but I think that you can [or must] tailor your
FS by setting the frame size and FS width.
Check out the McBSP user manual or reference guide.

mikedunn
>
> Thanks for your help,
> Best regards.

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

_____________________________________ Start a New Thread

Scinel-

> I'm using 6418 DSP and I want to configure McBSP in such a way
> that it sends "only one" frame sync signal when sending
> a frame (lets say frame length:100 and word length:8-bit) and
> only if there is data.
>
> When I configure FSGM as DXR2XSR it sends a frame sync signal
> on every byte, so I get 100 Frame sync signals. When I
> configure FSGM as INTERNAL, it sends frame sync signals
> periodically which I do not want.

Look for "frame length" in the C6x McBSP Reference Guide:

tp://focus.ti.com/lit/ug/spru580g/spru580g.pdf

Section 4.5.2 is a good place to start.

-Jeff

_____________________________________ Start a New Thread

Thank you very much for your comments.

When I tried to adjust "frame length" parameter. But:

- When I'm using FSGM=DXR2XSR these parameter does not effect anything. I again obtain "frame sync" on every byte.

- When I'm using FSGM=1 (FSX is driven by SRGR), "frame length" parameter causes the "frame sync" occur on "N" byte as I wanted, but when I set FSGM=1, this time "frame sync" becomes a periodic function and appears every "FPER" clock. I do not want this case because this time "frame sync" comes although there is no data on the line.

Thanks again for your help...
Sertabr />
Scinel-

> I'm using 6418 DSP and I want to configure McBSP in such a way
> that it sends "only one" frame sync signal when sending
> a frame (lets say frame length:100 and word length:8-bit) and
> only if there is data.
>
> When I configure FSGM as DXR2XSR it sends a frame sync signal
> on every byte, so I get 100 Frame sync signals. When I
> configure FSGM as INTERNAL, it sends frame sync signals
> periodically which I do not want.

Look for "frame length" in the C6x McBSP Reference Guide:

tp://focus.ti.com/lit/ug/spru580g/spru580g.pdf

Section 4.5.2 is a good place to start.

-Jeff

_____________________________________ Start a New Thread

Serta

> Thank you very much for your comments.
>
> When I tried to adjust "frame length" parameter. But:
>
> - When I'm using FSGM=DXR2XSR these parameter does not
> effect anything. I again obtain "frame sync" on every byte.

In that case, you're asking the McBSP to generate framesync on every DXR-to-XSR transfer. If your word length is 8
bits, then yes, you'd see framesync for each byte. If your word length is 32 bits, then every four bytes, etc.

> - When I'm using FSGM=1 (FSX is driven by SRGR), "frame
> length" parameter causes the "frame sync" occur on "N"
> byte as I wanted, but when I set FSGM=1, this time "frame
> sync" becomes a periodic function and appears every
> "FPER" clock. I do not want this case because this time
> "frame sync" comes although there is no data on the line.

One thing I don't understand about your explanation. You say "... and only if there is data". Doesn't this imply an
*external* framesync? I.e. some other device is driving framesync? If you use external framesync and clock, then I
think it's no problem for you to control the number of words per framesync.

-Jeff

> Scinel-
>
>> I'm using 6418 DSP and I want to configure McBSP in such a way
>> that it sends "only one" frame sync signal when sending
>> a frame (lets say frame length:100 and word length:8-bit) and
>> only if there is data.
>>
>> When I configure FSGM as DXR2XSR it sends a frame sync signal
>> on every byte, so I get 100 Frame sync signals. When I
>> configure FSGM as INTERNAL, it sends frame sync signals
>> periodically which I do not want.
>
> Look for "frame length" in the C6x McBSP Reference Guide:
>
> tp://focus.ti.com/lit/ug/spru580g/spru580g.pdf
>
> Section 4.5.2 is a good place to start.
>
> -Jeff

_____________________________________ Start a New Thread

I did some complicated "control the ON/OFF of the frame sync" code using a McBSP, several EDMA channels, and one or two timers - including the timer EDMA channels.

This was to interface a 6416 to AD6636 digital down converter using the serial interface of the AD6636.
This interface needed to read a 36B group from the AD6636 30,000 times a second. The read of the 36B group was clustered at the beginning of the read interval and the link to the AD6636 was at 18.75 MHz.

This was done by only turning on the read frame at the beginning of the read interval. When the 36 read frames had been output, read frame was disabled. Seems I only used 1 control bit to enable and disable the read frame, but when I started working this scheme, 2 control bits were used.

The problem was that the EDMA could not count 36Bs before the McBSP started read frame 37. To work around this the hardware guy and I had one of the timers count read frames. On the count of 36 read frames the timer EDMA would trigger an EDMA channel to disable the read frame control.
We used EDMA channels to disable and enable read frame.
We used EDMA channels to control McBSP input and output configuration.

The initial work for this scheme was very messing because the AD6636 required a two B command to read every 36B input. This means that several McBSP-EDMA channels were interacting. Start a New Thread

I did some complicated "control the ON/OFF of the frame sync" code using a McBSP, several EDMA channels, and one or two timers - including the timer EDMA channels.

This was to interface a 6416 to AD6636 digital down converter using the serial interface of the AD6636.
This interface needed to read a 36B group from the AD6636 30,000 times a second. The read of the 36B group was clustered at the beginning of the read interval and the link to the AD6636 was at 18.75 MHz.

This was done by only turning on the read frame at the beginning of the read interval. When the 36 read frames had been output, read frame was disabled. Seems I only used 1 control bit to enable and disable the read frame, but when I started working this scheme, 2 control bits were used.

The problem was that the EDMA could not count 36Bs before the McBSP started read frame 37. To work around this the hardware guy and I had one of the timers count read frames. On the count of 36 read frames the timer EDMA would trigger an EDMA channel to disable the read frame control.
We used EDMA channels to disable and enable read frame.
We used EDMA channels to control McBSP input and output configuration.

The initial work for this scheme was very messing because the AD6636 required a two B command to read every 36B input. This means that several McBSP-EDMA channels were interacting. Start a New Thread

TS-

It sounds like a really creative solution, thanks for posting. Normally I wouldn't have tried that because I prefer
to "save" EDMA for periodic, high rate data transfer that can make a substantial impact on code performance (for
example reduce ISR overhead). Our designs often combine McBSP, host port, and UTOPIA or GMAC so we feel we have
enough "interacting EDMA", as you put it, and we try to avoid any EDMA activity that we can.

But it's good to know that your technique can work. Something for me to keep in mind.

-Jeff

> I did some complicated "control the ON/OFF of the frame sync" code using a McBSP, several EDMA channels, and one or
> two timers - including the timer EDMA channels.
>
> This was to interface a 6416 to AD6636 digital down converter using the serial interface of the AD6636.
> This interface needed to read a 36B group from the AD6636 30,000 times a second. The read of the 36B group was
> clustered at the beginning of the read interval and the link to the AD6636 was at 18.75 MHz.
>
> This was done by only turning on the read frame at the beginning of the read interval. When the 36 read frames had
> been output, read frame was disabled. Seems I only used 1 control bit to enable and disable the read frame, but when I
> started working this scheme, 2 control bits were used.
>
> The problem was that the EDMA could not count 36Bs before the McBSP started read frame 37. To work around this the
> hardware guy and I had one of the timers count read frames. On the count of 36 read frames the timer EDMA would
> trigger an EDMA channel to disable the read frame control.
> We used EDMA channels to disable and enable read frame.
> We used EDMA channels to control McBSP input and output configuration.
>
> The initial work for this scheme was very messing because the AD6636 required a two B command to read every 36B input.
> This means that several McBSP-EDMA channels were interacting.

_____________________________________ Start a New Thread

There's one other point that's worth making here, Jeff. What I described below was completely "automatic" using several peripherals and several EDMA channels. After this elaborate control sequence was turned-ON, it ran completely automatically, though I tend to think of it as "auto-magically." Using the below scheme I was able to sample 36Bs (includes complex data from a Digital Down Converter - AD6636 ) 30,000 times a second without any CPU code involvement.

The scheme I'm describing was one of several intermediate attempts and it did not work correctly.

I'll describe what was done to make it work correctly.

TINT1 was set to interrupt 30,000 times a second and TINT1 triggers E_02 (EDMA_02) which set E_14 event flag(EF14).

EF14 started E_14 which output the 2B read command in conjunction with XEVT1. On completion of this control block(EDMA control), EF60 was set.

EF60 caused E_60 to execute which set read frame, FRST1, to one - ON. McBSP1 read is now making read frames, which in this case cause AD6636 to output Bs.

McBSP1 REVT1 causes B input into E_15 which reads 36Bs. On the completion of 36Bs E_15 sets EF61.

EF61 caused E_61 to execute which set read frame, FRST1, to zero-OFF. McBSP1 read - making read frames - stops.

The process is repeated when TINT1 triggers E_02

The problem here was that E_15 could not count to 36 before McBSP0 IN made 37 read frames, but it didn't do this 100% of the time. If McBSP1 IN made 37 read frames, there would be 37 Bs created by McBSP1 even if the AD6636 only output 36Bs.

To work around this - correct the delay in turning OFF FRST1, TINT2 was used as a counter. Its count replaced the E_15 count of read frames.

TINT2 EDMA channel ( Is it E_07?) counted to 36. On a count of 36, E_07 reset TINT2 count and set E_61, which turned OFF FRST. This happens before all of the 8 bits of the 36th B are clocked into McBSP1 IN and read by E_15.

At this point we decided this scheme was good enough

It took a number of iterations to reach this point.

Also something that is not clear in the above is that some of the EDMA channels had several control blocks and even some "null" control blocks to which they - the EDMA channel controller - chained. The above narrative also avoids the issue of syncing these different control blocks on the different EDMA channels.

I'll use only one control block for a simple description and that will be E_15. E_15 chained four control blocks. The first one read 36Bs*300 samples. This is 300 of the 30000 per second samples, or 1/100 - 10 ms, of the data. After 10ms the control block caused an interrupt. This control block also chained to the next control block which only read 4B of input, and it reads these 4Bs of input before the completion of the current sample interval. Since it was only 4 Bs of input - from a different location in the AD6636, the output command E_14 had to be different and the number of read frames, E_07, was also different. The data read was a signature from the AD6636 which indicated that the reading was still correctly aligned. The second control block chained to a third which read 30Bs*300, but placed this input in a different location - double buffering - than the first control block. The third control block chained to a copy of the second to again read the alignment signature.

The read interval - aka sample interval - was 1/30,000. For 300 update intervals the 36B update - includes 16b complex numbers on 6 channels, was grouped at the beginning of the read interval. On the 300th interval the 4B alignment data was read at the end of the sample interval. So the timing was somewhat sticky.

The 10ms interrupt allowed CPU code to check the alignment of the AD6636 signature, and input of the alignment signature could also include an update of the AD6636 configuration. So, the whole process was automatically with the CPU code able to "reach in" and change the output about 100 times a second.

I know this description doesn't describe the entire process accurately, but I hope it gives the readers an idea of what is possible.

A wonderful use of CodeComposer is the ability to "single step" this process. All it takes is substituting the TINT1 triggering of E_02 in a loop, and one can "single step" to their heart's content. Of course this process can be broken and tested at any point in the sequence. Start a New Thread

TS-

That's really something that you would take the time to document your approach in such detail. It's a valuable
contribution.

You make a key point in DSP coding: the need to let DMA channels do work whenever possible and therefore let chip
circuitry arbitrate who gets what memory resource when. DMA is a lesser known, but hugely significant, aspect of
computationally intensive coding. I know from experience that Linux server programmers (aka Host Media Processing
guys) dealing with something time-critical will spend months optimizing crucial loops and other sections of code, even
hand-coding in x86 asm language, and in all that time and effort, never touch DMA.

-Jeff

> There's one other point that's worth making here, Jeff. What I described below was completely "automatic" using
> several peripherals and several EDMA channels. After this elaborate control sequence was turned-ON, it ran completely
> automatically, though I tend to think of it as "auto-magically." Using the below scheme I was able to sample 36Bs
> (includes complex data from a Digital Down Converter - AD6636 ) 30,000 times a second without any CPU code
> involvement.
>
> The scheme I'm describing was one of several intermediate attempts and it did not work correctly.
>
> I'll describe what was done to make it work correctly.
>
> TINT1 was set to interrupt 30,000 times a second and TINT1 triggers E_02 (EDMA_02) which set E_14 event flag(EF14).
>
> EF14 started E_14 which output the 2B read command in conjunction with XEVT1. On completion of this control block(EDMA
> control), EF60 was set.
>
> EF60 caused E_60 to execute which set read frame, FRST1, to one - ON. McBSP1 read is now making read frames, which in
> this case cause AD6636 to output Bs.
>
> McBSP1 REVT1 causes B input into E_15 which reads 36Bs. On the completion of 36Bs E_15 sets EF61.
>
> EF61 caused E_61 to execute which set read frame, FRST1, to zero-OFF. McBSP1 read - making read frames - stops.
>
> The process is repeated when TINT1 triggers E_02
>
> The problem here was that E_15 could not count to 36 before McBSP0 IN made 37 read frames, but it didn't do this 100%
> of the time. If McBSP1 IN made 37 read frames, there would be 37 Bs created by McBSP1 even if the AD6636 only output
> 36Bs.
>
> To work around this - correct the delay in turning OFF FRST1, TINT2 was used as a counter. Its count replaced the E_15
> count of read frames.
>
> TINT2 EDMA channel ( Is it E_07?) counted to 36. On a count of 36, E_07 reset TINT2 count and set E_61, which turned
> OFF FRST. This happens before all of the 8 bits of the 36th B are clocked into McBSP1 IN and read by E_15.
>
> At this point we decided this scheme was good enough
>
> It took a number of iterations to reach this point.
>
> Also something that is not clear in the above is that some of the EDMA channels had several control blocks and even
> some "null" control blocks to which they - the EDMA channel controller - chained. The above narrative also avoids the
> issue of syncing these different control blocks on the different EDMA channels.
>
> I'll use only one control block for a simple description and that will be E_15. E_15 chained four control blocks. The
> first one read 36Bs*300 samples. This is 300 of the 30000 per second samples, or 1/100 - 10 ms, of the data. After
> 10ms the control block caused an interrupt. This control block also chained to the next control block which only read
> 4B of input, and it reads these 4Bs of input before the completion of the current sample interval. Since it was only 4
> Bs of input - from a different location in the AD6636, the output command E_14 had to be different and the number of
> read frames, E_07, was also different. The data read was a signature from the AD6636 which indicated that the reading
> was still correctly aligned. The second control block chained to a third which read 30Bs*300, but placed this input
> in a different location - double buffering - than the first control block. The third control block chained to a copy
> of the second to again read the alignment signature.
>
> The read interval - aka sample interval - was 1/30,000. For 300 update intervals the 36B update - includes 16b complex
> numbers on 6 channels, was grouped at the beginning of the read interval. On the 300th interval the 4B alignment data
> was read at the end of the sample interval. So the timing was somewhat sticky.
>
> The 10ms interrupt allowed CPU code to check the alignment of the AD6636 signature, and input of the alignment
> signature could also include an update of the AD6636 configuration. So, the whole process was automatically with the
> CPU code able to "reach in" and change the output about 100 times a second.
>
> I know this description doesn't describe the entire process accurately, but I hope it gives the readers an idea of
> what is possible.
>
> A wonderful use of CodeComposer is the ability to "single step" this process. All it takes is substituting the TINT1
> triggering of E_02 in a loop, and one can "single step" to their heart's content. Of course this process can be broken
> and tested at any point in the sequence.

_____________________________________ Start a New Thread