I am using a serial port to communicate with a remote diagnostics device.
The length of the response from the remote device varies depending upon the command but is known ahead of time. So, currently I send the command and wait for the required number of response bytes to be received.
I subscribe to the ‘SerialPort.DataReceived’ event whenever I’m not actively soliciting data. The handler for this event simply dumps any ‘unsolicited’ received data to a log (unsolicited data is typically only received if the remote device restarts unexpectedly, etc).
In some cases I want to send commands at a rate of about 60Hz.
My question is whether it’s best to unsubscribe/subscribe to the ‘SerialPort.DataReceived’ event every time I call my ‘SendCommand’ method to actively solicit data, or should I leave the event subscription alone and just toggle a boolean ‘TransferInProgress’ flag that the DataReceived handler can use to ignore incoming data when I’m actively soliciting it?
Here’s the current implementation:
public virtual bool SendCommand(byte[] command, ref byte[] response) {
try {
TransferInProgress = true;
OnTransferStarted();
// temporarily unsubscribe since we're actively soliciting data
_port.DataReceived -=
new SerialDataReceivedEventHandler(SerialPort_DataReceived);
_port.DiscardInBuffer();
_port.Write(command, 0, command.Length);
OnCommandSent(command);
// read the requested number of response bytes
int responseBytesRead = 0;
while (responseBytesRead < response.Length) {
responseBytesRead +=
_port.Read(response, responseBytesRead, (response.Length - responseBytesRead));
}
OnCommandResponseReceived(response);
return true;
}
catch (Exception ex) {
OnCommandSendFailed(ex.Message);
return false;
}
finally {
_port.DataReceived +=
new SerialDataReceivedEventHandler(SerialPort_DataReceived);
OnTransferComplete();
TransferInProgress = false;
}
}
-Trevor
Have you thought about handling all of your data reception in one place? You could treat the commands you send as fire and forget, parsing the data received for the responses. If the responses do not have an identifying header and the ONLY way you know how to parse them is by knowing which command you sent and the length of the response, then you could keep track of the commands sent in a queue. The way that would work, is that in your Data Received handler you would check the queue of commands you’re waiting on a response for, and then parse the data received like you do now.
Long story short, I would recommend handling all incoming data in one place.