I’ve been working on project with heavy serial communications between a PC and NetMF device (or two NetMF devices). Whist debugging i noticed something very interesting, having both the PC and the Micro Framework app in the same solution as they use the one comms library. When one app throws an exception or hits a breakpoint, it pauses all attached processes.
You might think thi is odd or perhaps just think it’s normal - however when you have the PC sending a chunk of data every 200ms and you have a break point in your NetMF app so you can debug the serial handler this becomes very important. Because the main app is paused, you’re not getting a large amount of serial data thrown at you, read into the buffer by the netmf app, and then consequently throwing a out of memory exception (which happens if you just nibble at the buffer… because the buffer keeps filling up.)
Just another thing that makes developing embedded apps with .NET Micro Framework that talk to other devices or computers so much easier. There’s nothing like being able to hit F5 in the IDE and have your NetMF device deploy, then once it’s deployed have the PC app fire up automatically (thats another really smart feature!) This makes the development toolchain so much simpler, and with the debugging above makes it so one application doesnt get way ahead of the other and wonder what’s going on haha.