I'm noticing that bytes get randomly dropped when using interrupt-driven serial communication on .Net MF 4.2 RC5 (Netduino Go!)
Here's how the port is being initialized.
public void Initialize(string port = "COM1", int baudRate = 115200, Parity parity = Parity.None, int dataBits = 8, StopBits stopBits = StopBits.One, int bufferSize = 1024) {
Incoming = new byte[bufferSize];
Uart = new SerialPort(port, baudRate, parity, dataBits, stopBits);
Uart.Open();
Uart.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler);
IncomingIndex = 0;
}
The content of the interrupt handler is not important: it gets/stores data one byte at a time, checks that each frame is well formed, has the correct length and passes the payload for processing if everything is OK.
The structure of a frame is: <frame start byte><total frame length><payload><frame stop byte>
The frame length is generally less than 25 bytes.
Based on what I've seen, It seems that the first byte of <payload> is getting dropped every once in a while.
This occurs even when throttling the data throughput with an 'ack' / 'nack' after each frame.
The code sending the data frame is as follows (the offset is always 0).
protected byte[] FrameStart = new byte[] { 0x7e, 0x00 };
protected byte[] FrameStop = new byte[] { 0x7e };
protected byte[] Ack = new byte[] { 0xaa };
protected byte[] Nack = new byte[] { 0xff };
public void Send(byte[] data, int offset, byte count){
FrameStart[1] = (byte)(count + FrameStart.Length + FrameStop.Length);
Uart.Write(FrameStart, 0, FrameStart.Length);
Uart.Flush();
Uart.Write(data, offset, count);
Uart.Flush();
Uart.Write(FrameStop, 0, FrameStop.Length);
Uart.Flush();
}
Any insight would be appreciated.
Thanks.
-Fabien.
PS: every so often, I get kicked out of the debugger while tracing through the data receiver's code.
Firmware info:
HalSystemInfo.halVersion: 4.2.0.0
HalSystemInfo.halVendorInfo: Netduino Go (v4.2.0.0 RC5) by Secret Labs LLC
HalSystemInfo.oemCode: 34
HalSystemInfo.modelCode: 177
HalSystemInfo.skuCode: 4099
HalSystemInfo.moduleSerialNumber: 00000000000000000000000000000000
HalSystemInfo.systemSerialNumber: 0000000000000000
ClrInfo.clrVersion: 4.2.0.0
ClrInfo.clrVendorInfo: Netduino Go (v4.2.0.0 RC5) by Secret Labs LLC
ClrInfo.targetFrameworkVersion: 4.2.0.0
SolutionReleaseInfo.solutionVersion: 4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino Go (v4.2.0.0 RC5) by Secret Labs LLC
SoftwareVersion.BuildDate: Mar 22 2012
SoftwareVersion.CompilerVersion: 410894
FloatingPoint: True
SourceLevelDebugging: True
ThreadCreateEx: True
LCD.Width: 0
LCD.Height: 0
LCD.BitsPerPixel: 0
AppDomains: True
ExceptionFilters: True
IncrementalDeployment: True
SoftReboot: True
Profiling: False
ProfilingAllocations: False
ProfilingCalls: False
IsUnknown: False
I had heard this mentioned before but I had never experienced this unreliability so consistently until today.
I'll experiment with lower speeds tomorrow and will report on my finding. This is unfortunate because I need all the speed I can get for an interactive Go! demo at Seattle Maker Faire this weekend.
Thanks,
Cheers,
-Fabien.
Cheers,
-Fabien.
