Sharing SPI bus between two cogs
smbaker
Posts: 164
Although 32 IO pins sounded reasonable at the start of my project, I've finally managed to run out of them. I have an additional SPI device that I need to connect, and only one pin left.
What I'm thinking is this -- I can share the SCLK, DI, and DO pins for the two SPI devices (this is after all how the SPI bus was designed to work).·Each SPI peripheral·would of course still need a unique CS pin, but I have enough pin budget for that.
Now on to my question. The two SPI devices will be used by two different cogs. Am I correct in assuming that if I protect the SPI code with a lock (LockSet/LockRet/etc), that I can successfully share the SCLK, DI, and DO pins between two cogs? The cog that is not using the SPI bus would set SCLK and DO to low before releasing it's lock, so that it would not interfere with the other cog that is using those same pins.
Does this all sound correct?
Thanks,
Scott
What I'm thinking is this -- I can share the SCLK, DI, and DO pins for the two SPI devices (this is after all how the SPI bus was designed to work).·Each SPI peripheral·would of course still need a unique CS pin, but I have enough pin budget for that.
Now on to my question. The two SPI devices will be used by two different cogs. Am I correct in assuming that if I protect the SPI code with a lock (LockSet/LockRet/etc), that I can successfully share the SCLK, DI, and DO pins between two cogs? The cog that is not using the SPI bus would set SCLK and DO to low before releasing it's lock, so that it would not interfere with the other cog that is using those same pins.
Does this all sound correct?
Thanks,
Scott
Comments
The correct way for communication between the slave prop and the third device would be through the master prop. Yes, this would reduce data rate on the bus by more than a factor of two. But you can tune this mechanism. When the slave device sends data the master prop controls the transfer, receives the data, but drops it. The slave prop gets the data by listening to the transfer. When the slave prop wants to send data to a third device the mast prop operates the clock line while the slave prop listens to the clock and operates the data line.
This approach does also not conform to the standard but I would consider it save. At least there is still only one master preventing clashes on the bus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys
For reference, see my schematic for Blades 1 & 4 in the SixBladeProb thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
My initial attempt at this was to share the DI, DO, and CLK pins. I placed locks around the code that used the SPI bus, so that both cogs could not use the bus at the same time. I had to be sure DI and CLK were set to low before a cog released the lock otherwise those two lines could be stuck high when the other cog got the lock. Generally, I seemed to be able to get this working with the spin version of the FSRW SPI code. The assembly version (sdpiqasm.spin) is another story. Unfortunately there's a few things going on in there that I don't understand yet, and I'm going to have to learn some prop assembly if I want to pursue this particular approach.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys
And to answer your original question, yes, use a lock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz