I wrote

>> "If the keyboard is not sending or if the system elects to override the
>> keyboard's output, the system forces the keyboard clock line to low
>> level for more than 60 microseconds while preparing to send data.
>> When the system is ready to send the start bit (the data line will be
>> low), it allows the clock line to go to high level"
>>
>> Now, re-reading that, possibly I'm looking at the wrong end of the
>> PIC's data packet. I do send the clock line low for>  60us, and that's
>> at the end of the transmission, after the Stop bit. However, the 4066
>> should be isolating the keyboard from that. But it's worth checking,
>> maybe there's leakage. I'm wondering why my keyboard (the waveform
>> of which I copied) has that 357us low on the clock line after the Stop
>> bit. I don't see it in the specifications. Perhaps reducing it to a=20
>> nominal bit width will fix the problem, without needing the 4066

That seems to be the fix. I appear to emulate what my keyboard does
too well. The 357us low assertion at the end of the keyboard data
transmission might be to prevent the PC from sending commands for
a period. When the PIC does it, the PC takes no notice but of course
the keyboard sees it as a request from the PC

With my 350us reduced to 44us (a nominal bit length), both the PIC
and the keyboard are able to use the same lines. In fact I'm typing this
with the PIC on the same line. Pushing the PIC's Send button does this

fffffff

So for the time being I've gone back to the original no-4066 circuit. I
notice the typematic speed has reduced a little though, that's something
to investigate

Thanks for making me explain and think out loud. Usually does the
trick

Joe

*
*
**********
Quality PIC programmers
http://www.embedinc.com/products/index.htm=20

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.