Go Down

Topic: Is there a 'Software SPI'? (Read 7063 times) previous topic - next topic

PeterH

In one of my applications the SPI pins are occupied by a motor shield but I want to use the SPI bus too. Is there any possibility of using a soft SPI bus on other pins? Given that people have created a software UART it doesn't seem completely out of the question, but I can't find any mention of this being done/tried.
I only provide help via the forum - please do not contact me for private consultancy.

magagna

I think this is what you want:

http://little-scale.blogspot.com/2007/07/spi-by-hand.html

Good luck!
http://en.wiktionary.org/wiki/magagna <-- My last name.  Pretty apt.

frank26080115

you are talking about bit banging SPI

shiftOut() is bit banging, pretty much exactly what you are looking for, see official Arduino reference for details

but please consider that SPI is designed to be used for multiple devices, so you shouldn't need to have a separate SPI bus for separate devices, unless you absolutely need parallel data transfer rates
Freelance engineer, consultant, contractor. Graduated from UW in 2013.

CrossRoads

Hook up your second device to SCK, MOSI, MISO, and give it its own SlaveSelect pin - that's the way SPI is designed to operate.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

PeterH

I do understand that multiple SPI devices could be connected to the same SPI bus; that's not the problem.

I only have one device that needs SPI, but the SPI pins are already being used for other purposes. I'll have a go at replacing the stock SPI API with one that implements the 'bit banging' approach that described here. Thanks for the suggestions, and especially thanks to magagna for the link to an example.
I only provide help via the forum - please do not contact me for private consultancy.

m_ri

if you read datashet of atmegaxxx, you'll see that is possible to use USART as SPI..you can search via google if there are libraries for this purpose,or you must implement this..

PeterH


shiftOut() is bit banging, pretty much exactly what you are looking for, see official Arduino reference for details


I'm pleased to see that the SPI API uses a class and a static instance, so it should be possible for me to derive a 'Software SPI' subclass from it and use instances of that anywhere that the hardware SPI could be used. But I'm still not quite clear what is the best way to implement the software SPI. At first I thought that shiftIn() and shiftOut() were the answer, but I don't see how to achieve the bidirectional concurrent transfer with those - is 'bit banging' the only option here, or am I missing a trick?

I only provide help via the forum - please do not contact me for private consultancy.

magagna

#7
Sep 24, 2012, 11:41 pm Last Edit: Sep 24, 2012, 11:47 pm by magagna Reason: 1
Quote

...At first I thought that shiftIn() and shiftOut() were the answer, but I don't see how to achieve the bidirectional concurrent transfer with those - is 'bit banging' the only option here, or am I missing a trick?


That's correct, shiftIn()/Out() aren't for bidirectional communication at the bit level. If you can program both communication endpoints you could use shiftin/out to communicate full bytes at a time by alternating calls...it would be slower, but you may not need to send massive amounts of data back and forth so that may not matter. If you only have control over the Arduino side and the other component only speaks hardware SPI, obviously this won't work....

As I was typing this an idea comes to mind -- what about using one of those remap-any-pin shields to swap some lines so your hardware SPI pins are freed up?

[edit] - This is what I'm talking about https://www.sparkfun.com/products/11002?
http://en.wiktionary.org/wiki/magagna <-- My last name.  Pretty apt.

PeterH

I'm in the UK which reduces my supply options a bit - I only found one in stock in the UK and it's in the post now. But it still goes against the grain to throw hardware at a problem which seems relatively feasible to fix in software so I'm going to keep pushing on with the idea of a software SPI.
I only provide help via the forum - please do not contact me for private consultancy.

Go Up