[A Project to interface a PS/2 keyboard to a 68hc11 microcontroller]
The Starting Situation
By the previous episode, I was getting the right number of clock-pulses per PS/2 key event, but not all the scancodes received seemed correct, eg:
|Key||Detected Scancode||Expected Scancode||Comment|
|Insert||0x0E 0x07||0xE0 0x70||swapped nibbles|
At first, I assumed that sampling the data-line precisely when the clock-line went low might be unwise, perhaps there is some signal skew between the clock and data-lines? There are many, many ‘net posts stating that you should delay a short while after the clock falls before sampling the data-line; but that isn’t the way all the clocked-data interfaces I have seen work – the clock is supposed to indicate the approximate center of the data-bit, not the leading or trailing edge of it.
Also, the above results were occurring absolutely every time, 100% reliably, which likely precludes a diagnosis of hitting data-line edges exactly when they are transitioning. Something else is up.
Squinting at the results table, and wondering why a couple of scancodes were correct, one other had nibbles swapped, but the others all seemed way off-beam, I came to the conclusion that I should write the detected/expected codes out by hand, in binary, on paper, and squint at those instead.
The Light Dawns
Oh, the bits are the the right value, but in reversed order. Doh!
One quick program-edit later, to have the ISR store the bits of each recieved octet in reverse order, and I am now detecting all the right scancodes for all 83 keys on the compact Cherry keyboard!
Even the 8-byte monstrosity that the “Pause” key produces: 0xE1,0x14,0x77,0xE1,0xF0,0x14,0xF0,0x77
And all using my original interface circuit, which in spite of all the previous doubts, works just fine.
That seems like a wrap, all over, the fat lady has sung. I’m calling the project a success as I have managed to achieve what I set out to do. However, I have not had quite so much luck with a couple of other PS/2 keyboards: the big kiddy-coloured “fumble-board” and a Dell keyboard: both of those always generate an 0x55 scancode approximately once per second, whether keys are being pressed or not, and pressing keys does not change that.
I am guessing that those much younger keyboards require some kind of initialisation command to be sent, or (wild guess, handwaving) that they have strong internal pullups (4K7 or lower) that have a metastable reaction to my overcurrent-elimination circuit.
For now, the job is done, and has been quite an education. Next post will be a wrap-up of lessons learned, experiences experienced, and the mistakes I won’t be making in future!