Take a look at:
http://www.lvr.com/usb.htm

Sorry, but this link isn't very useful. There are no C code examples either, only VB.NET and C#.NET.

ive done a lot of work with COM ports, both real and virtual. Generally, I've not had problems accessing any of the com ports that are assigned by USB-RS232 converters. Ive gone all the way up to COM16 or maybe higher.

when ive had problems, its been for one of two reasons:

(1) the default Windows COM settings is preventing the use of any com ports numbers above a certain default number, typically "COM4"... there is a way to set this higher, pretty easy once you find it. Unfortunately my home computer is running Linux so I can't recall where this setting is found.

(2) sometimes USB - RS232 converters made by lower-end manufacturers have problems. especially with handshaking. If all else fails try a different manufacturer.

First what i would do is make sure you can talk through the USB-RS232 cable manually. Use TeraTerm or PuTTy or HyperTerm or whatever terminal emulator you like. Make sure that your converter cable actually works via COM5 in the emulator as the "real" port does on COM1 separate from your program. If it does work, and your program truly is apples-for-apples, then I would work on tracing down the problem i described above in (1).

good luck

Thanks for your suggestions, jephthah!

I used the Windows HyperTerminal program to test both COM ports. The protocol I am using is really simple, I write the string "mem" to the port and receive the answer. If I connect my device to COM1, it works correctly, with COM5, no answer is recieved.

To test if COM5 can talk to itself, I shorted the TX and RX signals and there it is: the echo in the HyperTerminal program. So this is working correctly, at least it is able to understand it's own signals ;-)

The next test was to connect COM1 to COM5, so I created a small adapter cable where RX of COM1 connects to TX of COM5 and vice-versa. Using two HyperTerminal programs, I tried to type into one of them and look if the text appears in the other. But, unfortunately, this did not work.

So I guess there's a difference between the voltage levels of the two ports so maybe you're right and the USB-to-Serial bridge is not designed to meet the real RS232 standards.

Concerning the handshake signals: The two cables I am using have only 3 signal lines (RX, TX and GND I guess) populated through a headphone jack. Therefore I have always set the Handshake option to "none". I hope this is correct?

Best Regards
Chris

connecting one serial cable to the other, and running two instances of HyperTerminal on the two different ports will verify whether or not it works correctly.

but the thing to remember is both of your com ports are acting as a DTE ... in order to communicate straight through, one has to be a DTE and one a DCE. the difference between DTE (data terminal emulator) and DCE (data communication equipment) is that the TX and RX pins are swapped (pins 2 and 3, on a DB-9)

therefore you need a "null modem" cable to communicate between two com ports on two DTE machines (ie, typical PCs). In other words, cross over your pins 2 and 3 and retry :-) here's a good reference

since you're not using handshaking, your task is much easier. if you can get both of the COM ports to communicate back and forth -- in each direction -- then the problem is not your USB-Serial converter. If it's not the hardware, and you're certain your code is correct, then I would think its a Windows application setting. Perhaps your API limits the default Com Ports to COM1 - COM4 ?

if you get a chance, try using TeraTerm. it's open source freeware, and highly configurable, and IMO much better application than HyperTerminal. I think you'll like it.

they work fine

i work in a shop selling computer h/w and electronic kits/components and custmers regularly use usb/serial converter cables to program small microprocessor boards etc... so they shold work fine

i'm sure they do ... but which manufacturers are "they", that you're talking about working "fine"?

i mean, certainly *all* the various manufacturers don't work fine. because I've had *some* that don't work worth a damn, or they only work intermittently. often these are off-brand devices some people buy cheap off the internet. not to mention that even the good ones can fail.

Now, I don't know about his particular brand off the top of my head. It probably is fine.

but before I go debugging any code, i'm going to verify the hardware works first. I already learned that lesson, the hard way. Because I'm slightly dense, I learned it a few times.

do a google for maplin electronics

i think we are two trains passing each other in the night.