SerialPort ReadTimeout

I’m run into a problem when I try to modify the ReadTimeout while the serialport is open.

This is the error I get:


    #### Exception System.InvalidOperationException - 0x00000000 (1) ####
    #### Message: 
    #### System.IO.Ports.SerialPort::set_ReadTimeout [IP: 0009] ####
    #### Domotech.Remote.Config.Helper::ClearBuffer [IP: 0018] ####
    #### Domotech.Remote.Config.Download::DownloadNumbers [IP: 000e] ####
    #### Domotech.Remote.Config.Download::Run [IP: 001d] ####
    #### Domotech.Remote.Config.Helper::Download [IP: 0011] ####
    #### Domotech.Remote.Client::Start [IP: 0022] ####
    #### HomeControl.Program::Main [IP: 0018] ####
A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll

And this is the code I try to execute:


public void ClearBuffer()
{
    byte[] dummy = new byte[10];
    int timeout = serialPort.ReadTimeout;

    serialPort.ReadTimeout = 100;    // <-- PLACE WHERE ERROR OCCURS

    try
    {
        while (serialPort.Read(dummy, 0, 10) > 0) ;
    }
    finally
    {
        serialPort.ReadTimeout = timeout;
    }
}

Does anyone know how to solve this issue?

yes, only adjust the timeout before the port is open. That’s the only way you can do it. That may mean closing it and reopening it.

That’s what I call a real bad driver design…

There are many situations where the readtimeout should be adjusted while the serial port is open. My code for clearing the input is one of them.

I hope this issue will be solved in a next release of the NETMF. (Together with the new CAN driver of course)

Else I start thinking of selling my FEZ Cobra since I have the feeling I always need to use work-arounds in my code…

Note that this COM issue is in the core of NETMF, not a GHI implementation. You can add this to the issue list here http://netmf.codeplex.com/workitem/list/basic

We can push for this change on our end but the more interest there is for a feature/fix the faster it will make it to the release.

As for CAN, this is what we are actively working on now.

The micro framework is ALL about reduced size, and that means reduced capability. Sometimes that will mean compromises in your code or re-inventing code that the larger frameworks support. Other times it will mean implementing workarounds.

What is the problem space here? Why do you want to clear anything within a 100 ms time? There is probably more robust ways to skin this issue without resorting to timeouts - which seems rather odd.

Well, I’m communicating with a device that sends out complete tables of information at once. After each tablerow it sends a sync char.

Now, when the Fez did not receive the sync correctly, it must request the table again. But first, before requesting again, we must wait until the device stops sending.

When requesting a table, it can take a Few seconds before the device starts sending. So I can’t set the timeout to 100 from the start.

Typically, you would read whole messages always. If your message is fixed size, then read fixed size messages always. Verify, and do your thing. If message is variable, it should be pre-pended with Len bytes. Then read that many bytes, verify, and do your thing. The sync char would then just become an expected trailer (or an expected header before the Len bytes). Either way, you are always reading a message.

That is the ideal situation. But that’s not how the FEZ works ::slight_smile:

I get lost bytes almost everytime (and I use RTS/CTS handshaking). So sending len bytes will not solve this problem.

You talk about messages, I talk about tables of 1000 of bytes. That’s a whole time difference when sending :slight_smile:

Anyway, if someone is interested in a FEZ Cobra, you can contact me.

Give up too easy Wouter. There is nothing but darkness beyond Fez :slight_smile: Any platform will have its own issues beyond this simple bump in the road. 1000 bytes is nothing. I can send megabytes of mp3 via serial without any errors at 115K all day. There is something wrong with your code on 1 side or the other. What parms (baud, stopbits, parity, etc) are you using on both sides. It helps if you can reduce the problem and code to the smallest test possible.

Ok maybe I give up easy, but I already had too many issues with the FEZ.

I come from the ACME FOX board, but applied 12V instead of 5V one day (I didn’t sleep well the night before I guess). I thought the FEZ Cobra was a step forward because it worked with Visual Studio. Bad thinking…

Now I hate it being caught inside this managed environment. For a microcontroller running at 72MHz, the FEZ is just slow as hell.

In my project the FEZ must replace a Motorola 68HC16 running at 16Mhz and programmed in C, and the FEZ just can’t follow. I think that’s sad. To me the FEZ is just a nice toy but nothing I can use in a real situation.

Anyway, thanks for your help.

Ok. I would be interested in your cobra. william at hixbirmingham com

But your not programming an 'hc16 with C, why would you expect do do everything just the way you have done it before? Even moving between processors using the same language and be cause to rethink your approach to a problem. For example how I would approach a problem when I have to bit-bang a UART is completely different than if I were using a processor with a built in UART. I would not expect to take my bit-banging code methods and apply them to a hardware UART and even get as good as performance as I did with just bit-banging. If I learn to use a HW UART and write code that is tailored for it I will get much better performance.

Another good example, I used to write a lot of assembly code for the 68HC11 and was quite good at doing calculations that took advantage of the double wide accumulator. Since it was a weird 8/16 bit processor there things you could do with very low level code that you just could not do with other micro-controllers.

When working with a NETMF device you have a very interesting mix of low level control and higher level language constructs. You have threading, lots of HW resources, etc, and you have to learn to program in that environment.

My advice is quit trying to solve the problem the same way you are used to. Look at the tools that are available and make the most of them.

@ Jeff_Birt
+1. Well said.

Going from assembly/C to high level modern programing language like C#, you have to give yourself sometime to adjust to “think” in high level. Everything will be easier very soon. There is a learning curve to everything but to NETMF it is very small and to FEZ it is few days of work…while thinking “FEZ”…freakin easy!

…but then if someone is programming in assembly/C in very low level and all you need is UART then maybe NETMF is not the right choice. Now, add threading, file system and anytime that is more than one-file-driver and you will see how NETMF can do an amazing job