intermittent ps/2 keyboard problems

[Brietech]

So I'm attempting to use a ps/2 keyboard wired directly into a 28X1 chip for a project I'm working on. There are 10k-ohm pull-up resistors on the data and clock lines, and all of the connections appear solid (I measured them with an ohm-meter). It is powered either off of a 5V bench supply or 3xAAA batteries. The keyboard seems to randomly "freeze up" though, where it will work for the first 5-10 keystrokes, then apparently stop transmitting data (checked on an oscilloscope). Sometimes it will start up again and work for another 5-10 keystrokes, but it usually seems to eventually freeze up for good. I changed the keyboard for one from a project where it had been wired into an 18X (and working fine last time i had checked), and even with this new keyboard I'm seeing the exact same behavior.

This is the code running on the 28x1 (another 28x1 can read/write to the first "status" byte to reset it so it can accept another character)

startup:
put 0,0
hi2csetup i2cslave,%11100000

main:
	kbin [400,kbtimeout],b0	'grab one character
	get 0,b1
	if b1=1 then main	'if status=ready, discard character
	put 1,b0		'if status <> ready, store character
	put 0,1		'update status=ready
	pause 400

kbtimeout:
	goto main

Does anyone have any suggestions for what might be causing this behavior?

 

[hippy]

Do both keyboards work with the 18X ? If so this points to something 28X1 related. You could try the KBIN command without any timeout or extend the timeout to see if that changes behaviour.

 

[Brietech]

I changed it so that it doesn't use a timeout, but I'm still basically seeing the same behavior. It will work for a little while on power up, and then eventually lock up. I did notice that when it locks up, all 3 of the keyboard LEDs light up permanently (the picaxe normally blinks them after receiving a character as a means of showing feedback)

 

[Brietech]

I also tried it with a different 28X1 chip, with no change, and I measured to make sure that when the keyboard locks up, the clock and data lines are still high (so neither the picaxe or the keyboard is getting stuck and holding the line low or anything)

 

[BCJKiwi]

Are your keyboards 'new'?
Most new keyboards have onboard processors which interact with the PC in various ways and may not behave as expected when not connected to a PC.

If you have an old keyboard available, you could try that and see if it's any better.

 

[Brietech]

I think both of the keyboards are from 1998 or so. One of the keyboards had been hooked up to an 18X and works just fine (I tested it like a week or so ago), though (and the other keyboard is an identical model). The 28X1's don't have any weird keyboard issues, do they? This behavior is pretty weird.

Has anyone succesfully used one before?

 

[BCJKiwi]

Never used the keyboard functions so set one up on a breadboard with a 28X1 rev A.1

remmed out the i2c line
and added;
sertxd ("key = ",b0,13,10)
to your above code just to see if there was any input.
Nil output to terminal.

So I then remmed out all the b1 stuff resulting in a program as follows;

startup:
put 0,0
;hi2csetup i2cslave,%11100000
main:
 kbin [400,kbtimeout],b0 'grab one character
; get 0,b1
; if b1=1 then main 'if status=ready, discard character
 put 1,b0   'location,data if status <> ready, store character
; put 0,1    'update status=ready
 pause 400
 
 sertxd ("key =  ",b0,13,10)
kbtimeout:
 goto main

Get data on the terminal (not the right data of course as there is no translation table) for every keypress regardless of how often keys are pressed or how long the wait is in between key presses.

Don't know if this is of any help or not but am unable to reproduce the issue as described.

Addendum;
The manual indicates 4k7 pullups on clock and data, not 10k. Don't know if this makes any difference but breadboarded with 4k7.

 

[Brietech]

Hmm, I can pick up a pack of 4.7k's today and try it. I think that is what my 18X is using, but I'm not sure why that would be so important. On the other hand, I should mention that I had accidentally wired up the keyboard WITHOUT the pull-up resistors earlier, and I saw pretty much the exact same behavior (I really hadn't been expecting it to work at all).

I feel like the problem might be related to the picaxe sending a command to it that somehow gets corrupted when it tries to make it blink after receiving a key.

 

[hippy]

If you have a couple more 10K's put them in parallel with the existing pullups; as close to 4K7 as makes no odds.

I do think it is worthwhile getting your 18X out and seeing if there is a difference in operation and re-confirming the keyboards do work with an 18X. That's the first thing I'd do.

 

[Brietech]

Okay, so I haven't tried the resistor thing yet, but I finally had some more time to work on it, and I narrowed down the problem:

As far as I can tell, a complete "keyboard transaction" is as follows: Keyboard receives keypress and sends 1 byte of data, picaxe returns 1 byte of data (telling lights to turn on, i think), then returns 1 more byte of data (telling lights to turn off, presumably). I noticed that the lights were getting stuck "on" when the keyboard was locking up, and I also noticed that both the clock and data lines were left floating (and then pulled up to Vcc). By just applying a few more clocks by repeatedly grounding the clock line, I was able to bring the keyboard out of its "locked up" mode. Which leads me to the conclusion that the Picaxe is intermittently dropping clocks when it sends the 2nd data byte.

Therefore:
1) the clocks are not getting there electrically, but all of my connections seem good.
OR
2) the Picaxe is not driving the clock line enough times (some weird bug)
OR
3) the keyboard is somehow ignoring/missing the clock signals.

I don't have access to a reprogrammer at the moment, but if I just mask the Keyboard LEDs (i know there is some kind of kbled command), will that prevent the picaxe from trying to blinks the leds following a key-press?

 

[BCJKiwi]

Suggest you try the correct Rs before anything else as they have a significant bearing on the way the bus timing will behave so if you are missing a few clocks it may all be down to the resistors.

I noticed when testing, that the three keyboard lights were flickering all over the place when typing - did not pursue that aspect though.

 

[evanh]

Just add more 10k resistors in parallel with the existing 10k resistors.


Evan

 

[Brietech]

Okay, so I changed the resistors, and absolutely no change in behavior. I added the following line to the beginning of my program, however:

kbled %10000000 'disable LED blinking

and I now get the following behavior: On "boot up", the keyboard appears completely dead. The lights blink at power-on, but no response on the picaxe when I hit keys. If I unplug and replugin the keyboard, however, it begins to work flawlessly. This also happens if I repeatedly ground the clock line, to force additional clocks to go in. This still happens with 2 different keyboards that appear to work fine on an 18X chip.

Why does my 28X1 keep leaving my keyboard hanging?? Any thoughts, technical?

 

[Brietech]

I finally got it working relatively reliably with the following code:

startup:
setfreq m8
put 0,0
hi2csetup i2cslave,%11100000
pause 10000
kbled %10000111			'disable LED blinking

main:
	pause 300
	sertxd("getting key")
	kbin b0			'grab one character
	sertxd("got key")
	get 0,b1
	if b1=1 then main		'if status=ready, discard character
	put 1,b0			'if status <> ready, store character
	put 0,1			'update status=ready
	pause 400
	goto main

I changed the speed to 8 Mhz, and I also changed the speed (from slow to fast) that the master uses to read from it, and things appear to work now, BUT, I now have the following problem:

For some reason the actual byte that the 28X1 appears to receive using a "kbin" command is different than what an 18X chip recieves! For instance, all arrow keys now seem to produce the byte 0x12, rather than:

117=up key
114=down key
107=left arrow
116=right arrow (from a program that works fine with the same keyboard on an 18X)

and many of the letters/numbers produce different results! Did something change with the keyboard input on the 28X1, or am I just having ridiculously bad luck with all of this?!

 

[Technical]

From what we can see a second PICAXE is interrogating the first chip (over the i2c bus) about which the last key was pressed.

However this i2c communication could happen at any time. So it could occur half way through the kbin command, which could easily corrupt the data and/or disrupt the keyboard operation, as basically the communication with the keyboard will be disrupted for the duration of the i2c communication time.

The solution may be to add a handshake signal between the slave and master - so that the master only tries to read over the i2c bus when the slave is not within a keyboard command. We would certainly try all the testing without the master connected to start with.