Serial Port Pitfalls

User programs execute independently alongside the RIO device's firmware, forcing both programs to share the device's resources. Some resources such as memory and processing power share just fine, but the serial port is a resource that poses some unique challenges.

The problem is that the IDE uses the serial port to upload and debug programs. If you write your user code in such a way that it monopolizes the serial port, then the IDE will not be able to access the device.

This can be very stressful, indeed. If you cannot access the device with the IDE, then you cannot erase or replace the program in it.

Recovery

If you accidentally upload a program that monopolizes the serial port; don't panic, there is a way to recover. However, you'll note that the recovery method is non-trivial. This is one of the reasons that we recommend you develop your code on the bench, first, before deploying it to the field.

1. Disconnect power from the device.

2. With a screwdriver, remove the case from device, exposing the circuit board.

3. On one edge of the main circuit board, you will find a small push-button that will reset the device.

   If your RIO device has a radio installed, then the radio board may partially cover the reset button and make it more difficult to reach. You may need to use something that's thin and non-conductive. A toothpick or the plastic pocket-clip portion of a pen cap will work.

4. Hold the reset button down and turn the power to the device back on. If this switch is depressed at power-up, the user program will not be run.

5. Without unpowering the board again, use the IDE to erase the program.

Mouse Problems

Even if your code does not monopolize the serial port, RIO device programs can cause some very weird things to happen on your PC.

In most applications where you connect a serial device to a PC, the device acts as a slave. In such cases, a program running on the PC sends requests to the device, and the device responds. The device doesn't volunteer any data without a request.

But this not always the case with RIO devices running a user program. Imagine a scenario where your program sends status messages out the serial port and that port is connected to a PC (either directly or via a radio). Unless some program is running on the PC to access the serial port (Hyperterminal, for example), then the operating system will not know what to do with the incoming serial data.

If it was up to us, we'd prefer the operating system would simply ignore this unsolicited data, but that's not what Windows® does. For legacy reasons, Windows presumes that all unsolicited data must be coming from a mouse, and so it sends the data off to the built-in serial mouse driver.

Depending on the data in the log messages (and perhaps the version of Windows you are running), the PC could react in a wide variety of ways. I've seen unsolicited data cause the mouse zoom all over the screen and click in random places. I've even seen it cause system hangs and reboots.

I have tried uninstalling the serial mouse driver, but it does not seem to prevent this behavior. In fact, the only thing I have found to help is to minimize the amount of unsolicited data itself. Here's a few strategies you might try:

• Send small packets at high baud, and put large gaps between them.

  Serial mice send three byte packets at 1200 baud, and programmable RIO devices default to 57.6k baud. As long as your transmissions are shorter than 96 bytes and the transmissions are separated by at least a few milliseconds, then there is little chance that they will be mistaken for mouse data.

  If you use lower baud rates, then try to send even shorter packets.

• If you have to use very low baud rates (below 9600), then try to write your code so that serial data is only sent in a response to serial data received.

• If all else fails, try to minimize the amount of time that the device is connected to a PC without an application running to capture the serial data. Launch Hyperterminal or disconnect the serial cable when you are not running a program that talks to the RIO device.

Serial Port Strategies

When writing user programs that send/receive data over the serial port, you should always keep two things in mind:

1. Do not try to send or receive data immediately at the beginning of your program. Wait at least 5 seconds (5000ms) before you do any serial operations.

   This is important because after uploading your program to the device, the IDE will attempt to read and write various registers. Although your program will have been successfully written, the IDE will get confused if the program interferes with that serial traffic, and it will report an upload failure.

2. Keep serial communication to a minimum. Ideally, you would like your program to send/receive short bursts of serial data with large gaps of time in between each burst.

   The IDE will not be communicate with the RIO device while it is sending and receiving serial data, so it is important to leave large gaps of time (10 seconds or more) where there is no serial traffic. The IDE will automatically retry communication on a serial collission, and if you leave gaps that are sufficiently large, then the IDE will be able to ignore these problems – .

Modbus Remote Commands

RIO devices use the serial port to send Modbus remote requests and receive Modbus remote responses. Apply all the same precautions regarding their use as you would with the serial port.

In other words, if your program sends Modbus commands constantly, it will not be listening to Modbus requests sent to it. That includes requests to stop executing the program!