revised April 24th 2001, modification for Visual C++
revised April 29th 2001, correction of bugs that occured during reconnection
revised May 14th 2001, The sertest.cpp example contains a prototype error for Connect()
February 1st 2002, New Version (V2.0) completely updated. Handles modems directly
Revised June 22nd 2002, Tserial_event class updated to correct one bug,
wait for the thread termination before quiting or restarting. New "owner"
field added to ease interfacing with C++.
Revised May 16th 2005 I changed Tserial_event.cpp to change the DTR and
RTS configuration. This should solve a problem occuring with some devices
(hyperterminal problem). I have also added
a better demo with Borland C++ Builder.
If you experience any problem using this software, please be
sure that you have the latest version. Check our web site www.tetraedre.com
for an updated version of the software.
Otherwise report any bug to the address above or check the FAQ
Here it is. Finally, I think I've reached the final step in serial communication
programmation on Win32. This software has already been downloaded by several
thousands of programmers all around the world !
This new version (V2.1) is much more structured
when the previous one. I can handle either 1-byte exchange (like a UART)
or arrays of byte. The application is 100% event-driven on the user side
(the object itself is using one thread). And more important of all, this
new version handles also modem specific signals like CD and RI. CD allows
you to know if the modem is connected (to the other modem) or if you are
in command mode. And RI is the RING indicator.
With this version, you can make whatever you like (like for example
implementing PPP or simulating a microcontroller's UART)
I've removed the "non event-driven" version since I believe it is not so
usefull. Anyway, you can still download the V1.x package here
(serial.zip) or read its documentation
The version 2 can be downloaded here (serial2.zip).
this file includes Visual C++ and Borland C++ Builder working examples and documentation.
I hope that this version will be the ultimate library for the serial port.
I hope to receive your comments about it. Since the version 1.x was downloaded
more than 4'000 times in 8 months, I hope this one will be even better.
If you like this software, please let me know, 'cause I like to know what
people think of my work.
Please find hereafter the updated version of the documentation.
Every programmer knows that accessing the hardware ports of
a computer is getting more and more complicated. The software presented
here intends to ease the development of applications using the serial port
(COM) on computer running Windows 32-bits operating systems.
Allen Denver, from the Microsoft Windows Developer Support wrote one
of the only technical article describing in details how to use the serial
port under Win32. This article can be downloaded on Microsoft's web site.
A copy of this article can also be found here.
From that article, I've written two different software packages. You
are currently reading the documentation of version 2.x which is an "event-driven"
communication component. I define it event-driven since there is no busy
loop, no blocking waiting inside the whole software. Everything is done
on events, and can thus be very easily integrated inside a Windows application
(with user interface).
All software and documentation described here can be downloaded directly
here : serial2.zip
This software was developed with C++ Borland Builder 5 and tested also
with Visual C++ 6.
On Microsoft Windows, you can use COM1 to COM9 to access serial ports
but to access ports with numbers above 9, you need to use the following
port name : \\.\COM10.
Note that it is also possible to used \\.\COM1 to access COM1.
Compilation with Borland C++ Builder
The ZIP file contains two Borland C++ project files (bcb_demo.bpr and serialtest.bpr). Simply
open them, compile, run and enjoy !
Compilation with Microsoft Visual C+
The project was originally created to be compiled with the Borland C++
Builder development environment. In order to permit compilation with
Microsoft's Visual C++, I've modified a little the source code. A "#ifdef
__BORLANDC__" has been inserted in the header part of the serialtest.cpp
file in order to skip some Borland's specific pre-compiler commands.
IMPORTANT But more important. The event-driven application uses multithreading
in order to generate the events. So Visual C++ projects that use multithreading
must be compiled with the appropriate setting. In your project settings,
you MUST choose the multithreaded run-time library, otherwise the programme
will not compile
Before going into details, I would like to describe a little bit the concept
that I used here: In order to work with the serial port, you need to create
a Tserial_event object and configure it. In particular you must specify
a "manager". This is a callback function used by the serial object to notify
events. Seven kind of events can occur:
These events will help managing the serial port (or the modem) successfully
and efficiently. They are also usefull to manipulate input and output message
This event is generated when the serial port is opened and ready to
work. If the port is not opened successfully, the connect returns
directly with an error value
This event is generated when the serial communication is closed. This
might occur either after you called disconnect or if an error occured
This event is generated when the data you want to transmit have been
passed to the device driver (this doesn't mean that they reached the other
side of the serial cable). This event will allow you to send further outgoing
message and thus avoiding output buffer overflow. If you send only one
byte after the other, this event is similar to the UART's "TX EMPTY" IRQ.
This event is generated when data are received. You can specify how
much data you would like to receive by calling setRxSize, but this
doesn't mean that you will receive that number of data. Once again, if
you specify an RxSize of 1, then the event is similar to the UART's "RX
This event is generated when a RING occurs on your telephone line (if
you have a modem and if you specified to notify modem's events).
This event is generated when the modem is connected to the other modem
(for example after an "ATDT" command). For example, if you want to implement
PPP, this will tell you if you can send modem's command (ATZ,...) or if
you can send PPP messages.
This event is the opposite of CD_ON, it indicates when the communication
with the other modem dropped.
Simple application using the serial_event communication object
int connect (char *port_arg, int rate_arg, serial_parity parity_arg,
int ByteSize, bool modem_events)
Serial port setup and start of connection
port_arg : "COM1", "COM2", ...
rate_arg : 19200, 9600, ...
parity_arg : spNONE, spODD, spEVEN
ByteSize : size of data transmitted (7 or 8 bits)
modem_event : indicates if you want to receive CD and RING events
Returns 0 if no error occured
void setManager(type_myCallBack manager)
Specify the event manager of this communication object. This is the
address of the callback function.
void setRxSize(int size)
Specifiy the size of the data to read from the port. Note that this
might not always be the size of the data actually read. To know this value,
use the getDataInSize().
void sendData(char *buffer, int size)
Transmit the message array to the output driver. This buffer is copied
internally and should not be longer than SERIAL_MAX_TX, so the buffer may
be freed directly after the call. You should never call this function is
you have not received a SERIAL_DATA_SENT event (or if it's the first write).
int getNbrOfBytes (void)
Returns the number of bytes waiting in the input buffer. Not very usefull.
int getDataInSize (void)
Returns the number of data that have been read.
char *getDataInBuffer (void)
Returns a pointer to the buffer where the data read are stored. Since
this memory location is used by the serial object, you MUST call dataHasBeenRead()
once you finished reading the data, and you should not access the buffer
void dataHasBeenRead (void)
Calling this function will tell the serial object that you have read
the incoming data and that it can continue to read further incoming data.
If you do not call this function, the port is not read anymore.
void disconnect (void)
Disconnect the serial port.
When an event occurs, the serial object call the callback function (if
not null). This function must have the following prototype:
The object field is the address of the serial communication object
that has called the callback function.
event is the event kind that occured. It can be any of the seven
values described above. For six of them, the event is notified with no
additionnal data. The SERIAL_DATA_ARRIVAL is associated with data. These
one can be retrieved by calling getDataInSize and getDataInBuffer,
like described hereafter.
void SerialEventManager(uint32 object, uint32 event)
com = (Tserial_event *) object;
case SERIAL_CONNECTED :
printf("Connected ! \n");
case SERIAL_DISCONNECTED :
printf("Disonnected ! \n");
case SERIAL_DATA_SENT :
printf("Data sent ! \n");
case SERIAL_RING :
printf("DRING ! \n");
case SERIAL_CD_ON :
printf("Carrier Detected ! \n");
case SERIAL_CD_OFF :
printf("No more carrier ! \n");
case SERIAL_DATA_ARRIVAL :
size = com->getDataInSize();
buffer = com->getDataInBuffer();
Interfacing with C++
One of the major problem encoutered here is the fact that the SerialEventManager
function is a C function and not the method of a C++ object. Using C++ callback
is not as easy as using C callback.
In order to solve partially this problem, use the owner field of the Tserial_event
class. You can give him the address of a C++ object to be called by the callback
com->owner = (void *) object1;
Where object1 is a pointer to a Tmyobject having a method named