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

[Reinhard_Ostermeier]

@mhstr

Thank you guys for your observation until now.

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?

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.

[freeck]

Hi there,

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

[Reinhard_Ostermeier]

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.

[Gus_Issa]

@ 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.

[Gus_Issa]

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

[freeck]

Hi gents, Please do not quarrel
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?)

[Reinhard_Ostermeier]

Conditional Statements like

#if DEBUG
Debug.Print("abc");
 #endif

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.

[Gus_Issa]

@ 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.

[freeck]

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.

[leforban]

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

[Gus_Issa]

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

[Reinhard_Ostermeier]

@ 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.

[leforban]

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