Step pulse off timing

[buildlog]

I am not sure why the step off pulse timing is not accurate. It is weird that it works, but not accurately. It might be due to how the timer is turned on or restarted.

One solution might be to capture the pulsed on time in microseconds with esp_timer_get_time(), finish the interrupt code and add an empty while loop until another esp_timer_get_time() reaches the off time. I hate while loops in interrupts, but it should only be for a few microseconds, some of which will already have expired running the code before the while loop.

Bart

[buildlog]

The solution mentioned above appears to work fine.

I removed the timer interrupt that turns off the step pulse and replaced it with a delay loop at the end of the main stepper driver interrupt (void IRAM_ATTR onStepperDriverTimer())

// wait for step pulse time to complete...some of it should have expired during code above while (esp_timer_get_time() < step_pulse_off_time) { NOP(); // spin here until time to turn off step } set_stepper_pins_on(0); // turn all off

The stock Grbl setting is 3 uSecs, which is also the minimum. I am not sure why that is a minimum, but I'll leave it. Common drivers like the TI DRV8825 require a step pulse length of 1.9uS.

I don't think it should impact performance because the time is so brief. You can't go any faster than what the minimum step pulse timing will allow anyways. I have not profiled the code before that, but it probably uses up much of the time.

I have not committed the code yet, in case anyone wants to comment on this.

[buildlog]

For reference, here is the DRV8825 timing diagram.

[ggallant571]

I have been doing my own gcode processor for a couple of years using a STM32 device. Recently have started using various ESP devices for remote sensing projects. More than willing to migrate to your implementation.

[buildlog]

Changed to use method described above.