On 2/7/15 7:13 AM, joerg wrote:
Thank you all. Unfortunatly I'm still not able to get TimeLab
in contact with any of my RS232 interfaces. Is there may an
option when calling limelab.exe to force the usage of a
defined port?
Inbetween I tried also a lot with system.reg. HTerm is very
tolerant to the names given to the ports, TimeLab still can't find
any port.
BTW: I use HTerm only to check if other windows programms
can use the ports. When I normaly need a terminal I use a Linux
program like Putty. I only use Wine with a window program
if there is really no Linux alternative. So my Wine and windows
knowledge is limited.
one way to tell if a port is "alive and visible" under windows is to try
and use the "mode" command at the command prompt:
C:\> mode com2:
it will fail if the port doesn't exist, or is opened by some other
process. It is NOT unusual for a port to be grabbed up by some process,
which then dies without releasing it. I have a bunch of Singleboard
PCs running Windows 7 with a Garmin 18 hanging on COM1. Every once in a
while, the python program which I use to read it dies because COM1 is in
use.
There's also the whole "microsoft serial mouse device" problem. A
typical Windows 7 install (and other versions as well) will have a MS
serial mouse device in the device manager, and when booting, the device
driver goes out and looks for the mouse on COM1 (and maybe other COM
devices) If the wrong characters come back from the device at the wrong
time (e.g. something from the GPS receiver), the mouse driver takes over
the device (and randomly moves the cursor around the screen, sometimes).
You need to explicitly disable the device (and/or remove it) in Device
Manager.
In detail to your answers:
"Magnus Danielson" <mag...@rubidium.dyndns.org>
The trick is to link /dev/ttyS0 (or whatever) so that it occurs in
~/.wine/dosdevices/com1 which seemed to help a bit.
Already did this, and tried it now also in the folder where the
timelab.exe is in case that there is a problem with the path.
No success.
"Mark Sims" <hol...@hotmail.com>
I have seen several issues with Windows programs not releasing (or perhaps
not being able to releaase) the serial ports after using them. Once one of
these programs accesses the serial port, no other programs can use it until
you re-boot. I'm fighting windoze Hypertrm right now over this issue
trying to read from a freq counter for some ADEV measurements. Once
HYPERTRM runs, no other program can access the serial port.
Good point, I tried TimeLab direclty after fresh reboots, but the
interfaces are still invisible.
"Jim Lux" <jim...@earthlink.net>
One trick with Windows is to disable and then renable the serial port,
in particular, USB ports sometimes get stuck, and this fixes them.
There's also some power management things with USB connected ports that
can get things confused. (You don't want USB selective suspend enabled)
there's a command line tools that can do this, or you can use Device
Manager.
http://support.microsoft.com/kb/311272 describes devcon, which can do
all sorts of useful stuff.
Tried the program from your link, but
wine devcon findall =ports
was not able to find a port. Are you able to run it under Wine
or only under windows?
devcon is a *windows* program, and I think (pretty sure, but I don't
have a windows box here in front of me to check) has to be run with
administrator privileges. (e.g. right click "run as adminstrator" kind
of thing).
(minor windows rant.. I'm glad MS is tightening up security, but it
makes life hard for people running on a minimal embedded system. I wish
there was an easy way to say "it's' all running as root/administrator,
stop asking for username/password".
No better on Linux, it just manifests itself as needing to have users in
the right groups, and the permissions set up properly. But on Linux,
you can cheat and just always come in as root...)
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
