Ps/2 serial protocol

If the indicator LED is installed, it obviously needs a current-limiting resistor in series. Note that in debug mode configuration, the bps rate configuration actually selects a compile-time determined bps, which defaults to bps the same as the Arduino bootloader, which is convenient.

This allows installing one or two jumpers instead of 4 switches, for example. The RTS line is used to view the state of the serial port. With serial serial mice, the line is used to supply power to the mouse, and hence the mouse works only when the line is supplying the voltage.

However, if you use a logic level serial port with this converter, the state is typically inverted, which is why the default is active low.

You may configure it at compile time:. Note that the internal pull-up on the RTS pin means the default state is high, i. With the default, inverted, setting you should physically tie the pin to ground if it is unused, but with the non-inverted setting it may be simply left unconnected. You can upload the resulting ps2serial. To use a bootloader e. However, the fuse values aren't really critical.

Arduino users can probably just make do with the default fuse settings. Once configured, operation is pretty much automatic.

The watchdog timer is used to recover from errors by resetting the device automatically after a few seconds if something goes wrong. A reset may also be forced by sending an exclamation mark! If the mouse driver does not recognize the mouse, it is probably because it expects to read an id character on RTS pulse, and the pulse isn't working not connected, wrong polarity.

If using the Microsoft wheel mouse protocol, the id character may not be recognized by the driver try the regular Microsoft protocol to verify. In case of problems, also try the Mouse Systems protocol when possible, since it has no handshake requirement the RTS can simply be jumpered permanently. Also try the debug mode at bps on the same serial port and view the data in a terminal program.

Send a question mark? An "open-collector" interface has two possible state: low, or high impedance. In the "low" state, a transistor pulls the line to ground level. In the "high impedance" state, the interface acts as an open circuit and doesn't drive the line low or high.

Furthermore, a "pullup" resistor is connected between the bus and Vcc so the bus is pulled high if none of the devices on the bus are actively pulling it low. A general open-collector interface is shown below:. Figure 1: General open-collector interface. Data and Clock are read on the microcontroller's pins A and B, respectively.

As a result, Data equals D, inverted, and Clock equals C, inverted. Note: When looking through examples on this website, you'll notice I use a few tricks when implementing an open-collector interface with PIC microcontrollers. I use the same pin for both input and output, and I enable the PIC's internal pullup resistors rather than using external resistors. A line is pulled to ground by setting the corresponding pin to output, and writing a "zero" to that port.

The line is set to the "high impedance" state by setting the pin to input. Taking into account the PIC's built-in protection diodes and sufficient current sinking, I think this is a valid configuration.

Let me know if your experiences have proved otherwise. Communication: General Description. The bus is "idle" when both lines are high open-collector.

The host has ultimate control over the bus and may inhibit communication at any time by pulling the Clock line low. The device always generates the clock signal. If the host wants to send data, it must first inhibit communication from the device by pulling Clock low. The host then pulls Data low and releases Clock. This is the "Request-to-Send" state and signals the device to start generating clock pulses.

The parity bit is set if there is an even number of 1's in the data bits and reset 0 if there is an odd number of 1's in the data bits. The number of 1's in the data bits plus the parity bit always add up to an odd number odd parity. This is used for error detection. Data sent from the device to the host is read on the falling edge of the clock signal; data sent from the host to the device is read on the rising edge.

The clock frequency must be in the range 10 - This means clock must be high for 30 - 50 microseconds and low for 30 - 50 microseconds.. The Data and Clock lines are both open collector. I guess the AT, it added a microcontroller on the motherboard for the keyboard interface. And the keyboard had some level of the communication from the motherboard. Most important, the keycodes changed. It was a transition period. I once opened a keyboard, and the switch was there, but the usefulness passed, so no need to slot tge case for it.

Now the problem is that the number of combinations on a key board is vast. There are 5, unique combinations of two keys, , combinations of three, 4,, combinations of four…. But there were many keyboards out for terminals long before that, which had various uses besides text entry. I was a teenager back then and certainly had, and still have today a very different perspective. That said, the delay would still be required. It delays the latch clock relative to the shift register clock rather than delaying the shift register clock itself.

Without the delay the output would always be offset by one bit. Does anyone know of a single chip solution or something similar? Please be kind and respectful to help make the comments section excellent. Comment Policy. This site uses Akismet to reduce spam. Learn how your comment data is processed. By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more. It was a later iteration that used a microcontroller to handle the serial keyboard.