"Ron Huizen" <rhuizen@bittware.com> wrote in message
news:vk1mf7iui9cd71@corp.supernews.com...
> "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
> news:bhjft9$896d$1@ID-82263.news.uni-berlin.de...
> > Yes, this is one of my options as well. But I wasn't sure about the DMA
> > portion handling the sport TX buffer being full. Are you sure the DMA
will
> > wait until the buffer gets empty and then continue writing? If this is
> true,
> > then this will be a good solution for me. I can set the TX frame synch
to
> > data independent mode and set the frame synch clock to my desired output
> > rate. *If* the DMA can automatically pause every time the sport TX
buffer
> is
> > full and continue that'll be great - I'd appreciate a confirmation of
> this.
> >
>
> Bhaskar,
>
> The DMAs will definitely work with the tx buffers to do what you want.
Just
> like an rx dma, which gets invoked when there is data in the rx buffer,
the
> tx dmas get invoked when there is room for data in the tx buffers.  Same
is
> true for links as well.  If it didn't work this way, the DMA channels for
> these peripherals would be pretty useless.

I felt a little dumb asking for reassurance - thanks for making sure that
feeling didn't die :-)
I've actually used the DMA in this manner except for the fact that I didn't
use it in the data independent mode - that's the part that made me question
myself.

I'm still struggling to decide between the option of using the sport DMA for
the TX side vs configuring my buffers to match the decimation size. Either
ways, it's a big change in my code...I guess using the sports with data
independent frame synchs is the right way to do it - getting it to work
right is just details for me to deal with.

Cheers
Bhaskar


> ---------
> Ron Huizen
> BittWare
>
>

"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
news:bhjft9$896d$1@ID-82263.news.uni-berlin.de...
> Yes, this is one of my options as well. But I wasn't sure about the DMA
> portion handling the sport TX buffer being full. Are you sure the DMA will
> wait until the buffer gets empty and then continue writing? If this is
true,
> then this will be a good solution for me. I can set the TX frame synch to
> data independent mode and set the frame synch clock to my desired output
> rate. *If* the DMA can automatically pause every time the sport TX buffer
is
> full and continue that'll be great - I'd appreciate a confirmation of
this.
>

Bhaskar,

The DMAs will definitely work with the tx buffers to do what you want.  Just
like an rx dma, which gets invoked when there is data in the rx buffer, the
tx dmas get invoked when there is room for data in the tx buffers.  Same is
true for links as well.  If it didn't work this way, the DMA channels for
these peripherals would be pretty useless.

---------
Ron Huizen
BittWare

"Jon Harris" <jon_harrisTIGER@hotmail.com> wrote in message
news:3f3bd148$1_2@newsfeed...
> If you really can finish the data much faster than it needs to be output,
> you could reduce your buffer size.  This will make your output data less
> "bursty", but not totally even unless the input buffer size was down to 1
> (or 2 for downsampling by 2).

Yeah - I have this as one of my options. But it's the most difficult to
change in terms of code and I have to make sure my overheads for processing
each block is small enough that I can handle block sizes of 2 (for
downsampling by 2).
One of the things I plan to do is to profile my processing overhead and see
if I can optimize it (I already tried this and it didn't work, whereas a
block size of 10 did - so clearly my overheads are too large)

> Another idea, is it possible to slow down your output serial port to a
speed
> that exactly matches the output data rate?  Generally with audio, this is
> trivial using I2S mode, but I don't know about your application.  If so,
> then you can just use a DMA to send the data to the serial port buffer and
> it will naturally throttle it to the correct rate.  When the buffer is
full,
> the DMA will wait and you will have a uniform data rate.

Yes, this is one of my options as well. But I wasn't sure about the DMA
portion handling the sport TX buffer being full. Are you sure the DMA will
wait until the buffer gets empty and then continue writing? If this is true,
then this will be a good solution for me. I can set the TX frame synch to
data independent mode and set the frame synch clock to my desired output
rate. *If* the DMA can automatically pause every time the sport TX buffer is
full and continue that'll be great - I'd appreciate a confirmation of this.

Cheers
Bhaskar

>
> -Jon
>
> "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
> news:bhj765$544r$1@ID-82263.news.uni-berlin.de...
> > Hi all
> >
> > I need some suggestions on how to handle my problem (I believe there is
> more
> > than 1 solution).
> > I have data coming in at a certain rate, say fs. This is DMA-ed into
> > internal memory (using chained sport receive) in blocks of 100. (so each
> of
> > my ping-pong buffer is 100 samples deep).
> > Every time one buffer fills up, I start processing the data and generate
> > outputs. My processing is a filter and downsample operation.
> > My goal is to output my data on the sport transmits at a rate fs/D,
where
> D
> > is the decimation rate (say 2 for discussion purposes).
> >
> > With my current processing, since I crank on the data every time a
memory
> > buffer fills up (100 samples deep), I generate 50 output samples (with
> D=2).
> > This processing is done at the full speed of the DSP. So my output data
> > stream ends up having the data bunched up in bursts.
> > While my average overall data rate is still fs/2, if you examine a small
> > portion of time, the output data rate is pretty fast. I'd like some
> > suggestions on how I can use the capabilities of this DSP to get my
output
> > data rate to be closer (no need to be exact) to the intended output data
> > rate of fs/2.
> >
> > To re-iterate what I have going on now....
> > I wait for my DMA to signal that a buffer is full.
> > Crank on that data - which in turn outputs a burst of 50 samples (in the
> > background my next DMA has already started but is not complete).
> > Wait for my DMA to signal that a buffer is full (fairly long wait time
> > compared to the time to process and output the 50 samples)
> > Repeat
> >
> > I use the data dependent frame sync option on the sport transmit. So as
> soon
> > as I have 1 output sample ready, I write it out to the sport.
> > One option I have is to have the sport work on data-independent mode and
> > have it generate frame sync and the fs/2 rate. But I'm not sure how to
get
> a
> > stream of data into the TX buffer without overflowing that buffer.
> > Another option is to have a timer that fires an interrupt. I'd write my
> > output samples into a ring buffer. The ISR would write 1 sample to the
> sport
> > TX from the output buffer. I guess I need to do some more timing
analysis
> to
> > make sure this scheme won't ever fall behind the bursty output
processing.
> > Yet another option is to *not* buffer the input samples in large buffers
> and
> > instead process them immediately. In this case I have to ensure that my
> data
> > processing overhead is small enough that I can keep up with the input
data
> > rate.
> > Are there other options? Any flaws in my current options - are some
better
> > options than other?
> >
> > Sorry for the long winded email - I figured more info is better than
less
> to
> > get meaningful responses.
> >
> > Cheers
> > Bhaskar
> >
> >
> >
> >
>
>

If you really can finish the data much faster than it needs to be output,
you could reduce your buffer size.  This will make your output data less
"bursty", but not totally even unless the input buffer size was down to 1
(or 2 for downsampling by 2).

Another idea, is it possible to slow down your output serial port to a speed
that exactly matches the output data rate?  Generally with audio, this is
trivial using I2S mode, but I don't know about your application.  If so,
then you can just use a DMA to send the data to the serial port buffer and
it will naturally throttle it to the correct rate.  When the buffer is full,
the DMA will wait and you will have a uniform data rate.

-Jon

"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
news:bhj765$544r$1@ID-82263.news.uni-berlin.de...
> Hi all
>
> I need some suggestions on how to handle my problem (I believe there is
more
> than 1 solution).
> I have data coming in at a certain rate, say fs. This is DMA-ed into
> internal memory (using chained sport receive) in blocks of 100. (so each
of
> my ping-pong buffer is 100 samples deep).
> Every time one buffer fills up, I start processing the data and generate
> outputs. My processing is a filter and downsample operation.
> My goal is to output my data on the sport transmits at a rate fs/D, where
D
> is the decimation rate (say 2 for discussion purposes).
>
> With my current processing, since I crank on the data every time a memory
> buffer fills up (100 samples deep), I generate 50 output samples (with
D=2).
> This processing is done at the full speed of the DSP. So my output data
> stream ends up having the data bunched up in bursts.
> While my average overall data rate is still fs/2, if you examine a small
> portion of time, the output data rate is pretty fast. I'd like some
> suggestions on how I can use the capabilities of this DSP to get my output
> data rate to be closer (no need to be exact) to the intended output data
> rate of fs/2.
>
> To re-iterate what I have going on now....
> I wait for my DMA to signal that a buffer is full.
> Crank on that data - which in turn outputs a burst of 50 samples (in the
> background my next DMA has already started but is not complete).
> Wait for my DMA to signal that a buffer is full (fairly long wait time
> compared to the time to process and output the 50 samples)
> Repeat
>
> I use the data dependent frame sync option on the sport transmit. So as
soon
> as I have 1 output sample ready, I write it out to the sport.
> One option I have is to have the sport work on data-independent mode and
> have it generate frame sync and the fs/2 rate. But I'm not sure how to get
a
> stream of data into the TX buffer without overflowing that buffer.
> Another option is to have a timer that fires an interrupt. I'd write my
> output samples into a ring buffer. The ISR would write 1 sample to the
sport
> TX from the output buffer. I guess I need to do some more timing analysis
to
> make sure this scheme won't ever fall behind the bursty output processing.
> Yet another option is to *not* buffer the input samples in large buffers
and
> instead process them immediately. In this case I have to ensure that my
data
> processing overhead is small enough that I can keep up with the input data
> rate.
> Are there other options? Any flaws in my current options - are some better
> options than other?
>
> Sorry for the long winded email - I figured more info is better than less
to
> get meaningful responses.
>
> Cheers
> Bhaskar
>
>
>
>

Hi all

I need some suggestions on how to handle my problem (I believe there is more
than 1 solution).
I have data coming in at a certain rate, say fs. This is DMA-ed into
internal memory (using chained sport receive) in blocks of 100. (so each of
my ping-pong buffer is 100 samples deep).
Every time one buffer fills up, I start processing the data and generate
outputs. My processing is a filter and downsample operation.
My goal is to output my data on the sport transmits at a rate fs/D, where D
is the decimation rate (say 2 for discussion purposes).

With my current processing, since I crank on the data every time a memory
buffer fills up (100 samples deep), I generate 50 output samples (with D=2).
This processing is done at the full speed of the DSP. So my output data
stream ends up having the data bunched up in bursts.
While my average overall data rate is still fs/2, if you examine a small
portion of time, the output data rate is pretty fast. I'd like some
suggestions on how I can use the capabilities of this DSP to get my output
data rate to be closer (no need to be exact) to the intended output data
rate of fs/2.

To re-iterate what I have going on now....
I wait for my DMA to signal that a buffer is full.
Crank on that data - which in turn outputs a burst of 50 samples (in the
background my next DMA has already started but is not complete).
Wait for my DMA to signal that a buffer is full (fairly long wait time
compared to the time to process and output the 50 samples)
Repeat

I use the data dependent frame sync option on the sport transmit. So as soon
as I have 1 output sample ready, I write it out to the sport.
One option I have is to have the sport work on data-independent mode and
have it generate frame sync and the fs/2 rate. But I'm not sure how to get a
stream of data into the TX buffer without overflowing that buffer.
Another option is to have a timer that fires an interrupt. I'd write my
output samples into a ring buffer. The ISR would write 1 sample to the sport
TX from the output buffer. I guess I need to do some more timing analysis to
make sure this scheme won't ever fall behind the bursty output processing.
Yet another option is to *not* buffer the input samples in large buffers and
instead process them immediately. In this case I have to ensure that my data
processing overhead is small enough that I can keep up with the input data
rate.
Are there other options? Any flaws in my current options - are some better
options than other?

Sorry for the long winded email - I figured more info is better than less to
get meaningful responses.

Cheers
Bhaskar