> 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.

The 16C54's lack of interrupts does not eliminate the problem at the PIC's
end if, as in my example [controlling a multiplexed set of lights which is
driven by a shift register while analog-reading photogates] the PIC has to
do something besides talking to the PC; in my case, the code will execute
one light-change and photosensor-read, then talk to the PC until the timer
indicates it's time to change the lights and read the next photosensor, etc.
Another project I've done with worse timing constraints [albeit before I
came up with this protocol--getting the timing to work consistently was a
major pain] involved genlocking video: my CPU could spend all the time it
wanted talking to the PC [merely counting sync pulses] until the display
time arrived, but once the start-of-display scan line came, it had to spend
all its time for the next 2ms outputting video data.

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

/ACK, /Strobe, /Autofeed, /Reset, and the other output control signal are
all open-collector with feedback inputs.

> 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.

I had merely mentioned the uarts, latches, etc. because if they exist they
allow for better protocols; I2C, for example, is an effective multi-master
protocol using only two wires but it requires hardware assistance for a CPU
to operate as anything other than a sole master.

> 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.

If you leave interrupt windows between bits, that will impose a maximum
speed based upon the maximum possible latency.  While it's possible to come
up with better protocols which rely on specific behavior on the part of the
two systems [e.g. send a byte, then wait for the "slow" device to do an
"extra" transition on its clock or data wire to indicate it's just done an
interrupt] such protocols tend to be rather fragile and are often only useful
in the applications for which they are developed.  I was suggesting my proto-
col as an alternative which, while not optimal in every application would be
useable in all and which could therefore be coded once and re-used whenever
such a protocol was needed.

> 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.

Ah, but the Parallax programmer doesn't exactly have to do a whole lot while
it's talking to the PC.  In some applications, however, the PIC may be doing
extremely time-critical things [analog input being the most likely in many
cases, though video output or analog PWM'ing would also qualify] and be
unable to afford the time it would take to monitor for PC communication.