[A Project to interface a PS/2 keyboard to a 68hc11 microcontroller]
Due to the slightly odd (not to mention a little inconvenient) low-level PS/2 keyboard hardware-interface, a little bit of ingenuity may be required:
R1 and R2 are the pull-up resistors for the open-drain unidirectional CLK and bidirectional DATA signals. R3 and R4 are protective current-limiting resistors for the pins on the 68HC11, to cover the case where the bidirectional PC3 and PC7 pins might accidentally get configured as outputs at just the wrong time (I don’t want the magic smoke to escape!), and also to somewhat reduce potential overshoot/undershoot arriving at the 68HC11 pins. C1 and C2 are protective capacitors to (hopefully) eliminate any residual overshoot/undershoot. Be aware that although PC7 is a bidirectional pin, we will be configuring it as an output-only pin.
There is a secondary case requiring current-limiting R1 and R2: based on multimeter measurements, some “PS/2” keyboards have internal pull-ups on DATA and CLK, but pretty darned small ones, sometimes as small as 2K, which is bizarre but we must cope with such beasties as well as the more conventional keyboards.
The sizing of C1 and C2, above, is partially guesswork and partially from calculation. Hopefully, due to the relatively slow frequency of the DATA and CLK signals (10-30 KHz), this contraption should hopefully not slow down the rise-/fall-times beyond spec.
There is a certain amount of “moistened finger in the air” about this, but let’s see how it works out.
A significant feature of the diagram is the “kiddy-colour mspaint-style” representation – the reason why it is so apposite will be revealed in a later episode…
Wires, Passives, and a very old SCSI connector
In principle, the power lines for the PS/2 keyboard should be provided via a separate voltage-regulator, but I don’t happen to have a 275mA 5VDC precision regulator chip in the junk-pile, thus I will have to wing it, and hope for the best. At least having a common (albeit unregulated) ground with the (internally regulated) SBC, I might just get away with splitting the unregulated power from the wall-wart into two paths, one for PS/2 keyboard, other for the SBC regulator-input…
Hit the Button
The new program counts incoming clock-interrupts from an actual PS/2 keyboard, at least it will if I have all the wiring correct. Remember, the keyboard only emits clock pulses when a key is pressed or released, and each keypress should result in a serial bitstream of start-bit, 8 data-bits representing a scancode, a parity-bit, and a stop-bit – that should be eleven clock-pulses per press or release.
The hexadecimal pulse-counter is counting in multiples of 11 in response to keypresses! Brilliant!
Not Quite Perfect
I was expecting it to count 22 pulses per keypress+release, but we’re getting 33 pulses. I presume that I have misread the protocol descriptions, as it looks suspiciously as if either the “press” or “release” events are generating a prefix byte along with one of the scancode payloads.
Also, I am getting 33 pulses per press+release with only two of the three PS/2 keyboards I have to hand. The third one (a Dell keyboard) generates a very large number of pulses for each key-event – presumably this one has a weak internal pull-up which is causing the signal to ring. Either that, or it’s just typical Dell wierdness.
Although the Retrochallenge 04/2017 event has only a couple more days to go, it looks like there might just be a chance of me reading and displaying actual scancodes from the data-line before the curtain falls. Stay tuned!