Tom, agreed by no means a perfect solution but one that does work well
in practice if all you want is the serial communications for a moderate
number of connections (I'm currently up to COM25). If you need precision
timing then you need an alternative solution to USB.
The real underlying problem is that Microsoft assumes that any
communications device gratuitously supplying data at boot time, is a
mouse, without an easy/reliable method of disabling this behaviour.
FTDI devices with their device driver should remember the COM port they
have been assigned on an individual system even if they get plugged into
a different port/hub, and this greatly reduces reconfiguration effort if
you change any USB connections - Other manufacturer's devices have a
tendency to use a new COM port number each time they are plugged into a
different physical USB port connected to the same computer.
If you need a large number of serial connections from a single system, I
think you should look at RS232-Ethernet terminal/communications servers.
The timing problem will be even worse than a locally connected USB device.
On 27/01/2013 12:18, Tom Van Baak wrote:
Hi Stephen,
Your work-around is one often used. But it's not a clean solution. For example,
it is not possible to disable 'Serial Enumerator' until you first know the com
port number and have regained control of your bouncing-mouse-crazy machine.
This requires that you physically remove the plug in order to use the device
manager to hunt down the port in question. This cannot be done remotely. It
cannot be done without a human present to pull USB connectors in and out. It
cannot be done on a headless or embedded system. It doesn't scale well if there
are dozens of USB ports or dozens of machines. In my experience it also doesn't
work reliably over months and years worth of crashes and reboots; eventually
the system finds a way to reset the PnP configuration and then all the USB
ports need the work-around again.
What I'm searching for is a clean, robust way to solve the problem. The goal is
that an end-user can just plug in a fast talking serial timing gizmo and it
just works all the time, every time, especially the first time, without any
kind of human intervention.
/tvb
----- Original Message -----
From: "Stephen Tompsett" <[email protected]>
To: <[email protected]>
Sent: Sunday, January 27, 2013 1:13 AM
Subject: Re: [time-nuts] Serial port / Mouse issue (was mentioned in"Thunderbolt
Monitor")
A method that does work (for me) on Windows XP and Windows 7 to tame the
wild mouse.
1. Use a FTDI USB to serial port converter
2. Disable 'Serial Enumerator' in the advanced device settings properties.
I've used both single port adapters based on FT232 chips and 4 port
FT4232 devices.
N.B. This option does not appear to be available for standard COM ports,
or USB to Serial devices from other manufacturers.
On 27/01/2013 06:42, David J Taylor wrote:
-----Original Message----- From: Sarah White
[]
Whatever works for you though I guess. I was just explaining the
officially supported method *shrugs*
=================================================
It seems from Tom's comments that the various fixes don't work for
everyone. I count myself lucky that I've not needed any fixes for
either my Win-7/64 and my Win-8/64 PCs. Win-7/64 is from a Sure
Electronics evaluation board running at the default 9600 baud with
several sentences, and Win-8/64 from a Garmin GPS 18x LVC at 38400
baud, emitting just $GPRMC if I recall correctly.
I wasn't originally aware of the more recent Microsoft article, not
having needed it myself, so thanks for the pointer.
I hope the information we both presented will be helpful to someone.
Cheers,
David
--
Stephen Tompsett
--
Stephen Tompsett
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
