R – What Could Affect Values Returned By Serialport.Read()

netserial-port

I've written a simple app in C# 2.0 using the .Net Framework 2.0 Serialport class to communicate with a controller card via COM1.

A problem occurred recently were the bytes returned by the Read method are incorrect. It returned the right amount of bytes, only the values were incorrect. A similar app written in Delphi still returned the correct values though.

I used Portmon to log the activity on the serial port of both apps, compared the two logs and there where some (apparently) minor different settings and I tried to the imitate the Delphi app as closely as possible, but to no avail.

So, what could affect the byte values returned by Read method ?

Most settings between the two apps are identical.

Here is a list of the lines which differed in the Portmon log :

Delphi App :

IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:dc
ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:0
Replace:0 XonLimit:256
XoffLimit:256 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1
RM:100 RC:1000 WM:100 WC:1000 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask:
RXCHAR RXFLAG TXEMPTY CTS DSR RLSD
BRK ERR RING RX80FULL

C# App :

IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:1a
ERR:0 BRK:0 EVT:1a XON:11 XOFF:13
IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:0
Replace:0 XonLimit:1024
XoffLimit:1024 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1
RM:-1 RC:1000 WM:0 WC:1000 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask:
RXCHAR RXFLAG CTS DSR RLSD BRK ERR
RING

UPDATE:

The correct returned bytes were : 91, 1, 1, 3, 48, 48, 50, 69, 66, 51, 70, 55, 52, 93 (14 bytes).
The last value being a simple checksum.

The incorrect values returned were : 91, 241, 254, 252, 242, 146, 42, 201, 51, 70, 55, 52, 93 (13 bytes).

As you can see the first and the last five bytes returned correspond.

The ErrorReceived event indicates that a framing error occurred, which could explain the incorrect values. But the question is why would SerialPort encounter a framing error when the Delphi app apparently does not ?

Best Answer

Well, it seems as if the problem has been resolved (at least for the time being).

Apparently a framing error caused the return of incorrect values. I wrote a VB6 app, using the MSComm control, which worked fine, and compared the log files generated by Portmon.

I picked up the following differences

VB6 App :

IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:0 XonLimit:256 XoffLimit:256

C# App :

IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:0 Replace:0 XonLimit:1024 XoffLimit:1024

Playing around with the settings I found that if I set _serialPort.DtrEnable = true the C# App generates the following log entry :

IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:0 XonLimit:1024 XoffLimit:1024

That seemed to prevent the framing error and the application seems to be working fine.

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

C# – the difference between const and readonly in C#

Apart from the apparent difference of

having to declare the value at the time of a definition for a const VS readonly values can be computed dynamically but need to be assigned before the constructor exits.. after that it is frozen.
const's are implicitly static. You use a ClassName.ConstantName notation to access them.

There is a subtle difference. Consider a class defined in AssemblyA.

public class Const_V_Readonly
{
  public const int I_CONST_VALUE = 2;
  public readonly int I_RO_VALUE;
  public Const_V_Readonly()
  {
     I_RO_VALUE = 3;
  }
}

AssemblyB references AssemblyA and uses these values in code. When this is compiled:

in the case of the const value, it is like a find-replace. The value 2 is 'baked into' the AssemblyB's IL. This means that if tomorrow I update I_CONST_VALUE to 20, AssemblyB would still have 2 till I recompile it.
in the case of the readonly value, it is like a ref to a memory location. The value is not baked into AssemblyB's IL. This means that if the memory location is updated, AssemblyB gets the new value without recompilation. So if I_RO_VALUE is updated to 30, you only need to build AssemblyA and all clients do not need to be recompiled.

So if you are confident that the value of the constant won't change, use a const.

public const int CM_IN_A_METER = 100;

But if you have a constant that may change (e.g. w.r.t. precision).. or when in doubt, use a readonly.

public readonly float PI = 3.14;

Update: Aku needs to get a mention because he pointed this out first. Also I need to plug where I learned this: Effective C# - Bill Wagner

Best Answer

Related Solutions

C# – the difference between String and string in C#

This is the style that Microsoft tends to use in their examples.

C# – the difference between const and readonly in C#

Related Topic