Can the SPI library receive 32 bits on a Uno R3?
Does not SPI transfer data in 8 bit bytes ?
You could, of course, send the 32 bits as 4 bytes and reassemble them into a 32 bit variable at the receiving end
What is sending the 32 bits in your project ?
On Arduino Uno R3, if it's the Master, the SPI hardware can receive 32 bits all day long, simply by transferring four bytes. As the Master, the other device follows your timing, and will wait for your Uno R3 to set up and be ready to receive the next chunk of 8 bits.
If you are using the Uno R3 as a slave, I would rethink the proposition of using SPI in the first place. It is kind of conceptually a poor choice. SPI is best when the Uno is the master and some chip (not a microcontroller) is the slave, because otherwise you will have some timing and reliability problems that are really challenging to solve. I would use UART or I2C instead, which has these problems solved for you.
Well 4 bytes is exactly what I want to send but I thought a string of 32 bits might be faster then 4 separate bytes. This is Arduino to Arduino, both Uno R3 and it works flawlessly transmitting one byte.
I was thinking of moving the one byte Arduino to Arduino to I2C thus having the SPI port available to receive the 32 bits from a third Uno.
Which is recommended, the single byte on I2c and the four byte transmission on SPI or vice versa.
Or I guess I could use I2C for both with two addresses? But then we have to deal with bi-directional data flow.
The master R3 sends one byte to a second R3 and the master also receives 4 bytes from a third R3. Both are one way transmission and receive.
I suggest you stay with the SPI. You will be stuck with bytes when using the I2C bus and it is much slower. See if this helps: How do I transfer more than 1 byte at once via SPI bus? - Arduino Stack Exchange
Yes, I got the same basic advice from further reading on the topic.
Thank you to all here for your help.
If you implement software SPI (bit banging) you can create a loop to send any amount of bits, 3, 14, 15, 92, 653 whatever number you want.
An UNO is mostly slow with SW SPI unless you use low level IO registers directly.
If you communicate between computers you might add an extra byte (or two) as checksum of the data bytes, A simple checksum could be just adding the bytes modulo 256.
The receiving end can then check if the data is (likely) not corrupted.
Oh yeah, I know how to do that. Back with the 80s with the 8051s I was using a very basic ($400 at the time) C cross compiler. If the function wasn't in the K&R bible, you wrote it from scratch! I did I2C that way as well.
I think I will use the Arduino library SPI to read to send the 4 fast bytes to the other R3. Than use a bit banger for lower speed SPI needs. The third R3 will use I2c in a single direction since that only gets a single byte at a slow finger pace.
Why not sending the "slow" bytes over the fast channel too?
(or do they have a different purpose, so it would add an identification byte)
You only need a second select channel I guess to implement the "slow" bus. MOSI and clock can be reused and the routing of the databits depend on which CS line is used.
The 3rd R3 could also reuse the SPI bus with another CS line.