One mouse click, 2 PC's

I never said you could. My posts was about timing, you idiot.

When did the user say that it was a PS/2 mouse?

You could take two cheap mice apart and wire a DPST momentary switch with one Normally Open (NO) contact across each "click" switch (left or right, whatever) and then you can position each mouse cursor where it should go then hit the "double click" pushbutton.

It won't be "exactly" at the same time, but pretty close by PC standards.

You won't be able to easily accomplish anything useful fiddling with the wires leading directly to the mouse.

An alternative would be to use devices called "wedges".

Would it not be easier to simply jump online and DL the spec sheet for the interface involved? D'oh!

Communication (whether PS/2 or USB) between a mouse and a PC is two-way, so you can't just "fork" the wires.

You would need to use two mice, sharing a common switch.

Even then, you may find that the two PCs are slightly out of sync due to latency in processsing the clicks.

Interrupts aren't polled. Don't you even know the english word "interrupt"?

Or mechanical switch actuator (a pair of fingers).

Somebody finally got it right.

It would not be much, but he did not specify how much "at the same time" resolution he wanted.

I suggestion you get really good at clicking with your other hand and get another mouse and really practice on that timing!

On a 'traditional' or PS/2 mouse, it's a problem because the mice are clocked. On a USB mouse, it's a problem because the mice are polled. On a Bluetooth mouse, it's a problem because the mice are bonded to their master. On a serial port mouse, it'll work; just be sure your mouse can drive two serial receivers with a big enough signal. A Y-cable might be enough, not even any reason to open the mouse.

If you really DO want to hack into a mouse, you can bypass the left mouse switch with a relay, and wire an external button to close as many relays as you want to use (or as the available power will support). There may be latency times, though, for each mouse to debounce the input, and for the PC to recognize that there's an input event.

You need some D-Con with that many mice. ;-)

Ah.. a true Rube Goldberg / Macgyver if ever there was one.!! I love it!!!

use

antee

Uh-huh..... then explain how the average microprocessor services its interrupts when more than one interrupt are pending!!

You will find that on most devices, the interrupts are priortized (either in hardware, or in user-configurable software registers that control the interrupt hierarchy). The net effect of either yields delays that are quite similar to what you would expect from polling.

-mpm

A 9-pin or a 25-pin "D-Con"? :)

WHAT IF....

Instead of clicking two mice at exactly the same time, could you live with clicking the second mouse a known elapsed time from the first?

The "It's dead, Jim! I'm a country doctor, not a rodent reviver! D-con" ;-)

Thank you to all those who have kindly posted replies on this topic.

My reason for doing this is to synchronize two sets of stereo signals (audio) ... one set generated in software in each identical PC (Celerons). This is because I can find no affordable device that will record and playback simultaneously FOUR separate WAV or MP3 files.

If there are, somebody please let me know.

Since all generated signals are within the audio spectrum, I suspect interrupt and polling will not be significant factors.

All things considered though, the above suggestion of wiring a single SERIAL mouse to both ports seems like the most straightforward option so far. This is intended to activate the "play" button of the software audio signal generator.

Greg Hanson

He's used "non-polled" to mean "interrupt driven," e.g., that "when this here signal line is asserted, there's some hardware mechanism in place that diverts the CPU to run off and execute a certain chunk of code as immediately as possible" -- vs. "polled" which is generally understoof as a chunk of code that's being executed on a regular basis (due to a timer overflow or similar) that specifically checks an I/O line.

In general interrupt-driven approaches have lower latencies between "something happening" and the code that handles that "something" being executed. Another benefit of interrupt-driven I/O is that when no devices require attention, on CPU cycles whatsoever are spent worrying about hose devices... whereas with polled I/O you're chewing up some CPU cycles (although often a negligible percentage) verifying that, ah, OK, none of the devices need any attention.

The USB *bus* actually *is* polled, but the chipsets that interface to it generally perform that polling in hardware and then interrupt the main CPU if anything "interesting" has occurred. In a very real sense, a USB bus controller is a rudimentary I/O co-processor: It takes care of the drudge work of polling and hence provide the benefits of interrupt-driven I/O to the main CPU.

I don't think you can say that without specifying a polling rate, and certainly the distributions are different: Interrupt-driven I/O has latencies that peak at some small value and then a "long tail" that's created when interrupts are being held off for one reason or another. Polling I/O has latencies that are very close to a uniform distribution.

Personally I find polling using the main CPU distasteful once it hits more than about 10Hz.

---Joel

On Mon, 14 Jun 2010 15:45:22 -0700, "Joel Koltner" wibbled:

snipped-for-privacy@r27g2000yqb.googlegroups.com...

Not to mention that some OSes (specifically Linux, because I know it does) implement many device drivers as a bottom-half and top-half model. The top-half gets the interrupt and deals (in as short a time as possible) the absolute minimum to make the device happy (like emptying a limited capacity buffer into RAM or noting some state) then signals the bottom-half to come along and do the long slow boring processing when it can. As the bottom-half is implemented as a kernel tasklet which might conceivably require the further services of a kernel thread or possibly even a user space handler there are no guarantees that being "interrupt driven" means it is serviced to completion in a microsecond.

In other words, they *are* "hard" interrupts WHEN they do get polled, which they always eventually will, but it is a round robin polling regardless.

Bwuahahahahahahahahahaha!