I am working on a commercial application which will need to run without a PC. Whenever the debugger is inactive (Visual Studio is not actively debugging) my prototype (built on a FEZ Raptor) slows down massively, especially when handling exceptions. I have tried compiling it as Release and disabling all Debug.Print calls.
Is there some way to disable ALL debug communications, including the Exception stuff, whenever a debugger is not found?
This is a real problem, and I would really appreciate any help I can get. I have PCBs in production right now, and a rather important project is really counting on this system being functional in 2 weeks.
@ bigtwisty - When exceptions are thrown, they essentially call Debug.Print internally. I’m not sure of any way to disable that. Do you get a lot of exceptions being thrown? Is there any way to reduce that number?
The device is an automated exerciser intended to support Design Validation Testing on a BLDC controller my team is designing for a client. It is intended to run multi-day test scripts putting the controller through its paces while logging any faults. I am using exceptions to indicate certain fault status that may occur in the field. These conditions absolutely cannot lock up the software as we will lose valuable data.
Even if I attempt to write code that doesn’t throw exceptions in normal course (requiring a substantially different software approach) I still cannot guarantee that there will NEVER be an exception thrown. All I can do is handle exceptions properly in code.
If NETMF causes even temporary lock-ups when exceptions occur even when they are handled in software it really is not production ready. This sounds like a pretty big problem with NETMF, or the GHI implementation of it for any serious production environment.
@ bigtwisty - For applications with high performance requirements, it is not generally good practice to use exception handling for anything other than unexpected software faults. It is very resource expensive to “unwind” the stack when an exception occurs.
@ Gus: It is bad enough to worry me in a situation where testing costing $10k+ could be adversely impacted. Automotive testing is not cheap…
@ Robvan: That is something worth looking into. Do you have anywhere you can point me for directions?
@ Mike: That is probably good advice, which I will take into account in the future. I was using some custom exceptions to pass back info on what went wrong for logging purposes. I suppose I could use a “out string fault” parameter or something instead, but that will take some writing and would make things much less intuitive.
Update: As you probably expected, updating to QFE2 did not fix anything.
@ bigtwisty - is it a concern that it maybe worse later or it is a problem now. My understanding that this causes a delay but not significant for most needs. I am just trying to understand better so I can help you in finding a solution.
And switching to COM debugging will surely take care of this as recommended by the community.
[quote=“bigtwisty”]@ Robvan: That is something worth looking into. Do you have anywhere you can point me for directions?
pin PA25 (MODE) is used to initialize the board to use USB or Serial mode. Boot the device with this pin low and see how it effects performance.
Further, make your debug.print conditional instead of using a variable. This way non of the debug print will be included in your release code.
public static class DebugHelper
public static void Print(string msg)