Implementation of a serial communication protocol

Question

I need to implement a serial protocol to communicate with a device using .NET (C#). This implementation should be a library (.dll) to be used in different projects.

I have the datasheet that describe the protocol (baudrate, stop bits, message protocol, commands, etc.) and I know that I need to use SerialPort class from System.IO.Ports namespace.

But I have some doubts on how to struture/organize the code.

Here are some questions:

1. Should I be concern about thread management or this aspect should be managed by how is using the library?
2. Can I manage received/sent data using strings or should I use bytes?
3. Commands and fixed contents should be stored using enums, constants or something else?

Maybe those questions could be subjectives, but I would like to have some feedback from someone with more experience than me.

If someone has some examples, tips, best pratices, etc. on this subject, I will be very grateful.

• k3b: I think, the answer will depend on the problem domain you want to implement. Can you describe the problem domain?

Answer 1

Virtually all of your choices are going to be driven by the device itself and the traffic required to make use of the device. Your design will, necessarily, be driven by what the device is, how it works, how you want developers to interact with it, and how users want to use the device.

1) The question of thread management is the same everywhere--use a separate thread to keep other things from blocking if that's going to be a problem. Of course, that doesn't make the problem go away, it just changes the problem from blocking to concurrency/synchronization. But that's a different problem. All other things being equal, a separate thread for reads and writes dramatically simplifies how you decouple the IO from how you process the IO.

2) That depends entirely on what the device sends/recieves, both at the low level and at the design level.

3) Would the commands, fixed constants, or other aspects be subject to change? If the device is a work in progress, it certainly will. The most successful implimentation I've ever done was to create the IO as a read/write layer, connected to an interpreter layer that actually read the grammar from a resource, topped by an API layer for use by applications. That was for a device that was in development for a very long time and the command set changed frequently; that design made it possible to use the same code for multiple devices. Whether or not that works for you depends, again, on the device.

Answer 2

1. It depends. If the device can send messages asynchronously, you need separate threads for sending and receiving; if it only speaks when spoken to, you should use a single thread for simplicity.

2. It depends on the kind of information you need to send and receive, but typically you should use bytes to allow for non-ASCII control codes.

3. Use constants of type unsigned char.