Main > Main Forum
USB vs PS/2 vs COM vs LPT
JustMichael:
--- Quote from: DaOld Man on September 23, 2010, 12:35:48 am ---At the risk of getting stuck like a fly to a sticky fly strip:
If pin 2 is high and pin 3 is low, and you press two buttons at the same time, wont that connect pin 2 to pin 3, thus making a direct short on the parallel port?
Im not trying to claim to be an expert, but with the research Ive done on the parallel port, the output pins (2-9) are either high (+ 5 VDC), or low (ground).
And they are only good for a few milliamps, so it looks to me like you would short out the outputs and probably fry your board.
To quote Forrest Gump: "And thats all I got to say about that."
--- End quote ---
If the right buttons are pressed, you are correct. I even tried telling Driver-Man that earlier in this thread:
--- Quote from: JustMichael ---Judging from your schematic Pins 2, 3, and 4 will either be set low (ground) or high (power). I am guessing you will always have one pin set low and the other two set high to "rotate" the ground. Doesn't it seem bad to you to connect ground directly to power? VERY depended upon the chip(s), a grounded output can pull the high outputs down too. This will SEVERELY shorten the life of the chip(s). I wouldn't be surprised at all if on some computers it would release the magic smoke. What you need is 3 diodes. One on each of your ground lines before they are tied together. Placed properly, these diodes will prevent ground from being tied directly to power.
--- End quote ---
I even provided him with a picture of his 9x3 matrix with diodes that would avoid shorting power to ground.
For those that have have suffered through this thread this far please queue the "beating a dead horse" and the "dumber than a box of rocks" jokes...
Also does anyone know where to buy a "clue" and how much shipping would be? After all this I think someone needs one badly and it is not DaOld Man.
Driver-Man:
--- Quote from: JustMichael ---Even this little ascii art schemtic is a matrix. And yes it can have ghost presses too. I will show you how. Let's have pin 2 be ground and pin 3 be high. We will hold down both switches that are connecting pin 3 to pin 10 and 11. Ok now let's hold down the switch connecting pin 2 to pin 10. Now comes the "magic"... The red line shows the path ground will take. Please notice how it goes to both inputs even though NO switch directly connects pin 2 to pin 11.
--- End quote ---
Yes, you are right, Driver-Man realizes the truth. Very good, magic and all, I appreciate that. It's actually inverse situation and instead of ghosting it's blocking. So, when player 2 holds Button A, it will not register when player 1 hits that same Button A. -- Thank you again, and can we settle now that for only one joystick we do not need diodes?
--- Quote ---For those that have have suffered through this thread this far please queue
--- End quote ---
Do you realize MonMotha above confirmed most of what I was saying all along? Except diodes, you got that, you win, but that was beside the main point, my joystick really works, I did not lie to you, I just never got to wire both of them and realize the issue.
--- Quote from: MonMotha ---Please read the USB HID standard. It details every little part of USB HID.
--- End quote ---
Thank you.
--- Quote ---A USB HID device updates its ENTIRE STATE to the host every time it is polled; it does not attempt to send "just what changed" like a PS/2 keyboard does which makes "number of scancodes per second" an irrelevant statistic.
--- End quote ---
And what is the "host", where is the keyboard controller and keyboard buffer in your story?
Where is the keyboard interrupt and how all that plays out with USB polling rate and scan codes buffering? Also, of what use is the ability to update entire state if you can not GENERATE that information in necessary time-window...
Q.) If clock at that USB devices ticks at 120Hz, as JustMichael said, then it means it can only generate maximum of 120 bits per second, or bytes per second, or scan codes per second?
--- Quote ---For a boot protocol keyboard, the format of the update limits the device to 6 simultaneously activated inputs, but non-boot protocol devices need not have this limitation. It's actually possible to create a USB HID device that speaks a format very similar to that of a DualShock (to the extent that you could actually just dump the "data" section of a DualShock's communication into a USB packet with the appropriate headers!).
--- End quote ---
Is there default polling rate for USB joysticks, or would that all be the same as with keyboard and mouse? Does that depend on manufacturers, maybe drivers, or "windows setting"?
MonMotha:
--- Quote from: Driver-Man on September 23, 2010, 02:33:56 am ---
--- Quote ---A USB HID device updates its ENTIRE STATE to the host every time it is polled; it does not attempt to send "just what changed" like a PS/2 keyboard does which makes "number of scancodes per second" an irrelevant statistic.
--- End quote ---
And what is the "host", where is the keyboard controller and keyboard buffer in your story?
--- End quote ---
"Host" in USB terminology refers to "whatever is upstream on the cable" including all hardware and software. In other words, it's the USB root hub and host controller, and the software stack in your OS.
--- Quote ---Where is the keyboard interrupt and how all that plays out with USB polling rate and scan codes buffering? Also, of what use is the ability to update entire state if you can not GENERATE that information in necessary time-window...
Q.) If clock at that USB devices ticks at 120Hz, as JustMichael said, then it means it can only generate maximum of 120 bits per second, or bytes per second, or scan codes per second?
--- End quote ---
There is no keyboard interrupt. USB doesn't have "true" interrupts in the sense of directly allowing a connected device to assert an IRQ to the CPU. An interrupt endpoint on a USB device is polled (using reserved time on the bus) at a specific rate. This polling rate is set sufficiently high (for whatever application) that data being present on this endpoint and subsequently transferred to the host is essentially asynchronous to everything else going on hence functioning like an interrupt. On USB, the host controls everything. A device is not allowed to speak without the host giving its OK (by issuing an IN token). The interrupt endpoint poll rate ensures that these IN tokens are issued often enough that delay between them is inconsequential.
The host is also allowed to poll the HID device "whenever it darn well feels like it" over the control endpoint, but this is not done in normal operation.
Note that PCIe and newer PCI devices use a similar interrupt mechanism. Look up "message signaled interrupts" or MSI.
The USB bit clock is NOT 120Hz. IN tokens are issued to the interrupt endpoint at 120Hz (or whatever). The bit clock is 12MHz for full speed or 1.5MHz for low speed. This means that 12 million bits (1.5 megabytes) can be moved on the bus every second on a full speed bus. There's a fair bit of overhead, but that still leaves plenty of room to update HID type devices even at low speed. Most consumer mice and keyboards are low speed.
Since scancodes are one byte on USB, that means that a full speed USB device could transfer 1.5 million scancodes every second, though that's not really how it works. Every time the interrupt endpoint is polled by the host, the HID device sends its full status in the form of a "report".
For "array" format reports (used by most keyboards), there are a fixed number of "positions" in which scancodes can be placed. If there are fewer keys pressed than this number of positions, unused positions are marked unused. If more keys are pressed, a "Rollover Error" is indicated. If the interrupt endpoint is polled at 120Hz by the host, this would limit the maximum size of the array (and hence number of simultaneously pressed keys) to an unnecessarily (heck, unreasonably) large 12,500 (minus a fair bit for overhead, but you get the idea of the magnitude of the numbers) if you were willing to take up all the bandwidth on the bus.
"Variable" format reports instead use a single bit associated with a specific scancode for each possible key, button, etc. This means that there is no simultaneous key limitation for this format. This is how most arcade keyboard encoders work. In this case, one could report up to 100,000 inputs (again, minus a fair bit for overhead, but I'll ignore that here since it's still an huge number) 120 times per second. Clearly, data rate is not the limiting factor.
The USB specification is very clear on all this, though I'll admit it's not the best written standard I've read. You should read the specification before making technical arguments surrounding it. You have some major misconceptions about how USB works.
--- Quote ---Is there default polling rate for USB joysticks, or would that all be the same as with keyboard and mouse? Does that depend on manufacturers, maybe drivers, or "windows setting"?
--- End quote ---
For low speed devices, Windows uses the same polling rate for all HID devices (keyboards, mice, joysticks, gamepads, "vendor specific" devices, etc.) as far as I know, and that rate is (I think) 125Hz. For full speed devices and other OSes, the polling rate specified by the device is used. The device can pick pretty much whatever it wants, but 60-240Hz is common.
RandyT:
--- Quote from: Driver-Man on September 23, 2010, 02:33:56 am ---Yes, you are right, Driver-Man realizes the truth. Very good, magic and all, I appreciate that. It's actually inverse situation and instead of ghosting it's blocking. So, when player 2 holds Button A, it will not register when player 1 hits that same Button A. -- Thank you again, and can we settle now that for only one joystick we do not need diodes?
--- End quote ---
No, it's ghosting, otherwise known as "phantom" switch closures. "Blocking" is actually deliberately coded into firmware (or software in this case) as a preventative measure to ghosting, and since you were unaware of it's existence, you couldn't have coded for it. Nor would you need to, if the diodes are left in place, as the circuit was originally designed.
And yes, one joystick (all controls on a single "switched ground") probably does not need diodes, but that's a far cry from how you started this conversation.
Driver-Man:
--- Quote from: RandyT ---No, it's ghosting, otherwise known as "phantom" switch closures. "Blocking" is actually deliberately coded into firmware (or software in this case) as a preventative measure to ghosting,
--- End quote ---
Ok, if that's what you call it.
--- Quote ---and since you were unaware of it's existence, you couldn't have coded for it. Nor would you need to, if the diodes are left in place, as the circuit was originally designed.
And yes, one joystick (all controls on a single "switched ground") probably does not need diodes, but that's a far cry from how you started this conversation.
--- End quote ---
I did not write TGXLPT driver, that was written like 8 years ago, or more, as I said. If you look at MAME source code you should be able to find that same piece of code somewhere, in DOS MAME it was provided via Allegro library. Similarly, I only implemented (copy/paste) that same piece of code in my DOS TSR program which takes TXGLPT1 input and outputs key codes, at arbitrary frequency.
MonMotha,
We are not talking about the same thing. I am not talking about latency nor bandwidth, in fact I'm not talking about USB at all. Keyboard controller/buffer is the "host". Look, you are talking about the "middle", and I'm talking about the two ends:
- Micro controller, located on the device
- Keyboard controller (buffer), located on the computer
============================================
a.) Micro controller, located on the device
There must be some upper limit at what rate Micro controllers can *generate* bits/bytes per second. That is not USB specification, but Micro controller specification and no one came out with any sort of number for that.
b.) Keyboard controller (buffer), located on the computer
* Keyboard controller
http://en.wikipedia.org/wiki/Keyboard_controller_(computing)
- "In computing, a keyboard controller is a device which interfaces a keyboard to a computer. Its main function is to inform the computer when a key is pressed or released. When data from the keyboard arrive, the controller raises an interrupt (a keyboard interrupt) to allow the CPU to handle the input."
* Keyboard buffer
http://en.wikipedia.org/wiki/Keyboard_buffer
- "As the main computer receives each keystroke, it ordinarily appends the character which it represents to the end of the keyboard buffer."
This is not USB disk drive, here the CPU (OS) actually needs to take time off and make sure to put each code in the buffer, and then signal back to the device to send the next one... one by one? This is again not USB specification, this is dictated by mainly by the keyboard controller, and somewhat by the keyboard buffering functionality which is OS specific, or so it would seem.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version