Post by thread:External RAM

Randie, I have used an external SRAM with a PIC16C63. I use all of port B as a multiplexed data/address bus. Two control lines in port C control two 74HC373 latches that latch the address bits, two more lines are used to control RE and WE lines. It is quite fast to read and write to. I also added a battery to allow the RAM to be NV. Yes it uses lots of lines but I needed the speed. Using a serial access scheme would have been too slow in my application. Let me know if you want more info. Hope this helps Norm

At 07:32 1998-03-03 -0600, Norm wrote: >Randie, > >I have used an external SRAM with a PIC16C63. I use all of port B as a >multiplexed data/address bus. Two control lines in port C control two >74HC373 latches that latch the address bits, two more lines are used to >control RE and WE lines. It is quite fast to read and write to. I also >added a battery to allow the RAM to be NV. Yes it uses lots of lines but I >needed the speed. Using a serial access scheme would have been too slow in >my application. > >Let me know if you want more info. > An idea: 1) For real high speed sequential access: substitute the adress latches with loadable counters. And glue logic that advances it at every RE or WE pulse (or use separate pin). Then you have very high speed for sequential read or write. 2) Theese loadable counters are usually 4 bit wide per chip. So we can go down to 4 bit wide multiplexed adress and data bus. For the data read we need a quad 2 to 1 line selector, and for data write a 4 bit tristate buffer and a 4-bit tristate latch. Control all this using a 3 to 8 line decoder (and some glue gates)! Total pins used = 7. 3) Lot of chips above... Implement all above in one programmable chip. (Maybe include protection logic for power fail if backup battery... or other logic) /Morgan / Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \ \ .....mrtKILLspam@spam@iname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331 /

Hi Norm, My scenario is that I will have some serial data coming into the PIC at about 5Kbps. The data packet can be as long as 80 bytes each and I wish to store the last 10 packets (800 bytes). I think I'll also be using a PIC16C3. For now, I could store the entire packet into the PIC RAM (192bytes) and then send these to a serial EEPROM when the entire packet has been received, but I am thinking of extending the packet length which could be more than 192 bytes in the future. I don't have experience (not yet) of using serial EEPROM or SRAM with the PIC. Is the speed of writing to EEPROM too slow for my application if I am also receiving serial data at 5Kbps? Or should I go to faster SRAM or even serial SRAM? I don't need NVRAM (so no battery). Any comment you have would be appreciated! (and Thanks!) -Randie rohtsjiKILLspamglenayre.com {Quote hidden}> From .....cramerKILLspam.....DSEG.TI.COM Tue Mar 3 06:59:21 1998 > > Randie, > > I have used an external SRAM with a PIC16C63. I use all of port B as a > multiplexed data/address bus. Two control lines in port C control two > 74HC373 latches that latch the address bits, two more lines are used to > control RE and WE lines. It is quite fast to read and write to. I also > added a battery to allow the RAM to be NV. Yes it uses lots of lines but I > needed the speed. Using a serial access scheme would have been too slow in > my application. > > Let me know if you want more info. > > Hope this helps > > Norm >

On Tue, 3 Mar 1998 08:52:36 -0800 "Randie Ohtsji [4555]" <EraseMErohtsjispam_OUTTakeThisOuTGLENVAN.GLENAYRE.COM> writes: >Hi Norm, > >My scenario is that I will have some serial data coming into the PIC >at about 5Kbps. The data packet can be as long as 80 bytes each and >I wish to store the last 10 packets (800 bytes). I think I'll also >be using a PIC16C3. 5Kbps is about 500 bytes per second (using async with it's 2 bits overhead per byte) or 1 byte every 2 ms. Some EEPROMs are able to write that fast. The ones with a page buffer that can write several bytes in one write cycle would do it easily. However, if the data is being rewritten constantly, the EEPROM could wear out. If the packets are coming in constantly and the program is optimized to evenly distribute the writing over a 2K byte EEPROM, each EEPROM location would be rewritten every 4 seconds. An EEPROM rated for 10,000,000 writes would reach it's limit after 11,000 hours of such use (about 1.25 years). Of course the actual use wouldn't be that demanding, so an acceptably long life of the EEPROM may be realized. _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]

On Tue, 3 Mar 1998 17:20:00 +0100 Morgan Olsson <mrtspam_OUTINAME.COM> writes: > >1) For real high speed sequential access: substitute the adress >latches >with loadable counters. And glue logic that advances it at every RE >or WE >pulse (or use separate pin). Then you have very high speed for >sequential >read or write. A simplification of this theme would be to use ordinary ripple counters (74HC4040, etc) to drive some or all of the address pins. The PIC would control the counter's Clock and Reset pins. The memory is then organized as one or more blocks which are accessed sequentially. More than 1 block results from connecting some address pins to the PIC directly, and others to the counter. For example, if data is to be read from one block then written to another (at the same address in the block), it isn't necessary to do anything to the counter, just change the high-order address. Whether this is useful or not depends on how your application's data is organized. It also isn't too hard to use DRAM, and it ends up a lot less expensive if say 64Kbyte or more of RAM is needed. DRAM's have an address demultiplexer built in already so fewer pins are needed. But they aren't practical for battery backup. _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]

On Tue, 3 Mar 1998, Mike Keitz wrote: > On Tue, 3 Mar 1998 17:20:00 +0100 Morgan Olsson <@spam@mrtKILLspamINAME.COM> writes: > >1) For real high speed sequential access: substitute the adress > >latches > >with loadable counters. And glue logic that advances it at every RE > >or WE > >pulse (or use separate pin). Then you have very high speed for > >sequential > >read or write. > PTM: If you have a project somewhat critical of pins, you could do like this: pic PA0 |-----res--| counter PA1 |-----up---| PA2 |--R/W-- |_______________________ | | | |||||| | | A0 A1..A15 | | | |||||| | -----------|-------- |||||| | | | |||||| PB0 |--D0/D4-----| 2x4bit |--D0/D4--| PB1 |--D1/D5-----| tri-state |--D1/D5--| SRAM PB2 |--D2/D6-----| buffer |--D2/D6--| PB3 |--D3/D7-----| |--D3/D7--| You write and read the data hinible + lonyble. Counter gives you A0 to select HI, LO. If you don't understand this picture, it is not for you, I'm not going to explain it. It works, I have used this kind of system before connected to LPT-port of a PC. If you find it usefull and use it, send me a emeil ! -------------------------------------------------------------------------- PTM, KILLspampasi.mustalahtiKILLspamutu.fi, RemoveMEptmustaTakeThisOuTutu.fi, http://www.utu.fi/~ptmusta Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK Lab.engineer (PC support) Computer Center OI7234 Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014 Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577) --------------------------------------------------------------------------

On Wed, 4 Mar 1998 13:33:52 +0200 Pasi T Mustalahti <spamBeGoneptmustaspamBeGoneUTU.FI> writes: >PTM: If you have a project somewhat critical of pins, you could do >like >this: > > pic PA0 |-----res--| counter > PA1 |-----up---| > PA2 |--R/W-- |_______________________ > | | | |||||| > | | A0 A1..A15 > | | | |||||| > | -----------|-------- |||||| > | | | |||||| > PB0 |--D0/D4-----| 2x4bit |--D0/D4--| > PB1 |--D1/D5-----| tri-state |--D1/D5--| SRAM > PB2 |--D2/D6-----| buffer |--D2/D6--| > PB3 |--D3/D7-----| |--D3/D7--| > >You write and read the data hinible + lonyble. Counter gives you A0 to >select HI, LO. I assume the "tri-state buffer" is a 4-channel 1-2 analog multiplexer. I can see that reading would be no problem, but writing counts on one nibble's data staying in the capacitance of the lines while the other one is written. Also there is the problem of the RAM and PIC being in output mode at the same time, but analog multiplexers have enough on-resistance to limit the current in this case. Maybe the counter's clock line could also be used to enable the multiplexer only after the PIC's tris register had been set up. The sequence for writing would be: R/W high (read), output low nibble from PIC, pulse R/W low. The RAM writes XL, where X is unknown. Advance the counter, output high nibble, R/W still high. At this point, the RAM is reading XL. X may be contending with H if the multiplexer is still enabled, but L is being output to the unselected RAM pins. Now pulse R/W low, the RAM pins become inputs and accept the H nible from the PIC, and rewrite the L nibble that stays on the pins due to capacitance. This would likely work, but it seems rather iffy. If you don't need a lot of RAM, connect only some of the data lines and waste some space in the RAM chip. Too bad you can't buy 4-bit SRAMs any more (well, you can, but they cost much more than 8-bit ones). A certain chip maker really, really, needs to make a PIC with about 2Kbyte of RAM in it. Putting some extra logic with the PIC's parallel slave port so it could easily directly control DRAM would be really cool too. _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]

On Wed, 4 Mar 1998, Mike Keitz wrote: > On Wed, 4 Mar 1998 13:33:52 +0200 Pasi T Mustalahti <RemoveMEptmustaTakeThisOuTUTU.FI> > writes: > >PTM: If you have a project somewhat critical of pins, you could do > >like > >this: > > > > pic PA0 |-----res--| counter > > PA1 |-----up---| > > PA2 |--R/W-- |____________________________ > > | | | |||||| > > | | A0 A1..A15 > > | | | |||||| > > | --------x--|-------- |||||| > > | | | | |||||| > > PB0 |--D0/D4-----| 2x4bit |--D0--| > > PB1 |--D1/D5-----| tri-state |--D1--| SRAM > > PB2 |--D2/D6-----| buffer |--D2--| > > PB3 |--D3/D7-----| ... |--D7--| > > > >You write and read the data hinible + lonible. Counter gives you A0 to > >select HI, LO. PTM: Someone asked me to make some coerrections, so I made the them in the picture above. I'll add the missing R/W- and data-lines (latch-RAM) > I assume the "tri-state buffer" is a 4-channel 1-2 analog multiplexer. PTM: I used more than one chip here where there stands 'buffer' That anal-mux might give some advance. > A certain chip maker really, really, needs to make a PIC with about > 2Kbyte of RAM in it. PTM: In normal sittuations I I'm either satisfied with 10-20B of RAM or I need it so much that there is no possibilities to integrate it in the sama chip in todays technology. -------------------------------------------------------------------------- PTM, pasi.mustalahtiEraseME.....utu.fi, EraseMEptmustautu.fi, http://www.utu.fi/~ptmusta Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK Lab.engineer (PC support) Computer Center OI7234 Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014 Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577) --------------------------------------------------------------------------