In article <bg3mg3$kosvd$1@ID-82263.news.uni-berlin.de>, bhaskart@deja.com says...> Spiro - I've posted example code of chained DMAs atleast a couple of times > on this group - a google search would've found my earlier post. While sample > code of chained DMA would have answered Sanjana's very first question and > been terse, it would not have solved the real problem. > > Cheers > BhaskarHello Bhaskar, yes I see you have indeed. Generally speaking a second example is still useful (not as much as the first) - different comments, helpful similarities etc. As far as the real problem goes, I would suggest abandoning TCBs in favor of autobuffering and the 1/2 way DMA interrupt (check first if the processor has 1/2 way DMA interrupt). Its like having ping-pong buffers except without the TCB setup overhead. Instead of thinking about 2 buffers controlled by 2 TCB's, you think in terms of top and bottom halves of one big buffer. Spiro -- http://www.mobilecomms.com.au http://www.nexiondata.com
Sample code for data acquisition
Started by ●July 16, 2003
Reply by ●July 29, 20032003-07-29
Reply by ●August 11, 20032003-08-11
First of all Thanks to all for ur replies.... I was on Holiday and was not in sync with the thread.... The primary concern not using the internal memory is the memory available.... even if i employ ping-pong buffers for each bin(1bin=1024 points)the time to get 1bin into the int.mem is 1024/60MSPS is 17micro.sec...so for 391bins,17micro.sec*391=6.67m.sec..... whereas the time to calculate the 1024 point(1bin) FFT on board is 35 micro.sec..so in 6.67m.sec I would be able to process utmost 6.67msec/35.micro.sec=189bins about half.....and the rest I need to store on the on-borad memory for later processing....which is around 400KB((391-189)*2*1024)...whereas the on-board memory is 116KB......so that is makes me think of external memory....plz correct me if I am wrong...... Thank U all again Regards sanjana Ron Huizen <rhuizen@bittware.com> wrote in message news:<3F252D16.D8C53D11@bittware.com>...> Guys, > > Somewhere I think you've gotten off track on this thread. > > I'm sure I read somewhere in this thread a while ago that he > specifically said he was capturing a large block of data and wanted to > do FFTs on it. While capturing the data, instead of the processor > sitting idle until the large data block was captured to external memory, > he wanted to get started on the FFTs. Makes perfect sense to me. > Somewhere this info got lost and everyone started beating him up about > not being able to keep up in real-time ... > > ------ > Ron Huizen > BittWare > > Jerry Avins wrote: > > > > Bhaskar Thiagarajan wrote: > > > > ... > > > > > > Think about it... if you have a problem in internal memory, it won't go away > > > in external memory. > > > You are basically saying that the data is coming in too fast for your > > > processor to keep up real-time processing. So it doesn't matter what you do. > > > > Amen! > > > > > > Now, let me correct your calculations... > > > >1024*1/66.5MHZ..(15.398micro.sec)...but the fft on the > > > This is *not* the time it takes the DSP to collect 1024 points since you are > > > using the processor clock to calculate the time taken to acquire 1024 > > > points. This means your sampled data rate is equal to the processor clock, > > > which I doubt it true. If it is, then you'd better think about using an > > > FPGA. You need to use your sample rate from the A/D to figure how long it > > > will take to collect 1024 samples. > > > > > > Hope this helps > > > > > > Cheers > > > Bhaskar > > > > > ... > > It's easy to carry that further. Suppose it takes some number of cycles > > to acquire a sample. Let's take 10 cycles as a talking point. Than the > > acquisition time becomes 154 �sec., and the processing time being 35 > > �sec, that allows something under 200 �sec. to acquire and process the > > 1024 samples. Sampling at 5 Khz. is about all you can do that way. > > > > DMA can relieve the processor of the need to get and move the samples at > > the cost of some overhead. (Setting up the transfer, assigning the > > current buffer, etc.) Five �sec. ought to be plenty. then the sample > > rate could rise to 1/40 �sec., or 25 Khz. To go faster than that, you > > need a more modest goal. > > > > Jerry > > -- > > Engineering is the art of making what you want from things you can get. > > �����������������������������������������������������������������������
Reply by ●August 11, 20032003-08-11
"sanjana" <sanjana0706@yahoo.com> wrote in message news:ef48202a.0308111327.8bfcaed@posting.google.com...> First of all Thanks to all for ur replies.... > I was on Holiday and was not in sync with the thread.... > > The primary concern not using the internal memory is the memory > available.... > even if i employ ping-pong buffers for each bin(1bin=1024 points)the > time to get 1bin into the int.mem is 1024/60MSPS is 17micro.sec...soOK - just so that you make it abundantly clear. What is the sample rate (clock rate) of the A/D or codec you are using in your system?> for 391bins,17micro.sec*391=6.67m.sec..... whereas the time to > calculate the 1024 point(1bin) FFT on board is 35 micro.sec..so in > 6.67m.sec I would be able to process utmost > 6.67msec/35.micro.sec=189bins about half.....and the rest I need to > store on the on-borad memory for later processing....which is around > 400KB((391-189)*2*1024)...whereas the on-board memory is 116KB......so > that is makes me think of external memory....plz correct me if I am > wrong...... > > Thank U all again > Regards > sanjana > > > Ron Huizen <rhuizen@bittware.com> wrote in messagenews:<3F252D16.D8C53D11@bittware.com>...> > Guys, > > > > Somewhere I think you've gotten off track on this thread. > > > > I'm sure I read somewhere in this thread a while ago that he > > specifically said he was capturing a large block of data and wanted to > > do FFTs on it. While capturing the data, instead of the processor > > sitting idle until the large data block was captured to external memory, > > he wanted to get started on the FFTs. Makes perfect sense to me. > > Somewhere this info got lost and everyone started beating him up about > > not being able to keep up in real-time ... > > > > ------ > > Ron Huizen > > BittWare > > > > Jerry Avins wrote: > > > > > > Bhaskar Thiagarajan wrote: > > > > > > ... > > > > > > > > Think about it... if you have a problem in internal memory, it won'tgo away> > > > in external memory. > > > > You are basically saying that the data is coming in too fast foryour> > > > processor to keep up real-time processing. So it doesn't matter whatyou do.> > > > > > Amen! > > > > > > > > Now, let me correct your calculations... > > > > >1024*1/66.5MHZ..(15.398micro.sec)...but the fft on the > > > > This is *not* the time it takes the DSP to collect 1024 points sinceyou are> > > > using the processor clock to calculate the time taken to acquire1024> > > > points. This means your sampled data rate is equal to the processorclock,> > > > which I doubt it true. If it is, then you'd better think about usingan> > > > FPGA. You need to use your sample rate from the A/D to figure howlong it> > > > will take to collect 1024 samples. > > > > > > > > Hope this helps > > > > > > > > Cheers > > > > Bhaskar > > > > > > > ... > > > It's easy to carry that further. Suppose it takes some number ofcycles> > > to acquire a sample. Let's take 10 cycles as a talking point. Than the > > > acquisition time becomes 154 �sec., and the processing time being 35 > > > �sec, that allows something under 200 �sec. to acquire and process the > > > 1024 samples. Sampling at 5 Khz. is about all you can do that way. > > > > > > DMA can relieve the processor of the need to get and move the samplesat> > > the cost of some overhead. (Setting up the transfer, assigning the > > > current buffer, etc.) Five �sec. ought to be plenty. then the sample > > > rate could rise to 1/40 �sec., or 25 Khz. To go faster than that, you > > > need a more modest goal. > > > > > > Jerry > > > -- > > > Engineering is the art of making what you want from things you canget.> > >�����������������������������������������������������������������������
Reply by ●August 12, 20032003-08-12
The sample rate is 60MSPS... "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message news:<bh92cc$vsg5d$1@ID-82263.news.uni-berlin.de>...> "sanjana" <sanjana0706@yahoo.com> wrote in message > news:ef48202a.0308111327.8bfcaed@posting.google.com... > > First of all Thanks to all for ur replies.... > > I was on Holiday and was not in sync with the thread.... > > > > The primary concern not using the internal memory is the memory > > available.... > > even if i employ ping-pong buffers for each bin(1bin=1024 points)the > > time to get 1bin into the int.mem is 1024/60MSPS is 17micro.sec...so > > OK - just so that you make it abundantly clear. What is the sample rate > (clock rate) of the A/D or codec you are using in your system? > > > for 391bins,17micro.sec*391=6.67m.sec..... whereas the time to > > calculate the 1024 point(1bin) FFT on board is 35 micro.sec..so in > > 6.67m.sec I would be able to process utmost > > 6.67msec/35.micro.sec=189bins about half.....and the rest I need to > > store on the on-borad memory for later processing....which is around > > 400KB((391-189)*2*1024)...whereas the on-board memory is 116KB......so > > that is makes me think of external memory....plz correct me if I am > > wrong...... > > > > Thank U all again > > Regards > > sanjana > > > > > > Ron Huizen <rhuizen@bittware.com> wrote in message > news:<3F252D16.D8C53D11@bittware.com>... > > > Guys, > > > > > > Somewhere I think you've gotten off track on this thread. > > > > > > I'm sure I read somewhere in this thread a while ago that he > > > specifically said he was capturing a large block of data and wanted to > > > do FFTs on it. While capturing the data, instead of the processor > > > sitting idle until the large data block was captured to external memory, > > > he wanted to get started on the FFTs. Makes perfect sense to me. > > > Somewhere this info got lost and everyone started beating him up about > > > not being able to keep up in real-time ... > > > > > > ------ > > > Ron Huizen > > > BittWare > > > > > > Jerry Avins wrote: > > > > > > > > Bhaskar Thiagarajan wrote: > > > > > > ... > > > > > > > > > > Think about it... if you have a problem in internal memory, it won't > go away > > > > > in external memory. > > > > > You are basically saying that the data is coming in too fast for > your > > > > > processor to keep up real-time processing. So it doesn't matter what > you do. > > > > > > > > Amen! > > > > > > > > > > Now, let me correct your calculations... > > > > > >1024*1/66.5MHZ..(15.398micro.sec)...but the fft on the > > > > > This is *not* the time it takes the DSP to collect 1024 points since > you are > > > > > using the processor clock to calculate the time taken to acquire > 1024 > > > > > points. This means your sampled data rate is equal to the processor > clock, > > > > > which I doubt it true. If it is, then you'd better think about using > an > > > > > FPGA. You need to use your sample rate from the A/D to figure how > long it > > > > > will take to collect 1024 samples. > > > > > > > > > > Hope this helps > > > > > > > > > > Cheers > > > > > Bhaskar > > > > > > > > > ... > > > > It's easy to carry that further. Suppose it takes some number of > cycles > > > > to acquire a sample. Let's take 10 cycles as a talking point. Than the > > > > acquisition time becomes 154 �sec., and the processing time being 35 > > > > �sec, that allows something under 200 �sec. to acquire and process the > > > > 1024 samples. Sampling at 5 Khz. is about all you can do that way. > > > > > > > > DMA can relieve the processor of the need to get and move the samples > at > > > > the cost of some overhead. (Setting up the transfer, assigning the > > > > current buffer, etc.) Five �sec. ought to be plenty. then the sample > > > > rate could rise to 1/40 �sec., or 25 Khz. To go faster than that, you > > > > need a more modest goal. > > > > > > > > Jerry > > > > -- > > > > Engineering is the art of making what you want from things you can > get. > > > > > �����������������������������������������������������������������������
Reply by ●August 12, 20032003-08-12
"sanjana" <sanjana0706@yahoo.com> wrote in message news:ef48202a.0308120535.793048f5@posting.google.com...> The sample rate is 60MSPS...In which case, you are probably using the wrong architecture for your application...that's a really high sample rate. If you are using a Sharc - it's not possible to get data into the DSP (or external memory) at that rate. I don't know about the BlackFin but I suspect it's going to be pretty close if not impossible.> "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in messagenews:<bh92cc$vsg5d$1@ID-82263.news.uni-berlin.de>...> > "sanjana" <sanjana0706@yahoo.com> wrote in message > > news:ef48202a.0308111327.8bfcaed@posting.google.com... > > > First of all Thanks to all for ur replies.... > > > I was on Holiday and was not in sync with the thread.... > > > > > > The primary concern not using the internal memory is the memory > > > available.... > > > even if i employ ping-pong buffers for each bin(1bin=1024 points)the > > > time to get 1bin into the int.mem is 1024/60MSPS is 17micro.sec...so > > > > OK - just so that you make it abundantly clear. What is the sample rate > > (clock rate) of the A/D or codec you are using in your system? > > > > > for 391bins,17micro.sec*391=6.67m.sec..... whereas the time to > > > calculate the 1024 point(1bin) FFT on board is 35 micro.sec..so in > > > 6.67m.sec I would be able to process utmost > > > 6.67msec/35.micro.sec=189bins about half.....and the rest I need to > > > store on the on-borad memory for later processing....which is around > > > 400KB((391-189)*2*1024)...whereas the on-board memory is 116KB......so > > > that is makes me think of external memory....plz correct me if I am > > > wrong...... > > > > > > Thank U all again > > > Regards > > > sanjana > > > > > > > > > Ron Huizen <rhuizen@bittware.com> wrote in message > > news:<3F252D16.D8C53D11@bittware.com>... > > > > Guys, > > > > > > > > Somewhere I think you've gotten off track on this thread. > > > > > > > > I'm sure I read somewhere in this thread a while ago that he > > > > specifically said he was capturing a large block of data and wantedto> > > > do FFTs on it. While capturing the data, instead of the processor > > > > sitting idle until the large data block was captured to externalmemory,> > > > he wanted to get started on the FFTs. Makes perfect sense to me. > > > > Somewhere this info got lost and everyone started beating him upabout> > > > not being able to keep up in real-time ... > > > > > > > > ------ > > > > Ron Huizen > > > > BittWare > > > > > > > > Jerry Avins wrote: > > > > > > > > > > Bhaskar Thiagarajan wrote: > > > > > > > > ... > > > > > > > > > > > > Think about it... if you have a problem in internal memory, itwon't> > go away > > > > > > in external memory. > > > > > > You are basically saying that the data is coming in too fast for > > your > > > > > > processor to keep up real-time processing. So it doesn't matterwhat> > you do. > > > > > > > > > > Amen! > > > > > > > > > > > > Now, let me correct your calculations... > > > > > > >1024*1/66.5MHZ..(15.398micro.sec)...but the fft on the > > > > > > This is *not* the time it takes the DSP to collect 1024 pointssince> > you are > > > > > > using the processor clock to calculate the time taken to acquire > > 1024 > > > > > > points. This means your sampled data rate is equal to theprocessor> > clock, > > > > > > which I doubt it true. If it is, then you'd better think aboutusing> > an > > > > > > FPGA. You need to use your sample rate from the A/D to figurehow> > long it > > > > > > will take to collect 1024 samples. > > > > > > > > > > > > Hope this helps > > > > > > > > > > > > Cheers > > > > > > Bhaskar > > > > > > > > > > > ... > > > > > It's easy to carry that further. Suppose it takes some number of > > cycles > > > > > to acquire a sample. Let's take 10 cycles as a talking point. Thanthe> > > > > acquisition time becomes 154 �sec., and the processing time being35> > > > > �sec, that allows something under 200 �sec. to acquire and processthe> > > > > 1024 samples. Sampling at 5 Khz. is about all you can do that way. > > > > > > > > > > DMA can relieve the processor of the need to get and move thesamples> > at > > > > > the cost of some overhead. (Setting up the transfer, assigning the > > > > > current buffer, etc.) Five �sec. ought to be plenty. then thesample> > > > > rate could rise to 1/40 �sec., or 25 Khz. To go faster than that,you> > > > > need a more modest goal. > > > > > > > > > > Jerry > > > > > -- > > > > > Engineering is the art of making what you want from things you can > > get. > > > > > > > �����������������������������������������������������������������������
