SRAM Controller Update

[ylp88]

With a bit of spare time on my hands over this las tweekend, I was able to do a bit mroe work on my SRAM controller. I have since constructed a "refined" version of the original design on a breadboard which can access 256 byts of the SRAM chip's available 32K bytes. All went well as the temperature of the circuit's surroundings was measured and logged using a 28X.

Obviously, 256 bytes is not very impressive (even though it is RAM, not EEPROM) but with 32K at my disposal, I set out to expand the shift register addressin capabilities. Here I have run into a snag - I've run out of IOs!!!

Is there a way that I can get an extra 15 IOs using two digital pins? I've currently got 8 using a 74LS164 shift register but I need another seven. I considered using the last output of one the shift register as the data in to the next register but considered that that would mean that the second &quot;daisy chained&quot; register would be behind by one clock - <A href='http://wei-lee.customer.netspace.net.au/SRAMProt-A.gif' Target=_Blank>External Web Link</a> (there may be mistakes on this schematic - havn't checked it yet; nor is it finished). I also considered using the 74HC595 but that requires an IO to drive the latch pin which is an IO I cannot afford to use.

So the question is:
1) Is there a way to get the 75HC595 to work without having the controller having to interface to its latch pin?
2) Can I expand the 74LS164 to 15 or 16 bits while retaining two IO lines - data and clock?
3) Is it possible to use only one of the OSC pins to operate the PIC at 20MHz? I have come across a Colpitts oscillator (something similar to the LHS of <A href='http://us1.webpublications.com.au/static/images/articles/i308/30853_2lo.jpg' Target=_Blank>External Web Link</a>) but am not sure if it is suitable to drive the PIC in EC (external clock) oscillator mode. If it is, it will free up one IO pin (one pin for oscillator, instead of two) which I can then use to latch the 74HC595.
3) (Not the preferable option) What else can I use to get the outputs I require?.

Thanks for any help.

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

 

[andrewpro]

Do you have the I2C pins available? The MCP23017 is pretty simple to use and provides 16 I/O's.

If you dont have the I2C available, you could give the S version of the 23017 a shot. It's SPI, essentially the same as your shift registers I would imagine. (never used the SPI version myself).

--Andy P

 

[ylp88]

The 16F628 can implement SPI and i2c internally, however, I am currently using those pins as an asynchronous serial UART for communication with the host controller - PICAXE, PC or other uC.

Thanks for the comment, although I think I'll wait to see if anyone has any other ideas before I try to do something completely different.

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

 

[whizzer]

Hi ylp88,
When you said: <i>&#8220;I considered using the last output of one shift register as the data in to the next register but considered that that would mean that the second &quot;daisy chained&quot; register would be behind by one clock&#8221;. </i>

Maybe it&#8217;s a bit late in the day for me &amp; I&#8217;m missing something, but I&#8217;m having trouble trying to see why there would be any difficulty cascading two shift registers together.

Surely to get 15 address bits serially clocked-out, you would just need 15 clock pulses to do it? (instead of the 8 needed for the single shift register in your original design).
PS: I had a some difficulty fully discerning your circuitry on the your first referred web link. It didn't display too well on my LCD -either that or it's my eyes!

Edited by - whizzer on 28/05/2006 17:38:13

 

[ylp88]

Say I load the first register with a 1 then all bits thereafter are 0.

I clock it once then Q0 goes high. Clock again then Q0 goes low and Q1 goes high... and so on... then clock again and Q6 goes low and Q7 goes high which makes data input of the next register high, but that register was already clocked with the data that was in Q7 at the time of the clock pulse - a logic 0. In the next clock pulse, then the 1 on Q7, will disappear but not before the data is clocked into Q0 of the second register.

That was my interpretation of it - hope you understand what I'm trying to say. Perhaps a bit of a delay between Q7 of the first register and the data in of the seconds may help, but it is not going to work very well if the PIC accesses the data before the correct address is fully loaded.

Maybe my interpretation is wrong - I'm not too sure. Seems like a very fine timing issue. Maybe something that can be overcome by examining the timing diagrams very closely - rising and falling edges may make the difference even if the pulse if only 1us long... Too late in the day here too - it is already 12:30am... time to go to bed...

Any suggestions are still welcome.

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

Edited by - ylp88 on 28/05/2006 17:37:47

 

[hippy]

I don't see a problem with daisy-chaining two 164's to give a 16-bit shift register. Being edge clocked there should be enough of a lag for the Q7 to be latched into the next 164 Q0 before Q7 gets updated - If you look at it this way; that's exactly how each Qx latch connects to the next anyway.

There are reports of this working with 164's on Google, and intuitively I'd say it would work. Take a look at the Expandable 16-LED Sequencer which does the same as you're wanting ...

http://ourworld.compuserve.com/homepages/Bill_Bowden/page5.htm

If there is a problem, the easiest solution might be to simply delay the clock edge to the first 164 by a few nS by running that through an R-C.


Edited by - hippy on 29/05/2006 01:09:48

 

[whizzer]

After some sleep &amp; back in the light of day, my brain is functioning again.

The 74LS164 shift register family of chips is <i>designed </i> to be cascadable. To cascade two &#8216;164 shift registers together, simply extend the clock line to the next chip, and connect the first chip&#8217;s &#8216;Qh&#8217; output (pin 13) to the inputs of the second chip at pins 1 &amp; 2. Then the cascaded pair will behave as though it were a single register of 16bit length. This extending process can be done virtually ad infinitum.

In reference to your drawing, I think perhaps where some confusion came in, was the fact that because you weren&#8217;t using the address lines in a sequential manner, (which of course is fine), but perhaps it caused you to miss implementing the Qh output of your original &#8216;164 as an address line for your SRAM, (as well as coupling it thru to the input of the following &#8216;164.)

And of course since you only require 15 bits max for addressing, then that&#8217;s the number of clock pulses needed to serially &#8216;clock&#8217; the address pattern through. Then it&#8217;s just a matter of ensuring that the address bits are fully clocked in and have had some short time to settle before the SRAM data lines are asserted or read.

Hope this info is of some use to you, and all the best for your project!
Regards

Edited by - whizzer on 29/05/2006 09:27:33

 

[ylp88]

Ah, so if I understand correctly, the last output of the first register drives an address pin AND the data in of the second register as well? That seems to make sense and works with the clocking process I had though about. So basically, my logic was right, but my schematic layout was wrong...

Thanks for the help.

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

 

[ylp88]

On the side, however, does anyone know whether my assumptions about the single pin osciallator are correct? Can I use a Colpitts oscillator using a 20MHz cystal to clock the PIC at 20MHz in EC oscillator mode. That would free up another IO and possible allow me to add something &quot;extra&quot;...

<b><i>ylp8 </b> </i>

 

[whizzer]

Re separate oscillator&#8230;
mmmm theory says that this should be possible &#8211;but I haven&#8217;t tried it myself. Maybe there is someone else who has done this. Of course (to other readers here), it&#8217;s not something that a regular Picaxe user would be able to do, as the concept is only possible on certain chips, and in a different programming environment, e.g. assembler.

But there&#8217;s nothing like being able to utilise every single pin of a chip to its maximum capability! So, since theory says yes, I for one am encouraging you to give it a try!

Looks like you are going to end up with really handy little gadget here ylp

Edited by - whizzer on 29/05/2006 09:49:13

 

[hippy]

There should be no problem feeding a single pin osciallator clock into the PICmicro. You can test that in HS/XT/LP mode by simply removing xtal and driving the CLKIN line. Using EC makes the CLKOUT an I/O.

Those 'silver box' xtal oscillators as found on motherboards work. A Colpitts oscillator looks over-complex to me and you might have to buffer to get the required slew rate etc.

A 74LSxx inverter oscillator with xtal should work. 16F628A datasheet should describe this.

 

[ylp88]

Great - just the news I wanted to hear! Good to hear confirmation.

I'll look into the Colpitts oscillator nonetheless, because it is one of the suggested ways of using the EC oscillator mode according to one of Microchip's Application Notes. Despite it being more circuitry, it also seems quite compact and adding another 14/16 pin DIL 74xx inverter will take up some space, anyhow. Size is not overly critical in any case.

Thanks for the help and thanks for the encouragement whizzer and Hippy.

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

 

[xstamp]

It seems like a lot of work to address parallel SRAM using shift registers etc. Why not just use an I2C memory chip? For example, the Ramtron 64kbit non-volatile FRAM 8-pin device. Ramtron claim it&#8217;s good for 10 billion read/write cycles and is much faster than EEPROM. It is available in the UK from Farnell (part # 388-1234) for about 2 UKP each.

 

[whizzer]

Hi xstamp,
Ramtron had previously been mentioned on this Forum, but at the time it was rather difficult to find a supplier who was willing to sell in hobbyist (small) quantities &amp; who actually had them in stock ready for delivery. I&#8217;ll have to admit that I&#8217;ve had a particular interest in these memory products for some time, as the original technology that these devices are based on was developed in my neck of the woods &#8211;Australia.

 

[ylp88]

I've had these SRAM chips lying around for quite a long time - probably upwards from five years! So they did come &quot;free&quot;. In addition, my estimates indicate that the SRAM controller will be able to read and write faster than the master controller (PICAXE or other uC) could want to read or write from the chip so speed is not so much of an issue (10KB read/write speed at 4MHz. 20MHz clockable).

Overall, the design has not been overly difficult and has taught me quite a few things along the way. In addition, in doing this, I found that it is a lot easier to program SRAM chips than I originally thought.

My implementation currently uses two IO pins as a connection medium to the &quot;outside world&quot; - the master controller. It shoudl eb relatively easy to modify this interface to i2c, SPI or, as I have it now, asynchonous serial communiucations. Having RS232 equivalent communications allows the SRAM to be used with a 08, 08M, 18A etc... and other controllers which do not support i2c. Also, my setup should be able to implement the full 32K bytes of storage and a read/write endurance beyond reasonable count...

One way or the other, I believe that it has been a very good learning experience for me and I feel that this is the most important aspect. I hope to be able to use to to do a few things I have been hoping to make for some time now.

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

 

[hippy]

For most users FRAM is probably the best way to go, but I do like the solution of two 164's to be able to access 64Kx8 SRAM ( and another 164 gives access upto 16MB ) ... and I have a lot of 32KB/64KB SRAM's lying around.

I don't know what code ylp88 has, but I estimate read/write byte times should be less than 32uS, the serial interface is the current bottleneck.

ylp88 : Did you get the 16-bit shift register working ?

 

[ylp88]

I should have time to check it out this weekend but in simulation it worked so everything is looking good. I'm volunteering to do a draft exam paper for the WA Curriculum Council tomorrow which they are using to test their new Outcomes Based Education for the Course of Engineering they are introducing here in W. Australia, so no time tomorrow. I shall endeavour to do it on the weekend.

I'll keep you updated.

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