Serial Port Communication in WinXP (or NT/2000)
-
Hello, I've been trying to write a program in C++ (using Borland C++ 5.02 compiler, alternating with MSVC++ 6.0) that communicates with the serial port to read in data. I used the book "Serial Communications in C and C++" by Mark Goodwin as a reference, as it came with a floppy that contained source files including a class that reduced serial communications to a matter of declaring a variable and calling some member functions on it (eg. Port1.in_ready(), Port1.get(), etc). Anyway, the code compiles, but it fails in the linking stage as it says that there are external errors dealing with the class's commands -- even the example code would not work. So I did a bit of research and found out that XP does not allow users to freely access the serial COM ports (1-4), among others. One site suggested that downloading a certain driver would fix things, but I have not been able to find anything of that nature. Does anyone have any experience dealing with a problem similar to this? Is there something out there that I haven't found yet? Any help is greatly appreciated...
-
Hello, I've been trying to write a program in C++ (using Borland C++ 5.02 compiler, alternating with MSVC++ 6.0) that communicates with the serial port to read in data. I used the book "Serial Communications in C and C++" by Mark Goodwin as a reference, as it came with a floppy that contained source files including a class that reduced serial communications to a matter of declaring a variable and calling some member functions on it (eg. Port1.in_ready(), Port1.get(), etc). Anyway, the code compiles, but it fails in the linking stage as it says that there are external errors dealing with the class's commands -- even the example code would not work. So I did a bit of research and found out that XP does not allow users to freely access the serial COM ports (1-4), among others. One site suggested that downloading a certain driver would fix things, but I have not been able to find anything of that nature. Does anyone have any experience dealing with a problem similar to this? Is there something out there that I haven't found yet? Any help is greatly appreciated...
XP does not prevent access to the serial ports. But you can not use a Win98-compilant code to operate the serial ports. The access methods are different, and a code that compiles, links and runs fine on a Win98/Me-platform no longer does that under XP. Under XP, direct access (assembly-based) to the serial ports is prohibited: instead, you must utilize the Platform SDK commands to operate the ports. Luckily, Windows-family treats ports as files, so using
CreateFilewith a filename "COM1" opens the port. Here's a link to the MSDN Platform SDK site that discusses communications. The link. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
XP does not prevent access to the serial ports. But you can not use a Win98-compilant code to operate the serial ports. The access methods are different, and a code that compiles, links and runs fine on a Win98/Me-platform no longer does that under XP. Under XP, direct access (assembly-based) to the serial ports is prohibited: instead, you must utilize the Platform SDK commands to operate the ports. Luckily, Windows-family treats ports as files, so using
CreateFilewith a filename "COM1" opens the port. Here's a link to the MSDN Platform SDK site that discusses communications. The link. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.Thanks for the reply. So I have to basically rewrite a portion of my code to comply with using CreateFile and whatnot. This is where it gets confusing for me. From the link you provided: ---- /* A sample program to illustrate setting up a serial port. */ #include int main(int argc, char *argv[]) { DCB dcb; HANDLE hCom; BOOL fSuccess; char *pcCommPort = "COM2"; hCom = CreateFile( pcCommPort, GENERIC_READ | GENERIC_WRITE, 0, // must be opened with exclusive-access NULL, // no security attributes OPEN_EXISTING, // must use OPEN_EXISTING 0, // not overlapped I/O NULL // hTemplate must be NULL for comm devices ); if (hCom == INVALID_HANDLE_VALUE) { // Handle the error. printf ("CreateFile failed with error %d.\n", GetLastError()); return (1); } // Build on the current configuration, and skip setting the size // of the input and output buffers with SetupComm. fSuccess = GetCommState(hCom, &dcb); if (!fSuccess) { // Handle the error. printf ("GetCommState failed with error %d.\n", GetLastError()); return (2); } // Fill in DCB: 57,600 bps, 8 data bits, no parity, and 1 stop bit. dcb.BaudRate = CBR_57600; // set the baud rate dcb.ByteSize = 8; // data size, xmit, and rcv dcb.Parity = NOPARITY; // no parity bit dcb.StopBits = ONESTOPBIT; // one stop bit fSuccess = SetCommState(hCom, &dcb); if (!fSuccess) { // Handle the error. printf ("SetCommState failed with error %d.\n", GetLastError()); return (3); } printf ("Serial port %s successfully reconfigured.\n", pcCommPort); return (0); } ----- This sample program confuses me a great deal. Why does the main program need parameters (I was under the impression that it was called by the OS and executing began there -- thus, there are no inputs... and to further complicate things, neither of those parameters are used in the program!). Also, what are these data types that are declared - DCB, HANDLE, and BOOL (capital bool? C++ is case-sensitive, no?)? I guess I'm just overall sketchy on how to use CreateFile and those data types (HANDLE seems to be the port's data type, I guess), since I thought using a class that already did these things was the way to go and so didn't take the tim
-
Hello, I've been trying to write a program in C++ (using Borland C++ 5.02 compiler, alternating with MSVC++ 6.0) that communicates with the serial port to read in data. I used the book "Serial Communications in C and C++" by Mark Goodwin as a reference, as it came with a floppy that contained source files including a class that reduced serial communications to a matter of declaring a variable and calling some member functions on it (eg. Port1.in_ready(), Port1.get(), etc). Anyway, the code compiles, but it fails in the linking stage as it says that there are external errors dealing with the class's commands -- even the example code would not work. So I did a bit of research and found out that XP does not allow users to freely access the serial COM ports (1-4), among others. One site suggested that downloading a certain driver would fix things, but I have not been able to find anything of that nature. Does anyone have any experience dealing with a problem similar to this? Is there something out there that I haven't found yet? Any help is greatly appreciated...
-
Hello, I've been trying to write a program in C++ (using Borland C++ 5.02 compiler, alternating with MSVC++ 6.0) that communicates with the serial port to read in data. I used the book "Serial Communications in C and C++" by Mark Goodwin as a reference, as it came with a floppy that contained source files including a class that reduced serial communications to a matter of declaring a variable and calling some member functions on it (eg. Port1.in_ready(), Port1.get(), etc). Anyway, the code compiles, but it fails in the linking stage as it says that there are external errors dealing with the class's commands -- even the example code would not work. So I did a bit of research and found out that XP does not allow users to freely access the serial COM ports (1-4), among others. One site suggested that downloading a certain driver would fix things, but I have not been able to find anything of that nature. Does anyone have any experience dealing with a problem similar to this? Is there something out there that I haven't found yet? Any help is greatly appreciated...
Check out MSDN. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfiles/html/msdn\_serial.asp Kuphryn
-
Thanks for the reply. So I have to basically rewrite a portion of my code to comply with using CreateFile and whatnot. This is where it gets confusing for me. From the link you provided: ---- /* A sample program to illustrate setting up a serial port. */ #include int main(int argc, char *argv[]) { DCB dcb; HANDLE hCom; BOOL fSuccess; char *pcCommPort = "COM2"; hCom = CreateFile( pcCommPort, GENERIC_READ | GENERIC_WRITE, 0, // must be opened with exclusive-access NULL, // no security attributes OPEN_EXISTING, // must use OPEN_EXISTING 0, // not overlapped I/O NULL // hTemplate must be NULL for comm devices ); if (hCom == INVALID_HANDLE_VALUE) { // Handle the error. printf ("CreateFile failed with error %d.\n", GetLastError()); return (1); } // Build on the current configuration, and skip setting the size // of the input and output buffers with SetupComm. fSuccess = GetCommState(hCom, &dcb); if (!fSuccess) { // Handle the error. printf ("GetCommState failed with error %d.\n", GetLastError()); return (2); } // Fill in DCB: 57,600 bps, 8 data bits, no parity, and 1 stop bit. dcb.BaudRate = CBR_57600; // set the baud rate dcb.ByteSize = 8; // data size, xmit, and rcv dcb.Parity = NOPARITY; // no parity bit dcb.StopBits = ONESTOPBIT; // one stop bit fSuccess = SetCommState(hCom, &dcb); if (!fSuccess) { // Handle the error. printf ("SetCommState failed with error %d.\n", GetLastError()); return (3); } printf ("Serial port %s successfully reconfigured.\n", pcCommPort); return (0); } ----- This sample program confuses me a great deal. Why does the main program need parameters (I was under the impression that it was called by the OS and executing began there -- thus, there are no inputs... and to further complicate things, neither of those parameters are used in the program!). Also, what are these data types that are declared - DCB, HANDLE, and BOOL (capital bool? C++ is case-sensitive, no?)? I guess I'm just overall sketchy on how to use CreateFile and those data types (HANDLE seems to be the port's data type, I guess), since I thought using a class that already did these things was the way to go and so didn't take the tim
The sample program is written for a console application. Thus, the main function takes two parameters. The first one is a count of arguments, and is always equal or greater to 1. Having 1 there means that there are no actual arguments. The second is a pointer to a character string that specifies these arguments. These parameters are filled in by the OS when you execute this program. There is no need for you to use them, if you don't want to, but they offer a change for run-time control of the program. The parameter variables are not used: the program, although it offers the use of parameters, doesn't support them. They do nothing, so to speak. The data types DCB, HANDLE and BOOL are Windows Data Types. They are (mostly) defined in Windows.h, but you can find explanations from MSDN Library as well. DCB is a structure that depicts the format of a serial port. You fill this structure with relevant data (it has members for that), and send it to a serial port. Thus, the serial port gets configured to match your needs. You can set things like baud rate, parity bit, stop bit etc through this structure. HANDLE, on the other hand, represents the HAL (Hardware Abstraction Layer) -provided symbol of the data or a device requested. In english, everything in Windows is handles. You have a handle to a file, a handle to a brush or pen, a handle to a window (critical) and a handle to a program instance. You can consider it as a "tree of classes". HANDLE is the parent class, representing a handle of an object. HINSTANCE is a derived one, representing a specialized handle, a handle to a program instance. In real, none of these are actual classes. But thinking them like such makes things a bit easier to understand. Because there are no "a handle to a port", the general HANDLE is used instead. BOOL represents a boolean value in Windows: < 1 = false, > 1 = true. It exists because old Windows programming platform (3.1 or something) didn't have support for the actual C++ 'boolean' value,
bool. This variable (BOOL) is made to emulate a boolean value in Windows environment. But basically, this and the C++ boolean are one and a same thing nowadays. The variable is provided for backward-compatibility. All these questions (and many more) about Windows-programming are answered in Charles Peltzoid's excellent book 'Programming Windows'. It is _the_ bible of every Windows-developer. I suggest you to grab it from a local bookstore or a library and read it through. It will clarify many issues to you, giving exact knowle