Use common methods for ISR / babystep pulse delays

[thinkyhead]

To address #16617 this PR adjust the timing delays around babystepping.
The main fix is the delay after a babystep and before re-enabling the ISRs.
For consistency, use the same timing macros that are used for pulses in the ISR.

[sjasonsmith]

Unfortunately this doesn't make it any harder to shut the motors down. I haven't tested it much to verify other behavior is ok, but I can still shut down my 2208 driver just as easily as before.

[thinkyhead]

We'll have to see how the oscilloscope data compares to the previous runs and see if adjustment is going in the right direction or not.

[thisiskeithb]

Is anyone else seeing reboots when trying to babystep after this commit?

[thinkyhead]

A reboot implies an infinite loop. What happens if you disable the watchdog?

[thinkyhead]

For fun and maybe profit, also try replacing in Stepper::babystep…

DISABLE_ISRS() with DISABLE_STEPPER_DRIVER_INTERRUPT
and
ENABLE_ISRS() with ENABLE_STEPPER_DRIVER_INTERRUPT

To go back to the old ways also try…

DISABLE_ISRS() with cli()
and
ENABLE_ISRS() with sei()

[thisiskeithb]

A reboot implies an infinite loop. What happens if you disable the watchdog?

I ran out of time yesterday, but I rebased my config on 4a73379 and no longer experience reboots while babystepping. I assume 189c101 is what fixed it.

If something else crops up, I'll be sure to create an issue with configs & more info.

[thinkyhead]

I've got another alternative at #16829 (INTEGRATED_BABYSTEPPING) that starts to address the issue by moving babystepping handling into the Stepper ISR. The current code there just tries to get it working the same as before, but it probably has some different timing.

The current code doesn't attempt to add an extra margin before the step is interjected, but it's in the right place to start pulling in timing information for that.

If timing alone does the trick, that will be good. But I also have it in mind to add logic so the Stepper ISR will intentionally drop steps at regular intervals to accomplish reverse motion when an axis is moving. And, if that works, perhaps the same approach can work to add extra steps when it's moving. We'll see. First thing is just to make sure it doesn't blow anything up.

[thinkyhead]

I've added on to #16829 a small tweak to keep babystep pulses from being too close to normal step pulses, but it considers every axis, not just the one being babystepped, so the position of the pulse will only stagger slightly when pulse rates are high. As far as I can tell by staring at my code, it should work, but I'll give it a more thorough test later today.

I'm still trying to brainstorm some tricks that could be used to integrate more tightly into the pulse phase or even into the basic bresenham line algorithm itself to either add or leave out steps at regular time intervals, and also to scale the frequency of the babysteps according to the resolution of the axis.

The simplest idea I can think of is to add a "babysteps" field to planner blocks with the amount of steps to add or remove from the given move, but which will not be applied to the stepper counts. The planner would automatically add the right number based on the duration of the move and the resolution of a babystep. If you wanted to babystep but there was nothing in the planner, you could just send a "zero" move and the planner would send the babysteps to the stepper ISR.

The only caveat with this is that if you already started a long move, there's currently no way to modify it. While it should not be impossible to have the stepper ISR modify the running block in-place to produce more or fewer steps, it would definitely be challenging. If only we could mount the axes on other axes just for babystepping….