1. Home
  2. Embedded Programming
  3. PS2 Keyboard interacing theory

PS2 Keyboard interacing theory

Hi,

I am on an initial path to "shoe horn" in a PS/2 style keyboard interface for a HC11 microcontroller based product of mine.

There are a couple of IO pins utilised in this project which for the most part are being unused (they are periodically active in order to talk to a real time clock chipset).

I am investigating the two protocols to see if I can't "hijack" these IO pins while the RTC is out of action and use them to communicate with a PS/2 keyboard connected via some interfacing logic to the same pins.

The RTC chipset has a dedicated chipselect signal connected directly to the HC11, so I can effectivly make it ignore the state of it's clock and data pins while I want to communicate with the PS/2 keyboard. So that part is fine...

However I am wondering about the possibilities of doing the reverse operation.. I.e. disabling the keyboard while wanting to communicate with the RTC.

I have one spare (unused) IO pin on the current board layout and my current thinking is like this...

Connect the spare IO pin from the HC11 to the PS/2 clock signal, and share the pin currently used for bidirectional data IO with the RTC as the PS/2's data signal.

Pulling the dedicated IO pin low should inhibit the PS/2 keyboard from attempting to send scancodes (clock=low) while I'm using the other pin for communication with the RTC chipset. Any scans during this (short) time frame should be buffered by the keyboard and sent as soon as I release the clock.

However if I understand the PS/2 keyboard protocol well enough, the way the keyboard senses a request to send data to it, is for the data pin to be held low while there is a low to high transistion on the clock pin.

The first part of this sequence (pulling clock low, setting data low) will occur whenever I talk to the RTC over the same "bus"... as I'll pull the clock low to disable the PS/2 keyboard, and the shared data pin will logically pulse low every now and then while talking to the RTC chipset.

How will the PS/2 keyboard respond to this? Is it only caring about the state of the data pin upon the low to high clock edge, or is it attempting to start it's clocking sequence (to clock data in) upon the moment the data pin drops low while the clock pin is also low?

I assume in the first case I'm sweet (and can basically ignore the fact that the data signal will "randomly" toggle while talking to the RTC. While in the second case I'd expect the keyboard to send some form of error byte when I finally re-enable it (to indicate the fact of a failed transmission).

The above is probably really badly explained...

Thanks, Christopher Fairbairn

Reply to
Christopher Fairbairn
Loading thread data ...

Hi, it's been a while since I did this, I f remember correctly the keyboard generates the clock signal not your micro. When you power up the keyboard sends data byte aah untill your micro sends a reset command to it. The keyboard will send error codes whenever it detects activity that it does not understand. You can shut it off by removing the power.

Reply to
CBarn24050

Yes and no. The keyboard generates the clock, but the computer can stop the data transfer by pulling clock low.

/Jan-Hinnerk

Reply to
Jan-Hinnerk Reichert

The explanation is good enough for me ;-)

Original documentation on PS/2 keyboard is hard to obtain. You get quite some websites explaining the protocol if you google for "pic keyboard ps2". I like

formatting link

I expect the keyboard to sample data some time after clock has gone high, so you have no problem here.

However, there is one thing you haven't thought of. If you pull clock low, while the keyboard is sending data, the keyboard changes data until it realises that clock is pulled low (which may take up to one clock cycle (about 100us)).

So you have to wait some time between pulling clock low and accessing your RTC. Nevertheless, I would probably take another route to save pins, since this it is hard to track software errors in this setup.

/Jan-Hinnerk

Reply to
Jan-Hinnerk Reichert

yes that is true, but doesn't he want to use that pin for his rtc as well?

Reply to
CBarn24050

No, he only wants to use the data pin for both. He has one I/O-pin left for the clock.

Reply to
Jan-Hinnerk Reichert

Hello

Have a look at this one:

formatting link

You should be able to use the data line shared with the RTC for data and the free line (5; port-G3) for the clock. Ignore 3; IRQ.

If you're not using the IRQ you could connect it with the clock and make the it all interrupt driven.

Paul Bealing

formatting link

Reply to
Paul Bealing

Reply to
Laszlo Cser

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.