Searching \ for 'Cache ram/buffer ram howto??' 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=cache+rambuffer
Search entire site for: 'Cache ram/buffer ram howto??'.

Truncated match.
PICList Thread
'Cache ram/buffer ram howto??'
2003\02\18@202317 by michael brown

picon face
----- Original Message -----
From: "Tony Harris" <spam_OUTtonyTakeThisOuTspamELROYNET.COM>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Tuesday, February 18, 2003 6:13 PM
Subject: [ee]: Cache ram/buffer ram howto??


> Hi all,
>
> Ok, like most of my emails to this list - I'm kinda confused ;)
>
> I've noticed many projects that aquire data (pic based oscopes, data
> collection, etc.) store the values in RAM to be retrieved by the PIC
chip or
> by a comp connected to the overall device - while it is still
collecting
> data.
>
> So, my question is - let's say I have a circuit that based on a given
clock
> collects data from an input (a/d converter) and stores it in a RAM
chip -
> and I need to obtain that data to send out to a comp. or to display on
an
> LCD screen - on top of that I need to get the data fast enough before
the
> RAM overflows and starts back at the beginnign of the bank.  How do I
go
> about doing this?  Does anyone have any quality reference or
explanations on
> this topic?  Unfortunately, although I had seen tons of stuff I now
can't
> find the links and am lost :(.
>
> Any suggestions would help.
>
> I don't have any spectacular projects going on at the moment - mostly
it's
> just so I can setup a quick data logger to record voltage outputs so I
can
> see how the regulation is doing over time?

After writing much of this, and then rereading your post a couple of
times, I find that this may not describe exactly what you wish to do,
but maybe it will give you some ideas.  ;-)

Since you can't pour water in a pitcher faster than you pour it out,
without running it over, perhaps you may want to take a look at the
problem in reverse.  By determining the bandwidth of the most limiting
factor first, you will (hopefully) be able to avoid this situation.
From your description it sounds like you need to look at how fast you
can get data out of the PIC, and then look at setting your sampling
speed.  It sounds like in this case interrupts are going to be your
friend so that you can overlap some of the work.  This is usually the
case.  ;-)

For example, most of my projects involve displaying something on a
Hitachi type LCD screen.  Since I usually use 4 bit mode to write to the
display (instead of 8 bits at a time) to conserve I/O pins, this takes
an already bad problem and makes it worse.  The problem being the speed
at which the LCD operates.  This is exacerbated by using the "minimum
recommended" delays between I/O to the LCD.  If I drove the display by
this method, there would be virtually no time left to do anything else.
:-/

My solution to the problem is to put the LCD code in main level along
with any other non time-critical functions.  I also use the BUSY flag
feature of the LCD to drastically speed up the I/O.  Once I've done
that, I can do timing analysis and figure out just how fast the display
really is when being used as desired.  For example, the display is quite
fast, until I scroll it or clear it.  These processes take varying
amounts of time, so I really have to test it in the manner in which I
will be using it to get a good feel for what will work.

After I've done that, I can now calculate, with reasonable certainty,
just how fast I can feed it data.  Given that information, I can make a
fairly accurate calculation of the maximum sampling/baud rate that I
could use to collect data.  In the case of a time critical input stream
(like serial data), I use interrupts to handle reading the data as
efficiently as possible.

Bit-banged serial data, for example, can be received very efficiently by
using TMR interrupts to sample the bits at critical times and then
returning back to main level after each sample.  Once the entire byte
has been received, you simply pass it to the main level code and the LCD
routine will print it when it gets a chance.  As you've probably already
guessed, what shall I do if the main level hasn't processed it yet, but
I now have another piece of data to get displayed?

The answer?  Use a FIFO, circular queue or whatever you wish to call it.
This acts like a capacitor (in electrical terms) by providing a
smoothing function to the data flow.  Much serial data comes in bursts
of several characters at a time followed by a pause (e.g. GPS).  A FIFO
or queue will give you a place to stuff things until the main level has
an opportunity to process it.  Of course if this queue is too small, you
will have to sacrifice some of your data.  :-(  The nice thing is that
driving the LCD is now asynchronous to my data collection.  The time
critical stuff is handled in a timely manner and the LCD grinds along at
a consistent pace as quickly as possible.

This was the only working way that I could come up with for an early
project I did to read serial data on an F84 and display it to an LCD.  I
find it useful to do this (or variations of it) in many of my projects
now.  My remote control thermometer project uses this technique to
handle the incoming I/R data while the main level crunches away at the
Dallas 1-wire bus and the LCD.  This "overlapping" of the work makes
greatly increases the amount of work that can be done in a given amount
of time.  Sort of like multitasking without an RTOS.  Of course this is
a basic example, but should get the idea across.  Learn to look for ways
of doing two or more things at once.  Interrupts and timers are a great
way of doing this.

In the case of your idea (now that I think I get it), your sampling rate
will have to limited to what the PIC can handle.  This can be done in
ways other than just taking less samples.  For example reading every
other or every third sample from the RAM instead of trying to grab them
all may give you acceptable results without getting behind and losing a
large amount of data.  Compromise is key.

michael

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\18@213523 by Ray Gallant

flavicon
face
Double buffer memory.

----- Original Message -----
From: "Tony Harris" <tonyspamKILLspamELROYNET.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Tuesday, February 18, 2003 8:13 PM
Subject: [ee]: Cache ram/buffer ram howto??


> Hi all,
>
> Ok, like most of my emails to this list - I'm kinda confused ;)
>
> I've noticed many projects that aquire data (pic based oscopes, data
> collection, etc.) store the values in RAM to be retrieved by the PIC chip
or
> by a comp connected to the overall device - while it is still collecting
> data.
>
> So, my question is - let's say I have a circuit that based on a given
clock
> collects data from an input (a/d converter) and stores it in a RAM chip -
> and I need to obtain that data to send out to a comp. or to display on an
> LCD screen - on top of that I need to get the data fast enough before the
> RAM overflows and starts back at the beginnign of the bank.  How do I go
> about doing this?  Does anyone have any quality reference or explanations
on
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\18@224804 by Tony Harris

flavicon
face
That is really vague and hard to search on.  I'm not sure if you do any
programming in the gaming arena, but double buffers are frequently used for
page flipping to create smooth graphics, if you search on double buffer
memory, just about every link you get will be either graphic card
specifications, double buffer programming, page flipping, double buffer
scrolling, direct X back buffers, etc.

Do you know of any specific material relating to implementation with a pic?

-Tony
{Original Message removed}

2003\02\18@232752 by Tony Nixon

flavicon
picon face
Tony Harris wrote:
>
> That is really vague and hard to search on.  I'm not sure if you do any
> programming in the gaming arena, but double buffers are frequently used for
> page flipping to create smooth graphics, if you search on double buffer
> memory, just about every link you get will be either graphic card
> specifications, double buffer programming, page flipping, double buffer
> scrolling, direct X back buffers, etc.
>
> Do you know of any specific material relating to implementation with a pic?

The basic idea is quite simple.

One approach would be to split he RAM into two halves.

The first half begins to fill with data being aquired by the system.

The system uses the second half of RAM to display contents, transmit it,
or what ever.

When the first half fills up, the system swaps it's access to each half,
such that the second half now starts filling with data, while the first
is used as mentioned before.

When the second half fills etc etc etc

If it takes longer to process data from one buffer than it takes to fill
the other, then just stop aquiring data after it is full until ready to
start again.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
EraseMEsalesspam_OUTspamTakeThisOuTbubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\18@235114 by Scott Dattalo

face
flavicon
face
On Wed, 19 Feb 2003, Tony Nixon wrote:

{Quote hidden}

In my opinion, a better approach is one (circular) buffer and two
pointers. Of course, it depends on the type of data one receives and how
it is processed (and may be totally inappropriate for the particular
application the original poster is interested in [but I didn't see that
part of the thread]). But for communication links, data comes in a
byte-at-time and is handled as a stream. If a large chunk needs to be
processed at once then I still think that a circular buffer with two
pointers is useful.

For the 18f family, I reserve FSR2 for interrupts and FSR0 and FSR1 for
non-interrupts. Here's an example of one of my interrupt handlers for
receiving data from the usart:

check_USART_RX_interrupt:               ;
       BTFSC   PIR1,RCIF               ;
        BTFSS  PIE1,RCIE               ;
         BRA   check_next_interrupt    ;
                                       ;

       LFSR    2,RxBuffer              ;   *** Rx Interrupt ***
       INCF    RxIndexInt,W            ;
       ANDLW   RX_INDEX_MASK           ; We just received a byte in the
       MOVWF   RxIndexInt              ;UART. This byte gets stored in
       MOVFF   RCREG,PLUSW2            ;  RxBuffer[RxIndexInt] = RCREG

...

Then the main loop will call a function

       RCALL   RxProcessOneByte

Which does this:


RxProcessOneByte:
       MOVF    RxIndexInt,W            ;Did we receive a byte? If the Rx
                                       ;  Indices
       XORWF   RxIndex,W               ;for the interrupt and
                                       ; non-interrupt code
       BNZ     rpob1                   ;are different then we have a
                                       ;byte.
       RETURN                          ;Otherwise we don't...
                                       ;
rpob1:
       INCF    RxIndex,W               ;Advance the non-interrupt index
       ANDLW   RX_INDEX_MASK           ;using roll-over arithmetic
       MOVWF   RxIndex                 ;and get the byte that the
       LFSR    0,RxBuffer              ;interrupt routine placed into
       MOVFF   PLUSW0,RxNextByte       ;the RxBuffer.
       CLRF    PLUSW0                  ;Wipe out the byte in the RxBuffer
                                       ;so that
                                       ;we don't get fooled later when
                                       ;the pointer
                                       ;wraps around


The two pointers are "RxIndex" and "RxIndexInt". Everytime the interrupt
routine receives a byte, "RxIndexInt" is advanced by one (and the new byte
is placed into the buffer). The non-interrupt code compares these two
indices. When they're different, the next byte is "processed".

With a single circular buffer you'll probably be able to make it bigger
than one of the two ping-pong buffers. With a larger buffer, there's less
risk of buffer overflow. Buffer overflow sucks.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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