Win32 API for virtual COM port interface, anyone can help?

[elrayes]

comport api

Hi all

I want to interface a USB virtual COM port device (CDC), and I want to use Win32 API for COM port interface, but totally lost between handlers, CreateFile and plenty other API's and functions, can anyone offer help?

thanks

 

[John Miles KE5FX]

virtual com port windows api

Take a look at comblock.h in the GPIB Toolkit ( http://www.ke5fx.com/gpib/setup.exe ). When you run the setup program, the source files are installed in the same directory as the executables. comblock.h is in the gpiblib subdirectory.

This file is used to talk to Prologix GPIB-USB adapters, which use virtual COM ports. (There are also TCP/IP and FTDI-specific providers in the same .h file.)

 

[elrayes]

virtual com port api

Hi John

Thanks for your valuable information, the toolkit seems to me great, where i can find an example or API's manual for "how to use", the .h and .c files are great, good work john.

 

[John Miles KE5FX]

win32 virtual com apis

There's not really an API, per se. The major programs have their own user guides (accessible by hitting F1 or Help->User guide), and the individual functions are documented in their respective source files (to the extent they ever will be). The COMBLOCK providers are fairly self-explanatory if you surf through comblock.h; it's not a large file.

 

[arthur0]

com port interface

Hi elrayes,

Fortunately, dealing with virtual serial ports is transparent and exactly the same as dealing with regular serial ports (provided you’re not the one creating the virtual port).
Unfortunately, there’s no specific API for dealing with serial ports, so you’ll have to either treat them as files, or use a ready made ActiveX or COM object with its associated API.
If you’re a seasoned programmer and begin with a good design (as opposed to hacking code), the task of writing a “driver”/API is not difficult and the code practically writes itself (very few lines of code, really!), but otherwise writing a robust serial communication engine is not trivial.
I could briefly say that this involves the following:

1. open the COM as an overlapped file;
2. create and spawn 3 threads taking care of reading, writing and management (monitor and shut-down), respectively, together with associated synchronization events (to be used with WaitForMultipleObjects);
3. pumping messages in and out of circular (or dynamically allocated, whichever you prefer) buffers.

If what I said here sounds familiar, you’ll have no problems writing your own API quickly and I think you should attempt to do so.
Otherwise I’d suggest finding a good ActiveX.

Arthur