Debug.Print() - application is slow without connection to VS(or MFDeploy)

If I’m not totally wrong this bug was identified after the last release by MS, and it has definitely to be fixed by the NETMF team.
So hopefully the next MS release will solve this bug.

1 Like

Hi there,

I cannot find any post on this issue lately. Has this issue being solved in the meantime?

As far as I know ist fixed in NETMF 4.4.
So we have to wait for GHI to make an V4.4 based SDK.
There has no timline for that I know about.

@ Reinhard Ostermeier - and we do not know yet what problems 4.4 may introduce. Wrapping the debug print statements in a conditional statement is the best option for now.

@ andre.m - and how do you know I didn’t? :wink:

Hi gents, Please do not quarrel :wink:
A workaround would be nice and sufficient for now. I have already tested the conditional statement " if debug.isattached" but that did not work. As long as I have the usb cable attached it will “influence” execution of the application…
Gus, Which conditional statement are you refering to or would you suggest? ( reply #19 perhaps?)

Conditional Statements like


will only solve part of the Problem.
Every exception, every GC collect, every ending thread, …
Will also trigger a Debug.Print() from inside NETMF.
My solution currently is to not connect the USB calble when in productive use.
But if USB is your Primary way of powering your board, then this is unfortuenatelly also not an Option.

@ Reinhard Ostermeier - you can also switch debugging to the serial port and leave the serial port unconnected. A simple Jumper on the move pin will do the job.

Thanks gentlemen,

I can live with the present limitation. most important is to know that the strange behaviour of my application was not code related.

@ Gus - This involve to not use the serial port for something else…

@ leforban - correct, that one port. The others are fine.

@ Gus - For me the only reason to have the USB cable connected all the time is being able to do FW updates with FEZConfig by remote Access. This will not work if Debug is on RS232.
Now with being able to update the BootLoader with IFU too, this bug does not bug me that much anymore.

allowing debugging to null output would be a nice feature don’t you think?