1

i would like to implement a rather simple function, that outputs the byte array of a serial port, e.g.

byte[] o = readAllDataFromSerialPort();

Implementing the actual serial port functions is done. I use the serial port to receive some data and process the data through the event DataReceived.

sp = new SerialPort(portname, 9600, System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
sp.Handshake = Handshake.None;
sp.DataReceived += new SerialDataReceivedEventHandler(serialDataReceived);

I check the received data for an "message end"-package in order to then close the serial port, so sth. like

if (data = "UA") sp.Close()

So basically what I would like to do is wait for the closure, before giving back the data, so that on the top level view the program doesn't progress, until the data has arrived. However I cannot wrap my head around as to how I implement this "waiting" in an effective and elegant way, as I'm relying on events for my data. Any hints or clues or examples would be much appreciated.

JoeyD
  • 277
  • 3
  • 14
  • Waiting is a very bad idea, it is likely to cause deadlock. The universal advice applies, just don't bother. You are just adding failure modes to your program for no benefit at all. – Hans Passant Jul 18 '15 at 15:20

2 Answers2

1

Serial ports are not open or closed. The Open or Close functions open a handle to the serial port driver.

If no handle is open to the driver all input from the port is ignored.

The only way you can determine whether you have received all the data is to design a protocol that provides you with a guaranteed way to detect the end of a transmission.

You can do this with one of:

  • Either select a unique terminator for the end of your message,

  • Include a length towards the beginning of your message that indicates the amount of remaining data, or

  • Wait for long enough (which also depends) to be sure no more data is pending.

A further reason for the Open, Close metaphor is that a serial port is typically an exclusive resource and only a single process can gain access to the handle at a time to prevent incompatible (and possibly dangerous) access to the device at the other end of the port inadvertently. You should keep the port open throughout your program to prevent the connected device from becoming inaccessible because another program opens the device inappropriately.

The lack of hot-plugging facilities (and in fact device identification) makes serial ports much more static and keeping the device open should not be a problem.

You seem to favour the third option. Implement this by resetting a timer that is set each time data is received, and if it expires assume the transmission is complete.

Pekka
  • 3,529
  • 27
  • 45
0

As it sais on the SerialPort.Close() documentation:

The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.

There is no way to wait for it to be closed. you can call it a "bug" or a "function as designed"

It is a bad practice to Open and Close a SerialPort over and over again with the same program. You should keep the SerialPort open.

If you really want to close it and will open it later again you can add a small sleep before returning, but sleeps without meanings are bad practice.

I found this nice post https://stackoverflow.com/a/10210279/717559 with a nice quote:

This is the worst possible practice for "best practice" advice since it doesn't at all specify exactly how long you are supposed to wait.

Community
  • 1
  • 1
Danpe
  • 18,668
  • 21
  • 96
  • 131
  • Thanks for the advice, however I still would like to close the port, as I use it from different parts of the program. Any idea on how I could implement my idea? – JoeyD Jul 18 '15 at 14:51
  • 1
    I understand, still it will be better to have a SerialManager class (maybe singelton) that all the parts of your program will access the serial through this class. then you wont need to close and open it over and over again. Does this make sense ? – Danpe Jul 18 '15 at 19:02