can a usb trim state cause a 1/(48,000,000/64k) second resync timeout?
What if I change the frequency using the api? Will it have a dead-time of over a ms?
So is it really required to stop the clock, just to change the frequency? Or just figure it might not run past the trigger point and run
through the entire counter (1.3 ms of dead time)? Is it best to reduce this possibility by stopping the clock, changing the freq, and then starting it?
It seems so to me.
So, it seems it IS required to stop the clock if you want a clean change of freq.
But, if you stop the clock.. [catch 22]
Anyone have a better answer?
Could you please elaborate what is [catch 22]. And what all are the issues you are facing if you stop and start the clock
I want no glitch