Just catching up - whew!

Several people noted that the 2-line solution has been done by TI. 
Thanks - good to know.

Vasile Surducan wrote:
 >> Jake Anderson wrote:
 >>> I think the solution may be in the analogue regime, You could do it 
with
 >>> 1 pin per pic a cap and some resistors.
 >>> Analouge gives you the ability to communicate multiple bits of data 
over
 >>> one line. The question is, how.
 >> Bingo!
 >
 > Bingo but looser. You need voltage to current conversion for long
 > lines.

Long lines are not a requirement.

Wouter van Ooijen wrote:
> I start to send an 0 and pull line A low. Next I see line B has been
> pulled low. Is this the acknowledge for my pulling A low, or an attempt
> from my peer to start sending a 1?

I would say that your peer isn't allowed to send something until you've 
sent it a command telling it to.  That is, you have to have a 
master/slave relationship, with the slave sending only when requested.

Not sure about the threading - you may have been talking about NOT 
requiring master/slave; if so, I agree, I can't see how that would fit 
here either.

And also:
> Another note on time-independent protocols: I would also require that
> the proctocol is lockup-free: whatever state the two sites start in,
> after a finite (and reasonable?) number of exchanges they must be able
> to communicate. This facilitates error recovery, independent
> powerup/reset, and hot-plugging.

I agree, and I haven't solved that yet.  The best I've come up with so 
far is something like this:

Send data as 8 bits with an inverted parity bit following.  I.e., 0 is 
sent as binary 0000 0000 1.

Start a new message with some large number of 0 bits (18 seems like 
enough, but fewer may be sufficient), followed by a 1.

On a parity error, or on startup, or whenever you're confused, wait for 
that startup string, then begin again.

If the master has asked for a response from the slave, and the slave 
takes an eternity to respond (seconds, e.g.), give up and take over 
again.  This violates the requirement for complete time-independence. 
But, in my original application, slow (second-resolution) timekeeping is 
globally available, and I bet for most applications, you can define both 
some glacial measurement of time and a length of time beyond which you 
assume your peer is dead.
-- 
Timothy J. Weber
http://timothyweber.org
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist