Searching \ for '2-Wire, Bi-Directional Protocol' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=wire+directional
Search entire site for: '2-Wire, Bi-Directional Protocol'.

Truncated match.
PICList Thread
'2-Wire, Bi-Directional Protocol'
1996\07\03@111609 by rdmiller

picon face
On Wed, 3 Jul 1996, Byron A Jeff wrote:
[...]
> Query: Does anyone have a reliable bi-directional handshaking protocol that
> can be implemented using 2 I/O pins? My first pass at it can create deadlock
> if both try to send at the same time...
[...]

Have you considered the Multi-Master IIC protocol?

Collision detection is done by checking whether either of the lines is
still being held low every time you let them go high.  (IIC is wire-OR'd.)
The first controller which sees the collision immediately switches into
RECEIVE mode while the other continues without noticing.  Make sure you
give the lines enough time to "settle" before checking them, of course.

Rick Miller

1996\07\03@123410 by Byron A Jeff

flavicon
picon face
>
> On Wed, 3 Jul 1996, Byron A Jeff wrote:
> [...]
> > Query: Does anyone have a reliable bi-directional handshaking protocol that
> > can be implemented using 2 I/O pins? My first pass at it can create deadlock
> > if both try to send at the same time...
> [...]
>
> Have you considered the Multi-Master IIC protocol?

Nope.

>
> Collision detection is done by checking whether either of the lines is
> still being held low every time you let them go high.  (IIC is wire-OR'd.)
> The first controller which sees the collision immediately switches into
> RECEIVE mode while the other continues without noticing.  Make sure you
> give the lines enough time to "settle" before checking them, of course.

Meaning the protocol is syncronous right? Someone out there is driving
a clock that the masters use to syncronously transmit.

I was hoping for something simpler because:

1) It's point to point with only two stations
2) I need async communication between the two.
3) The data is being passed on another channel.

Some ASCII art of my proposed project:




           ----------                          ----------
           |        |                          |        |
           |        |---> A to B handshake --->|        |
           |        |                          |        |
           |        |<--- B to A handshake <---|        |
           |        |                          |        |
RS-232 <--->|  PIC A |<- Bidirection data BUS ->| PIC B  |<---> MIDI IN/OUT
           |        |                          |        |
           |        |                          |        |
           |        |                          |        |
           |        |                          |        |
           |        |                          |        |
           ----------                          ----------

Typical of handshaked parallel transfers between devices like printer ports
and whatnot.

So the transmit protocol for each is:

1) Check other handshake line and make sure its inactive.
2) Place your data and Assert your handshake line.
3) Wait for the other to assert it's handshake.
4) Remove data and de-assert your handshake.

The problem is a deadlock occurs if both are in sync and both do (1) and (2)
at the same time. Talk about blown buffers! Even if the actual transfer
is preceeded with a null handshake both will proceed.

I'll probably implement a simple backoff. Since PIC A is handling a higher
speed than PIC B I'll give it a shorter backoff delay if it finds that
PIC B has requested at the same time as PIC A.

Anyway it's an interesting problem.

BAJ

1996\07\03@143635 by Kalle Pihlajasaari

flavicon
face
Hi,

> Typical of handshaked parallel transfers between devices like printer ports
> and whatnot.
>
> So the transmit protocol for each is:
>
> 1) Check other handshake line and make sure its inactive.
> 2) Place your data and Assert your handshake line.
> 3) Wait for the other to assert it's handshake.
> 4) Remove data and de-assert your handshake.

Reminicent of EI, EO two wire interrupt controller daisychaining.

Have a look at a Zilog data book and use the method described
somewhere in there.  The devices have an effective master and slave
flavour but in your case it won't matter as the 'bus' will be
released regularly.  Basicly the 'slave' chip asks for permission
and receives it if the master is available at other times the
master waits for the slave to ACK after a request.  It is easier
to leave the connection tilted in one direction when idle if there
is bandwidth as there cannot be the deadlock you mention.

> The problem is a deadlock occurs if both are in sync and both do (1) and (2)
> at the same time. Talk about blown buffers! Even if the actual transfer
> is preceeded with a null handshake both will proceed.

Place a 1kOhm resistor in series and the blown buffer will be avoided.

Cheers
--
Kalle Pihlajasaari     spam_OUTkalleTakeThisOuTspamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

1996\07\03@152527 by Norm Cramer

flavicon
face
At 12:18 PM 7/3/96 -0400, you wrote:
>>
>> On Wed, 3 Jul 1996, Byron A Jeff wrote:
>> [...]
>> > Query: Does anyone have a reliable bi-directional handshaking protocol that
>> > can be implemented using 2 I/O pins? My first pass at it can create
deadlock
{Quote hidden}

No, each master generates his own clock.  The two lines are SCL (clock) and
SDA (data).  The devices connect to the bus via "open collector" outputs and
whoever lets the data line go high while the clock line is high first loses
the contention.  BTW, a device can hold the clock low to hold off a transfer
if it needs the time.  The protocol is pretty simple.  Philips has an I2C
device databook that explains it well.  I think the Microchip App note does
ok also but the Philips book is better.  Check out the Microchip App note at
their web site.  They even have example code to play with (haven't tried it
yet).

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...