Closed Harvie closed 4 years ago
That's good news. Do you know how to use git and make pull request with your changes on github?
BTW if host tries to send data often, maybe we should just call keyboard.keyboard_handle(&leds) more often (eg. after each button sent)... It will handle incoming data. I already forgot how PS2 protocol works since the last time i've been doing the modifications... Do you thing that's a good idea?
Problem is that every PS2 implementation is bit different, so we need to be sure that we are compatible with everyone. I see the code that you suggest was already there, but i've commented it out.. I am not really sure why... Probably i was thinking it's not needed. I think we can include it again. But i would be happy if i had some deeper theorethical undestanding of why this is done.
Here http://www.burtonsys.com/ps2_chapweske.htm they say following:
Host-to-Device Communication:
The packet is sent a little differently in host-to-device communication...
First of all, the PS/2 device always generates the clock signal. If the host wants to send data, it must first put the Clock and Data lines in a "Request-to-send" state as follows:
Inhibit communication by pulling Clock low for at least 100 microseconds. Apply "Request-to-send" by pulling Data low, then release Clock.
The device should check for this state at intervals not to exceed 10 milliseconds. When the device detects this state, it will begin generating Clock signals and clock in eight data bits and one stop bit. The host changes the Data line only when the Clock line is low, and data is read by the device when Clock is high. This is opposite of what occours in device-to-host communication.
I am not yet sure what this means for our code... But i think it implies that when hosts requests communication, it holds clock low only initialy and then continues to hold data low instead. so if we don't catch the request on clock during the first 100 microseconds it might be missed unless we check the data line as welll. Which is speaking in favor of change that you suggest.
I strongly recommend that both the clock and data lines be sampled. Assuming the device isn't transmitting anything, there shouldn't be any other reason that the data line is low, so according to the spec we can safely assume that the host is in an RTS state.
From what I can tell, the clock is only pulled low to inhibit communication and force the device to listen, which isn't a problem if it isn't actively transmitting anything, so really it should be looking out for the data line being held low. That also lines up with having to check once every 10ms or less, since the data line should be held low within that period.
@thomotron thanks for peer review. Fixed in a043002 , closing.