Well, let the master PIC send messages to the slave and tell the slave what
to do, then read the result from the slave. It's no different than
interfacing another IC except that YOU define the protocol between them. Use
I2C if you like or plain parallell communication or RS232 or whatever feels
good.

> Well, let the master PIC send messages to the slave and tell the slave what
> to do, then read the result from the slave. It's no different than
> interfacing another IC except that YOU define the protocol between them. Use
> I2C if you like or plain parallell communication or RS232 or whatever feels
> good.

I've been working on a good bus protocol for potentially-busy CPU's. The
best I've come up with so far for connecting precisely two CPU's which may
be arbitrarily busy and do not have any "special" hardware useable for such
a task is described below. Note that I2C does not meet this criterion since,
without hardware assistance, a busy slave device could miss bits coming from
the master.

Hardware:
The hardware consists of two open-collector signal wires for a two-device
configuration, or three or four [four wires will reduce CPU overhead on any
devices that aren't being addressed] open-collector wires for any other
number of devices.

Protocol:
All data bytes are formatted as nine bits: a "0" start bit and eight data
bits. Other than during a byte, all "1" bits received will be ignored. Any
device transmitting should send at least one "1" bit before the first zero
bit, and messages are ended by sending a "1" bit where the start bit would
be expected.

During idle state, both lines are idle. To send a zero, the sender asserts
line A; the receiver then asserts line B to acknowlege receipt. Once the
sender sees B asserted, he releases A; the receiver will then release B.
Once the sender sees B released, he can send the next bit.

To send a one, the procedure is as above except that the sender asserts B
and the receiver acknowleges by asserting A, etc.

If the sender is sending a message to which a reply is expected, he will
assert B to send the final "1" and the receiver will assert A. Then the
sender will release B and the receiver will release A and assert B [to
send his leading "1" bit]. Since the sender has released B and yet it
is still asserted, the sender can tell that B has acknowleged the sender's
release of B and is trying to send a bit.

While this protocol is somewhat speed-limitted by the requirement of two
transitions in each direction for each bit sent, it is completely insensitive
to any unexpected delays either party might experience. Naturally, if one
party is busy with a 90ms task every 100ms the throughput will suffer, but
any bits sent will be (eventually) received and confirmed.

>I've been working on a good bus protocol for potentially-busy CPU's. The
>best I've come up with so far for connecting precisely two CPU's which may
>be arbitrarily busy and do not have any "special" hardware useable for such
>a task is described below. Note that I2C does not meet this criterion since,
>without hardware assistance, a busy slave device could miss bits coming from
>the master.

cut........

>What does everyone think of this as a protocol?
>
Clumsy and unnecessary. Consider this protocol.

Two pics or any other devices, with one input and one output each. they
don't ever change (great for the PC printer port). To communicate one drops
its output the other then provides an ack etc....... and then provides the
clock for the sender. Work out the details yourself but I've given you the
idea.

You have with just two fixed lines bidirectional tranfer with handshaking
built in!

This is how the parallax programmer comunicates the the PC with just two
fixed direction lines. Its brilliant!

> Two pics or any other devices, with one input and one output each. they
> don't ever change (great for the PC printer port). To communicate one drops
> its output the other then provides an ack etc....... and then provides the
> clock for the sender. Work out the details yourself but I've given you the
> idea.
>
> You have with just two fixed lines bidirectional tranfer with handshaking
> built in!
>
> This is how the parallax programmer comunicates the the PC with just two
> fixed direction lines. Its brilliant!

For this protocol to work, however, it is necessary that the device
responding to the clock do so within a known, finite, amount of time
and this time limits the speed of communications (e.g. if the slave
may take up to 1ms to respond to the clock pulse, then the master
must wait 1ms after every bit to ensure that it's reading the correct
data). There are some cases in which this requirement is acceptable--
often a micro will have nothing better to do than wait for clock signals
from a PC. But if both devices may be genuinely busy, I don't think
any approach without two bidirectional wires or latching hardware will
work.

[snip]
>Two pics or any other devices, with one input and one output each. they
>don't ever change (great for the PC printer port). To communicate one drops
>its output the other then provides an ack etc....... and then provides the
>clock for the sender. Work out the details yourself but I've given you the
>idea.
[snip]

Hmm. This one's fine provided that the sender can keep up with the clock
provided by the receiver. John Payson's go can cope with either end being
busy at any time for as long as required.

I think I've figured out how to apply it to many devices using the third
line, but perhaps John would be kind enough to post that bit too?

>For this protocol to work, however, it is necessary that the device
>responding to the clock do so within a known, finite, amount of time
>and this time limits the speed of communications (e.g. if the slave
>may take up to 1ms to respond to the clock pulse, then the master
>must wait 1ms after every bit to ensure that it's reading the correct
>data). There are some cases in which this requirement is acceptable--
>often a micro will have nothing better to do than wait for clock signals
>from a PC. But if both devices may be genuinely busy, I don't think
>any approach without two bidirectional wires or latching hardware will
>work.
>
>
My apologies, I was off track. I hadn't reviewed close enough your orginal
criteria and you are right of course, an interupt would knock out my system.

I haven't checked in detail and taking your word for it, your system could
work in the circumstances you outlined though you probably wouldn't be
recommending it as the first one to consider. Usually there are other
"work-arounds" otherwise a protocol like this would be commonly known and used.

Also, I didn't mean to send my reply as it was. I always start of brash and
mellow down on the second or third revision. I changed proceedure with
eudora and sent the 1st draft accidentally. I didn't mean to it be so sharp
on this matter, sorry.

> I haven't checked in detail and taking your word for it, your system could
> work in the circumstances you outlined though you probably wouldn't be
> recommending it as the first one to consider. Usually there are other
> "work-arounds" otherwise a protocol like this would be commonly known and
used.

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.

> Also, I didn't mean to send my reply as it was. I always start of brash and
> mellow down on the second or third revision. I changed proceedure with
> eudora and sent the 1st draft accidentally. I didn't mean to it be so sharp
> on this matter, sorry.

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

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

>The 16C54's lack of interrupts does not eliminate the problem at the PIC's

cut cut...

>all its time for the next 2ms outputting video data.

Well, lets agree to disagree, I still don't see that any of the above
necessitates bidirectional lines os esoteric protocols.
>
>> 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'm not sure enough to argue and what the defined standard is but in
practice different systems are used and what works on many cards may fail on
others just when you were sure of universal compatibility. |I have been
caught with an eprom emulator and a 8748/9 burner, both published in US
mags via DIY in hong kong..

>If you leave interrupt windows between bits, that will impose a maximum
cut cut......
>useable in all and which could therefore be coded once and re-used whenever
>such a protocol was needed.

As long as the technical merrits are on the table I'm not going to argue
endlessly on philosophical design preferences. Personally, I believe in
tailor made optimal solutions but I realize it a personal choice.
>
>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.

John, whatever.... but I still fail to see how you have adaquately
promoted your system as been practical. Purely from a technical point, the
issue is far from resolved.

I know what works for me and all the senarios you forwarded I am sure I can
solved in simpler ways than you prepose. As I said before, maybe the whole
matter is philosophical, but regardless of, I don't feel comfortable
continuing as others are paying to down load this and it hasn't appeared to
have wide spread appeal (interestingly!).

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

John, I think your 2-wire bidirectional protocol idea is very
good. Asynchronous protocols are tricky, and I'm not sure I understand
all details, but it certainly looks like good and robust
engineering. Incidentally, I have seen a proprietary protocol invented
by Sony for high speed communication between a PC and their
DataDiscman, using similar principles. Keep up the good work!

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

Jim, the fundamental flaw of the system you describe is its time
dependence. It was a serious mistake of Parallax to use this protocol,
since it causes malfunction of their PIC programmer, as has been noted by
several subscribers to this mailing list in the past (eg with an HP host
and an IBM host).

It isn't possible to control the timing of a generic PC compatible so
well that you can communicate with the speed that Parallax
expects. There are two possible solutions: (1) Either slow down the
current protocol so much that PC timing can be guaranteed, or (2) use
an asynchronous protocol, like the one John suggested. The latter
alternative is preferrable, since it allows much higher bandwith.
(John, don't worry about your protocol being speed limited - it is
the synchronous protocols that are speed limited!)

The serious thing is that Parallax *cannot* correct this design
mistake with just new PC software. In both cases, they would have to
replace the PIC in the socket. In (2), they would also have to replace
the parallel port plug, as their current plug uses pins 2, 11, and 25.

> 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

Interrupts and cache memory. You also need to go through the PC
parallel port interface, and signals *do not* appear on the port any
precise delay after setting the corresponding register bits.

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

There is description of this in the excellent PC Parallel Port
FAQ. Out of my memory, at least 16 and 17 (pulled-up OC, can be both
written and read). You can also connect a status line output with a status
input to get a bidirectional line.

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

Jim, if you have a portable routine for outputting precisely timed
signals on a PC parallel port, what accuracy can you get? Can you
submit it to the list? I'm sure that list subscribers would be very
interested in testing it.

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

I agree that the Parallax system makes a good case in point :-).

I don't want to pick on Parallax, because they make good products, and
I think they have a good company policy in general. However, I have
pointed out this problem to them and essentially received a short-cut
answer like "Tough luck for you - We can't test all PCs." There is no
question Parallax has been aware of the time dependence problem. A
good protocol for high-speed communication with a PC must necessarily
be time independent.

>>>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!
>
>John, I think your 2-wire bidirectional protocol idea is very
>good. Asynchronous protocols are tricky, and I'm not sure I understand
>all details, but it certainly looks like good and robust
>engineering. Incidentally, I have seen a proprietary protocol invented
>by Sony for high speed communication between a PC and their
>DataDiscman, using similar principles. Keep up the good work!
>
cut cut......{Quote hidden}

>
>I don't want to pick on Parallax, because they make good products, and
>I think they have a good company policy in general. However, I have
>pointed out this problem to them and essentially received a short-cut
>answer like "Tough luck for you - We can't test all PCs." There is no
>question Parallax has been aware of the time dependence problem. A
>good protocol for high-speed communication with a PC must necessarily
>be time independent.
>
>Cheers,
>
> -- Martin
>
>

If anyone is seriously interested in the long reply to this please email me
direct and I will send a copy or upload to the pic list if there is a number
of people asking.

>
> I've been working on a good bus protocol for potentially-busy > CPU's.

---------- cut -----------

> Protocol:
> All data bytes are formatted as nine bits:
> a "0" start bit and eight data bits.
> Other than during a byte, all "1" bits received will be ignored. Any
> device transmitting should send at least one "1" bit before the first zero
> bit.
>
---------- cut -----------

Can you please explain the last sentence.
It looks like a limitation to me (if one data bit mast be '1' there is only
7 data bits).