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
ADSP 21160 and sport transmit
Started by ●August 15, 2003
Reply by ●August 15, 20032003-08-15
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 ismore> 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 eachof> 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, whereD> 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 (withD=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 assoon> 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 geta> 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 thesport> TX from the output buffer. I guess I need to do some more timing analysisto> 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 buffersand> instead process them immediately. In this case I have to ensure that mydata> 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 lessto> get meaningful responses. > > Cheers > Bhaskar > > > >
Reply by ●August 15, 20032003-08-15
"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 aspeed> 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 isfull,> 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 amemory> > 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 myoutput> > 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 toget> 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 timinganalysis> to > > make sure this scheme won't ever fall behind the bursty outputprocessing.> > 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 inputdata> > rate. > > Are there other options? Any flaws in my current options - are somebetter> > options than other? > > > > Sorry for the long winded email - I figured more info is better thanless> to > > get meaningful responses. > > > > Cheers > > Bhaskar > > > > > > > > > >
Reply by ●August 18, 20032003-08-18
"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 istrue,> 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 bufferis> full and continue that'll be great - I'd appreciate a confirmation ofthis.>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
Reply by ●August 18, 20032003-08-18
"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 DMAwill> > 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 synchto> > data independent mode and set the frame synch clock to my desired output > > rate. *If* the DMA can automatically pause every time the sport TXbuffer> 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. Sameis> 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 > >