On Thu, 16 Jun 2005 22:55:43 -0400, "GTS" <x> wrote:
>"Michael" <Michael.RemoveThis@discussions.microsoft.com> wrote in message
>>I am having the following problem with my serial port (COM1), and it seems
>>to be windows (XP Professional) related:
>> I think Windows is controlling the DTR (pin4) and RTS (pin7) signals from
>> COM1. Instead of these pins being user controlable, windows seems to be
>> setting and holding them both active (+6V). On normal ports both signals
>> are negative (-5V). I think it is a Windows (and not hardware/bios) problem
>> because in bios mode (i.e. before windows boots up) both these pins
>> are -5V, however once windows starts up it controlls these pins makinging
>> them +6V. Curiously, when the computer wakes up from standby/hybernation
>> both pins go to -5V, however as soon as anything tries to access the port,
>> both pins return to +6V.
You might try a more lateral approach to this issue.
As has been mentioned, NT isolates software from the hardware, though
perhaps not quite as absolutely as one might like. Since DirectX was
added to NT 4, driver code can play in Ring 0, and Witty demonstrated
how malware can in fact puke over raw HD from within NT (XP), NTFS
etc. notwithstanding. In Witty's case, it may have been because it
was acting within the firewall product it had burrowed into, and thus
enjoyed that app's low-level system access.
Be all that as it may, I'd be thinking along the lines of creative
cabling (assuming your serial device is external).
It's quite common to have devices that don't assert various serial
control lines properly, and/or require behavior that isn't provided by
what they are connecting to. This is over and above the "null modem"
issue, where you cross over various lines to that two "terminals"
(i.e. computers) and talk as if there were modems between them.
It's been a while, but as I recall, there are two sets of handshaking
control lines; Data Terminal Ready and Data Set Ready, and Clear To
Send and Ready To Send. The first set usually refelct powered-on
status, whereas the second reflects the more dynamic state of being
ready to handle data or not. In addition, some devices may care about
the Ring Indicator line.
So it was common practice to wire these up in various ways, to spoof
them into various states - forcing CTS/RTS to go wherever DTS/DTR
goes, or force DTS/DTR to always be On, etc. RTFM so you don't fry
something - serial ports are about the only thing in the PC that still
uses -12V, and that's an unwelcome voltage in most places.
The other approach is to talk to the modem (if that's what it is) via
the AT command set, so you can tell it how to behave. Once again,
it's RTFM time; most Rockwell (Conexiant) chipsets use the same AT
extended command set, but with other modem chipsets (especially
USR/Texas Instruments) YMMV.
You can write your own "modem" .INF file to pass along the vocabulary
you'd like your modem (or "modem") to use, or better yet, do a Save As
of one of the existing modem .INF and hack that to taste.
Less extreme, and sometimes enough, is to add extra AT commands via
the modem's "Extra settings". There's an implicit AT, and if you want
to nuke the modem back to factory defaults before laying down the law
afresh, start with &F (or Z if you have saved settings you'd rather
fall back to instead). These reset commands tend to blow everything
away, so you can often put "spare" settings behind the Z or &F as a
way of "commenting them out", e.g. &C1&F will blow away &C1, whereas
&F&C1 will assert &C1 after blowing everything else away.
HTH
>------------------------ ---- --- -- - - - -
Forget
http://cquirke.blogspot.com and check out a
better one at
http://topicdrift.blogspot.com instead!
>------------------------ ---- --- -- - - - -
FAQ
Search
Profile
Private Messages
Log in
