Serial communication using c

To create an instance of the SerialPort class, you simply pass the SerialPort options to the constructor of the class. Once you are ready to use the Serial Port, you will need to open it:. Now, we are ready to receive the data. However, to write this data to the TextBox on a form, we need to create a delegate. NET does not allow cross-thread action, so we need to use a delegate.

The delegate is used to write to the UI thread from a non-UI thread. We can now receive data from a serial port device and display it on a form. Some devices will send data without being prompted. However, some devices need to be send certain commands, and it will reply with the data that the command calls for. The Win32 API provides more handshaking options, which aren't directly supported by this library. These types of handshaking are rarely used, so it would probably only complicate the classes.

If you do need these handshaking options, then you can use the Win32 API to do that and still use the classes provided by the library. Another problem is that you don't know when the data arrives and often you don't even know how much data will arrive. Win32 provides asynchronous function calls also known as overlapped operations to circumvent these problems. Asynchronous programming is often an excellent way to increase performance, but it certainly increases complexity as well.

This complexity is the reason that a lot of programs have bugs in their serial communication routines. Things get even more complex in GUI applications, which uses the event driven model that they're used to. This programming model is a heritage of the old bit days and it isn't even that bad. The basic rule is simple All events are send using a windows message, so you need at least one window to receive the events.

Most GUI applications are single-threaded which is often the best solution to avoid a lot of complexity and they use the following piece of code in the WinMain function to process all messages:. Because the GetMessage function blocks until there is a message in the message queue, there's no way to wake up when a serial event occurs.

Of course you can set a timer and check the ports there, but this kind of polling is bad design and certainly doesn't scale well. Unfortunately the Win32 serial communication API doesn't fit in this event driven model. It would be easier for GUI applications that the Win32 API posted a message to a window when a communication event occurred this is exactly what the bit implementation looked like.

If you implement your own message-pump, you can use the MsgWaitForMultipleObjects to wait for a windows message or a windows object to become signaled. The following piece of code demonstrates how to do this it assumes that the event handle that is being used for asynchronous events is stored in the variable hevtCommEvent :.

This code is much more complex then the simple message pump displayed above. This isn't that bad, but there is another problem with this code, which is much more serious. The message pump is normally in one of the main modules of your program.

You don't want to pollute that piece of code with serial communication from a completely different module. The handle is probably not even valid at all times, which can cause problems of its own. This solution is therefore not recommended. MFC and OWL programmers cannot implement this at all, because these frameworks already their own message pumps.

You might be able to override that message pump, but it probably requires a lot of tricky code and undocumented tricks. Using serial communications in a single-threaded event-driven program is difficult as I've just explained, but you probably found that out yourself.

How can we solve this problem for these types of applications? The answer is in the CSerialWnd class, which posts a message to a window both the message and window can be specified by the programmer whenever a serial event occurs. This makes using a serial port in GUI based applications much easier. This library cannot perform magic, so how can it send messages without blocking the message pump? The answer is pretty simple. It uses a separate thread, which waits on communication events.

If such an event occurs, it will notify the appropriate window. This is a very common approach, which is used by a lot of other serial libraries. The communication thread is entirely hidden for the programmer and doesn't need to affect your architecture in any way. The current implementation contains four different classes, which all have their own purpose. The following three classes are available. If you're not using a message pump in the thread that performs the serial communication, then you should use the CSerial or CSerialEx classes.

You can use blocking calls the easiest solution or one of the synchronization functions i. WaitForMultipleObjects to wait for communication events. This approach is also used in most Unix programs, which has a similar function as WaitForMultipleObjects called 'select'. The CSerialEx adds another thread to the serial object. This frees the main thread from blocking, when waiting for serial events. These events are received in the context of this worker thread, so the programmer needs to know the impact of multi-threading.

If all processing can be done in this thread, then this is a pretty efficient solution. You need some kind of thread synchronization, when you need to communicate with the main GUI thread i. However, if you don't communicate a lot with the main thread, then this class can be a good alternative. GUI applications, which want to use the event-driven programming model for serial communications should use CSerialWnd.

It is a little less efficient, but the performance degradation is minimal if you read the port efficiently. Because it fits perfectly in the event-driven paradigm the slight performance degradation is a minimal sacrifice. This is, of course, bad practice in in a commercial application blocking the message pump hangs the application from the user's point of view for a certain time.

As long as you know what the impact is of blocking the message pump, you can decide for yourself if it is acceptable in your case could be fine for testing. Because this wrapper is very thin you can also choose to use CSerialWnd directly. Using the serial classes can be divided into several parts. First you need to open the serial port, then you set the appropriate baudrate, databits, handshaking, etc This is pretty straightforward. The tricky part is actually transmitting and receiving the data, which will probably cause the most time to implement.

At last you need to close the serial port and as a bonus if you don't then the library will do it for you. The implementation is very straightforward and looks like this there is no error checking here for simplicity, it is there in the actual project :.

Of course you need to include the serial class' header-file. Make sure that the header-files of this library are in your compiler's include path. All classes depend on the Win32 API, so make sure that you have included them as well.

I try to make all of my programs ANSI and Unicode compatible, so that's why the tchar stuff is in there. So far about the header-files. The interesting part is inside the main routine. At the top we declare the serial variable, which represents exactly one COM port. Before you can use it, you need to open the port. Of course there should be some error handling in the code, but that's left as an exercise for the reader.

Besides specifying the COM port, you can also specify the input and output buffer sizes. If you don't specify anything, then the default OS buffer sizes are being used older versions of the library used 2KB as the default buffer size, but this has been changed. If you need larger buffers, then specify them yourself.

Setting up the serial port is also pretty straightforward. The settings from the control panel or Device Manager are being used as the port's default settings.

Call Setup if these settings do not apply for your application. If you prefer to use integers instead of the enumerated types then just cast the integer to the required type. So the following two initializations are equivalent:. In the latter case, the types are not validated. So make sure that you specify the appropriate values. Once you know which type of handshaking you need, then just call SetupHandshaking with one of the appropriate handshaking. Writing data is also very easy.

Just call the Write method and supply a string. The Write routine will detect how long the string is and send these bytes across the cable. If you have written Unicode applications like this one then you might have noticed that I didn't send a Unicode string.

I think that it's pretty useless to send Unicode strings, so you need to send them as binary or convert them back to ANSI yourself. Because we are using hardware handshaking and the operation is non-overlapped, the Write method won't return until all bytes have been sent to the receiver. If there is no other side, then you might block forever at this point. Finally, the port is closed and the program exits. This program is nice to display how easy it is to open and setup the serial communication, but it's not really useful.

The more interesting programs will be discussed later. Like in real life it's easier to tell something what to do then listening to another and take appropriate actions. The same holds for serial communication.

As we saw in the Hello world example writing to the port is just as straightforward as writing to a file. Receiving data is a little more difficult. Reading the data is not that hard, but knowing that there is data and how much makes it more difficult. You'll have to wait until data arrives and when you're waiting you cannot do something else.

That is exactly what causes problems in single-threaded applications. There are three common approaches to solve this. The first solution is easy. Just block until some data arrives on the serial port. Just call WaitEvent without specifying the overlapped structure. This function blocks until a communication event occurs or an optional time-out expires. In Windows ,. To find out the COM number corresponding to your serial port,. If you double click on COM24,you can see the details of the corresponding port.

Windows10 Accounts. Opening and Closing a Serial Port. CreateFile is a Win 32 function which is used to create or open a file, stream or an IO device like serial port. On success CreateFileA will return a handle which is then used to refer the connection in all subsequent operations. After opening a serial port using the CreateFileA function you should close it with CloseHandle function, otherwise port will become unavailable to other programs.

Now let's write a small program to open and close a serial port on Windows. To Configure the DCB structure we use two functions, GetCommState function which retrieves the current control settings of the serial port and SetCommState function which configures the serial port with the new values in DCB structure provided by us.

ReadIntervalTimeout Specifies the maximum time interval between arrival of two bytes. If the arrival time exceeds these limits the ReadFile function returns. ReadTotalTimeoutConstant is used to calculate the total time-out period for read operations.

For each read operation, this value is added to the product of the ReadTotalTimeoutMultiplier member and the requested number of bytes. ReadTotalTimeoutMultiplier is used to calculate the total time-out period for read operations.

For each read operation, this value is multiplied by the requested number of bytes to be read. After this you have to set the values using SetCommTimeouts function. Writing data to the opened serial port is accomplished by the WriteFile function.

Microcontroller Interface. The Controller waits for a character to be received and lights up the corresponding LED. The code for interfacing MSP is available in the Github repo. Add a comment. Marc Balmer Marc Balmer 1, 1 1 gold badge 11 11 silver badges 18 18 bronze badges. Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog. Podcast Making Agile work for data science. Stack Gives Back Featured on Meta.

New post summary designs on greatest hits now, everywhere else eventually.