Image Map Image Map
Results 1 to 7 of 7

Thread: PS/2 KB help needed--what's wrong with this waveform?

  1. #1
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,152
    Blog Entries
    20

    Default PS/2 KB help needed--what's wrong with this waveform?

    I've been working on a PS/2 keyboard emulator and think that I've pretty much got it.

    However, the subject system "clicks" on keystrokes as if it sees them, but registers nothing. So here's the logic analyzer waveform for "space" ("make" code 0x29). What's wrong with it? Top line is clock, lower line is data.

    space.jpg

    Both lines are driven open-drain with 4.7K to +5V.

  2. #2

    Default

    https://www.avrfreaks.net/sites/defa...20Keyboard.pdf

    According to this the communication is done correctly, the waveform looks just like it should be. Read on the falling edges of the clock pulse, first the start bit, then 0x29 LSB first, then odd parity bit 0, then stop bit 1.

    I would look at it with an oscilloscope to see how the raw signal looks like - possibly the analyzer can read it, but it is somehow incorrect from the machine's viewpoint? What clock rate is this?

  3. #3

    Default

    Hallo Chuck,

    I found a file on my PC explaining the PS/2 protocol. The first negative edge should be situated in the start bit. The next eight edges should be the data and the 10th should be the parity. Next comes the stop bit that is always High. So far so good as I can see (I assume the parity is correct). Then the document says a Low must follow: "After receiving the parity bit, the keyboard will send another one pulse and then take the Data line into Low state for the next pulse." The figure also shows this High bit as only one clock long. Your data line just seems to remain High. It could be the cause of your problem.

    I hope this helped.
    With kind regards / met vriendelijke groet, Ruud Baltissen

    www.baltissen.org

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,152
    Blog Entries
    20

    Default

    I've read conflicting information on that last bit. Some sources label it "ACK", which to me says that the host should take the data line low on the last pulse to acknowledge that the character has been received correctly.

    My logic analyzer is set to the basic 250MHz single-channel sample rate with glitch detection, so I suspect that isn't the problem.

    I did the PS/2 to XT converter code years back, so I thought I understood the protocol, but there's clearly something I'm missing. I'm going to take a real PS/2 keyboard and run the same trace and see what's different--something I probably should have done in the beginning.

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,152
    Blog Entries
    20

    Default

    Here's a real keyboard. Note the turnaround "glitch" in the clock line after the character is sent, with the host holding the clock line low:
    KEY2.jpg

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,152
    Blog Entries
    20

    Default

    Turns out that I was using 3.3V GPIO pins to the MCU; even though I set them to open-drain, they were apparently locking up with the pullups to 5V. Moved the lines to some 5V tolerant ones and things look much better--I'm getting the clock-low ACK from the PC now. Still more debugging to be done, but at least I'm generating the right codes.

  7. #7
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,152
    Blog Entries
    20

    Default

    I'll cap this one off by saying that the IR keyboard works now, with one or two minor caveats.

    The first one is that it discards all host-to-keyboard messages (the keyboard sends but has no capability to receive). It wouldn't matter anyway, as there are no status LEDs and the typematic rate can't be changed.

    The second caveat is that I haven't figured out what to do with the "nipple mouse"--it's not accurate enough for precision work; perhaps I'll just end up translating the movements to cursor sequences. And I haven't implemented the "NUM" key, which turns part of the keyboard into a numeric keypad. It's not a feature I'm likely to ever use.

    I constructed the prototype using a Maple Mini (72MHz STM32F103), but it could easily be built with a Blue Pill or any of the other STM32F1xx evaluation kits. There's USB available on the board, but I need a PS/2 design for my particular purpose. If one wanted USB output, it would be pretty straightforward; there are plenty of examples of the STM32F1xx as an USB HID application.

    I used the libopencm3 support library and the end result uses less than 4K of code space out of 128KB available. RAM is used mostly for receive and transmit buffering. The code is kind of need, as it uses a bidirectional counter running at about 12Mhz and precisely marks the edges of the data output (bitrate is about 11KHz).

    Here's the widget on a scrap of prototype board. The IR receiver is a Vishay TSOP4838 and the headers are, right to left: serial debug, JTAG programming, keyboard output.

    keything.jpg

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •