3

I'm trying to make a keyboard emulator on ATmega16A. I'm currently implementing logical low as output-zero, and, since the host(?) is supposed to pull up the line, I send logical high state as input mode of my pins. This lets me easily check that inhibit condition hasn't happened while I'm transmitting data, in addition to outputting "1".

But the problem is that in this mode, the time to raise the voltage to 95% VCC appears to be about 25 μs, which is quarter of the maximum allowed clock period (minimum frequency is 10 kHz). So I've now tried to actively drive the pin to VCC, and only then switch it to input mode to check for inhibit condition.

Is this kludge of actively driving the bus high actually legal from the protocol POV? I'm following this document and have failed to find how exactly one should output logical high level.

Should I instead use a lower-resistance pull-up resistor on the keyboard side and leave the pin in input state when trying to output logical high value?

Ruslan
  • 854
  • 7
  • 16
  • If it's but a quarter of the maximum allowed time, what's the issue you want to solve by actively driving the pin high (which you really shouldn't, this seems to be an open collector bus)? – Marcus Müller Sep 01 '19 at 10:25
  • @MarcusMüller From the document I reference in the OP, _"The time from a data transition to the falling edge of a clock pulse must be at least 5 microseconds and no greater than 25 microseconds."_ 25 microseconds is what it takes to barely reach something resembling good logical high value, and I should have pulsed the clock by this time. Not sure how reliable such transmission would be. Also, looking at a real keyboard's oscillogram, I see it's much more abrupt transitions. – Ruslan Sep 01 '19 at 10:29
  • 1
    95% is not "barely resembling a good signal", to be honest, it's pretty solid (and not very surprising it takes long – effectively, the pull-up has to charge the parasitic line capacitance, and you know how capacitor charge curves look!). I really don't know enough about the IO pin characteristics of ATMegas to comment on impedance, but PS/2 really is an open collector bus, and thus you mustn't actively drive it high, because you'd be missing the inhibit condition. Maybe adding *weak* pullups on the keyboard side would be permissible? (completely different direction: why not USB? why Atmega?) – Marcus Müller Sep 01 '19 at 10:37
  • @MarcusMüller USB is what I'm planning to take as input (making a converter), Atmega because it's what I already have and what I thought would allow me to debug the PS/2 side of the future converter. – Ruslan Sep 01 '19 at 10:45
  • Hm, I wasn't aware the ATMega16 does USB! – Marcus Müller Sep 01 '19 at 10:49
  • @MarcusMüller of course it doesn't. As I said, I wanted to debug the implementation of PS/2 protocol before I get something more capable. – Ruslan Sep 01 '19 at 10:55
  • 1
    But what sense would debugging a hardware that you won't use in the end make? – Marcus Müller Sep 01 '19 at 11:11
  • 1
    @MarcusMüller logic doesn't depend on hardware. What I'm trying to develop first is the logical side: bits, delays, sequences of commands and responses etc. – Ruslan Sep 01 '19 at 11:14
  • "logic doesn't depend on the hardware" <-- that's profoundly untrue, as your timing problem impressively demonstrates! – Marcus Müller Sep 01 '19 at 11:22
  • 1
    ATMEGA16 does USB, but badly - see AVRUSB. – Jasen Слава Україні Sep 01 '19 at 11:32
  • 1
    You could do what the MCS51 series (8051 and siblings) do: Switch to high for a short time with a low impedance and after that switch to high impedance. Well, you might need an additional port pin and a resistor for that. Or you try the internal pull-ups. – the busybee Sep 01 '19 at 11:40
  • @thebusybee well, that's what I meant by _"actively drive the pin to Vcc, and only then switch it to input mode"_ – Ruslan Sep 01 '19 at 11:41

1 Answers1

7

With PS/2 interfaces, both the host and the device should have pull-ups. So put stronger pull-ups on AVR side. Pulling it high even for a moment is just wrong.

Justme
  • 127,425
  • 3
  • 97
  • 261