Maker Pro
Maker Pro

Multiple Masters on SPI

S

sms

Jan 1, 1970
0
I'm working on a design where a Cortex M3 writes data to an SPI Flash
memory. The issue is that I have a data acquisition device that also
needs to read the SPI Flash. Both devices can only be SPI masters. The
UART on the Cortex M3 is being used for something else and I2C is too
slow. Essentially we're trying to make the SPI Flash into a dual-port
SPI Flash with external logic.

In searching for a solution I've seen that a lot of people have had a
similar issue with SPI, needing multiple masters to be able to read from
slave devices, which is not something SPI was designed for.

I'm trying to figure a way to use the I2C bus from the Cortex M3 to
control some sort of multiplexer that can disconnect the Cortex M3 from
the SPI bus and allow the data acquisition device to take over the bus.
We have no GPIO pins available on the Cortex M3 to use for handshaking
or to control the multiplexer.

We're thinking of using a I2C port expander (TCA9554
<http://www.ti.com/product/tca9554>) to control a mux like a 74F257A.

Block diagram is at: <http://oi40.tinypic.com/34qvexl.jpg>

If there are any SPI experts out there willing to take a look at this
provide some feedback it would be appreciated.

Again, the considerations are:
1. We have no GPIOs still available.
2. The I2C bus is too slow to use for reading the contents of the Flash.
3. The UART is being used for something else.
4. We want to read the Flash from both the Cortex M3's SPI port and from
an external DAQ's SPI port.
5. The Cortex M3 and the DAQ can only be SPI masters.
 
L

Lasse Langwadt Christensen

Jan 1, 1970
0
Den onsdag den 23. oktober 2013 23.12.38 UTC+2 skrev sms:
I'm working on a design where a Cortex M3 writes data to an SPI Flash

memory. The issue is that I have a data acquisition device that also

needs to read the SPI Flash. Both devices can only be SPI masters. The

UART on the Cortex M3 is being used for something else and I2C is too

slow. Essentially we're trying to make the SPI Flash into a dual-port

SPI Flash with external logic.



In searching for a solution I've seen that a lot of people have had a

similar issue with SPI, needing multiple masters to be able to read from

slave devices, which is not something SPI was designed for.



I'm trying to figure a way to use the I2C bus from the Cortex M3 to

control some sort of multiplexer that can disconnect the Cortex M3 from

the SPI bus and allow the data acquisition device to take over the bus.

We have no GPIO pins available on the Cortex M3 to use for handshaking

or to control the multiplexer.



We're thinking of using a I2C port expander (TCA9554

<http://www.ti.com/product/tca9554>) to control a mux like a 74F257A.



Block diagram is at: <http://oi40.tinypic.com/34qvexl.jpg>



If there are any SPI experts out there willing to take a look at this

provide some feedback it would be appreciated.



Again, the considerations are:

1. We have no GPIOs still available.

2. The I2C bus is too slow to use for reading the contents of the Flash.

3. The UART is being used for something else.

4. We want to read the Flash from both the Cortex M3's SPI port and from

an external DAQ's SPI port.

5. The Cortex M3 and the DAQ can only be SPI masters.

tristate (with pullup on ce when you don't need the spi bus), why would
you need any extra hardware?

if CE is high the device doesn't care, if you are not trying to clock out
data the master doesn't care


-Lasse
 
S

sms

Jan 1, 1970
0
On 10/23/2013 3:34 PM, Lasse Langwadt Christensen wrote:

tristate (with pullup on ce when you don't need the spi bus), why would
you need any extra hardware?

if CE is high the device doesn't care, if you are not trying to clock out
data the master doesn't care

Tri-stating actually takes more hardware than using a MUX because we'd
have to tri-state two SPI Clocks, two SPI chip selects, and two SPI data
outputs. Unfortunately most of the pins out of the processor are not
open-drain, including the ones for the SPI interface.
 
L

Lasse Langwadt Christensen

Jan 1, 1970
0
Den torsdag den 24. oktober 2013 01.59.48 UTC+2 skrev sms:
On 10/23/2013 3:34 PM, Lasse Langwadt Christensen wrote:



<snip>








Tri-stating actually takes more hardware than using a MUX because we'd

have to tri-state two SPI Clocks, two SPI chip selects, and two SPI data

outputs. Unfortunately most of the pins out of the processor are not

open-drain, including the ones for the SPI interface.

a pullup and diodes could do that

but why not just configure the SPI pins to gpio inputs when you don't need them?

-Lasse
 
S

sms

Jan 1, 1970
0
Den torsdag den 24. oktober 2013 01.59.48 UTC+2 skrev sms:

a pullup and diodes could do that

but why not just configure the SPI pins to gpio inputs when you don't need them?

Yes, that's a good idea. It will save the mux chip. I have to ask one of
software people if they are willing to continually reprogram the GPIO
direction for the SPI CLK, SPI CS, and SPI Data, on the processor and on
the DAQ.
 
S

sms

Jan 1, 1970
0
On 10/24/2013 10:22 PM, Joe Chisolm wrote:

Depending on the part, turn off the SPI function with the M3 pin
select and set the pins to input. Turn it back on and initialize when
you need to talk to the flash. This of course depends on you having
a way to tell the DAQ to shut up and leave the bus idle.

NXP LPC1347. You're right, we can switch the pins to inputs. We do have
handshaking between the two devices to prevent both from trying to use
the SPI bus at the same time.

The final product won't need this type of thing, but for development we
need this capability.
 
J

Jasen Betts

Jan 1, 1970
0
I'm working on a design where a Cortex M3 writes data to an SPI Flash
memory. The issue is that I have a data acquisition device that also
needs to read the SPI Flash. Both devices can only be SPI masters. The
UART on the Cortex M3 is being used for something else and I2C is too
slow. Essentially we're trying to make the SPI Flash into a dual-port
SPI Flash with external logic.

You want synchronous read and write that dual port memory allows?
 
M

Martin Riddle

Jan 1, 1970
0
Yes, that's a good idea. It will save the mux chip. I have to ask one of
software people if they are willing to continually reprogram the GPIO
direction for the SPI CLK, SPI CS, and SPI Data, on the processor and on
the DAQ.

Have the M3 monitor the bus for inactivity, then allow it to write.
Sort of make it a slave, and give the DAQ device priority to avoid
collisions.

Cheers
 
Top