tags:

views:

519

answers:

3

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

A: 

My opinion if I'm understanding correctly would be to simply handle all your receiving data in the DataReceived handler or you have one other options.

If the data received between actual request isn't much you could just read the buffer and log it before transmitting your request. The serial driver receive buffer may be enough to store a small amount of data. Then send the request and read in just the response. This will probable be the easier method and simpler code.

Bobby Cannon
A: 

I normally toggle a boolean. With subscribing/unsubscribing you run the risk of subscribing to the same event more than once. For instance in your code if OnTransferStarted() throws an exception you will subscribe twice to the DataReceived event.

Peter van der Heijden
A: 

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.

nathan
I like the idea of using a queue to track commands but I'm wondering how I'd be able to detect unsolicited data? How would I be able to determine if the remote device fires out a few bytes in between commands using this method? (note: the remote device occasionally seems to reset itself and sends out a few 'startup' type bytes. I don't have control over this, unfortunately).
You'd still detect the unsolicited data in your Data Received handler, but you would know it's unsolicited because you have no commands in your "SentCommandsQueue". I've had similar problems in serial communications, you'll have to buffer your received data and piece together the answers parsing out the reset messages. Once you have a complete response, remove the command from your queue. Since the reset bytes seem to have some sort of signature for the beginning of the sequence, you should be able to parse them out easily.
nathan
I think I can probably implement something like this. My only reservation is that the reset bytes aren't always the same (in order or quantity), so it might be possible to end up with an unintended offset if the reset data is received in between normal commands.That said, I believe this particular serial device has an option to enable command echoing. I can use the command echo as the identifying header during parsing of the response array.