Post by thread:Serial RAM??

I am considering a data logging project that would sample a number of sensors and record the data for later playback into a PC host for analysis. Minimally it would need to record one or two hundred bytes per second for several minutes, ideally quite a bit more. So something like 32K to 256K of memory would need to be written and then later read back. There is almost no requirement to randomly access this memory, just need to write it as data comes in and read it for upload to the PC. I know that I could build a data and address bus out of I/O pins, but that seems like overkill and would probably use too many pins anyhow. I have seen serial EEPROMS and they would almost be perfect except for the slow programing and power consumption. Is there a serial SRAM available? or a simple way to use commodity SRAM chips? Any other thoughts? -dg David Gould spam_OUTdgTakeThisOuTillustra.com 510.869.6383 or 510.305.9468 Informix Software (formerly Illustra) 1111 Broadway #2000 Oakland, CA 94607 - I realize now that irony has no place in business communications.

David, TRY PCF8570 256 x 8 Static RAM made by Phillips which interfaces to the I2C bus. There are larger than 256 bytes but I don't know who makes them. Regards, Mark At 22:47 29/05/97 -0624, you wrote: {Quote hidden}>I am considering a data logging project that would sample a number of sensors >and record the data for later playback into a PC host for analysis. Minimally >it would need to record one or two hundred bytes per second for several >minutes, ideally quite a bit more. So something like 32K to 256K of memory >would need to be written and then later read back. There is almost no >requirement to randomly access this memory, just need to write it as data >comes in and read it for upload to the PC. > >I know that I could build a data and address bus out of I/O pins, but that >seems like overkill and would probably use too many pins anyhow. > >I have seen serial EEPROMS and they would almost be perfect except for the >slow programing and power consumption. Is there a serial SRAM available? >or a simple way to use commodity SRAM chips? > >Any other thoughts? > >-dg > >David Gould .....dgKILLspam@spam@illustra.com 510.869.6383 or 510.305.9468 >Informix Software (formerly Illustra) 1111 Broadway #2000 Oakland, CA 94607 > - I realize now that irony has no place in business communications. > > ---------------------------------------------------------------------- Mark Hitchings R&D Engineer Intelligent Control Systems Laboratory School of Microelectronic Engineering Griffith University, Nathan, Qld. 4111 ph: +61 7 3875 5067 fax: +61 7 3875 5384 email: mhitchinKILLspamme.gu.edu.au ----------------------------------------------------------------------

David Gould <.....PICLISTKILLspam.....MITVMA.MIT.EDU> wrote: > I am considering a data logging project that would sample a number > of sensors and record the data for later playback into a PC host for > analysis. Minimally it would need to record one or two hundred bytes > per second for several minutes, ideally quite a bit more. > .... > I have seen serial EEPROMS and they would almost be perfect except > for the slow programing and power consumption. Is there a serial > SRAM available? or a simple way to use commodity SRAM chips? David: You could rig up an SRAM with a counter chip on its address lines, then just clock the counter with the PIC and present data 8 bits at a time to the SRAM's data bus... But I'd probably recommend using the serial EEPROMs, instead. Microchip makes large (64K) EEPROMs, and they can be powered from a pin on the PIC (so you can power them down when you're not actually accessing them). As you've noticed, the write time IS relatively slow (10 milliseconds max), but you can get around that with just a little bit of cleverness: 1. The large EEPROMs allow "block writes" of 8 or 16 bytes at a time. Writing a block takes the same amount of time as writing a single byte, so using this feature drops the write time to 1.25 ms/byte, max. 2. If you use multiple EEPROMs, you can interleave writes to them. That is, you can write a block of 8 bytes to one chip, then (while that chip is occupied in its 10-ms write cycle), you can write the next block of 8 bytes to another chip. If you use two EEPROM chips, this cuts the write time in half, to 0.625 ms/byte. At 0.625 milliseconds per byte, you can store 1600 samples per second. -Andy === Andrew Warren - EraseMEfastfwdspam_OUTTakeThisOuTix.netcom.com === Fast Forward Engineering, Vista, California === http://www.geocities.com/SiliconValley/2499

At 22:47 29/05/97 -0624, you wrote: >I am considering a data logging project that would sample a number of sensors >and record the data for later playback into a PC host for analysis. Minimally >it would need to record one or two hundred bytes per second for several >minutes, ideally quite a bit more. So something like 32K to 256K of memory >would need to be written and then later read back. There is almost no >requirement to randomly access this memory, just need to write it as data >comes in and read it for upload to the PC. > >I know that I could build a data and address bus out of I/O pins, but that >seems like overkill and would probably use too many pins anyhow. > >I have seen serial EEPROMS and they would almost be perfect except for the >slow programing and power consumption. Is there a serial SRAM available? >or a simple way to use commodity SRAM chips? > >Any other thoughts? I've been thinking along similar lines. So here goes, EEPROM has several important features: Relatively low power (I can turn it off when I'm not using it) Not affected by power glitches (except when writing) SLOW (1ms write time) Only one supplier of 128k x 8 chips (that I've found) Expensive (10 x cost of PIC) SRAM has some important features too: Eats power like it's going out of fashion Wiped by power glitches Damn FAST Lots of suppliers Fairly cheap (2 x cost of PIC) DRAM entered briefly into my considerations: Pretty low power Wiped by some power glitches Pretty fast Needs refresh electronics (real killer) For the sort of data rates you are talking about EEPROM should be quite feasible. If you need to write more than 500 bytes/second you might have to work a bit harder. Rather than have a proper address bus how about using a counter? You are only going to want to read/write sequentially anyway. What I need now is a couple of months to design the board and write some (really quite simple) code for it. Sadly there are lots of other projects mounting up on my desk at the moment, so let me know how you get on. Keith. ========================================================== Keith Dowsett "Variables won't; constants aren't." E-mail: kdowsettspam_OUTrpms.ac.uk WWW: http://kd.rpms.ac.uk/index.htm

At 10:47 PM 5/29/97 -0624, you wrote: >it would need to record one or two hundred bytes per second for several >minutes, ideally quite a bit more. So something like 32K to 256K of memory >would need to be written and then later read back. There is almost no >requirement to randomly access this memory, just need to write it as data >comes in and read it for upload to the PC. RAMTRON http://www.ramtron.com makes what they call FERAMs. These are pin and software compatible with I2C EEPROMs, but the 10mS delay we are all used to using is _!NOT!_ required. Also, you can write the entire chip in sequence after a single addressing command! This sounds like it would be ideal for your application. I am awaiting a few samples. Pricing is pretty good, too - very competitive to EEPROM for what you advantages you get, imho. Andy ================================================================== Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865 Hardware & Software for Industry & R/C Hobbies "Go fast, turn right, and keep the wet side down!" ==================================================================

At 06:51 AM 5/30/97 -0400, you wrote: >RAMTRON http://www.ramtron.com makes what they call FERAMs. These are pin >and software compatible with I2C EEPROMs, but the 10mS delay we are all >used to using is _!NOT!_ required. Also, you can write the entire chip in >sequence after a single addressing command! Odd - that link gets me to:- http://www.sni.net/sni/index.html and not the FRAM company's home page. Netscape does not report a domain server error or any exception, can you confirm that address actually gets you to RAMTRON ? Rgds Mike Perth, Western Australia PS: And yes I did a cut and paste as well - it was entered correctly. Some say there is no magic but, all things begin with thought then it becomes academic, then some poor slob works out a practical way to implement all that theory, this is called Engineering - for most people another form of magic. Massen

> From: David Gould <@spam@dgKILLspamILLUSTRA.COM> > To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU > Subject: Serial RAM?? > Date: Friday, 30 May 1997 14:41 > > I am considering a data logging project that would sample a number of sensors > and record the data for later playback into a PC host for analysis. Minimally > it would need to record one or two hundred bytes per second for several > minutes, ideally quite a bit more. So something like 32K to 256K of memory > would need to be written and then later read back. There is almost no > requirement to randomly access this memory, just need to write it as data > comes in and read it for upload to the PC. > > I know that I could build a data and address bus out of I/O pins, but that > seems like overkill and would probably use too many pins anyhow. > > I have seen serial EEPROMS and they would almost be perfect except for the > slow programing and power consumption. Is there a serial SRAM available? > or a simple way to use commodity SRAM chips? > > Any other thoughts? > Yeah. I'd think about doing on-the-fly compression of your data - ie RLL, or maybe an ADPCM-like system. Given that most transducers change slowly, this'd save space over saving absolute value every time. Another idea would be to dedicate a low-end PIC to generate address/data for a parallel memory device, and communicate with it via serial lines from your main PIC. Lower device count than using logic chips, and its smarter. Also leaves main PIC with plenty of free lines. (which you need for a logger) Consider making it detachable from the logger, and with an inbuilt lithium battery, and you could use SRAM instead of EEPROM (cheaper & available larger), and you could make up a 'reader' unit for a PC. Unit could be disposable when battery went flat, or replace battery(or recharge - personally, I'd use lithium - they last longer than NiCd in that sort of app anyway...). With datalogging, you should monitor the battery, so you don't lose data. What language would you use for logger? Most systems I've seen have really brain-damaged schemes for programming them. I'd be interested in hearing your ideas. I'd use something like an '84 with EE^2 for program memory, write a C (or maybe basic) like language on a PC based text editor, then have the PC compile that into a hex file and d/l it to program memory. Saves having an interpretive based system that has to fetch tokens from somewhere, and allows easy use of library functions. My 2c worth of what a decent datalogger should do - I might do it one day... MikeS <RemoveMEmikesmith_ozTakeThisOuTrelaymail.net>

> From: Mike <spamBeGoneerazmusspamBeGoneWANTREE.COM.AU> > To: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU > Subject: Re: Serial RAM?? > Date: Friday, 30 May 1997 20:45 > > At 06:51 AM 5/30/97 -0400, you wrote: > > >RAMTRON http://www.ramtron.com makes what they call FERAMs. These are pin > >and software compatible with I2C EEPROMs, but the 10mS delay we are all > >used to using is _!NOT!_ required. Also, you can write the entire chip in > >sequence after a single addressing command! > > Odd - that link gets me to:- http://www.sni.net/sni/index.html > > and not the FRAM company's home page. > > Netscape does not report a domain server error or any exception, can > you confirm that address actually gets you to RAMTRON ? > I'd love to blame NetScape, being an IE user, but... That one caught me out a while ago - what you do is goto that page, click on findit, and you see the following sentence... (Note: If you were expecting to see another company's web site, but got SuperNet's web site instead, click here for a possible explanation.) doing that gets you this - (excerpt only) 1) The URL you entered was not complete. If the web for which you are searching is hosted on one of our shared-web machines, then omitting any required part of their URL (for example, going to http://www.domain.com/ when the correct URL was really something like http://www.domain.com/domain/ or http://www.domain.com/~user) could send you to our home page, since in this case their web site may in fact be hosted on the same machine as our web page. (They would need to upgrade their web site to one of our Virtual Domain hosting services for the previous simpler URL to work as expected.) Now we're getting somewhere! Try - http://www.ramtron.com/ramtron/ It worked for me - I just tried it again. > Some say there is no magic but, all things begin with thought then it becomes > academic, then some poor slob works out a practical way to implement all that > theory, this is called Engineering - for most people another form of magic. > Massen Any sufficiently advanced technology is indistinguishable from magic Niven or Asimov - I think it was the former. MikeS <RemoveMEmikesmith_ozTakeThisOuTrelaymail.net> They're a friendly enough company - sent me a databook - all the way down here to Oz.

> At 10:47 PM 5/29/97 -0624, you wrote: > >it would need to record one or two hundred bytes per second for several > >minutes, ideally quite a bit more. So something like 32K to 256K of memory > >would need to be written and then later read back. There is almost no > >requirement to randomly access this memory, just need to write it as data > >comes in and read it for upload to the PC. > > RAMTRON http://www.ramtron.com makes what they call FERAMs. These are pin > and software compatible with I2C EEPROMs, but the 10mS delay we are all > used to using is _!NOT!_ required. Also, you can write the entire chip in > sequence after a single addressing command! In some applications I've done using FRAM devices, there sometimes seems to be a memory-loss problem when the system is powered down and back up. I don't know whether this is due to the system's CPU going bonkers and writing something it shouldn't as it loses VDD, but I'd suggest anyone using the FRAM devices take care to ensure that their system shuts down nicely when it loses power. Also, another important thing to note about FRAMs: they perform a store operation as soon as they get the last data bit of a byte, even if the write is not terminated properly. This is in contrast to most EEPROMs which will abort a page-write cycle without writing anything if, e.g., they receive a stop in the middle of a byte.

The nicest ram I have seen is the Dallas semiconductor RAMport ram, unfortunatly the largest size is 2k X 8. It requires around 700nS to read/write - it uses parallel 8 lines to communicate to the memory, but the clever thing is that it only uses 2 io control lines. The 8 lines of data/addr bus are fed thru the chip - so you still can use these lines as io. When you select the ram the output lines are latched, and the ram accessed. Geoff. http://www.dalsemi.com/Prod_info/Memory/ramport.html {Quote hidden}>I am considering a data logging project that would sample a number of sensors >and record the data for later playback into a PC host for analysis. Minimally >it would need to record one or two hundred bytes per second for several >minutes, ideally quite a bit more. So something like 32K to 256K of memory >would need to be written and then later read back. There is almost no >requirement to randomly access this memory, just need to write it as data >comes in and read it for upload to the PC. > >I know that I could build a data and address bus out of I/O pins, but that >seems like overkill and would probably use too many pins anyhow. > >I have seen serial EEPROMS and they would almost be perfect except for the >slow programing and power consumption. Is there a serial SRAM available? >or a simple way to use commodity SRAM chips? Geoff Smith --------------------------------------------------------------- Home (UK) | Interval Research Corp. | Palo Alto, California RemoveMEgsmithaEraseMEEraseMEcix.compulink.co.uk | RemoveMEgsmithspam_OUTKILLspaminterval.com | (415) 842-6159

At 09:27 PM 5/30/97 +0930, you wrote: >> >RAMTRON http://www.ramtron.com makes what they call FERAMs. >http://www.ramtron.com/ramtron/ >It worked for me - I just tried it again. May I suggest that when you reference a URL it be in full so we don't waste both our both valuable time. Rgds Mike Doin what yah always did will get yah what yah always got. Some say there is no magic but, all things begin with thought then it becomes academic, then some poor slob works out a practical way to implement all that theory, this is called Engineering - for most people another form of magic. Massen

> From: Mike <RemoveMEerazmusTakeThisOuTspamWANTREE.COM.AU> > To: EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU > Subject: Re: Serial RAM?? > Date: Saturday, 31 May 1997 03:34 > > At 09:27 PM 5/30/97 +0930, you wrote: > > >> >RAMTRON http://www.ramtron.com makes what they call FERAMs. > > >http://www.ramtron.com/ramtron/ > > >It worked for me - I just tried it again. > > May I suggest that when you reference a URL it be in full so we don't > waste both our both valuable time. > Hey, Mike, I didn't post the original message - just the one with the corrected URL. I just had a sense of deja vu about the problem, so thought I'd help :) MikeS <RemoveMEmikesmith_ozKILLspamrelaymail.net>