Sign in to follow this  
-D_a_A-

USB/Serial ports, addresses and accessing with inpout32.dll

Recommended Posts

-D_a_A-    122
I'm trying to learn a little bit about serial/com port communication using C++ and I'm using the inpout32.dll to get direct access since I'm under windows XP and I'm programming a console/dos app, (and I'm a beginner so no Win API for me yet, hence the inpout32.dll). And I'm using a Laptop without any real serial ports so I'm using a USB/serial converter, Put the problem is that the functions in inpout32.dll uses the addresse to the ports to write/read, So my question is, can I use the inpout32 approach to get direct access to the port when I'm using the USB/Serial, or is there another way or maybe a way to find out the adress to the "emulated" serial port.... Anyone???

Share this post


Link to post
Share on other sites
moosedude    145
I think maybe it would be a good chance to start learning a bit of the windows API, it really is fairly simple (easy for me too say!) for what you're attempting to do. Any console application you create should still work for win32 programming.

You can use the CreateFile/ReadFile/WriteFile to perform this without over complicating things. There are loads of tutorials that appear on google for this sort of thing and you won't get too bogged down in the API.

the addresses for the ports are usually;

com1 0x3f8
com2 0x2f8

in DOS, you would of used the outport inport functions to write/read data to these addresses in order to get the comport too dance. Which was technically asking the BIOS of the computer to perform the operation for you.

the key rule here, is that generally speaking it should be possible to talk too any device connected to the computer using the same method as reading and writing files.

Share this post


Link to post
Share on other sites
MJP    19786
Yeah you almost definitely want to use the Windows API for this, it's not terribly hard to work with for serial communications. I remember I wrote a serial port class that used the Win32 functions back before I started doing any real Windows GUI programming, and I managed just fine. You can also probably find about a hundred pre-made classes for doing this if you do a quick search on google.

Share this post


Link to post
Share on other sites
-D_a_A-    122
Quote:
Original post by kiwibonga
You can go into device manager, open the properties for the COM port, and see the info you need in the "Resources" tab.


No that doesn't work for me, since I'm using my USB/Serial converter, it shows up in the device manager as (in my case Com5) but I can't get the address to the port,

Quote:
Original post by moosedude
the addresses for the ports are usually;

com1 0x3f8
com2 0x2f8

in DOS, you would of used the outport inport functions to write/read data to these addresses in order to get the comport too dance. Which was technically asking the BIOS of the computer to perform the operation for you.


As I understod from what I have read I can't access the addresses direct when running NT-systems, I've tried some old code samples using the outport/inport but these just crashed the app, but when using the inpout32.dll I can at least write/read to/from the addresses, but I can't find the address that correspond to my "emulated serial port",


I where hoping someone know a way around this so that I wouldn't have to start with the API and GUI quite yet, since I don't understand the slightest thing about it.

Well of to google :)

Thanks guys :)

Share this post


Link to post
Share on other sites
moosedude    145
This is testing my memory a bit, but anything above com4 requires special treatment. I believe it repeats the address range of com1-com4 and you are required to do some additional programming to account for this.

but the nice thing about the windows API is that you don't need the address at all, when you call CreateFile to open the communications port, you just tell it which one you want.

I've dug out some code extracts from an old project, to open a comport;

BOOL result;

HANDLE hComm = CreateFile("COM1",GENERIC_READ | GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,NULL);
if(hComm==INVALID_HANDLE_VALUE) return;

DCB settings;

result = GetCommState(hComm,&settings);
if(!result) return;

settings.BaudRate = 9600;
settings.ByteSize = 8;
settings.Parity = 0;
settings.StopBits = 1;

result = SetCommState(hComm,&settings);
if(!result) return;

Writing to a comport;

bool comm::write(char *src,int length)
{
DWORD bytesWritten;
DWORD result;

result = WriteFile(hComm,src,(DWORD)length,&bytesWritten,NULL);
if((result)&&(bytesWritten>0)) return true;

return false;
}

and reading;

void comm::read(char *dest,int length)
{
DWORD bytesRead;
ReadFile(hComm,dest,length,&bytesRead,NULL);
}

and closing;

void comm::close()
{
if(hComm!=NULL) CloseHandle(hComm);
}


I don't want too go into too much detail and confuse things for you, but you cannot also create "events" associated with the comport, which are triggered whenever some data is received (but ignore that for now, if you read something about overlapped structures don't worry too much about it)

Share this post


Link to post
Share on other sites
MJP    19786
Quote:
Original post by moosedude
This is testing my memory a bit, but anything above com4 requires special treatment. I believe it repeats the address range of com1-com4 and you are required to do some additional programming to account for this.



No it's ports above COM9 that require you to create a special string to open. This was simply a limitation of using strings to refer to com ports, since you have more characters when you go to 2-digit numbers.

Quote:
MSDN Docs
To specify a COM port number greater than 9, use the following syntax: "\\.\COM10". This syntax works for all port numbers and hardware that allows COM port numbers to be specified.


The relevant documentation is here and here.


Also -D_a_A-:

In case my earlier post as well as moosedude's code didn't make it clear, you can use the serial-port/file-IO functionality of the Windows API separately from everything else in the API. This means you wouldn't need to worry about opening or managing a window, responding to messages, or anything like that. You can just use those 3 functions in a console app if you'd like. It may seem like stepping into the Windows API is going to bring a whole mess of things with it, but in this case I think you'd be okay. Just don't be afraid to read through the MSDN documentation for any functions you use.



Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this