Reply by Bernhard Holzmayer July 22, 20032003-07-22
QBA wrote:

> Or you can do it using firmware... > Before entering ISR or busy section of code, you increment a > counter, and before entering idle section of code, you increment > another counter. Use you timer interrupt handler to keep track > these two numbers and let your application run for however long > you think is necessary, do little math and you will have your > answer. > > I did this on an ADSP-21062 communication/data acquisition project > to ensure it had adequate throughput. Very little code overhead > to implementing these counters and a timer interrupt. > > Ching Wang > QBA Technologies, Inc. > DSP, FPGA, Firmware and Software >
Yes, it's a good approach, too. I use it every now and then. However, if processing has different paths and thus varying timing requirements, you have to deal with dynamic head-room in an interrupt service routine which might change at every sample. I found it much easier to monitor it with a scope, especially if the scope is able to visualize every occurrence as an overlay (infinite persistence). Last not least: I can use this method without a debugger, if my board has a single I/O pin left (which usually is the case). Bernhard -- before sending to the above email-address: replace deadspam.com by foerstergroup.de
Reply by QBA July 22, 20032003-07-22
Or you can do it using firmware...
Before entering ISR or busy section of code, you increment a counter, and
before entering idle section of code, you increment another counter. Use you
timer interrupt handler to keep track these two numbers and let your
application run for however long you think is necessary, do little math and
you will have your answer.

I did this on an ADSP-21062 communication/data acquisition project  to
ensure it had adequate throughput. Very little code overhead to implementing
these counters and a timer interrupt.

Ching Wang
QBA Technologies, Inc.
DSP, FPGA, Firmware and Software

"Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
news:1660145.tqHvZPx07z@holzmayer.ifr.rt...
> Zach R. wrote: > > > I am a new DSPer who is using a blackfin 535 ez-kit. I am trying > > to implement a program which requires streaming audio and am > > troubleshooting. How much processing can this chip support before > > it will no longer be able > > to stream the audio? Thanks, Zach > > Hi Zach, > what I did to find out: > set up the raw streaming environment: ADC-DSP-DAC or whatever it is. > every time the DSP enters the interrupt service routine for sample > (or block) processing, you set a flag (I use an LED on the board). > When the interrupt service routine is left, you remove the flag. > > Take an oscilloscope, measure the ratio of the flag: ON/(ON+OFF) and > you'll have a measure: > a ratio of '0' is an idle DSP, > '1' would mean there's no processor time left, > '0.7' might be a sound value if your application is complete. > > Bernhard > > -- > before sending to the above email-address: > replace deadspam.com by foerstergroup.de
Reply by Matthew Donadio July 16, 20032003-07-16
On Wed, 16 Jul 2003 11:00:16 -0700, Andor wrote:
> PS: There used to be this DSP-Zen guy around (Dr. Zen?). I'm sure he > would approve :).
That would be the illustrious Reverend Sigmund Zen. -- Matthew Donadio (m.p.donadio@ieee.org)
Reply by Andor July 16, 20032003-07-16
Jesper Buch wrote:
...
> Zach R. wrote: > > I am a new DSPer who is using a blackfin 535 ez-kit. I am trying to > > implement a program which requires streaming audio and am troubleshooting. > > How much processing can this chip support before it will no longer be able > > to stream the audio? Thanks, Zach > > There is no such answer.
In fact, there is just the right answer, but it is reserved for Zen masters to reply to impetuous Zen students. The answer is "mu" (not the micro-mu, and also not the feared "ni"). This word kind of "unasks" the question. Neat, isn't it? To Zach: Instead of saying "mu", I say "It depends", which is almost as efficient. Divide the instruction rate of the Blackfin by the sampling rate of the audio, and you get the number of instructions you have to process an audio sample. Now look at the (worst case) number of instructions your algorithm takes for a sample, and you have a real answer. Regards, Andor PS: There used to be this DSP-Zen guy around (Dr. Zen?). I'm sure he would approve :).
Reply by Bernhard Holzmayer July 16, 20032003-07-16
Zach R. wrote:

> I am a new DSPer who is using a blackfin 535 ez-kit. I am trying > to implement a program which requires streaming audio and am > troubleshooting. How much processing can this chip support before > it will no longer be able > to stream the audio? Thanks, Zach
Hi Zach, what I did to find out: set up the raw streaming environment: ADC-DSP-DAC or whatever it is. every time the DSP enters the interrupt service routine for sample (or block) processing, you set a flag (I use an LED on the board). When the interrupt service routine is left, you remove the flag. Take an oscilloscope, measure the ratio of the flag: ON/(ON+OFF) and you'll have a measure: a ratio of '0' is an idle DSP, '1' would mean there's no processor time left, '0.7' might be a sound value if your application is complete. Bernhard -- before sending to the above email-address: replace deadspam.com by foerstergroup.de
Reply by Jesper Buch July 16, 20032003-07-16
"Zach R." <zrimkunas@verizon.net> skrev i en meddelelse
news:E62Ra.164$0F4.78@nwrdny02.gnilink.net...
> I am a new DSPer who is using a blackfin 535 ez-kit. I am trying to > implement a program which requires streaming audio and am troubleshooting. > How much processing can this chip support before it will no longer be able > to stream the audio? Thanks, Zach
There is no such answer. It depends on what you do and how you do it.
Reply by Zach R. July 15, 20032003-07-15
I am a new DSPer who is using a blackfin 535 ez-kit.  I am trying to
implement a program which requires streaming audio and am troubleshooting.
How much processing can this chip support before it will no longer be able
to stream the audio?  Thanks,  Zach