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.
Give up too easy Wouter. There is nothing but darkness beyond Fez 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.
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.
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