Serial Communication x 2 Under XP or Vista Using USB->Serial Adapters

In article <8f8ec9f7-9741-44cf-803f-
bd9a675caa1e@y1g2000pra.googlegroups.com>, alex.louie@email.com says...
> On Dec 10, 3:28 pm, David Brown
> <david.br...@hesbynett.removethisbit.no> wrote:
> > Jujitsu Lizard wrote:
> > > Hi,
> >
> > > I develop embedded software for a living.  We need to instrument the
> > > bidirectional serial interface between our product and a daughterboard
> > > (containing its own microprocessor) so that we can have another piece of
> > > software (which we write to run under XP or Vista) examine the serial
> > > communication and look for logical errors.
> >
> > > It would seem most convenient for us to use two of those cheap
> > > USB->Serial adapters and just wire them up so that only the receive
> > > portion is used. One of the adapters would monitor the communication
> > > from our product to the daughterboard, and the second adapter would
> > > monitor communication going in the other direction.
> >
> > > Questions:
> >
> > > a)Is there a better approach (especially recognizing that we want
> > > maximum portability and that very few laptops these days ship with one
> > > let alone two serial ports)?
> >
> > > b)Will Windows keep up with 2 streams at 19,200 baud?
> >
> > > c)Are there any web pages that you've found especially helpful?  I did
> > > find this one:
> >
> > >http://msdn.microsoft.com/en-us/library/ms810467.aspx
> >
> > > Is this the correct API to use?
> >
> > > d)Are there any books or additional resources on this topic that you'd
> > > recommend?
> >
> > > e)Our boards work at 3V, but I think serial communication is 12V by
> > > specification.  If anyone is aware of a commercial level-shifter so that
> > > we don't need to build one ...
> >
> > > Thanks sincerely for the help,
> > > The Lizard
> >
> > Try the FTDI FT2232D - it's a dual serial-to-usb converter, so you only
> > need one device.  You can buy a ready-made DLP-2232M-G module with the
> > device, USB connector, and supporting components in a DIP package.
> >
> > <http://realterm.sourceforge.net/> RealTerm is a terminal emulator which
> > supports two serial ports at once (input is shown in two different
> > colours), which is useful for this sort of thing.
> >
> > Be aware that buffering, especially with USB, will give you
> > unpredictable latencies so the timing of inputs from the two channels
> > will not be reliable (but it will probably be good enough if you are
> > using a half-duplex protocol).
> >
> > Of course, if the protocol is half-duplex, it's possible to cheat with a
> > couple of diodes and a resistor, and only one serial port.
> 
> Beware the FTDI software.  Evil.
> 
I just heard once again today, of the problems that can occur if your
USB serial port is receiving data when you plug in the USB side.  
Apparently,  it can make the serial port act like a mouse if there
is serial data arriving when the USB side is enumerating.  I
don't know if it was an FTDI-based USB-Serial converter, but I know
that happens with FTDI chips.  Apparently the  internal state machine
isn't able to enumerate and process incoming data at the same time.

Mark Borgerson

"David Brown" <david.brown@hesbynett.removethisbit.no> wrote in message 
news:i6ednXDCbf80393UnZ2dnUVZ8oKdnZ2d@lyse.net...
>
> Of course, if the protocol is half-duplex, it's possible to cheat with a 
> couple of diodes and a resistor, and only one serial port.

Nah, full duplex.

But good thought ... 

Jujitsu Lizard wrote:
> "David Brown" <david.brown@hesbynett.removethisbit.no> wrote in message 
> news:i6ednXDCbf80393UnZ2dnUVZ8oKdnZ2d@lyse.net...
>>
>> Of course, if the protocol is half-duplex, it's possible to cheat with 
>> a couple of diodes and a resistor, and only one serial port.
> 
> Nah, full duplex.
> 
> But good thought ...

By "half duplex" I mean that only one side is transmitting at any given 
time (even though there are two lines).  That's very common in 
communications protocols - one side "asks", then the other side 
"answers".  "full duplex" means that both sides can be transmitting at 
the same time.  If that's the case, then I hope that you don't need much 
information about the synchronisation between the channels, because that 
will mean a *lot* more work.

Another idea would be a little microcontroller with three UARTs - read 
the two lines in, and write out a combined signal.  Then you could do 
timing analysis (such as time stamping) or other analysis in the 
microcontroller program.

LittleAlex wrote:
<snip>
> Beware the FTDI software.  Evil.

I've heard that a number of times, but never had problems with the FTDI 
drivers myself.

Their example software, such as the Delphi wrapper for their DLLs, leave 
a lot to be desired (a single global variable for the device handle is 
not exactly good software design, especially when you want to use a 
two-channel device like the FT2232) - treat it as an example, and write 
your own.

"Jujitsu Lizard" <jujitsu.lizard@gmail.com> wrote in message 
news:erWdnXcaXdtMaKLUnZ2dnUVZ_r6dnZ2d@giganews.com...
> Hi,
>
> I develop embedded software for a living.  We need to instrument the 
> bidirectional serial interface between our product and a daughterboard 
> (containing its own microprocessor) so that we can have another piece of 
> software (which we write to run under XP or Vista) examine the serial 
> communication and look for logical errors.
>
> It would seem most convenient for us to use two of those cheap USB->Serial 
> adapters and just wire them up so that only the receive portion is used. 
> One of the adapters would monitor the communication from our product to 
> the daughterboard, and the second adapter would monitor communication 
> going in the other direction.
>
> Questions:
>
> a)Is there a better approach (especially recognizing that we want maximum 
> portability and that very few laptops these days ship with one let alone 
> two serial ports)?
>
> b)Will Windows keep up with 2 streams at 19,200 baud?
>
> c)Are there any web pages that you've found especially helpful?  I did 
> find this one:
>
> http://msdn.microsoft.com/en-us/library/ms810467.aspx
>
> Is this the correct API to use?
>
> d)Are there any books or additional resources on this topic that you'd 
> recommend?
>
> e)Our boards work at 3V, but I think serial communication is 12V by 
> specification.  If anyone is aware of a commercial level-shifter so that 
> we don't need to build one ...
>
> Thanks sincerely for the help,
> The Lizard

Try an upmarket USB interface with as many serial ports as you need.
I have used MOXA PCI and PCIe boards with good results so I suggest a MOXA 
Uport.

If you can use the plug in cards then MOXA's own library for access works 
much better than Windows comport stuff.

I'm not sure if they support the USB adapters with the same library.

Another good way to go is to use a PCMCIA card serial porta dapter - these 
are real comports in hardware.


Michael Kellett 

"Jujitsu Lizard" wrote:

>I develop embedded software for a living.  We need to instrument the 

why do you hide your identity?

[...]

>a)Is there a better approach (especially recognizing that we want maximum 
>portability and that very few laptops these days ship with one let alone two 
>serial ports)?

other poster already pointed out that you don't get precise timing
information if you use two Windows comm ports.

>b)Will Windows keep up with 2 streams at 19,200 baud?

Remember the computing power we needed to handle the speed of 56K
modems and ISDN adapters.

>c)Are there any web pages that you've found especially helpful?  I did find 
>this one:
>
>http://msdn.microsoft.com/en-us/library/ms810467.aspx
>
>Is this the correct API to use?

Yes. And there are some pitfalls to avoid, e.g. handling of
communication errors and break conditions and FIFO issues
(ReadIntervalTimeout + FIFO = Fun).

>d)Are there any books or additional resources on this topic that you'd 
>recommend?

You might have a look at http://sourceforge.net/projects/serialapi/
for an application example or easier access to the comm port.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

In comp.arch.embedded,
Mark Borgerson <mborgerson@comcast.net> wrote:
>> 
> I just heard once again today, of the problems that can occur if your
> USB serial port is receiving data when you plug in the USB side.  
> Apparently,  it can make the serial port act like a mouse if there
> is serial data arriving when the USB side is enumerating.  I
> don't know if it was an FTDI-based USB-Serial converter, but I know
> that happens with FTDI chips.  Apparently the  internal state machine
> isn't able to enumerate and process incoming data at the same time.

That may be a Windows problem and happens not only with FTDI or even
USB stuff. Windows has always had problems when serial data comes in
during boot. Last time I experienced it was a year ago with W2000 and
a serial GPS. If the GPS was on during boot (and thus spitting out NEMA
sentences), it was detected as a mouse and the cursor would move
randomly over the screen (the serial mouse driver does little data
checking aparently). Have not tested this with XP or Vista, but I doubt
there will be much change as this behaviour has not changed since W3.1
(or even earlier?).

A USB attach may trigger the same sequence of events as during boot to
try and detect what is attached and cause the same effect.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

How do you power off this machine?
	-- Linus, when upgrading linux.cs.helsinki.fi, and after using the machine for several months

On 2008-12-11, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> Mark Borgerson <mborgerson@comcast.net> wrote:
>
>> I just heard once again today, of the problems that can occur
>> if your USB serial port is receiving data when you plug in the
>> USB side.  Apparently, it can make the serial port act like a
>> mouse if there is serial data arriving when the USB side is
>> enumerating.
>
> That may be a Windows problem and happens not only with FTDI
> or even USB stuff. Windows has always had problems when serial
> data comes in during boot.

It's definitely a windows problem, and it occurs with all
serial ports.  My empolyer makes serial ports attached via
various buses (ISA, PCI, USB, Ethernet), and if there's data
coming in when Windows starts up the port, Windows decides it's
a mouse.  It's a bug in Windows, and it's always been there.

> A USB attach may trigger the same sequence of events as during boot to
> try and detect what is attached and cause the same effect.

Probably.  The Windows serial device drive framework is pretty
FUBAR (and has been for decades).

-- 
Grant Edwards                   grante             Yow! HUMAN REPLICAS are
                                  at               inserted into VATS of
                               visi.com            NUTRITIONAL YEAST ...

On Thu, 11 Dec 2008 13:37:47 +0100, Stef
<stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>That may be a Windows problem and happens not only with FTDI or even
>USB stuff. Windows has always had problems when serial data comes in
>during boot. Last time I experienced it was a year ago with W2000 and
>a serial GPS. If the GPS was on during boot (and thus spitting out NEMA
>sentences), it was detected as a mouse and the cursor would move
>randomly over the screen (the serial mouse driver does little data
>checking aparently). Have not tested this with XP or Vista, but I doubt
>there will be much change as this behaviour has not changed since W3.1
>(or even earlier?).

Still there as of XP embedded. We ended up isolating the serial data
lines until XPe told the front panel controller "Hey, I'm awake," at
which time we would allow the NMEA strings to be passed. Annoying. 

-- 
Rich Webb     Norfolk, VA

On Thu, 11 Dec 2008 11:38:21 -0500, Rich Webb <bbew.ar@mapson.nozirev.ten>
wrote:

>On Thu, 11 Dec 2008 13:37:47 +0100, Stef
><stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>>That may be a Windows problem and happens not only with FTDI or even
>>USB stuff. Windows has always had problems when serial data comes in
>>during boot. Last time I experienced it was a year ago with W2000 and
>>a serial GPS. If the GPS was on during boot (and thus spitting out NEMA
>>sentences), it was detected as a mouse and the cursor would move
>>randomly over the screen (the serial mouse driver does little data
>>checking aparently). Have not tested this with XP or Vista, but I doubt
>>there will be much change as this behaviour has not changed since W3.1
>>(or even earlier?).
>
>Still there as of XP embedded. We ended up isolating the serial data
>lines until XPe told the front panel controller "Hey, I'm awake," at
>which time we would allow the NMEA strings to be passed. Annoying. 

Don't you know the boot.ini switches /FASTDETECT and /NOSERIALMICE?

http://technet.microsoft.com/en-us/sysinternals/bb963892.aspx

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel