Multiple Masters on SPI

Started by sms October 23, 2013
On 2013-10-23, sms <> wrote:
> 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? -- &#9858;&#9859; 100% natural --- news:// - complaints: ---
On Thu, 24 Oct 2013 10:07:39 -0700, sms <>

>On 10/24/2013 2:20 AM, Lasse Langwadt Christensen wrote: >> 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> >>> >>> >>> >>>> 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. >> >> 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.
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