SPI SRAM from microchip - More Prop Interface Questions

[Mark Swann]

To Mike Green, or any,

In another thread I proposed a method of increasing the through-put of the 23K256 serial SRAM from MicroChip by ganging multiple SRAMs in parrallel. (I have attached a schematic image of the device for reference.) Each would share the same clock pin, but the data in/out pins would be separated·and wired to different pins on the Prop.

I thought about this for a while and concluded, initially, that the input and output pins (SO and SI) would need to be connected to different Prop pins. Until I looked at the spec sheet more closely.

When I looked more closely,·I saw that SO is high-impedence when the device is reading data from SI. That lead me to conclude the input and output pins could be wired together and connected to the same pin on the Prop, as long as·the pin on the Prop is also high-impedence (set as an input) when the Prop is reading from SO.· This would clearly save a pin on the Prop.

I haven't looked at the current SPI objects in OBEX but, if I were a betting man, I would bet that those objects implement I/O on separate pins.·

This is too simple. Someone else must have clearly considered this and discovered some folly in it that I cannot see.

Can this be done?

Mark

[Mike Green]

I looked at the spec too and it does look like you can save an I/O pin by wiring SI and SO together. I plan to use the serial SRAM that way. Some other SPI devices work the same way. For example, you can use the Vinculum USB Host that way. It uses an 11 bit data frame where the first 3 bits are always from Propeller to Vinculum and the remaining 8 bits can go either way.

[Mark Swann]

@ mike,

Thanks for confirming that.

Mark

[dMajo]

Mark,

Usually in such applications you wire SI directly to the uC and insert a resistor between the SI and SO to limit the current in case of driving errors (SO and uC both outputs with opposite levels). This should work everywhere even if SO is not three-stated.

[Mark Swann]

dMajo said...
Mark,

Usually in such applications you wire SI directly to the uC and insert a resistor between the SI and SO to limit the current in case of driving errors (SO and uC both outputs with opposite levels). This should work everywhere even if SO is not three-stated.
Excellent suggestion. I admit I was worried about that but didn't consider your solution.
What resister value do you suggest?

Thanks.

[Mike Green]

Somewhere between 470 Ohm and 1K. That would limit the short circuit current to 3-6mA, more of an issue with the SRAM than the Propeller since the Propeller's I/O pin structures are quite robust.

[jazzed]

Re: Limit current in case of driving errors.
Why is this a concern? The SPI out pin is tri-state when data is not active.

... if all else fails, read the instructions :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

[dMajo]

At times I wonder me if Mike, besides never sleeping, live in a kind of hollywood study with hundreds display consoles each one on its thread

Thanks Mike

[dMajo]

jazzed said...
Re: Limit current in case of driving errors.
Why is this a concern? The SPI out pin is tri-state when data is not active.

... if all else fails, read the instructions :)


Mark wanted (as I understood) transform a 3wire spi interface to 2wire by linking together the SI and SO to save pins on a parallel multi-IC ram application.

When dealing for example with SIPO/PISO registers that haven't the tristated output on two wire comunication usually you clock the bit in (uC output) then you change to input to read the output·(eg. of the last in chain that is connected throuh a resistor to the uC)·in the same clock period.

So, not all devices have tristate outputs: this is the solution to it this

Post Edited (dMajo) : 1/22/2009 5:43:51 PM GMT

[Mark Swann]

jazzed said...
Re: Limit current in case of driving errors.
Why is this a concern? The SPI out pin is tri-state when data is not active.

... if all else fails, read the instructions :)


You are right, if I write the driver carefully to flip the outa pins from output to input (via dira) at the right time evertime.

[jazzed]

I guess taking the safest approach is best if you want to ensure all future devices would operate properly over time in a volume product.

... if all else fails, read the crystal ball :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

[Timothy D. Swieter]

Excellent question Mark. I was just starting to wonder something similar about this SRAM device too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)