6 replies to this topic

[Chris Walker]

Version: 4.1.0 Update 6 RC 1 (version 4.1.0.6 RC1) [replaced by 4.1.0.6 RC2]

[bill.french]

can you expand on this a bit: 6. Bugfixes: SerialPort.Read() timeout now implemented properly

[Chris Walker]

Hi Bill,

can you expand on this a bit:
6. Bugfixes: SerialPort.Read() timeout now implemented properly

In .NET MF, the SerialPort.Read() function had two bugs which made it inconsistent with the desktop version:
1. If the user passed in an "infinite timeout", the Read() function was not returning until the full number of bytes was available. Instead, the SerialPort.Read() function should return "up to count bytes" as soon soon as there is at least one byte available. This was causing major performance issues as users were needing to read one byte at a time or use DataReceived as a workaround.
2. When a timeout occured, it was not throwing a TimeoutException. This meant that you couldn't tell the difference between "end of file" and "timeout". This has been fixed (note: although there is a Timeout exception in the .NET MF core, there is no System.TimeoutException class...so you'll get System.Exception with a sub-designation of timeout instead; that will automatically be addressed if/when a System.TimeoutException class is added to .NET MF 4.2+).

We took care to make sure that almost all existing code should continue to work properly (or degrade fairly gracefully).

Chris

[Philip]

1. If the user passed in an "infinite timeout", the Read() function was not returning until the full number of bytes was available. Instead, the SerialPort.Read() function should return "up to count bytes" as soon soon as there is at least one byte available. This was causing major performance issues as users were needing to read one byte at a time or use DataReceived as a workaround.

Chris

Hi Chris,

Your last post has confused me. Its not strictly a Netduino issue, since it relates to the Serial Port timeout feature in general (and how it 'ought' to work). I'm using firmware 4.1.0 (update 6) RC 1. I'm trying to respond to the arrival of 2 bytes from the serial port (called 'sp'). I use:

int count = sp.Read(bytebuf, 0, 2);

in my data received event handler, thinking that if I set an infinite timeout (value -1 ?) it will just wait until it gets 2 bytes, and then put them in 'bytebuf'. At the moment I'm sending these 2 bytes from a 'terminal' program. I am not using a special 'end of message' byte, since I know how many bytes to expect.

Sometimes it works, reading both bytes and putting them both in bytebuf, and sometimes it takes just one byte and returns (and then gets the other one). When it gets one byte it reports sp.BytesToRead = 0 (just before actually calling Read()), whilst returning a 'count' value (from the sp.Read call) of 1. When it gets the second byte both these values are set to 1.

Your post (above) confused me even further. If I ask for 2 bytes, you say that it might return with just one (which agrees with your 'up to 2 bytes'). My question (eventually) is this. Surely any transfer will start with one byte - once this has happened, the call to read could return with that byte (as it seems to do). What is the purpose of the byte count parameter in the Read() call? Will it just keep reading the port and returning with unknown numbers of bytes until the total is reached (or the timeout expires)?

I may have just answered my question, but can I just check my understanding?

Thanks,

Phil

[Chris Walker]

Hi Phil, Great question. In .NET, the .Read(...) functions return _up to count_ bytes. Somtimes you'll get just one byte on the first read, but then bigger chunks on subsequent reads. It depends on how fast the queued DataReceived event handler is called and the data is read. SerialPort.BytesToRead should always give you the number of bytes _currently in the read buffer_. The index/count parameters of the read call allows you to fill just part of your buffer with data. So if you had a buffer which you wanted to fill with 512 bytes, you could read data in and then increment the index (and decrease the count) values appropriately until the buffer was filled or you had enough data to process. Does that help answer your question? Chris

[Philip]

Hi Phil,

In .NET, the .Read(...) functions return _up to count_ bytes. Somtimes you'll get just one byte on the first read, but then bigger chunks on subsequent reads. It depends on how fast the queued DataReceived event handler is called and the data is read.

Chris

Thanks Chris,

I've now implemented the code to get the rest of the expected content, and it works reliably, with varying numbers of bytes returned at a given time. At first I just couldn't get my head around the fact the the Read() function was maintaining 'state' about how many characters were left to read, especially since it was sometimes being called multiple times (via the DataReceived event).

This has been very instructive, and has changed my understanding about how the serial port works.

On a slightly different subject, is there ever going to be a book or web site containing all this accumulated wisdom - I can always (eventually) find a solution to things, but I still have no 'first' port of call for questions (except this forum).


Phil

[Chris Walker]

On a slightly different subject, is there ever going to be a book or web site containing all this accumulated wisdom - I can always (eventually) find a solution to things, but I still have no 'first' port of call for questions (except this forum).

Phil,

Glad that everything is working out with serial ports for you now. Awesome.

We'll have a Wiki soon. Plus there's some additional tutorials and such in the works...

Chris