hi, i am trying to implement the circular buffering mechanism in a c code using pointers for one of the applications. can anyone explain to me an efficient algorithm (instruction cycles wise) to implement this. thanks in advance, kunal This message was sent using the Comp.DSP web interface on www.DSPRelated.com
circular buffering C code
Started by ●March 16, 2005
Reply by ●March 16, 20052005-03-16
dsp_rookie wrote:> hi, > i am trying to implement the circular buffering mechanism in a c code > using pointers for one of the applications. can anyone explain to me an > efficient algorithm (instruction cycles wise) to implement this. > > thanks in advance, > kunal > > This message was sent using the Comp.DSP web interface on > www.DSPRelated.comIt depends greatly on the processor you're writing for. If your processor supports circular buffers in hardware and you don't use that support, you waste cycles, memory, or both. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●March 16, 20052005-03-16
"dsp_rookie" <mk_gandhi4@yahoo.com> writes:> hi, > i am trying to implement the circular buffering mechanism in a c code > using pointers for one of the applications. can anyone explain to me an > efficient algorithm (instruction cycles wise) to implement this.The easiest thing I know to do is make your buffer size 2^M. Then updating the index is done by ANDing it with 2^M - 1. -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://home.earthlink.net/~yatescr
Reply by ●March 17, 20052005-03-17
On Wed, 2005-03-16 at 19:09 -0600, dsp_rookie wrote:> hi, > i am trying to implement the circular buffering mechanism in a c code > using pointers for one of the applications. can anyone explain to me an > efficient algorithm (instruction cycles wise) to implement this.Jack Ganssle had some code in his newsletter "The Embedded Muse" a few issues ago. He clarified a few things in the next issue as well. You might want to take a look at it. I think the URL is www.ganssle.com. I hope I'm spelling his name correctly--forgive me Jack if I'm butchering it. Cheers.
Reply by ●March 17, 20052005-03-17
in article 4qfb3ql0.fsf@ieee.org, Randy Yates at yates@ieee.org wrote on 03/16/2005 22:21:> "dsp_rookie" <mk_gandhi4@yahoo.com> writes: > >> hi, >> i am trying to implement the circular buffering mechanism in a c code >> using pointers for one of the applications. can anyone explain to me an >> efficient algorithm (instruction cycles wise) to implement this. > > The easiest thing I know to do is make your buffer size 2^M. Then updating > the index is done by ANDing it with 2^M - 1.i second this advice. if your coding in ANSI C (the C for DCSP chips have a few non-ASNI extensions), the easiest foolproof way to do it is to have your buffers as big as a power of two (say, 0x00010000), and then *every* time your index is incremented or adjusted, mask it with one less (0x0000FFFF), and you'll always stay in your buffer. if you're doing a long FIR filter with this technique, there is another trick you can use so that you don't have to mask each and every time the pointer moves, but you have a counter telling you where you are in the buffer. is that what you're doing. if you're doing cascaded biquad IIR filters, you don't need a circular buffer. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●March 17, 20052005-03-17
If I may ask, why code Circular buffer in C at all? Assuming you are using a DSP chip for your programming, there is bound to be a hardware circular buffer which can be programmed only through assembly.From your question I infer that you are worried about cycles and if you are then you shd be choosing to code in assembly.Thats your best bet. In fact strictly speaking circula buffer is precisely one of the reasons for you to choose assembly over C. --Bhooshan This message was sent using the Comp.DSP web interface on www.DSPRelated.com
Reply by ●March 17, 20052005-03-17
in article HZudnepsv95WW6TfRVn-tg@giganews.com, bhooshaniyer at bhooshaniyer@gmail.com wrote on 03/17/2005 13:04:> If I may ask, why code Circular buffer in C at all? Assuming you are > using a DSP chip for your programming,it's a fine question to ask but that is actually a rather big assumption. still, a lot of DSP is done "native", as it should be. why should consumers have to buy an extra outboard DSP board when their Pentium or Power PC chip can do whatever the processing is, just fine? if you are using VC++ or Code Warrior running on a PC or Mac to do your DSP, *you* have to worry about pointer (or array index) wrap-around because the hardware will not. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●March 17, 20052005-03-17
"James Morrison" <spam1@emorrison.ca> wrote in message news:1111033232.16006.25.camel@oxygen.emorrison.ca...> On Wed, 2005-03-16 at 19:09 -0600, dsp_rookie wrote: >> hi, >> i am trying to implement the circular buffering mechanism in a c code >> using pointers for one of the applications. can anyone explain to me an >> efficient algorithm (instruction cycles wise) to implement this. > > Jack Ganssle had some code in his newsletter "The Embedded Muse" a few > issues ago. He clarified a few things in the next issue as well. > > You might want to take a look at it. I think the URL is > www.ganssle.com. I hope I'm spelling his name correctly--forgive me > Jack if I'm butchering it.I looked it up but couldn't find the "clarified" part. It seems the article was in the last issue posted on the site. ?? Fred
Reply by ●March 17, 20052005-03-17
"robert bristow-johnson" <rbj@audioimagination.com> wrote in message news:BE5F3876.5581%rbj@audioimagination.com...> in article HZudnepsv95WW6TfRVn-tg@giganews.com, bhooshaniyer at > bhooshaniyer@gmail.com wrote on 03/17/2005 13:04: > >> If I may ask, why code Circular buffer in C at all? Assuming you are >> using a DSP chip for your programming, > > it's a fine question to ask but that is actually a rather big assumption. > still, a lot of DSP is done "native", as it should be. why should > consumers > have to buy an extra outboard DSP board when their Pentium or Power PC > chip > can do whatever the processing is, just fine? if you are using VC++ or > Code > Warrior running on a PC or Mac to do your DSP, *you* have to worry about > pointer (or array index) wrap-around because the hardware will not. > > -- > > r b-j rbj@audioimagination.comThis is probably the "wrong" time or place to mention this because of the group's likely bias but nonetheless since this is *not* comp.dspchip. But, to expand on rb-j's point: When I'm managing software developers I insist that they *not* use assembler - well .... without very good reason. Compilers have a lot of good attributes - including the ability to generate more efficient code than humans in many cases. To what degree this is true for DSP chips is likely variable. The real motive is that assembler is a lot harder / more expensive to maintain. So, if you're a loner and will live with the code forever then maybe that's OK for you. But if you will have to revisit the code after 5 years or if someone else will have to do the same, then you really have to think about it. OK - maybe for a circular buffer it might be warranted. But I wouldn't start there! We used to say that code should be made efficient after it's written (OK - that doesn't include dumb design) because bottlenecks are easier to instrument than to predict. Is that still a valid / valued viewpoint? If so, maybe after knowing where the bottlenecks are it could be justified going to assembler in those cases that don't yield? Now don't gimme no "he man" talk y'hear? Fred
Reply by ●March 17, 20052005-03-17
Fred Marshall wrote: ...> We used to say that code should be made efficient after it's written (OK - > that doesn't include dumb design) because bottlenecks are easier to > instrument than to predict. Is that still a valid / valued viewpoint? If > so, maybe after knowing where the bottlenecks are it could be justified > going to assembler in those cases that don't yield? > > Now don't gimme no "he man" talk y'hear?Aw, Fred: If I wanted to be a he man, I'd write it all in Fortran. :-) I don't like in-line assembly for production work for all the reasons you give. I'd rather write a well documented C-callable assembly function that can be rewritten for any subsequent port or other modification. That way makes for a smoother interface. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
