Main > Main Forum
USB vs PS/2 vs COM vs LPT
Lewis Black:
If nothing else this has been a very educational thread, but I still I eagerly await the troll's flame-out.
SavannahLion:
--- Quote from: Driver-Man on September 27, 2010, 04:41:37 am ---
--- Quote from: Malenko ---What exactly was the point of this thread again?
--- End quote ---
Everyone can obtain their own numbers now, after that, the point is whatever you choose it to be. You could also ask your friendly neighborhood Driver-Man to make you a better driver for that crappy USB connection of yours.
--- End quote ---
At this point, I would not install anything you wrote. I would recommend the same to anyone else looking at any of your software. You present a danger copying and pasting code you apparently do not even bother reviewing or understanding. See my next point.
--- Quote ---
--- Quote from: JustMichael ---Now that is a very good question!
--- End quote ---
Don't you see 7ms lag between each key would mean only about TWO KEYS per frame @60 FPS animation?
--- End quote ---
This statement is so patently ludicrous you should be kicked out of here for it. Simply playing a game with the keyboard would prove this statement wrong.
Rather than seeking education and understanding, Driver has done nothing but attempt to disprove nearly every statement that has been written here. Only when that evidence is painfully overwhelming does Driver switch his argument to another focus. Where is the value in a thread filled with nonsense counter arguments?
This thread needs to end.
MonMotha:
Since I was scratching my head over this one, Driver-Man's "port 0x81" appears to come from the USB endpoint number. Of course, this is not an IO port at all; it's just an identifier to separate out some of the traffic on the USB line from other traffic, but that's the only place I can think of this number coming from. Actual IO port 0x81 would be part of the configuration registers for the 8237 DMA controller that was used on the ISA bus. I believe those registers still exist for use with the LPC bus, but I could be wrong. I certainly wouldn't expect applications or the OS to look for or place keyboard data there. If you did so on a PC where those registers were active, the results could be...interesting.
--- Quote from: RandyT on September 26, 2010, 11:56:55 pm ---Somewhat spotty compatibility with older OSes when you deviate from the "boot compatible" keyboard device. I even have a device that should be boot compliant which works fine under 98SE and XP, but performs poorly for gaming under 2K. Haven't tested it with Win7 yet, but I'll bet it's ok. If it is, it will probably see the light of day eventually. PS/2 just works, though, and I've seen a lot of folks here resort to using it when the USB side of things doesn't go their way. That's why I tend to coax folks into using PS/2 for key input if they have the port available to them, and have never had anyone be disappointed with the performance they experience for doing so. If nothing else, it does an excellent job for this application, and doesn't use up a USB port that could be used for something else a little less mundane.
--- End quote ---
This is a little off-topic, but it sounds like you may have some experimental data I can use (saving me the trouble of setting up one of my USB dev boards to determine it myself). If you declare your usage as a keyboard but with "variable" (non-array) format data, 1 bit each corresponding to a pre-defined keycode, does it work in Windows or any OS for that matter? Clearly, this is not boot protocol compatible, but I can see nothing in the HID standard that would prohibit it. This would let you send all 104 keycodes of a standard PC keyboard using only a 13 byte report (albeit without the ability to indicate RolloverError if ghosting occured and with a potentially quite large report descriptor).
DillonFoulds:
I think my ~9s on 100m Track and Field disproves driver-man all together, but I'm willing to try out an LPT solution to see if it actually makes any difference...
AndyWarne:
--- Quote from: Driver-Man on September 27, 2010, 08:04:09 am ---
You are not really achieving anything by sending the full information in the first 32 bytes, since you will still be sending as many of those packets as keys were pressed, just like my USB trace shows too. You are stuffing 5x32 = 160 bytes down the USB pipe just to signal 5 keys are down!?
--- End quote ---
Ok here we go again. You have missed out the captures above this which show no keys pressed, the ones which send all zeros.
So, we start with no keys pressed (all zeros). Then the next packet, 2ms later, when all keys are pressed, contains all the keys. Thats all we need to know.
But for info, now, after that another 4 packets are sent, with all the keycodes. These form no part in the process as the host already knows all 5 keys are pressed. These packets are simply repeating data already sent.
So, why are they sent? Well... the host polls the device at 2ms intervals. Usually the device will send a NAK unless it has some data to send. The trace does not show the NAKed polls as I have turned off "Disply NAKed transactions" in the view to avoid clutter.
The device has "Acked" 5 transactions and sent data. The reason I do this is just in case the host might have missed the first one. I could just send one packet every time there is a change but I send 5 (or more accurately I respond to 5 requests from the host). There is no advantage to be gained by sending only one packet so I send 5. This does not slow the process as the host gets the 5 keys in one go, on the first packet. The others are just to "make sure".
Many USB devices ACK all requests from the host and send data on all requests. I just happen to ACK 5 then stop sending unnecessarily until the next state change.
The only part you need to look at are the transaction with no keys and the one after it with 5 keys.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version