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. �����������������������������������������������������������������������
Sample code for data acquisition
Started by ●July 16, 2003
Reply by ●July 25, 20032003-07-25
Reply by ●July 25, 20032003-07-25
If this message was to make some fun....there are many aces in this group(Jerry,Bhasker,ajith....list goes on)who just never ridicule...u may be an ace at ur edge...I wonder how one could become an professional before passing through the beginners stage(thatz me)....may be u could kindly throw some light on this... Jerry Avins <jya@ieee.org> wrote in message news:<3F217313.1A370ACA@ieee.org>...> 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 ●July 27, 20032003-07-27
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 ●July 27, 20032003-07-27
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...
Somewhere at the start (like about 2 weeks ago I suppose), there was a
request for sample code for using TCB's. Did anyone provide this (or
did we go down the path of "its a better educational experience to make
you do it yourself")?
Well anyhow, "Here's one I prepared earlier". I doubt very much the
page numbers would line up with your data book! In my example, I've got
2 TCBs pointing back to themselves (to separate unrelated processes).
For 'ping-pong' buffers, you make the 2 tcbs point to the 'other' tcb in
parameter pCP.
Spiro
struct tcb_struct { // p6-39 the tcb parameter block is used for
"chaining" DMA requests
int pECEP;
int pEMEP;
int pEIEP;
int pGP; // general purpose DMA register
int pCP; // address of next tcb block
int pC; // count
int pIM; // memory increment step size
int pII; // buffer address
} sport0A_tcb, sport0B_tcb;
void Codec_Init(void)
{
// Init DMA SPORT0
* (int *) SRCTL0 = 0x013C20f3; // p 9-23. enable spa, dma, chaining
// see p6-40 about why you need to mask with 1ffff and
// then set bit 200000
sport0A_tcb.pCP = (((int)(&sport0A_tcb)+7) & 0x1FFFF) | 0x20000;
sport0A_tcb.pC = 6; // DMA character count
sport0A_tcb.pIM = 1; // DMA memory pointer increment step size
sport0A_tcb.pII =(int)_DMA_buff1_in;// DMA receive buffer address
// start dma by writing address of tcb to chain reg
* (int *) CPR0A = sport0A_tcb.pCP;
// see p6-40 about why you need to mask with 1ffff and
// then set bit 200000
sport0B_tcb.pCP = (((int)(&sport0B_tcb)+7) & 0x1FFFF) | 0x20000;
sport0B_tcb.pC = 6;
sport0B_tcb.pIM = 1;
sport0B_tcb.pII =(int)DMA_buff2_in;// DMA receive buffer address
// start dma by writing address of tcb to chain reg
* (int *) CPR0B = sport0B_tcb.pCP;
}
--
http://www.mobilecomms.com.au
http://www.nexiondata.com
Reply by ●July 28, 20032003-07-28
Dear Spiro
i also noticed the diversion of the subject in groups as
discussion is in progress. But i think that it will be helpful to
others for getting different dimension of the problem. Also in the
groups, i found that there is lots of harsh word usage, when some one
asks some simple questions (collectively named as home work question
by some techie). i think it will be more helpful for the most cases if
some one provides a good start point for approaching the problem along
with the sarcasm. since most of the people are very new to the
subject. so their level of thinking is very much different from others
like a experienced one. Also spoon-feeding is not a good solution for
them to achieve success in their career. Also i wish to point out that
none of them are Gurus in any field and i personally think that some
of them who visit in the groups are very junior with less experienced
both in practical and theoretical knowledge, like me. i think some
others are very old and good experienced people. They are their own
idea to direct others. i am not say that they are correct always,
since mankind is itself imperfect. so if they make some mistakes,
others should have the brave enough to point it out. but should keep
in mind of using language. The arrow which was fired, and the words
once used could not be retrieved (try to translate a proverb from
Indian mythology, this may not an exact translation but i think u got
what i meant). The above is completely my personal view.
Also some words about the problem which sanjana had
posted. From reading the problem, what i understood was she/he was
not lack of the sample code (even though the subject line is like that
and it is more evident from the following discussion), instead she
wants to know whether is it possible to acquire and process the data
within the limited time span and I think that she had her own method
to acquire and process the data. Also a simple search on the ADI web
site will gives lots of example code. i think bhasker had mentioned
this in one of his reply.
regards
ajith
Spiro <HOUSTON_we_have_a_problem@127.0.0.1> wrote in message news:<MPG.198f00d1b0fee290989680@news-server.bigpond.net.au>...
> 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...
>
> Somewhere at the start (like about 2 weeks ago I suppose), there was a
> request for sample code for using TCB's. Did anyone provide this (or
> did we go down the path of "its a better educational experience to make
> you do it yourself")?
>
> Well anyhow, "Here's one I prepared earlier". I doubt very much the
> page numbers would line up with your data book! In my example, I've got
> 2 TCBs pointing back to themselves (to separate unrelated processes).
> For 'ping-pong' buffers, you make the 2 tcbs point to the 'other' tcb in
> parameter pCP.
>
> Spiro
>
>
>
> struct tcb_struct { // p6-39 the tcb parameter block is used for
> "chaining" DMA requests
> int pECEP;
> int pEMEP;
> int pEIEP;
> int pGP; // general purpose DMA register
> int pCP; // address of next tcb block
> int pC; // count
> int pIM; // memory increment step size
> int pII; // buffer address
> } sport0A_tcb, sport0B_tcb;
>
>
> void Codec_Init(void)
> {
> // Init DMA SPORT0
> * (int *) SRCTL0 = 0x013C20f3; // p 9-23. enable spa, dma, chaining
>
> // see p6-40 about why you need to mask with 1ffff and
> // then set bit 200000
> sport0A_tcb.pCP = (((int)(&sport0A_tcb)+7) & 0x1FFFF) | 0x20000;
> sport0A_tcb.pC = 6; // DMA character count
> sport0A_tcb.pIM = 1; // DMA memory pointer increment step size
> sport0A_tcb.pII =(int)_DMA_buff1_in;// DMA receive buffer address
> // start dma by writing address of tcb to chain reg
> * (int *) CPR0A = sport0A_tcb.pCP;
>
> // see p6-40 about why you need to mask with 1ffff and
> // then set bit 200000
> sport0B_tcb.pCP = (((int)(&sport0B_tcb)+7) & 0x1FFFF) | 0x20000;
> sport0B_tcb.pC = 6;
> sport0B_tcb.pIM = 1;
> sport0B_tcb.pII =(int)DMA_buff2_in;// DMA receive buffer address
> // start dma by writing address of tcb to chain reg
> * (int *) CPR0B = sport0B_tcb.pCP;
> }
Reply by ●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. �����������������������������������������������������������������������
Reply by ●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 �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 ●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 ●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. �����������������������������������������������������������������������
Reply by ●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'tgo 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 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 acquire 1024 > > > 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 how longit> > > 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. > > �����������������������������������������������������������������������
