We have done some further testing around this, and to ensure the buffer on the PC doesn't get filled quicker than it's being emptied, the below approaches can be used:
1) Throttling Approach: Disable the vMicro > Debugger > Full Speed (No Throttle) setting
Open the Project Properties (vMicro > Project Properties), and set the "Throttle (ms)" to 60 (it defaults to 80 when the value is 0)
This should keep up with the real world actions of turning the pot with the @Plot charts and Serial Monitor
2) Non-Throttling Approach: Enable the vMicro > Debugger > Full Speed (No Throttle) setting
Use the
HitCounters on the breakpoints to only report when it is a multiple of 60 (so every 60ms). This gives finer control of which breaks report how often which is useful when using a mixture of break/tracepoints in your sketch. This can be changed from being ms to being a counter in the Project Properties > Hit Counters setting, if you want it to report every x times it hits the tracepoint instead of every x ms.
Additionally you can use
conditions on the break/tracepoint to check the value has changed by more than a specified amount (e.g. 5) by storing the previous value in your sketch, and using the condition to compare the previous and current reading, ensuring they have changed by more than a specified amount before it reports.
Hit Counters and Conditions can be used together to prevent over-reporting a non-changing value, with much finer grained control over it when compared to the throttling, but at present if the data is coming in faster than ~60ms then it begins to lag behind reality.
We will look at improving the maximum speed this runs at in the future, and we will update when there is any change to this.