I would like to ask if anybody here has the same experience with Debug.Print() as me.
Everything is quite OK when application running on Raptor(last firmware vers. 4.3.6.0 ) and using Debug.Print() is connected to Visual Studio 2012 Express. But if the VS is closed and Raptor is reset then the same application runs significantly slower. If I open and connect MFDeploy(to see Debug.Print()) then the application start to run at standard speed again. So I have such suspicion that Debug.Print() without connected “listener” causes some delays(I can imagine this behaviour as USB is not RS232 and PC is not here only as a stupid listener).
I have connected/disconnected MFDeploy and reset Raptor a lot of times and behaviour is still the same - application runs significantly slower without connection to VS or MFDeploy.
So is it necessary to remove(conditional compilation) Debug.Print() from the code for final release or it is OK to have Debug.Print() inside the code no matter if some “debug viewer”(VS or MFDeploy) is connected?
There is a bug in NETMF code so it does not remove Debug.Print() statements in Release build. You definitely [em]must [/em]remove them manually. Conditional compilation works; there’s also a nice trick with Debugger.IsAttached property (so you only print when somebody listens, be it a debug or release build).
Another option is to set the mode to debug over serial, perhaps after done debugging your app using usb. This is good anyways as you will see any messages on the serial port COM1, or simply leave it unconnected.
Is this same for the Cobra II and/or all boards … I am using a Cobra II and when I toggle a bit on the display to know its healthy, it is slower when not debugging?
Is there any limitation when COM1 is used for debugging regarding speed?
I am guessing the USB can handle the debug messages much faster than RS232, but maybe does not matter as debug messages are probably not sent directly but through some message queue + interrupt driven RS232 transmission…
I have also another question regarding debugging through VS. Can debug messages somehow prevent successful deployment from VS? Because I can see time to time that VS can not connect to the Raptor - there is deployment errors etc.
Should it be somewhere at the start of the application some Delay to enable the debugger to connect/deploy? I have seen such a note regarding this Delay in another forum thread but I do not think debugger should rely on some application Delay.
Serial debugging is slower, but I was surprised that the difference is not that big (with G120).
When your device is very busy, VS might not be able to start deployment.
A simple
while(true) {}
in the main routine can be enough to prevent connection.
I admit, added support for VS2013 was great thing. However, apart from that I only see talks about how great the future will be. I would really like to see MS fixing all those small issues that were reported on codeplex. But for some reasons I have a feeling it is not going to happen any time soon - and let’s hope I am wrong here.
A lot of issues have been updated recently on codeplex.
Also changes are submitted by the MS Team.
But a lot of People who has some insight say there will come great things to be anounced soon, but so far I have heard of no News.
I agree. The driving force behind the re-activation of NETMF is mostly because of Azure. Some of the key indicators why issues within NETMF will and have to be fixed are:
=>Azure Service Bus
=>Azure Even Hubs
=>Azure Mobile Services (Managed and node.js backend)
All of this above services have been very successful in the last few month’s (or better, this year).
Another reason is the fact, that some key persons regarding NETMF have been called back on stage by MSFT (read it here on the forums).
But what I think matters the most, is the fact that MSFT is starting to open source :NET (in general, not only NETMF) NET core has been open-sourced a few weeks ago and right after they published the code, there has been the first pull-request for a bug fix on GitHub by the community.
A complete separate and new website for NETMF has been created as well:
We can influence user Debug.Print() messages - e.g. by conditional compilation or by System.Diagnostics.Debugger.IsAttached property.
By the way does System.Diagnostics.Debugger.IsAttached wok “on-line” so it respects connecting/disconnecting MFDeploy “dynamically” or it is checked just during start up?
But my main question here is how can we influence printing of Exceptions reason which are normally appear in Debug output channel?
Is the Exception printing somehow connected with compilation type: Debug or Release? Because if it is not possible to influence this then we are facing even bigger problem because we can catch exceptions - so application behaves correctly - but the reason of exceptions are still appearing in the Output so the application will go again slower. Am I right or the behaviour of Exceptions printing is different?
@ mhstr - As I see it, exceptions, threads and GC use debug messages.
For GC the output can disabled by a static flag in the Debug class.
But for the others I see no way to do so.
And there might be even more events on which debug prints are done from inside the core/framework.
The “output” is managed by TraceListeners in .NET. You can check the documentation here:
I am not sure if this will work in NETMF, but you can try to remove all listeners and to set filters for your listeners. it’s pretty well documented on MSDN (the link above).
And if you switch to “debug” within the output window and you right click within the window, you should be able to set filters as well.
UPDATE: This will only prevent the execution of the method, not more.
I doubt that as well. I saw this TRACE conditional symbol (build tab) within the project properties, I tried to remove that but no effect.
You can attach this attribute on your Main-Method (In Program.cs) to suppress all output when running in release mode:
[Conditional(“DEBUG”)]
using System;
using System.Collections;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Presentation.Shapes;
using Microsoft.SPOT.Touch;
using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using System.Diagnostics;
namespace GadgeteerApp7
{
public partial class Program
{
[Conditional("DEBUG")]
// This method is run when the mainboard is powered up or reset.
void ProgramStarted()
{
/*******************************************************************************************
Modules added in the Program.gadgeteer designer view are used by typing
their name followed by a period, e.g. button. or camera.
Many modules generate useful events. Type +=<tab><tab> to add a handler to an event, e.g.:
button.ButtonPressed +=<tab><tab>
If you want to do something periodically, use a GT.Timer and handle its Tick event, e.g.:
GT.Timer timer = new GT.Timer(1000); // every second (1000ms)
timer.Tick +=<tab><tab>
timer.Start();
*******************************************************************************************/
// Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
Debug.Print("Program Started");
try
{
throw new Exception();
}
catch(Exception ex)
{
}
}
}
}
In the above code the exception will not be traced to the output window.
But it is important to have the “Define DEBUG constant” checkbox checked within your project properties (configuration debug, build tab). Otherwise it will turn off tracing in debug as well. (see attached image).
I am quite new in the NETMF world but I am little bit surprised that these things are not somehow solved.
I am sure the solution with switching debug to COM1 can solve these things but what we can do in case all RS232 ports are utilized by an application (almost my case) then even the application handles all exceptions properly and due to the fact that exception reasons are anyway sent to Debug channel(which can be only USB if COM1 is utilized by application as well as all other RS232 ports) the application will be very very slow without VS(MFDeploy) connected. And it will be the case at the customer side so what we can do?
