Searching \ for 'Circular Buffer Help' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=circular+buffer
Search entire site for: 'Circular Buffer Help'.

Truncated match.
PICList Thread
'Circular Buffer Help'
1998\04\26@155402 by Tom Handley

picon face
  I would really like to hear from you software `Gurus' on this...

  Given a 32K Byte SRAM circular buffer, a `trigger-event', and a fixed
delay count after the event, I would like to know the best method of
determining when the event' occurred.

  One method would subtract the delay count from 32K and use the result to
clock the SRAM address counter to point to the event.

  Another method is reading the current SRAM address counter and
subtracting the delay to get an absolute pointer to the event.

  In any case, You are working with the relative offset from the event.
Both methods will provide a pointer to the event using simple math. My
question is; do you really need to read the counter address in this
application? From a software standpoint, is there any advantage?

  This has a direct impact on my PIC-based logic analyzer project and I
would like to `nail this down' as I can save resources with the first method.
Thanks,

  - Tom

1998\04\27@071101 by Caisson

flavicon
face
> Van: Tom Handley <spam_OUTthandleyTakeThisOuTspamTELEPORT.COM>
> Aan: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Onderwerp: Circular Buffer Help
> Datum: zondag 26 april 1998 21:51
>
>    I would really like to hear from you software `Gurus' on this...

Oh, Jolly !  Now I can pose as a 'Guru' ;-)

>    Given a 32K Byte SRAM circular buffer, a `trigger-event', and a fixed
> delay count after the event, I would like to know the best method of
> determining when the event' occurred.
>
>    One method would subtract the delay count from 32K and use the result
to
> clock the SRAM address counter to point to the event.

This method is usable, although you will be referring to the Adress-counter
as in the next example.  It'll take more time though, 16K clock's take some
amount of time ...  And what if you want to have more samples _before_ the
event than _after_ (say 90% before and 10% after) ...

>    Another method is reading the current SRAM address counter and
> subtracting the delay to get an absolute pointer to the event.

This method is quite fast, because you only have to do a simple 16-bit
subtraction/addition.  And that for any event-delay.

>    In any case, You are working with the relative offset from the event.
> Both methods will provide a pointer to the event using simple math. My
> question is; do you really need to read the counter address in this
> application? From a software standpoint, is there any advantage?

No, you don't have to.  But it will be quickest. _and_ you will have an
absulute reference.  (Two counters, one in hardware & one in software
_could_ get out-of-sync ...)

>    This has a direct impact on my PIC-based logic analyzer project and I
> would like to `nail this down' as I can save resources with the first
method.
> Thanks,
>
>    - Tom

Greetz,
 Rudy Wieser

1998\04\27@101243 by Tom Handley

picon face
  Rudy, thanks for the feedback. I agree that the ability to read the
absolute address is a plus. Note, the current design does this. That
particular CPLD contains the address counter and control circuitry to read
the counter as well as the SRAMs. By eliminating the need to read the
absolute address, I could move the counter to a single 74x393 and free up a
lot of CPLD resources for other functions, possibly reducing the design from
3 CPLDs to 2.

[concerning the first method without an absolute address]
>This method is usable, although you will be referring to the Adress-counter
>as in the next example.  It'll take more time though, 16K clock's take some
>amount of time ...  And what if you want to have more samples _before_ the
>event than _after_ (say 90% before and 10% after) ...
>...................  (Two counters, one in hardware & one in software
>_could_ get out-of-sync ...)

  The delays are fixed at 1, 16, 64, 256, 1024, 4096, 16384, and 32768
Bytes. The host still has to read 32K Bytes. My thought was to subtract the
fixed delay from 32K and clock the result into the host buffer. At that
point you would have a pointer to the trigger in the host buffer. Then you
would clock in the remaining Bytes. With the absolute address, the host
would first read the address, then reset the counter and read 32K. Once the
captured data is in the host, it seems to me that the host software would
have to do similar math to look at events before and after the trigger. I'm
not too concerned about the hardware counter and the host pointer getting
out of sync if the hardware design is `clean'. Still, I'm leaning towards
providing the absolute address.

  - Tom

At 11:42 AM 4/27/98 +0200, Rudy Wieser wrote:
{Quote hidden}

1998\04\28@071928 by Caisson

flavicon
face
> Van: Tom Handley <EraseMEthandleyspam_OUTspamTakeThisOuTTELEPORT.COM>
> Aan: PICLISTspamspam_OUTMITVMA.MIT.EDU
> Onderwerp: Re: Circular Buffer Help
> Datum: maandag 27 april 1998 16:04

Hello Tom,

>    Rudy, thanks for the feedback. I agree that the ability to read the
> absolute address is a plus. Note, the current design does this. That
> particular CPLD contains the address counter and control circuitry to
read
> the counter as well as the SRAMs. By eliminating the need to read the
> absolute address, I could move the counter to a single 74x393 and free up
a
> lot of CPLD resources for other functions, possibly reducing the design
from
> 3 CPLDs to 2.

[Cut]

Oh ...  I was thinking you wanted to build a stand-alone device, but I
understand now that you are designing a sort of PC-probe.

O.k.  Why not give the PC the data as-is ?   At the next adres would be
the first valid sample.  Clock 32K times and your buffer is send to the
host
in the most usefull way there is.  The first valid sample at offset 0 in
the
Host-buffer. Just send the event-delay value as special data to your host.
The Trigger-Event would be at that offset in the Host-buffer.

In this way you would not need an absolute adres into your sample-buffer.
This would even mean that resetting the hardware adress-counter is not
needed anymore ...

Greetz,
 Rudy Wieser

1998\04\28@170430 by ape

flavicon
face
> This method is quite fast, because you only have to do a simple 16-bit
> subtraction/addition.  And that for any event-delay.
>
> >    In any case, You are working with the relative offset from the event.
> > Both methods will provide a pointer to the event using simple math. My
> > question is; do you really need to read the counter address in this
> > application? From a software standpoint, is there any advantage?
>

Correct me if I'm wrong but whenever I have used a circular buffer, I get to
the top of
my memory map and rollover back the the start of my memory map.  My current
location is my latest sample, and the next highest byte is my oldest data.  If
your 'trigger
event' occured BEFORE you rolled over, it would no longer be SIMPLE math.  What
would be wrong with haveing the 'trigger event' run a simple interupt that
simply stores
a counter location to RAM?

P.S. My programming knowledge far exceeds my PIC knowledge (which doesn't
say much).

1998\04\28@172253 by Andrew Warren

face
flavicon
face
Mark Devin Newland <@spam@apeKILLspamspameskimo.com> wrote:

> Correct me if I'm wrong....

   Ok.

> .... but whenever I have used a circular buffer, I get to the top
> of my memory map and rollover back the the start of my memory map.
> My current location is my latest sample, and the next highest byte
> is my oldest data.  If your 'trigger event' occured BEFORE you
> rolled over, it would no longer be SIMPLE math.

   Sure it would, Mark... Look at these two examples:

       Buffer extends from 0000 to FFFF.  Trigger event occurred 5
       cycles ago.

       Example #1:  Current location = 9.

           Subtract 5 to find the trigger location:
           Trigger event occurred at 9 - 5 = 4.

       Example #2:  Current location = 2.

           Subtract 5 to find the trigger location:
           Trigger event occurred at 2 - 5 = -3 = FFFD.

   See?  It works even if your subtraction wraps around the buffer.

   -Andy

=== Andrew Warren - KILLspamfastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499 (personal)
=== http://www.netcom.com/~fastfwd (business)

1998\04\28@181700 by Tom Handley

picon face
  Rudy, I really should have posted this in my PIC-based Logic Analyzer
topic so it would have been easier to see where I was comming from.

  The host sends the delay count to the analyzer as part of the sample
request so it already knows the delay. Once `armed' the analyzer records
data in the circular buffer until a trigger event. Then a delay counter
is started. At the end of that count, the address counter clock is
disabled and the capture mode is complete. The host can monitor this.
I like your suggestion of clocking in 32K and then subracting the delay.
Last night I did another update to that particular CPLD and I was able to
eliminate 1 74x-family `glue' chip while retaining the capability to read
the absolute address. At this point, eliminating the address read-back
will not save anything so I'll keep it.

  - Tom

At 09:26 AM 4/28/98 +0200, you wrote:
{Quote hidden}


'Circular Buffer Help'
1998\05\04@033238 by Caisson
flavicon
face
> Van: Tom Handley <TakeThisOuTthandleyEraseMEspamspam_OUTTELEPORT.COM>
> Aan: RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU
> Onderwerp: Re: Circular Buffer Help
> Datum: woensdag 29 april 1998 0:10

Hello Tom,

>    Rudy, I really should have posted this in my PIC-based Logic Analyzer
> topic so it would have been easier to see where I was comming from.

Ah, I have to confess : I do not read every article that is posted ...
)-: It would take to much time ... :-(

>    The host sends the delay count to the analyzer as part of the sample
> request so it already knows the delay. Once `armed' the analyzer records
> data in the circular buffer until a trigger event. Then a delay counter
> is started. At the end of that count, the address counter clock is
> disabled and the capture mode is complete. The host can monitor this.

That is as much as I thought.  Good to know we are talking about the same
method of operation !

> I like your suggestion of clocking in 32K and then subracting the delay.
> Last night I did another update to that particular CPLD and I was able to
> eliminate 1 74x-family `glue' chip while retaining the capability to read
> the absolute address. At this point, eliminating the address read-back
> will not save anything so I'll keep it.
>
>    - Tom

Ehh .. Tom, something keeps nagging me :  Why do you need to be able
to read the absolute adres of the Sample-buffer ?  As you've seen, you
don't
really need it (anymore).

Greetz,
 Rudy Wieser

1998\05\06@044518 by Tom Handley

picon face
  Rudy, while I was designing the chip-set I was always concerned about
unforeseen software issues. One of those was the ability to know the
absolute (physical) trigger address. I've looked at several other designs
and some included it. I really did'nt think it was necessary but I added it
in case others might see a benefit. When a `gotcha' cropped up and it looked
like I was going to have to eliminate it or add a `glue' chip, I sought
opinions from the group. Some folks preferred the capability. I was able to
squeeze in some extra logic to cover the `gotcha' so I decided to retain it.
If I removed it, I would free-up 4 I/Os and 1 dedicated input. That may
allow me to fit the external decade clock prescaler in that chip. This would
eliminate 2 74x390s but, internally, that chip's resources are mostly
`exhausted'...

  From a software standpoint, it makes no difference if I keep it. It uses
4 states of a 12-state machine. The first 8 control reading data from the
SRAMs. If you ignore it, your host (PIC or PC) has one less control line to
deal with (3 state-select inputs vs. 4).

  - Tom

At 02:27 PM 4/29/98 +0200, Rudy Wieser wrote:
[snip]
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...