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

Regards,

Jim


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