SerialTool Software review

Main Screen. On the starting screen of SerialTool, you can see on the far left a toolbar that can be moved at will and represents the directly available functions. Here you have quick access to SerialTool's main functions, such as importing serial ports, terminal or hexadecimal mode, setting alarms, and all other functions that we will analyze later.

Session Packets List

On the left side of the main screen, there is the session dedicated to incoming and outgoing packets for active serial ports. This window can be detached from the main window and moved at will. This list contains the essential data of the packets that have passed through the serial port. I find it an absolutely distinctive feature for professional software. This is, among many others, an extremely useful function to see the history of packets and their order of sending and arrival at the assigned serial ports.

By right-clicking, SerialTool allows you to view all previous and subsequent packets in the terminal or hexadecimal terminal screen.
In this case, we can focus on a specific packet and view all the traffic received before or after. This function is very useful when faced with an anomaly and needs to isolate all serial traffic starting from a specific point.

Packet Viewer

By right-clicking on the packet list, you can access a series of packet viewing options. To explain better, by pressing “Display this packet” (or alternatively double-clicking on the packet), a screen appears that allows you to analyze the packet closely. A really cool feature of this screen is that it allows me to see the distance from the previous and next packet, copy it to the clipboard, or export it directly to a binary file. Exceptional!

Keyboard input

In the lower part, there is an edit box that allows you to type the bytes of interest directly from the keyboard in terminal mode.

Quick Buffer

The main screen starts with a terminal in the center and an edit box at the top where you can type bytes to send to the serial port, first choosing the serial port (I will explain how to set the serial port below), the sending mode, whether ASCII or HEX, whether to include the classic CR (Carriage Return) and LN (Line Feed) at the end, the possibility of adding CRC in direct or inverted format (little endian or big endian) for the available CRC types. I must admit there is a very wide selection of CRCs from 8-bit to 32-bit with various polynomials. The ones I use most are CRC-8 and CRC 16 Modbus. This depends a lot on your applications.

The SEND button allows you to send the content you have entered. This upper area above the terminal is called Quick Buffer and is very practical to use because it is always available at the top of the screen, although it can be hidden to have more available screen area.

Terminal View Settings

In the main screen, we also find the last useful line, which also allows quick access to some functions, including searching for a specific ASCII or hexadecimal buffer in the session packets, clearing the terminal content, temporarily stopping data arrival and preventing its display, recording all serial port traffic, directly controlling the serial port RTS and DTR pins, and setting data display parameters such as timestamp format, maximum number of lines, and more.

Among other functions, SerialTool also allows you to log serial port traffic to a file in binary or ASCII format. You can select which serial port to monitor and the type of traffic to monitor, whether incoming, outgoing, or both.If you need long logging sessions to monitor the behavior of the serial port, this function will be extremely interesting. SerialTool becomes a true monitor and sniffer for the serial port without the need for external devices.

I recently discovered the meaning of the chip icon on the left represented by a Chip. When the “Turbo” mode is set in the general settings of SerialTool, this icon turns red, and SerialTool takes full control of system resources, allowing even the fastest packets to be received (from my tests) at intervals shorter than 40ms.

It should be noted that once the turbo mode is activated, the PC in Windows and my MacBook activate the internal cooling fan. The official explanations say to use this function sparingly. From my tests, I found that when dealing with remote devices sending packets very close together (e.g., GPS modules), it is advisable to significantly reduce the number of lines viewable by the terminal or hexadecimal terminal so that the user interface's graphic refresh is very fast. This allows me to maintain a very precise timing in packet reception. This little trick is not explained in the official documentation but seems very useful to share with you.

From the tools bar, we can choose the terminal screen as well as the Hexadecimal screen where all the traffic is shown in hexadecimal, the raw bytes.

Here some screenshots of the Terminal View Settings

I would like to spend a word about the “Show only different packet” function available in Terminal Settings. The wording is not very clear, but it essentially allows you to print to the reference terminal only when the packet is different from the previous one.

Imagine you are dealing with a scale that sends you a packet with the weight of the object being weighed at that moment. Suppose it is a glass into which you are pouring a certain amount of water constantly, while your scale continues to send you the weight every 200ms, and you want to display only when the weight changes, and in this case, the packet is different from the previous one.

By enabling this function, SerialTool will only show packets that are different from the previous ones, so you will see very clearly how the weight changes.

Note that this only affects the display, as the packets are still present in the session packet list as explained earlier.

Hexadecimal Terminal

From the tools bar, we can choose the terminal screen as well as the Hexadecimal screen where all the traffic is shown in hexadecimal, the raw bytes.

This data display is quite convenient when dealing with serial port traffic that is predominantly hexadecimal and not ASCII.
I believe for speed reasons all serial communication is displayed on one terminal at a time, but it is also possible to view it in mirroring mode, both in terminal and hexadecimal terminal mode, by setting the “Mirror Console and HEX Grid all Serial data” function. I must admit that this description is not very clear, but essentially all data traffic is “printed” on both terminals simultaneously. This risks slowing down the display and not being exactly precise with timing, but for those who want to try it and if your applications are not “time critical,” you can safely activate this mirroring function.

Serial Ports Configuration

Here is the first difference with RealTerm and CoolTerm. SerialTool allows you to open and monitor multiple serial ports simultaneously without having to launch two instances of the software.
For this reason, you need to assign a serial to each serial port. Hmm?
Yes, this play on words can generate some confusion, but if you think about it, if we have to manage multiple serials simultaneously, we need to define which COM port (in Windows) or which device (better said, file) in MacOS and Linux must be assigned by SerialTool to its reference serial. To be clearer, in Windows, we must declare (assign) our COMx (e.g., COM4) to SerialTool's serial number 1.

If we want to use a second COM port (for example, COM5), we can assign it to serial 2, and so on. For the free version, I believe there is a limit of two serial ports. I bought the PRO version, which allows me to assign up to 4 serial ports. In my daily work, I typically have 3 in constant use. Let's see how the serial port configuration screen looks.

As you can see, we can set many parameters, including adding a manual serial port. I happened to install a virtual port in MacOS, it was not recognized during the scan by SerialTool, and I had to add it manually. I think this is one of the usual problems with Apple's libraries that complicates even simple things.

That said, you can set the serial port opening parameters (after assigning it) and proceed with the opening. One of the nice and unique things about this software is that it allows me to open the serial port with the RTS pin in the state I prefer. What do I need it for? I'll explain. Working in the embedded world and having to write bootloaders for updating the firmware of my devices, I use the RTS pin connected to my USB-Serial converter. As soon as I turn on my device, if the RTS pin (connected to an I/O) is set to “high” (5 VCC), my device automatically goes into bootloader mode.

I have encountered several difficulties in the past writing dedicated software to manage this PIN when opening the serial port. The other reference software does not set the PIN automatically when opening the serial port. An annoyance! SerialTool seems to know the problem and handle it.

Among the various options, it is also possible to set a baud rate outside the common standards. Be careful! This does not mean you will be able to communicate, for example, at 250000 baud because it depends on two other factors: the USB-Serial converter you are using and the drivers of your operating system. I can suggest using FTDI on your boards (if you decide to install a converter on each board) or using WaveShare's USB to RS232/485/TTL converter. With these two components, I was able to communicate even outside the usual 9600/19200/57600 and 115200 baud.

Some printers I played with required 250000 baud, and with these converters in Windows, I had no problems.

Compatible with RS232/422/485.

I would like to clarify a point that annoys me a lot when I see advertised among serial port software the phrase “Compatible with RS232/422/485“.

I get the impression that those who write this misleading phrase do not know what they are talking about. The serial port and its management do not have any parameters dedicated to RS232/422/485! The serial port has nothing to do with the physical transport of data, whether it is RS232, RS422, RS485 or TTL.

Let's clarify. The serial port is opened with parameters related to packet transmission/reception, not the logical levels of how the hardware sends them. To be clearer, the ASCII buffer “Hello World” is always sent in the same way regardless of the physical interface that sends it!

If you take, for example, the USB serial converter I mentioned from WaveShare, you will see that it has different outputs:

In RS232: -3 Volts / -15 Volts –> Bit =1   or   +3 Volts / +12 Volts –> Bit = 0

or

In TTL: 0 Volts –> Bit = 0   and   5 Volts –> Bit = 1

In summary, RS-232/RS-485/RS-422 do not define a communication protocol; they are simply electrical interfaces.

DO NOT be deceived when software claims to be compatible with these electrical standards because compatibility is determined by the hardware you use, not the software!!!

Serial last byte timeout… a unique feature of SerialTool and CoolTerm fefining the Inter-Byte Timeout

A unique feature that I've only found in SerialTool and CoolTerm is the ability to define the time interval between the last received byte and the next one to define a packet. This setting is referred to as the “Last byte timeout”.

Real-World Example: TeraTerm (generic terminal software) vs. Dedicated Serial Port Software

Let's consider a practical example. If you're using TeraTerm, a common terminal emulator, it doesn't matter much if the bytes arrive in the terminal emulation spaced 100 milliseconds apart. In this case, we're dealing with a terminal emulation, which, as mentioned earlier, is a visual (ASCII) interaction between the user and the remote device. The important thing is to be able to read the data. However, if you're using dedicated serial port software, you're probably dealing with “train of bytes” and the arrival interval in asynchronous mode takes on a much more important meaning! In this case, you absolutely need to distinguish when a packet starts and ends.

Some might argue that a serial packet is a kind of telegram with a defined header and footer, making it easy to determine. Well… let's say that's not always the case. It might be, but there can be some dangerous pitfalls in this reasoning.

Let's start from the beginning and imagine, as in our initial example, that our typical packet in hexadecimal starts with 0x03 and ends with 0x02 and contains 128 bytes of payload in between. Now, suppose the remote device composes this payload in parts, and these parts are assembled in a thread (in the presence of an operating system, of course) in blocks of 32 bytes. So, we have 4 blocks of 32 bytes each that are sent as they are created within the thread directly to the serial port.

In this case, it could happen that the header along with the first block is sent immediately, or rather, that the distance between the first 32 bytes is constant.

Let's assume the specific case where our application needs to have a timeout or consider the packet reception time within a certain time frame. If the period is predetermined (for example, 300ms to receive our 1 + 128 + 1 bytes at 115200 bps), there is a risk that the packet generated by our remote device will arrive in chunks and cannot be properly defined even in the presence of a well-defined header and footer.

If we imagine an even more difficult situation, our packet arrives in fits and starts, our application times out, and then the remaining part of the processed packet arrives.

As unlikely as this situation may seem, trust me, it happens. And… the less often it happens, the harder it becomes to find the bug. SerialTool, in the list of session packets (especially received ones), needs to know when the packet should be considered arrived without necessarily having to understand the protocol used and thus determine that the reception session is complete. This is where the concept of the parameter mentioned above comes into play, allowing us to define that after a certain number of milliseconds have elapsed since the last received byte, the received packet is to be considered complete.

If there are anomalies in the transmission of our remote device, we can easily find them without the need for logic state and protocol analyzers, and without having to waste hours analyzing the traffic to find when the anomaly occurs.

The Importance of the Serial port packet concept and its applications

The concept of a packet is also related to all the other functionalities that SerialTool offers, such as triggering an alarm if a packet does not start with a certain byte or if the packet contains a certain byte or sequence of bytes. SerialTool, in this case, allows for surgical operations on the data traffic and to detect anomalies where we typically need external laboratory tools, personnel trained to use them, and able to identify when the problem actually occurs.

I personally found this little detail to be very significant and very useful. Only software of a certain caliber and made by experienced hands understands the importance of this parameter. Perhaps I have gone on too long and risked creating some confusion in the minds of those who use serial port software to communicate with Arduino and receive 16 bytes per minute. If, on the other hand, you develop critical applications that involve the serial port, you know what I'm talking about. And for those who one day find themselves facing this problem, they will understand the meaning of everything I have just explained and will come back to read word for word what I have written.

Serial Port Overlapped mode or Non-Overlapped mode (Windows only)

In addition to the previously discussed session packet functionality, SerialTool for Windows offers the option to open the serial port in either overlapped or non-overlapped mode.

Non-Overlapped Mode

Blocking: The program execution waits until the entire data transfer (read or write) is complete.
Suitable for: Simple applications with minimal data transfer, where responsiveness is not a major concern.

Overlapped Mode

Non-blocking: The program continues execution while the data transfer is ongoing, allowing for other tasks to be handled simultaneously.
Suitable for: Large data transfers or applications that require responsiveness during data communication.