- instead of using FALLING interrupt state, use the CHANGE mode. That way you get an interrupt on both falling and rising clocks.
Yes, I think I came to that same conclusion as well!
Today's theory is that I can look for the data line to go low - since the data always starts with a start bit of 0, I can tell which way the data is going based on the clock line, and I'll just count 11 clock changes to get the data.
Capturing device->host data is pretty easy, it's host->device stuff (like LED commands) which is causing me issues at the moment.
- you could use a 'man in the middle' setup, where the clock lines from the host and device are wired to separate pins on the arduino. The software would have to echo the clock state to the other pin, but you would be able to detect whether it was the device or host yanking the clock line. But then the keyboard wouldn't work if the sniffer was off.
There's already commercial devices out there that do that, and they don't work that well - I have one collecting dust in my desk drawer. I know it's possible to do this by just 'sniffing' the lines because I have one that works, the problem is that the manufacturer isn't around anymore.