3

I am developing a program that polls a device for actvity. In the past I have always used a USB device with a pure USB device driver. The upside of this was that that device was blazingly fast. The downside was that it limited me to the DLL the manufacturer distributed with it.

For certain reasons beyond my control I have to switch to a new USB device that emulates a serial port. In this case it uses an Atmel chip for that. I have also tried an FTDI-chip based device.

I have all of this working but there's a slight drawback. Connecting and disconnecting to the serial port is much slower. There is a noticable half to full second delay which the users that know the old situation complain about.

My strategy has always been to only be connected to the device when I needed to be. But I am starting to wonder if maybe I should change strategies and stay connected all day. But that has the obvious drawback of having to keep track of whether or not the connection is still up, and reconnecting if it's not.

Am I being overly cautious by connecting on demand, or is staying connected all day the obvious solution? Perhaps there is a third option I am missing here? Thanks.

StanB123
  • 131
  • 1
  • 1
    It's unclear from your question if staying connected is a viable option, and only you can decide if the additional development time is worth it, but my choice would be to stay connected. One second is a really long time to wait every time you want some data. – Robert Harvey May 31 '16 at 19:06
  • The program performs multiple bursts of short lived activity, and is actually in idle state during most of the day. I don't have enough experience with serial communication to tell if it will remain stable if unused for most of the day. – StanB123 May 31 '16 at 19:09
  • If your program is the only one using the port, what's the down side in keeping it open other than the small development effort to make sure it stays that way? – Blrfl May 31 '16 at 19:10
  • Good point, I am the only one using it. I guess I would only have to check if it's still working when I resume activity. – StanB123 May 31 '16 at 19:12
  • You should keep it open if possible. Regular serial doesn't have out of band signaling to detect its presence, so instant startup times can be nearly impossible. Also ftdi drivers (well, the 2.0) are great. – whatsisname Jun 01 '16 at 07:04

1 Answers1

2

Keep the connection open and separate the logic of ensuring the connection is open from the actual using of the serial connection.

In C# I would provide the following methods for using the serial connection:

public T WithSerialConnection<T>(Func<MySerialConnection, T> f);

public void WithSerialConnection(Action<MySerialConnection> act);

MySerialConnection represents an open serial connection, replace it with your own class or with a stream from your language/library. f and act receive this as a parameter and are isolated from how you open and close the connection.

You can require that f and act can be called more than once with the same effect; i.e. they should be a kind of pure except for sending and receiving bytes via the serial port.
With this requirement the implementation of WithSerialConnection() can:

  1. at first, assume the serial connection is working (which is fast); and,
  2. only when catching an exception reveals that the connection is not available recover by closing and reopening the serial connection and calling f or act again.
Kasper van den Berg
  • 2,636
  • 1
  • 16
  • 32