Post by thread:[PIC] PC keyboard emulator problem

Hi all I'm working on a project based on this http://home.clear.net.nz/pages/joecolquitt/pic_keyboard.html The intention is to monitor/capture/transmit keypresses of the PC keyboard, using a PIC circuit between the keyboard and the PC. Although it can be added in parallel A problem has arisen which has me stumped. The keyboard freezes when the PIC transmits a character down to the PC. The PC still recognises and displays any further characters sent by the PIC, so the clock and data lines are still working As far as I can tell, according to the pdf linked to on the page, the PIC transmission is within timing specs (as evidenced by the PC recognising characters sent). On occassion I've had the PIC emulate the timing exactly but the keyboard still stops As I understand it, PC keyboard outputs are open-collector or open-drain with pullups to Vcc. My grounding transistors are in parallel with those, which I wouldn't have thought to be a problem. I've also tried disconnecting the keyboard during a PIC transmission using 4066 switches but no luck I see no glitches on data, clock or Vcc, and there's no sequence which would put the keyboard in a state to receive commands. All I see is a character going to the PC from the PIC Any thoughts ? When it's sorted out I'll put the relevant parts up as a project/reference on PIClist TIA Joe * * ********** Quality PIC programmers http://www.embedinc.com/products/index.ht

On 29/07/2010 11:41, ivp wrote: > Hi all > > I'm working on a project based on this > > http://home.clear.net.nz/pages/joecolquitt/pic_keyboard.html > > The intention is to monitor/capture/transmit keypresses of the > PC keyboard, using a PIC circuit between the keyboard and the > PC. Although it can be added in parallel > > A problem has arisen which has me stumped. The keyboard > freezes when the PIC transmits a character down to the PC. > The PC still recognises and displays any further characters > sent by the PIC, so the clock and data lines are still working The data is bidirectional somehow, I forget the details. Maybe the keyboard is waiting for something. The three LEDs are not set by keyboard at all, but set by commands from PC, that I'm 100% sure of.

> The data is bidirectional somehow, I forget the details. Maybe > the keyboard is waiting for something. Hi Michael Well that's the puzzle. If you read Section 3 of the keyboard spec pdf you'll see what's need for the keyboard to become an input device. I don't believe, or at least see how, my PIC puts it in that state a) if the keyboard thinks that is being requested to accept data it starts clocking. I don't see it doing that b) isolating the keyboard with the 4066 prevents any signals at all reaching it c) sending data from the PIC when the keyboard is idle rules out a contention condition (plus the 4066 isolation case) Joe * * ********** Quality PIC programmers http://www.embedinc.com/products/index.ht

Hi. From your curcuit, it seems as you have hard-wired data/clock from both connectors. So when the PIC sends, that will make the kaybaord to think that the "host" will be sending something. And it will not, probably. That might be why the keybaord locks up. I would try with isolate the two connectors, so that when the PIC sends, it's quiet on the line back to the kaybaord. I havn't looked into it deaper, but maybe a couple of diods ? I have also checked this page : http://www.computer-engineering.org/ps2protocol/ Regards, Jan-Erik. On 2010-07-29 12:41, ivp wrote: {Quote hidden}> Hi all > > I'm working on a project based on this > > http://home.clear.net.nz/pages/joecolquitt/pic_keyboard.html > > The intention is to monitor/capture/transmit keypresses of the > PC keyboard, using a PIC circuit between the keyboard and the > PC. Although it can be added in parallel > > A problem has arisen which has me stumped. The keyboard > freezes when the PIC transmits a character down to the PC. > The PC still recognises and displays any further characters > sent by the PIC, so the clock and data lines are still working > > As far as I can tell, according to the pdf linked to on the page, > the PIC transmission is within timing specs (as evidenced by > the PC recognising characters sent). On occassion I've had > the PIC emulate the timing exactly but the keyboard still stops > > As I understand it, PC keyboard outputs are open-collector > or open-drain with pullups to Vcc. My grounding transistors > are in parallel with those, which I wouldn't have thought to be > a problem. I've also tried disconnecting the keyboard during > a PIC transmission using 4066 switches but no luck > > I see no glitches on data, clock or Vcc, and there's no sequence > which would put the keyboard in a state to receive commands. > All I see is a character going to the PC from the PIC > > Any thoughts ? When it's sorted out I'll put the relevant parts up > as a project/reference on PIClist > > TIA > > Joe > > * > * > ********** > Quality PIC programmers > http://www.embedinc.com/products/index.ht

{Quote hidden}> I'm working on a project based on this > > home.clear.net.nz/pages/joecolquitt/pic_keyboard.html > > The intention is to monitor/capture/transmit keypresses of the > PC keyboard, using a PIC circuit between the keyboard and the > PC. Although it can be added in parallel > > A problem has arisen which has me stumped. The keyboard > freezes when the PIC transmits a character down to the PC. > The PC still recognises and displays any further characters > sent by the PIC, so the clock and data lines are still working > > As far as I can tell, according to the pdf linked to on the page, > the PIC transmission is within timing specs (as evidenced by > the PC recognising characters sent). On occassion I've had > the PIC emulate the timing exactly but the keyboard still stops > > As I understand it, PC keyboard outputs are open-collector > or open-drain with pullups to Vcc. My grounding transistors > are in parallel with those, which I wouldn't have thought to be > a problem. I've also tried disconnecting the keyboard during > a PIC transmission using 4066 switches but no luck > > I see no glitches on data, clock or Vcc, and there's no sequence > which would put the keyboard in a state to receive commands. > All I see is a character going to the PC from the PIC > > Any thoughts ? When it's sorted out I'll put the relevant parts up > as a project/reference on PIClist I suspect the keyboard is seeing the characters you are sending as commands to the keyboard, but as it doesn't know what to do with them it goes into dumb mode. But then I thought this was how barcode scanners and the like worked, so that doesn't make sense either ... -- Scanned by iCritical.

On 2010-07-29 13:29, spam_OUTalan.b.pearceTakeThisOuTstfc.ac.uk wrote: {Quote hidden}>> I'm working on a project based on this >> >> home.clear.net.nz/pages/joecolquitt/pic_keyboard.html >> >> The intention is to monitor/capture/transmit keypresses of the >> PC keyboard, using a PIC circuit between the keyboard and the >> PC. Although it can be added in parallel >> >> A problem has arisen which has me stumped. The keyboard >> freezes when the PIC transmits a character down to the PC. >> The PC still recognises and displays any further characters >> sent by the PIC, so the clock and data lines are still working >> >> As far as I can tell, according to the pdf linked to on the page, >> the PIC transmission is within timing specs (as evidenced by >> the PC recognising characters sent). On occassion I've had >> the PIC emulate the timing exactly but the keyboard still stops >> >> As I understand it, PC keyboard outputs are open-collector >> or open-drain with pullups to Vcc. My grounding transistors >> are in parallel with those, which I wouldn't have thought to be >> a problem. I've also tried disconnecting the keyboard during >> a PIC transmission using 4066 switches but no luck >> >> I see no glitches on data, clock or Vcc, and there's no sequence >> which would put the keyboard in a state to receive commands. >> All I see is a character going to the PC from the PIC >> >> Any thoughts ? When it's sorted out I'll put the relevant parts up >> as a project/reference on PIClist > > I suspect the keyboard is seeing the characters you are sending as > commands to the keyboard, but as it doesn't know what to do with them it > goes into dumb mode. > > But then I thought this was how barcode scanners and the like worked, so > that doesn't make sense either ... Barcode readers designed to be used between a PC keyboard and a PC, uses a "Wedge". Now, I do not think that thing simply hard-wires the in and out connectors as in this case. I'm pretty certain that it contains some electronics to isolate interfaces. You can't see/know without opening one, of course

ivp wrote: > Well that's the puzzle. If you read Section 3 of the keyboard spec > pdf you'll see what's need for the keyboard to become an input > device. I don't believe, or at least see how, my PIC puts it in that > state Maybe the keyboard thinks the PC is trying to send to it when it sees pulses it didn't create? ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

>> I suspect the keyboard is seeing the characters you are sending >> as commands to the keyboard, but as it doesn't know what to do >> with them it goes into dumb mode Alan, I'll double-check all signals when I'm at that PC tomorrow. There is a protocol for the PC to request the keyboard accept data >From the specs - "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 nominal bit width will fix the problem, without needing the 4066 > Barcode readers designed to be used between a PC keyboard > and a PC, uses a "Wedge". Now, I do not think that thing > simply hard-wires the in and out connectors as in this case. > I'm pretty certain that it contains some electronics to isolate > interfaces Jan-Erik, If so, those electronics would have to allow the bi-directionality of the lines Joe * * ********** Quality PIC programmers http://www.embedinc.com/products/index.ht

On 2010-07-29 14:24, ivp wrote: {Quote hidden}>>> I suspect the keyboard is seeing the characters you are sending >>> as commands to the keyboard, but as it doesn't know what to do >>> with them it goes into dumb mode > > Alan, > > I'll double-check all signals when I'm at that PC tomorrow. There > is a protocol for the PC to request the keyboard accept data > >> From the specs - > > "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 nominal > bit width will fix the problem, without needing the 4066 > >> Barcode readers designed to be used between a PC keyboard >> and a PC, uses a "Wedge". Now, I do not think that thing >> simply hard-wires the in and out connectors as in this case. >> I'm pretty certain that it contains some electronics to isolate >> interfaces > > Jan-Erik, > > If so, those electronics would have to allow the bi-directionality of > the lines > Right, the "wedge" has to monitor the wedge-PC line to see if the PC's tried to send. And if so, relay that over to the keyboard side. If I understand correctly. Or simply connect the PC and kayboard directly (if the PC wants to send). Maybe that can be built using discrete electronics also, I havn't thought about it. I did some Googling to try to find some exemple schematics on a "wedge", but only come up with different text-based descriptions. All saying that a "wedge" is what allows two sources (the keybaord and something else, often a barcode reader) to communicate with a PC... > Joe > > * > * > ********** > Quality PIC programmers > http://www.embedinc.com/products/index.ht

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