Hi Steve,

This lag can happen if the arduino is sending huge numbers of debug trace messages to the pc.

There are lots of options that you can enable to prevent this but by default the plugin should prevent the issue.

Before I explain some options, I would like to understand which features you are using? Please answer following questions...

1) Using the Analog/Digital/Free mem graphical reports?
2) Have unconditional breakpoint in fast running methods such as loop()?
3) Have multiple unconditional breakpoints in fast running methods such as loop()?
4) In the Micro Trace, how many messages are you seeing per second (approx)?
5) Are you using the "Hit Counter" system? 
6) Have you applied conditions to any breakpoints?
7) How many breakpoints do you have in your project?
8) Have you changed the "Throttle" settings from their default values?
9) Which arduino board are you using?
10) Are you using the default serial/usb port or another port or softwareSerial?

Thanks

Thanks for the info. Future releases of the debugger will become more efficient. It sounds like your usb drivers/pc/vm can't handle 12 messages per second. 

Questions and Solutions

1)
Are you also sending serial messages while debugging? This is okay but will add to the load.

2)
I forgot to check that you are using the default debugger speed on the normal serial upload port? I guess from your answers that you are?

3)

We should try to limit the debugger messages to fewer than 10 per second and see if that works better. The problem is that windows will queue the messages if it can't process them fast enough and the arduino runs at 16mhz.

This is how to configure unconditional breakpoints to work at 5 per second.

1) Project properties>Hit Counter=Millis
2) Breakpoint>Hit Counter=200

This ensures that the breakpoint is only executed every 200 milliseconds which is 5 per second.

Please try this and let me know if it makes a difference. Your arduino will certainly work faster and be more responsive than before.

Summary

The reason why the arduino will work faster with the solution in 3), is that if you allow breakpoints to happen too often VM will automatically slow the arduino down (using delay) in an attempt to avoid the problem you have been having. 

This forced "slow down" is called the "Throttle" and is only used if breakpoints attempt to work at 16mhz. You can increase the throttle (ms) in the project properties BUT I do not recommend this. This is really designed for new users who don't understand how the arduino works. By default throttle shows as 0 in the project properties, 0 invokes a default of 80 milliseconds. This means that if a breakpoint/tracepoint is hit within 80 milliseconds of the last one then the arduino will pause until the time delay has reached 80ms. If your own arduino program code sends a lot of manual serial messages on the same port then 80ms might not be a high enough throttle value.

The "Throttle" is not the best solution, the best solution is to place breakpoints in locations in the code that are hit every so often or when major events occur or by using the "Condition" property of the breakpoint or by making use of the "Hit Counter" system explained above.

I have done extensive testing in this area, my pc is quite quick and this is not an exact science but I would like to see your sketch and try it for myself with your code. Can you please zip and email the sketch folder and Visual micro folder below the sketch to info [at] visualmicro.com

Expert Mode - No Throttle, the Arduino runs at full speed

If you understand the rules and also understand the impact of serial messages on your program then the "Throttle" system can be disabled using the Visual Studio Project Property "Throttle Enabled = False".

With the Throttle disabled it is possible for the Arduino to send debugger messages faster than your pc/vs can process them. The effect is that what you see on the screen during debug falls behind "real-time" with the Arduino. You end up seeing what the Arduino was doing in the past. This is confusing and can be dangerous. 

I don't know how fast the Arduino loop() runs on a 16mhz chip but let us assume it could be 100,000 times per second.  If you have a tracepoint in the loop() then your pc will need to process 100,000 debugger messages per second which also involves updating the debugger displays (UI). This is too much information for a pc to handle. 

Furthermore the TracePoint notification is sent by the Arduino using Usb/Serial. This in itself has restrictions as to how fast it can work and how much data it can send at any given speed.

BUT, We might want multiple TracePoints to execute within a short space of time. For example when a button is pressed we might want 10 or 50 TracePoints to be "Hit" in various locations within our code. However, when the button is not pressed we might not require any Tracepoints at all.

phew! thanks for letting me know