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

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:

formatting link

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

Reply to
Jujitsu Lizard
Loading thread data ...

A) Probably not. One improvement would be to use a dual-port serial adapter rather than two single adapters. KeySpan makes one.

B) Depends on what else it's doing. Disk I/O blocks serial activity, so your buffering requirements are "unknown".

C) That's a 13-year old app note. Good luck getting it to compile with current tools.

D) A web search? "Jan Axelson's Lakeview Research" is a good resource.

E) V.24 communication is at 12V. Serial communication is at whatever levels -you- choose.

AL

Reply to
LittleAlex

My experience with those little adapter widgets has been pretty good. I've certainly used one around here in exactly that capacity, just snooping a serial link, and it works fine. Never tried two at once though, so your milage may vary.

As regards the level shift issues, if you're really going rail to rail at 3V then if I recall correctly you're still generating (barely) recognizable RS-232 1's and 0's. Depending on how the receiver hardware in any given widget is being implemented, you could be okay as is.

If you're not feeling like taking those sorts of chances with your $7.99, then I've got a nifty little widget I'm looking at on my desk; the Silicon Labs CP2102-EP eval module. It's got their 3.3V UART ->

USB chip on there, along with an RS-232 level charge pump, but the link between them is made with 0.100" jumpers, so you can just pull the jumpers, hook your signal wires up, and go about your business.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi

Jujitsu Lizard escreveu:

Yes. That would be to use a RS-232C analyzer.

Reply to
Cesar Rabak

You should be careful with that. I had the weird problems when attempting to run two USB to serial adapters (PL2303) at the same time. For example: if there are more then three _identical_ characters in a row, then every 4th character is lost. This looks like the software or firmware bugs perhaps with RLE compression that they might be using. Yes, I tried the latest drivers.

Doing serial to USB or Ethernet yourself?

No problems with throughput up to the maximum rates. The PL2303 dongles usually work up to 230k, the FTDI ones up to 115k.

MSDN is all you need. AFAIK the standard commport API didn't change since Windows 2.x

An embedded system engineer never heard of MAX232, eh?

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

That would be an FTDI TTL-232R-3V3 or TTL-232R-3V3-WE cable. USB on one end, 3.3 V async serial on the other, 0.1" SIL or tinned wires. Carried by the usual vendors.

A roll yer own approach may be to use the FTDI interface chips to an internal USB hub to a single cable to the PC. Haven't tried this but it seems this could get you two virtual comm ports over a single USB cable.

Or, a plethora of microcontrollers have USB peripherals nowadays. The FTDI cable approach may still be simpler, though.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Surprisingly, I have an MSEE but I never design hardware. In a best case, it gives me the background to check hardware designed by others.

I joined The Dark Side (software) very early in my career.

However, I am now an expert at designing and building two different circuits.

a)The two-resistor voltage divider. (I even know the formulas by heart!) On a very good day, I can do three resistors!

b)The LED indicator (I can even select the resistor myself!). So, with 12 volts in, I can make the LED light! I also know that, unlike resistors, LEDs can only work in the circuit one way! (Naturally, the way I deal with this is to grab about 10 LEDs and start plugging them up until one works. The probability is about 2**(-10) that they all won't work. Other engineers actually figure out which is the plus thingie and which is the minus thingie--too much work for me.)

(a) and (b) are pretty much the limit of my hardware design experience for the past 15 years.

Design-checking is another matter ...

The Lizard

Reply to
Jujitsu Lizard

Two independent USB-Serial bridges will work if you can tell which one is inbound and which is outbound. The order in wich Windows detects the two bridges is random.

If the timing between the two serial streams is important I'd suggest a different approach:

Use a microcontroller with two hardware serial ports and USB (eg Atmel AT90USB1286/1287). Monitor each serial stream on the microcontroller and send the packets to the host together with a header containing the direction and a timestamp. The PC then gets both streams through a single connection and can identify the timing through the timestamps. USB is not realtime(*), but since the microcontroller provides the timestamps they are precise and reliable.

If you do it my way Windows won't see any serial stream. Full Speed USB (11 MBps) should have plenty of headroom for your data.

You really should have the Visual Studio, the MSDN Library and the DDK.

(*) There are may serial devices that will run poorly with USB-serial bridges due to timing issues. Serial ports transmit byte by byte, USB works on blocks, so the whole timing will change. I don't use USB-serial bridges at all. Cardbus or ExpressCard serial interfaces have real UARTs and behave like real serial ports. Watch out! ExpressCard has both a single PCIe lane and one USB, and some lazy bones use the USB part of ExpressCard for interfacing. So watch out that you get a card that really use the PCIe lane.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

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.

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.

Reply to
David Brown

Beware the FTDI software. Evil.

Reply to
LittleAlex

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

Reply to
Mark Borgerson

Nah, full duplex.

But good thought ...

Reply to
Jujitsu Lizard

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.

Reply to
David Brown

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.

Reply to
David Brown

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

Reply to
MK

why do you hide your identity?

[...]

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

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

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

You might have a look at

formatting link
for an application example or easier access to the comm port.

Oliver

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

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?
 Click to see the full signature
Reply to
Stef

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.

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
 Click to see the full signature
Reply to
Grant Edwards

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
Reply to
Rich Webb

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

formatting link

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.