Interesting Visual Studio feature

Archive
1

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.

2

Good to know

3

Interesting. Thank you.

This will be handy in future!

4

how do you put a pc program and netmf program together in a project? Simply putting two solutions together and VC# will do the job?

5

Yes, you will then have to set the property to start both programs (you will probably want that).

You can do it like this:

http://blogs.msdn.com/b/zainnab/archive/2010/05/10/multiple-startup-projects-vstipenv0015.aspx

Good luck :wink:

6

It is a great feature. I use it a lot for win app talking to fez app. Could be comm or ethernet, etc. You can also order which app starts first. This hints at some of the power hidden jewels in the debugger. Some other real useful stuff:

  1. conditional break point. Can use on fez side also.
if (Debugger.IsAttached && bufSize > 0)
{
    Debug.Print("Panda: Break on bufSize");
    Debugger.Break(); // now inspect threads on both sides.
}
  1. Thread window. See all threads on both sides. Double click on each to jump to current instruction on that thread. Easily see threads on both sides. Not sure why NETMF does not expose ID on Thread object. You can see ID from the threads window however. Available from Debug/Windows. Info avail after break point.
  2. For comm. Set your read/write timeout to forever or some high number of seconds. Or returning from a break your current read/write could timeout.

Goes on an on. There is a lot much power behind the covers.

7

You can also add conditional breakpoints in the IDE without code Will, just add a normal breakpoint, then right click on it and click “breakpoint condition”. You can also make breakpoints run macro’s, print messages (When Hit option) and set how many times it has to be hit before it will break (Hit Count). These are extremely helpful.

terrogen, just create a blank solution, add your projects. They dont have to be the same target, and you can add references to a netmf library from the PC.