One mouse click, 2 PC's
in [Design]
|
From: mpm on 14 Jun 2010 16:44 On Jun 14, 3:19 pm, "Michael A. Terrell" <mike.terr...(a)earthlink.net> wrote: > whit3rd wrote: > > > On Jun 13, 5:09 pm, kening...(a)overden.com (Ken Ingram) wrote: > > > Is there any practical way that would enable me to use a single mouse > > > click in order to start a sequence at exactly the same time on two > > > separate PC's (identical units)? > > > > I suppose this means hacking into the mouse lead itself, but how to > > > find the relevant wires? > > > 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. ;-) > > -- > Anyone wanting to run for any political office in the US should have to > have a DD214, and a honorable discharge.- Hide quoted text - > > - Show quoted text - A 9-pin or a 25-pin "D-Con"? :)
From: mpm on 14 Jun 2010 16:46 On Jun 13, 7:09 pm, kening...(a)overden.com (Ken Ingram) wrote: > Is there any practical way that would enable me to use a single mouse > click in order to start a sequence at exactly the same time on two > separate PC's (identical units)? > > I suppose this means hacking into the mouse lead itself, but how to > find the relevant wires? > > Ken Ingram 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?
From: Michael A. Terrell on 14 Jun 2010 17:41 mpm wrote: > > On Jun 14, 3:19 pm, "Michael A. Terrell" <mike.terr...(a)earthlink.net> > wrote: > > whit3rd wrote: > > > > > On Jun 13, 5:09 pm, kening...(a)overden.com (Ken Ingram) wrote: > > > > Is there any practical way that would enable me to use a single mouse > > > > click in order to start a sequence at exactly the same time on two > > > > separate PC's (identical units)? > > > > > > I suppose this means hacking into the mouse lead itself, but how to > > > > find the relevant wires? > > > > > 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. ;-) > > > > -- > > Anyone wanting to run for any political office in the US should have to > > have a DD214, and a honorable discharge.- Hide quoted text - > > > > - Show quoted text - > > A 9-pin or a 25-pin "D-Con"? :) The "It's dead, Jim! I'm a country doctor, not a rodent reviver! D-con" ;-) -- Anyone wanting to run for any political office in the US should have to have a DD214, and a honorable discharge.
From: Greg Hanson on 14 Jun 2010 18:29 On Mon, 14 Jun 2010 12:45:15 -0700 (PDT), whit3rd <whit3rd(a)gmail.com> wrote: >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. > 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
From: Joel Koltner on 14 Jun 2010 18:45
"mpm" <mpmillard(a)aol.com> wrote in message news:92354892-0f43-4c64-ade1-497be8af3410(a)r27g2000yqb.googlegroups.com... >Uh-huh..... then explain how the average microprocessor services its >interrupts when more than one interrupt are pending!! 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. >The net effect of either yields delays that are quite similar to what >you would expect from polling. 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 |