Reply by Bhaskar Thiagarajan 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 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 &#4294967295;sec., and the processing time being
35
> > > > > &#4294967295;sec, that allows something under 200 &#4294967295;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 &#4294967295;sec. ought to be plenty. then the
sample
> > > > > rate could rise to 1/40 &#4294967295;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. > > > > > > > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by sanjana 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 &#4294967295;sec., and the processing time being 35 > > > > &#4294967295;sec, that allows something under 200 &#4294967295;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 &#4294967295;sec. ought to be plenty. then the sample > > > > rate could rise to 1/40 &#4294967295;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. > > > > > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Bhaskar Thiagarajan 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...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 &#4294967295;sec., and the processing time being 35 > > > &#4294967295;sec, that allows something under 200 &#4294967295;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 &#4294967295;sec. ought to be plenty. then the sample > > > rate could rise to 1/40 &#4294967295;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.
> > >
&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by sanjana 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 &#4294967295;sec., and the processing time being 35 > > &#4294967295;sec, that allows something under 200 &#4294967295;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 &#4294967295;sec. ought to be plenty. then the sample > > rate could rise to 1/40 &#4294967295;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. > > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Spiro July 29, 20032003-07-29
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 > Bhaskar
Hello 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
Reply by Bhaskar Thiagarajan July 28, 20032003-07-28
"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.
Yes, what you wrote makes sense. But the OP wasn't saying this...which took a bit of time to figure out, after which we had to set her straight on her calculations. I thought the thread had pretty much made things crystal - not sure why more bytes are being thrown at it. 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 Bhaskar
> 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 &#4294967295;sec., and the processing time being 35 > > &#4294967295;sec, that allows something under 200 &#4294967295;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 &#4294967295;sec. ought to be plenty. then the sample > > rate could rise to 1/40 &#4294967295;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. > > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Jerry Avins July 28, 20032003-07-28
Ron Huizen wrote:
> > 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 >
... Ron, There were several -- and separable -- misconceptions in the original scheme. One was that a block of data suitable for FFTing had to be acquired in external memory, then moved to internal memory. Another was that the time to acquire a block was the block size times the processor clock rate, without accounting for the sample rate. A fresh look at the underlying assumptions of Sanjana's overall design seemed appropriate. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by sanjana July 28, 20032003-07-28
sorry for looking from a negative face.....atleast i m satisfied that
I m getting tuned...

an2or@mailcircuit.com (Andor) wrote in message news:<ce45f9ed.0307270352.21d173ff@posting.google.com>...
> sanjana wrote: > > If this message was to make some fun.... > > Sanjana, I did not want to make fun of you and I'm sorry if you > understood it that way. > > Your words described exactly what I feel everytime I design and debug > a DSP system: I work out some blueprint to solve a given task (line > 1), never quite sure whether it really works (line 2 and 3) and always > worrying about whether I can meet the tight timing specs required > (line 4). > > So you spoke out of my heart when you wrote what I quoted. Today is > Sunday, and instead of enjoying a nice day off I'm at work trying to > figure out some bug, and all I feel like is singing the DSP blues .... > :). > > Regards, > Andor > > > > > Andor wrote: > > > > > > > > sanjana wrote: > > > > > i have thought of procedure > > > > > > > > ta taa ta ta > > > > > > > > > but dont know whether that is feasible or not... > > > > > > > > ta taa ta ta > > > > > > > > > not sure whether its gonna work.... > > > > > > > > ta taa ta ta > > > > > > > > > i worry about the timings much.... > > > > > > > > ta taa ta ta > > > > > > > > etc. > > > > > > > > :) > > > > > > What's with you, Andor? A good rule -- few of us are good enough to > > > follow it all the time -- is to say nothing when there is nothing good > > > to say. It's the other end of the spectrum to indulge in unprovoked > > > ridicule when you have nothing to say at all, good or ill. I trust it > > > was an aberration, or humor gone awry. > > > > > > Jerry
Reply by Ron Huizen July 28, 20032003-07-28
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 &#4294967295;sec., and the processing time being 35 > &#4294967295;sec, that allows something under 200 &#4294967295;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 &#4294967295;sec. ought to be plenty. then the sample > rate could rise to 1/40 &#4294967295;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. > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Jerry Avins July 28, 20032003-07-28
Spiro wrote:
> > Damn I hate it when I'm happily following a thread and you (bastard) > gurus manage to lose me (and it happens all the bloody time). Maybe > after another 20 years of doing this stuff... >
... That looks like nice, straightforward code. Not being a guru, I can't certify its correctness. At this point in the discussion, exactly how to set up ping-pong buffers is way down the pike. At this point, we're trying to explain to the OP that when taking one sample every processor clock tick (he doesn't say how he might manage or wants to do that), there's no time left over to run an FFT. Even non gurus like us can take a stab at getting that across. By now, he's probably figured out for himself which of the numbers he took for granted are wrong, then we can get back to explaining why DMAing first into external memory, and after that buffer is full, transferring its contents to internal memory is unnecessary and has to be slower than DMAing into internal memory in the first place. Only then will the details of ping-pong buffering become relevant. To put a fancy name on it, the thread slid back a level to system design. It still addresses what the OP wants to do. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;