Tying two shift registers together to communicate 8 bits between them

Let me see if I got this:

1. send bit's serially to shifter.
2. shifter sends bits parallel (how far?)
3. Another shifter converts back to serial
4. receiver gets bits

Points to realize:

• A shifter will go one direction only. Serial to parallel is one and parallel to serial is another.
• There is a finite time to shift added to the serial out.
• Serial can always have errors! This design does not take that into account.
• Distance on parallel is always shorter because of attenuation. Serial much better.

     I will let you ponder these and then answer why go to this trouble?

Clem

Hi screamingtiger

Actually, the parallel or Serial distance is not relevant, a parallel bus is simply a number of serial channels , attenuation would be the same or not relevant in the compare , this is a physical limitation not a protocol one, you can line drive a parallel bus as easily as a serial one

I2C, SPI and UART (Old School TTL version of RS232) are all reliable and as much as a parallel is, the built in hardware of the devices makes using it as simple as parallel, if not simpler, there are many techniques you can use to ensure integrity of the passed message including sending the byte then the inverse, or a check sum, or a parity bit (See RS232), if these where not reliable then pretty much every automotive system (New ones), medical devices, laptops, automation systems would be unreliable... there not, also you do not specefy the speed at which you need to transfer data, these serial protocols go easily up to 10Mbit if needed which equates to perhaps 1MByte/Second, more than most microcontrollers could handle so the serialization is or should not be an issue

clemm

Robert Peter Oakes

The more I think about this the more I need to experiment.  Thanks for your information and thoughts and if you bear with me maybe you can understand my crazy thought process.

Originally I had the receiver requesting 1 byte of information over and over again from the sender.  Every request required work on the sender's part to get the information and send it.  What I noticed is that for the most part, the information doesn't change that much.  Lets say it changes on average 1 time per second, but the receiver will request 100 times per second just in case, because you never know when it will change.

So the receiver is requesting over and over and the sender sends the exact some byte over and over.  So my thought is the sender could set a shift register and then only change it when necessary.  This means the receiver can read it 100 times per second without any work needed by the sender until it changes.  This can greatly relieve the load on the sender right?

Why two shift registers?  Well originally I thought I would wire 8 GPIO pins together to send this information.  So between two pics, that is 16 pins being used up!

Then I realized two shift registers can be run by 4 pins each so I would only use 8 pins total between the two.  the registers are just there to save pins.

Does that make sense?  Keep in mind I have the mindset the receiver "asks" for the information.  The receiver's only job is to get this information and do something with it.  The sender's job is much more than just to send, it has 10 other things to do and cant be bogged down just sending information.

I now realize the analogy I need to think about.  A button being pushed.  I can check to see if the button is pressed in a loop over and over, OR I can setup an interrupt to only check it when it is pushed.

The concept in this case is that the receiver should not request information, but rather the SENDER SENDS information only when it changes.  I think I see my flaw.

Now need to try to work this out.  Perhaps SPI is the way to go over all.  I can send my byte of information and then the next byte can be some sort of XOR value to check validity.  I don't see that step needed with a shift register since I can read the pins in order and cant miss a bit.

Okay, now you set forth the problem, the solution is more obvious. If you have a case where the data may change, setup an interrupt from the sender to the receiver. Interrupts allow less processing and are more efficient. The interrupt is like a shoulder tap to receive new data. A SPI is a master (could be sender) and slave(could be receiver). The only rule is master shall control clock and initiate talk.Data can be returned from slave only when master send something even dummy data. I hope that helps and not muddies the water for you.

Clem

So, on the receiving side, the SPI/I2C works the same basic way as the Serial

Has a message arrived ?, if so read it and put in a variable, update whatever your going to based on this value

now do other stuff but check the receivers on each loop to check for any updates, if you get a new byte, compare to the current, if there different then do whatever you do with the data, if it is the same, just ignore it

Job done

Thanks, I have to use I2C from the Pi to the arduino as I want the Pi to be master but the Arduino I2c library  doesn't support being a slave.

The reason I was trying to avoid this is I have to use SPI to communicate with a sensor as well so I will be using Ic2 and SPI at the same time in the Pi.

I'm going to figure this out tomorrow and if it wont work I'll have to used the shift registers.

Thanks for your information!

Joey

The guys at Wyolum created an arduino slave that interfaced with a GPS. (called I2GPS)

The idea was it sat as a I2C device (addr 88) and you polled it for an update.

You might be able to see what they did and replicate it to allow the Arduino to be a I2C slave.

Mark

I'm not sure how I messed my post up.  Ardunio is fine as a slave for I2C.  It doesn't support being a  slave for SPI.

I got it all working now for the most part.  Thanks!

I'm not sure how I messed my post up.  Ardunio is fine as a slave for I2C.  It doesn't support being a  slave for SPI.

I got it all working now for the most part.  Thanks!