Post by thread:Cache ram/buffer ram howto??

----- Original Message ----- From: "Tony Harris" <spam_OUTtonyTakeThisOuTELROYNET.COM> To: <.....PICLISTKILLspam@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.

Double buffer memory. ----- Original Message ----- From: "Tony Harris" <tonyKILLspamELROYNET.COM> To: <.....PICLISTKILLspam.....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}> 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? > > -Tony > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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_OUTTakeThisOuTbubblesoftonline.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Wed, 19 Feb 2003, Tony Nixon wrote: {Quote hidden}> 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. 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.