Interfacing between two microcontrollers over two wires.

This question is more of a generic question in which I'm seeking an optimized algorithm.

Basically I have two microcontrollers. One runs at a speed 6x slower than the other. Special feature pins of the micros are used up and all I have are two GPIO pins from each one for communication. One pin is the clock and one is data.

What I'm trying to do is have the slow micro request initial information from the faster micro. For example, I'm sending byte 5A to the faster micro and I expect it to return A5 but it does not.

Here's the code I tried:

For Slow micro that wants information

;request
set counter to 8
Start loop
rotate right LSB from accumulator to Carry
set GPIO pin to Carry value
lower clock
raise clock
decrement counter
restart loop if counter isn't 0.

;response
set counter to 8
Start loop
lower clock
raise clock
get Carry value from GPIO pin
rotate right Carry into MSB of accumulator
decrement counter
restart loop if counter isn't 0.

Click to expand...

For Fast micro that has information

;get request
set counter to 8
Start loop
wait until clock is low
get Carry value from GPIO pin
rotate right Carry into MSB of accumulator
wait until clock is high
decrement counter
restart loop if counter isn't 0.
if accumulator is 5A then
set accumulator to A5
end if
;do response
set counter to 8
Start loop
wait until clock is low
rotate right LSB from accumulator to Carry
set GPIO pin to Carry value
wait until clock is high
decrement counter
restart loop if counter isn't 0.

Click to expand...

What am I doing wrong?

At work I do this all the time between a micro and a touch screen for industrial equip ... for all intentions, the touch screen is another micro.

These systems have to be spot on and not miss a beat in terms of communication. Handshaking is a must, as well as sending data in structured packets.

A typical packet might consist of 6 bytes .... [SYNC1][SYNC2][Address][Data][CRC][Seed]

1) SYNC1 and SYNC2 are always the same value where the receiver doesn't process any data until those two BYTES are received
2) The Address is a reserved block of memory on the receiver you want to write Data to.
3) Data is what you want to fill the Address with on the receiver
4) CRC is a simple XOR of all 6 BYTES including the Seed
5) The Seed is essentially a moving target ... it can be as simple as a counter that counts to 255 and recycles back to 0. The purpose of the Seed is to create change even if the data being sent is the same. There are deeper reasons for this, that I won't go to far into other than it adds a slight degree of robustness.

The key thing to consider is that BOTH the touch screen (micro) and the micro work the same way from an independent point of view. The Address location represents a reserved area of memory that exists on both micro's. Within each micro the functionality works based on what Data is in the memory Address rather than what is immediately streaming in serially. To prevent collisions, on either end, each micro cannot write to its own reserved memory block Address unless the Data is received serially. It can only read from it's own reserved memory block Address. It can however read and write to non reserved areas of memory just as you normally would.

I'm working at the bit level, not at several bytes level.

I program in pure Assembly language inside of the micro , so your bit level and my bit level are going to be about the same.

These are the functions I have for the 8051 so far
but the problem is it won't work for two micros with speeds of a 6x difference from each other.

Use I²C (IIC = inter integrated circuit) as it can run at any speed between 0 (DC) and about 400kHz. Google "bitbang I²C 8051" should get you working routines.

Mike.

Their routines I think would only work if both devices share the same clock speed or are very close to the same clock speed. I'm dealing with two micros in which the speed difference is 6x apart

They will work at any clock speed that suits both processors. If the slower one needs more time it can use clock stretching to slow the transfer down. It is a protocol especially designed for such a situation.

Mike.

Just use an RS232 type serial protocol, speed of the processor makes no difference, as you adjust the timing routines accordingly - easily done using software serial.

Nigel Goodwin said:

Just use an RS232 type serial protocol, speed of the processor makes no difference, as you adjust the timing routines accordingly - easily done using software serial.

Click to expand...

It may be worth checking out the asynchronous 1-pin Icom CI-V protocol (reference info'). I was able to implement a single pin bit-banged interface on a PIC 12F683 to my Icom 756PRO-II transceiver at 9600 baud and it worked quite well.

mik3ca,

Make your life easier and use the UART built into the 8051 the buffer is only like one or two BYTES so you will need to process the incoming data on your own. In my setup within the ISR I have a BYTE FIFO, and then apply the 6-BYTE packet format I described above. If the packet does not match then it does not get processed.

Mike - K8LH said:

It may be worth checking out the asynchronous 1-pin Icom CI-V protocol (reference info').

Click to expand...

I can't say I was aware of any such protocol

I always used my own protocol for bi-directional comms on a single pin.