Using SRAM (or NVRAM)

[ylp88]

As part of a scrolling LED message project, I was planning on storing character data and message data on a RAM chip. Why RAM? I will probably be getting the controller to access (read and write) to the memory very often, in which case, a EEPROM would probably wear out pretty fast. The ability to store graphical animations is also more likely to be possible using RAM as this would wear an EEPROM out even faster!

My question is: does anyone have any experience in interfacing a SRAM or NVRAM chip to a controller.

I was assuming that it simply requires its address pins to be set to the required address (11 bits for a 2KB chip, 13 bits for 8KB) and then its control line pins (read/write, output enable, chip select etc.) to be configured and then the data appears as eight parallel bit on its IO port.

Does anyone know if this is correct?

In particular, I am thinking of using a 6116P-3 (2KB) (Datasheet: <A href='http://www.futurlec.com/Memory/6116P-3.shtml' Target=_Blank>External Web Link</a>) or 6264P-12 (8KB) (Datasheet: <A href='http://www.futurlec.com/Memory/6264P-12.shtml' Target=_Blank>External Web Link</a>). The datsheets I was able to aquire look like VERY poor scanned copies but from what I can make out, they seem to be very alike to Maxim's NVRAMs.

Thanks in advance for any advice.

<b><i>ylp88 </b> </i>

 

[ylp88]

NVRAMs are also a possibility but they are several times more expensive and I don't necessarily need the non-volatility of the memory, although it would be nice in some cases. If anyone has had experience with the NVRAMs, however, I would still like to hear from you.

I'm open to other options for storage, too. I've estimated that I'll need at least 2KB (bytes, not bits) in total but may need more, but that can come later.

<b><i>ylp88 </b> </i>

 

[SD2100]

I think also with RAM you have to constantly send it a refresh signal. Also EEPROM would be way to slow for fast graphics. You could pre store stuff in ROM or EPROM then load it into RAM !!.

Edited by - Phil75 on 15/04/2006 16:09:30

 

[notwhoyouthink]

You could always try the Philips PCF8570 as sold by Rev-Ed <A href='http://www.semiconductors.philips.com/acrobat/datasheets/PCF8570_4.pdf' Target=_Blank>External Web Link</a> http://www.semiconductors.philips.com/acrobat/datasheets/PCF8570_4.pdf
8 of these on the I2C bus would provide you with your 2K as they are 256B each.

 

[hippy]

Using standard SRAM is as easy as you suggest; set the address, move the right control lines, read in the data. No refresh needed for SRAM.

Many automatically select low power mode when not chip selected and can keep their data by simply powering them from a battery, so a battery backed-up SRAM is a fairly easy option.

The downside is of course the high line count, with the data bus pins needing to be bi-directional. It would be possible to use 8-bit binary counters to give an address to the chip needing just clear and increment to be able to select any particular address with few lines needed. Most access I'm guessing would be sequential and three lines ( clear, inc msb, inc lsb ) would be able to get to any address of 8KB with 65 pulses of those lines maximum.

Using I2C RAM would be the easiest, but the cost could become prohibitive. One thing to bear in mind is that most SRAM I see for sale these days is surface mount rather than DIP, although it may be possible to salvage from an old PC or somewhere - I found a nice 32Kx8 on an ISA modem card.

 

[hippy]

Just looked at some old 486 motherboardds and the external cache there appears to use 3.3V 32Kx8/64Kx8 SRAM.

Having eight times the capacity you need, you could interface using just one data line and discard the other seven; 8Kx8=64Kx1. That would simplify interface at a cost of speed. Should be doable as a 64Kx2 with a PICAXE-18 and two 8-bit counters which could act as the memory managing slave for the main processor via a serial link ...<code><pre><font size=2 face='Courier'> PICAXE-18
.---------. | |
| TX |----' |
| RX |&lt;-----' 64K x 8
| | R .-----------.
| DOUT |--====--. | |
| DIN |&lt;-------^--------&lt;&gt;| D1 | 6 x R
| | R | D2-7 |---===--.
| DOUT |--====--. | | _|_ 0V
| DIN |&lt;-------^--------&lt;&gt;| D0 |
| | | |
| R/W |------------------&gt;| R/W |
| /CS |------------------&gt;| /CS |
| | .-----. | |
| INC |-------&gt;| CTR |---&gt;| A8-15 |
| | .---&gt;| | | |
| | | `-----' | |
| | | .-----. | |
| INC |---|---&gt;| CTR |---&gt;| A0-7 |
| CLR |---^---&gt;| | | |
`---------' `-----' `-----------' </font></pre></code> You should be able to test without wiring in counters by using the three counter control lins as A0-2 and seeing if you can read/write the 16-bits available.

 

[ylp88]

Thank for that everyone. I did consider using i2c SRAM but though it a bit expensive but although it is, it is not as expensive as I though it would be. I'll consider it when my design gets around to that stage.

I'm interested in using the SRAM from old computers, though. I might scour around and see what I can find. SMD parts are not too much of a problem, so long as as it is not too small. I can handle most SOIC chips, as well as a few others I can't remember the name of.

As for some chips having too much RAM, I was thinking of using the RAM in 256 byte block. This would allow me to use an 8-bit shift register to access the address lines (easily compatible with the PICAXE's 8-bit variables) and then each chip will toggle one of the remaining address lines to access the block it wants. It will result in only around half or so of the memory being used but if it's all I need then it doesn't really matter.

Again, thanks for the advice and help.

UPDATE: I managed to find a whole lot of DRAM but that would mean I have to constantly refresh the memory which is certainly not desirable and possibly not possible. I've got a feeling that the SRAM may have disappeared to SRAM heaven... I'll keep looking...

<b><i>ylp88 </b> </i>

Edited by - ylp88 on 16/04/2006 03:25:28

 

[hippy]

http://www.rapidelectronics.co.uk ( Semiconductors | Micro &amp; Crystals | Memory | Renesas SRAM ) ... 128K x 8 @ 1.20 GBP

 

[Mycroft2152]

You only need 1 counter chip. The CD4020 or CD4040 are 12 and 14 stage binary counters.

Here's a link to a simple NVRAM memory circuit.

<A href='http://f3.grp.yahoofs.com/v1/sCNCRAnrZiBIDxbUDt3Y6qlm3t61FlJc0lpuDGYTpQJiHPGNN5w6_P7xZySQoe8seL_FNgsTY5mZtKF92xEQ9LQXu5028Q1p/wilf_nv/Nv%20memorizer.gif
' Target=_Blank>External Web Link</a>
TANSTAAFL!

Myc

 

[ylp88]

hmmm... Can you post the link again? It deosn't seem to work for me...

<b><i>ylp88 </b> </i>

 

[Mycroft2152]

here is the link. the circuit is from one of our posters -- Wilf.

It is in the Yahoo BEAM group.

If this doesn't work i can email the gif file.

http://f3.grp.yahoofs.com/v1/wDFCRBRKw24a8cwrv4nFiMT9O13G9WlNW7yDojs1eYXP-y8D10r5G09jv4XL7FEfaxV1JWIHF0qNI_5uV78hVLa5DRMzKSt9/wilf_nv/Nv%20memorizer.gif


Myc

 

[Bloody-orc]

could you please email it to rellermaa at gmail dot com

 

[ylp88]

Yeah. E-mail it to me if you don't mind. My e-mail should be in my profile details - click the icon above.

Thanks for that.

<b><i>ylp88 </b> </i>

Edited by - ylp88 on 16/04/2006 15:10:40

 

[Bloody-orc]

heres the schematic:
www.rellermaa.pri.ee/Nv_memorizer.gif

thanks Mycroft2152

Edited by - bloody-orc on 16/04/2006 15:24:29

Edited by - bloody-orc on 16/04/2006 15:25:03

 

[ylp88]

Thank you.

<b><i>ylp88 </b> </i>

 

[Mycroft2152]

Your email address wasn't in the profile

Myc

 

[Mycroft2152]

I've just posted the NVRAM gif at

<A href='http://
http://groups.yahoo.com/group/PICAXE_circuits/files/Circuits/ ' Target=_Blank>External Web Link</a>

http://groups.yahoo.com/group/PICAXE_circuits/files/Circuits/

PICAXE_circuits is a new Yahoo group open to everyone as a SUPPLIMENT to this forum. Its purpose is to be used as an archive for circuit files and program files only.

(It's a handy place for those of us who are not ASCII artists)

Any posts that belong in this PICAXE Forum will be deleted -- Myc, list godfather

 

[Mycroft2152]

I'll get one these external links correct someday!

Myc

<A href='http://groups.yahoo.com/group/PICAXE_circuits/files/Circuits/' Target=_Blank>External Web Link</a>

 

[hippy]

Re : Single versus Multiple Counters for address

A single counter requires more clock pulses to get to a particular address. For 8K that's 4096 on average, with two counters, 7-bit and 6 bit, just 64 ( 96 if not optimised ), taking [probably] around 200mS ( 300mS ) to select the last byte of 8K memory as opposed to 12S.

If usually accessing sequentially it's not so much of a problem. If random access is needed it could be.

In a non-PICAXE setup, not so much of a problem.

 

[Michael 2727]

The original link posted did work,,if-
you removed the &lt;B&gt; that was accidently
tacked on to the end of it, was probably
the result of a copy &amp; paste from the sved
URL
If a link fails to work it pays to scroll
across the address and have a look.
It only takes 1 character on the end to make
the whole thing fail.

Another trick is to <b>Backtrack </b> an
address to the previous &quot; / &quot; and try that.
This does not always work but sometimes you
get lucky.

HTML tips 101.

Michael -

 

[Mycroft2152]

Thats for the hints.

Is there any way to edit a message after it hase been posted?

Myc

 

[ylp88]

There is a way to edit - just click the &quot;Edit message&quot; button above. ^^^

It is odd that the e-mail is no longer in profile. It used to be there - people would just e-mail me sometimes!

<b><i>ylp88 </b> </i>

Edited by - ylp88 on 17/04/2006 08:00:27

 

[ylp88]

Speed may play an issue if I want the display to show graphical information. Scrolling text is perhaps only a slight issue.

I want to define my own fonts. With a maximum width of 8 pixels (allows me to define &quot;image fonts&quot; as well as normal ASCII) so maximum character size is 8x8 pixels. This means that for each character, I will use 8 bytes.

I was thinking of using a shift register to shift 8-bits of parallel data onto the SRAM address pins which corresponds to the character I am looking for (eg. &quot;A&quot; or &quot;g&quot; or &quot;G&quot; etc...). With 8 address lines used, I will use 3 others for the controller to select which column of the character is needed.

For example, if I am requiring the letter &quot;A&quot;, then I shift in %01000001 (decimal 65) into the register. Using three other address lines, I configure them to be %000. This then reads the 8-bits of the first column (%000) of the character. As I am still reading the same character, I just change the three address lines (without changing the shift register) for %001 and then read the second column (%001) of display data. As so on...

As such, I don't really need to change the shift register data very often if I use characters but if I want larger graphics (ie. beyond the 8x8 pixel block), then the register may need to change more often. Character font data will of course be read unsequentially. Certainly a good frame rate is desirable. And of course, it would be desirable to have a bit of headroom in timings.

My method seems a bit indirect (hopefully you know what I am trying to get at) but it appears that it would allow more flexability, short of feeding parallel data straight into the SRAM address pins from a controller.

hmmm... Needs more thought... I'll get back to all of you when I've thought some things through...

<b><i>ylp88 </b> </i>

 

[hippy]

ylp98 : Your shift-register idea sounds ideal, and even quicker than a pure counter. While the SRAM is not chip-selected you have the data out lines which could be used (shared) to feed one or two shift registers.

Perhaps a good configuration is an 8-bit shift register to A3-A10, counter to A0-A2 to clock out 8 pixels and the higher bits of the counter to A11-upwards. Full access to entire SRAM, really quick access to the first 2K, and not too slow for the rest.

A further enhancement would be to add a bit-addressable latch ( for write ) and multiplexor ( for read ) so the full 8-bit width of the SRAM could be used.

Thanks to yourself and myc for suggestions which could be useful in a future project I've been planning.

 

[ylp88]

With all of this discussion on use of the SRAM modules, I have decided to have a bit of a play around with my humble 16F628A chips. The plan is to use two shift registers to act as a single 16-bit shift register. This would be controlled by two PORTA pins. Using PORTB (minus RA1 and RA2, which are used for the hardware UART), they can read AND write to the data lines (I love how plain PICs are bidirectional on nearly all of the pins!). Spare PORTA pins would make up two pin shortfall of a byte wide data bus. Read/write and other control pins would be controlled by PORTA. The 16F628 can also run at 20MHz because the instruction cycle is 5MHz giving an instruction time of 0.2us, or 200nS, quite a bit longer than is required by a 100-150ns SRAM, although 4MHz or 8MHz operation is more than likely to be used for most applications.

I can then construct a module which can read and write from SRAMs up to 64KB (kilo BYTES) and interface it to any other controller with a serial interface (PICAXE included). A single IO would indicate a read or write operation. Expandability could be provided using the chip select pins, much alike normal EEPROMs used with PICAXEs.

The controller (eg. PICAXE or plain PICmicro etc.) would select either a read or write operation and serially transmit a 16-bit address word to the module (ie. two bytes). The data would them be read from the SRAM and serially transmitted to the controller, or simply written to the SRAM, as appropriate.

Although more complicated in design than using a pre-built i2c EEPROM (eg. a 32Kbyte 24LC256), it could be used over and over without needing to worry about maximum read and write cycles. It is also 64Kbyte which is only twice as much as the 24LC256 but can make a lot of difference!

With super capacitors getting very cheap these days (around AU$4.00 for a 1F - one FARAD - 5.5V model), you can almost have the equivalant of a fast EEPROM with NVRAM features!

I'll let you know if I do decide to persue this... Need to brush up on a bit of assember - just got the UART working about an hour ago. Now I just need a SRAM chip to work with...

<b><i>ylp88 </b> </i>

 

[hippy]

You could probably bit-bang the serial on PORTA which would allow the whole of PORTB for data bus interfacing.

 

[ylp88]

I was just trying to get my head around a little problem I have but am having a bit of trouble understanding my logic.

To make routing (of a PCB) easier, it would be nice to simply connect <b>any </b> SRAM data line to <b>any </b> IO on the SRAM controller (16F628, for example). The same would apply to the shift register(s) to the SRAM address lines.

How can I do this? My logic (which I'm having trouble getting around...):
If I write to an address, say 0x0001, but the address lines are not connected in &quot;order&quot; (ie. A0 to D0, A1 to D1, ... , An to Dn), then the data may be in fact written to address 0x0008. However, when I read the data back, I set the address lines to 0x0001, but due to the &quot;incorrect&quot; wiring, it accesses 0x0008 - the register which the data I want was stored in anyway.

The same should apply to the data lines, hopefully. The data will appear in the correct &quot;order&quot; on the controller's IO lines but if they are connected to the SRAM's IO lines incorrectly, the bits will be stored out of order in the SRAM, literally storing a different value in the loaction than that the controller intended it to store. However, when I read the data back, the &quot;incorrect&quot; data on the IO lines will appear at the &quot;wrong&quot; controller input pins but eventually reassemble to create the original data anyhow.

If this all holds true, it would make routing MUCH more simple. I would also assume that it would require NO software modifications - anotehr assumption I think is cirrect but am not entirely convinced as yet (help me here as well!).

Hope someone out there can help me with my logic - I do hope it is all correct.

If this is all corrent, I was thinking it could make an interesting hardware encoder. Data stored is scrambled by mixing/crossing data lines and the data can only be reconstructed if the data lines are read in the order they were scrambled in. The result: simple encoding with <b>NO </b> timing overhead/cost. The order of the datalines would of course have to be kept secret!

EDIT: (just saw Hippy's message)
hmmm.. Bit banging the data is a possibility, although it would rquire more timing overhead which may be a disadvantage in some applications which can process data very quickly. The internal UART has the advantage of being internally buffered and baud rate is very easily adjusted according to requirements.

<b><i>ylp88 </b> </i>

Edited by - ylp88 on 17/04/2006 15:00:44

 

[hippy]

<i>Hope someone out there can help me with my logic - I do hope it is all correct. </i>

It is. It's all arbitrary which address and which data lines go where for SRAM.

You can do the same for EPROM as long as the bytes and bits are all juggled about before the EPROM is burnt.