Public Sub ProgramStarted()
Debug.EnableGCMessages(False)
Dim t As New Thread(AddressOf Thread1)
t.Start()
Debug.Print("Program Started")
End Sub
Dim i, i2 As Integer
Sub Thread1()
Dim led As Boolean
While True
led = Not led
Mainboard.SetDebugLED(led)
Thread.Sleep(100)
Try
i \= i2
Catch ex As Exception
End Try
End While
End Sub
This message will cause a considerable lag:
[quote]A first chance exception of type ‘System.Exception’ occurred in GadgeteerApp1.exe
@ iamin - I’ve tried it (in C# and pure NETMF, sorry)
I have this behaviour :
debugger attached : slow blinking
debugger not attached : fast blinking
debugger detached : thread aborted
I would be enclined to think that the slow blinking is somehow expected, as the debug information (exception + data) has to be transfered to VS.
So, to me, this is normal behaviour.
But I think that the debug.print slowdown is not related to this. Unless I completely misunderstood what you wanted to say :-[
[quote=“Bec a Fuel”]
I would be enclined to think that the slow blinking is somehow expected, as the debug information (exception + data) has to be transfered to VS.
So, to me, this is normal behaviour.[/quote]
If you power your board not from USB, you will see fast blinking. If you power it from USB and VS debugger is not attached, blinking will be slow.
The point here is that if you see any messages (of any kind: Debug.Print, GC, Exceptions etc.) in your Output window, you can be sure that it will adversely affect the speed of you application if VS debugger is not attached, but your board is powered from USB.
[quote=“iamin”]
If you power it from USB and VS debugger is not attached, blinking will be slow.
The point here is that if you see any messages (of any kind: Debug.Print, GC, Exceptions etc.) in your Output window, you can be sure that it will adversely affect the speed of you application if VS debugger is not attached, but your board is powered from USB.[/quote]
I have the behaviour you describe only when I use Debug.Print() statements, not with exceptions.
That’s why I mentionned the Debugger.IsAttached property. If I use it as a test to enable Debug.Print(), then no matter how I power the board, it will blink fast.
By everything described in this thread we can disable debug print’s from GC and we can dynamically turn on and off our own debug prints.
But I guess there is no way to stop exceptions and scheduler, … from using Debug.Print.
As long as anything from the framework uses it, there can be a lag in certain situations.
@ Gus: You once asked yourself (or your colleges) if GHI might be able to solve this issue. Did anything came back as answer?
In fact I would guess, that all that needs to be done is to check the Debugger.IsAttached flag inside the Debeug.Print method.
There is a bug in NETMF code where Debug.Print is not compiled away in Release build mode. If it was, we would have a perfectly normal solution — Release builds in production, Debug build in development.
Maybe another solution would be to use Trace.Print() instead of Debug.Print() ?
Trace.Print() has a conditionnal attribute that will prevent its compilation if the corresponding symbol is not set.
For instance, you can set the TINYCLR_TRACE symbol in the Debug configuration and omit it in the Relase configuration.
@ Bec a Fuel - Since exceptions and scheduler also use Debug.Print internally, I guess there must be a change in the framework to solve the issue.
Messages like “The Thread ### has ended” are always in the output window, no matter if debug or release build.
And these Messages will run into the USB Timeout as well, if no debugger is attached.
If there is no method to deactivate this messages, like GC has, then we are doomed.
@ Reinhard - Yes, you’re right, but my purpose here was more to avoid the Debug.Print() issue than fixing the whole system
Debug.Print() has no conditionnal attribute whereas Trace.Print() has one, so I thought it could be wise to use Trace.Print(). At least for our own debug info.
@ iamin - It seems that there are some differences between our config. Maybe Gadgeteer vs NetMF ? Or GHI’s firmware vs Oberon’s ?
For the following video, I’ve used this code, very similar to yours.
private static OutputPort _ledRed;
public static void Main()
{
_ledRed = new OutputPort(Pin.PE4, false);
new Thread(Blink2).Start();
Thread.Sleep(Timeout.Infinite);
}
private static void Blink2()
{
Int32 i, j;
j = 0;
while (true)
{
_ledRed.Write(Debugger.IsAttached);
Hardware.Led1.Write(!Hardware.Led1.Read());
Thread.Sleep(100);
try
{
i = 10/j;
}
catch (Exception ex)
{
}
}
}
First, you can see the board powered via external power. It’s blinking fast.
Second, I remove power and plug the USB cable. Still blinking fast.
Third, I attach the debugger (red led turns on) and blinking becomes slow.
@ Bec a Fuel - I guess that when the debugger is attached and an exception occurs, that the device sends information about the exception to the debugger (should I stop or should I go).
That might be the reason why in this case it gets slower with attached debugger.
But I guess if you put a couple of Debug.Print’s instead of the exception in your loop it might be the other way around.
