>Well, often there are other features that can be used, most notably either:
>[1] a UART on one/both ends [makes things REAL obvious/easy]; [2] a function
>to latch whether a port pin has changed [even if it has since changed back]--
>this allows a decent bidirectional interleaving protocol to be run on two
>single-directional wires; or [3] a function to keep a pin pulled low after
>something external pulls it low [I2C clock works like this].  I was suggesting
>my protocol in the context of people using a device like the 16C54 which has
>none of the above, talking to a PC printer port which has none of the above.

Sorry again John but I'm really lost now!

YOUR intial crittia was for devices arbitrarily busy. Your then described a
system that I though, and still think was "fringe" and unlikely to be
required.  I put forward a commonly used system that didn't require
bidirectional lines and also would work if the devices were  arbitrarily
busy. As david Knell pointed out the downfall of this system is if the
sending device is interrupted during transfer.

Correct me if I'm wrong but the 16C54 does not have interrupts so the
problem has been eliminated at one end already.  The PC does have interrupts
and if interupted will sending could miss the clock.  But as one end is
stable, you could extend my forwarded system to provide a "clock echo" from
the reciever  or a million other systems  without the need for bidirectional
lines.

Speaking of bidirectional lines, which lines of a PC printer port are
defined as neccessarily bidirectional? Hmm?

I suggested there were work arounds to the problem you first preposed and
David Knell extended to include arbitrarily delays after transfer had began,
a much harder problem. None of the work arounds I had in mind included
uarts, latches, bells, whistles or even sirens, just good software design.

If your system works, and agian I stress I haven't nutted it out (knowing
there's no need) enough to say that it does,  It still must surely be the
last gasp solution given the range of simple solutions available. My system
synchonizes the devices at the start of the tranfer and the only way it will
fail is if it is interrupted, so why not turn off the interrupts and be done
with it? If latency is a problem allow interrupt windows between bits. You
can always reestablish synchronization after each bit exactly as you first did.

BTW A 16c54 and the printer port for your system you say? Didn't I point out
the parallax programmer used the system I forwarded?  Isn't the parallax
programmer a 16C57 talking to a printer port? And, yes it doesn't require
bidirectional lines or any sort of "two for one" protocol.

Regards,

Jim


-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Makers of low cost,
 mega featured PIC programming tools.
newfound@ne.com.au
------------------------------------------------------------------