Attempting to monitor the serial port can be a frustrating experience. Without buying
expensive shrink wrapped software, there’s really nothing available. That was my
motivation for creating an MFC program called COMMSPY. COMMSPY is a dialog based,
serial port monitor for Windows. It is a Windows GUI built around the ever
popular Visual C++ SDK sample “tty.c”, and built under Visual C++ 4.2+. It provides a
user friendly interface, with full customization of the port and display settings only
a few clicks away. COMMSPY will remember every one of the settings, including the position
of the dialog, and restore them the next time you run it.
To use COMMSPY, you’ll need a “break-out” cable. Connect two of its ends between the
two devices communicating, and the third end to either COMM1 or COMM2 of the PC on which
COMMSPY is running. Then update the communication settings, setting the port to either
COMM1 or COMM2, whichever you hooked the third end of the cable to. This is the COMMSPY
main window:
Figure 1: COMMSPY main window
It is intentionally laid out to look like an oscilloscope. The window on the left is
the serial port output, in the middle the serial port settings, on the right the display
settings, and on the bottom the command buttons. To start monitoring the serial port,
simply select “Start!”:
Figure 2: COMMSPY main window while monitoring
The serial port output window changes to full dialog mode, hiding unused
controls. To stop monitoring, select “Stop!”.
I ran into some problems while developing COMMSPY. First, I had problems
getting the thread to terminate. Since its sitting inside WaitForCommEvent(),
the only way to communicate with the thread is through a comm event. It turns
out that WaitForCommEvent() will instantly return if the comm mask is changed with
SetCommMask(). I was doing that, but it wasn’t working. Then I noticed that an
OVERLAPPED structure must be passed to WaitForCommEvent() in order for that to work
correctly. Second, the controls on the dialog were slow to repaint when monitoring
started. This was because I was originally connecting to the COM port AND starting
the thread, then rearranging controls. When the second threads starts, it and the
main thread start competing for CPU cycles, which slows down the repaint of the
controls. When I split the monitoring functionality (GCommMonitor) up (into Connect()
and Monitor()), and rearranged the controls in-between calling those two functions,
everything worked smoothly.
Below is a few diagrams which will demonstrate a few possible configurations
of the “break-out” cable. The below samples assume you have one or more PCs, and
some external device with which it is (the are) communicating:
Figure 3: PC#1 communicating to external device via COMM2, COMMSPY monitoring
COMM1
Figure 4: PC#1 communicating to external device via COMM1, COMMSPY,
on PC#2, is monitoring COMM1
These are the features I really wanted to add to this version, but never
had the time:
- Resume scrolling – as new data is monitored, the output window is automatically
scrolled. To stop scrolling, the user should be able to simply click
anywhere in the output window. To resume scrolling, they would select
the command button “Continue Scrolling” - Trigger – when a user specified stream of data comes across the port,
alert the user. - Print – print all or a selection of the output window.
- Resizable dialog – make the dialog resizable, adjusting the controls
as necessary.
Download source (includes compiled EXE) – 147 KB