drivers:stepper Step-Dir Pin toggle Frequency to High

[jbehrensnx]

Describe the bug

The current step-dir implementation in step_dir_stepper_common toggles in single_edge mode the step pin twice as fast as it can. For some board and stepper controller combinations (for example Teensy 4.0 board with a TI drv8424 stepper controller) this causes the pin to be toggled to fast and thus erroneous behavior - e.g. the motor not stepping.

To Reproduce

1. Connect a drv8424 stepper controller with a Teensy 4.0 board and use the counter timing source (didn't test work queue timing)
2. Test the driver via the shell, using microstep resolution of 1 and a microstep interval of 5000000 - i.e. 200 steps/s
3. Observe the motor

Expected behavior

The motor should step correctly.

Possible solutions

One possible solution is to use a 50% duty cycle of the step signal - like the drv8424 driver before the step-dir generalization. This requires an internal doubling of the step signal frequency and step counting only on every second interrupt. In addition, the step signal needs to be explicitly set to low when stopping, possibly after a short delay after stopping the timing source.
These changes are only needed for single_edge mode. dual_step mode can remain like it is.

That said, this is only one possible solution and I am interested if there are other ideas on how to solve this.

[jilaypandya]

Ping @faxe1008

[faxe1008]

@jbehrensnx So the issue is that your Teensy toggles too fast and the drv8424 is not fast enough to detect the edges?
Datasheet:

Thinking about it - maybe it would make sense to change the step-dir impl generally so that for each timing source event we toggle the pin once, but depending on dual_edge we change the timing source frequency? This should space out the toggeling more and resolve the issue.

In addition, the step signal needs to be explicitly set to low when stopping, possibly after a short delay after stopping the timing source.

Can you explain why?

[jbehrensnx]

So the issue is that your Teensy toggles too fast and the drv8424 is not fast enough to detect the edges?

Yes. The NO. 2 timing of of 970ns is the issue. On the Nucleo F767ZI the pulse duration step high is ca 800ns, which while below 970 seems to be enough. On the Teensy however, pulse duration step high is only about 60ns - way to short.

Thinking about it - maybe it would make sense to change the step-dir impl generally so that for each timing source event we toggle the pin once, but depending on dual_edge we change the timing source frequency? This should space out the toggeling more and resolve the issue.

That would be my solution as well. We will also have to adjust step counting as well.

In addition, the step signal needs to be explicitly set to low when stopping, possibly after a short delay after stopping the timing source.

Can you explain why?

We run the risk of loosing steps otherwise. Without this after stopping the step signal might remain on high. The first toggle of a new movement would then set the pin to low, not doing a step despite us expecting to and adjusting the step count. Deliberately setting the pin to low would alleviate this. Note that this is only needed for stop and disable, regular movement should stop correctly on low.
Possibly delaying this is because at extremely high frequencies an additional timing source event might trigger before the timing source stop takes effect and with a delay. We would guarantee, that the step signal would always be low. That said, I dont know how realistic the case requiring the delay is. If we do incorporate the delay, it would most likely need to be implemented via workqueue, as the stop and disable events should be ISR safe to allow stopping from interrupt context.

[dolence]

More robust generic drivers like the ones used to drive bigger motors need wider pulse length. The driver I'm using requires 2 us wide pulses to work. Also, enable need to be active for at least 5 us before start generating pulses. Perhaps a way to adjust the pulse length would be a nice fit for both issues.

[jilaypandya]

Hey @jbehrensnx, I don't think this is a Bug, since the feature step_pulse_width is missing in stepper_driver_subsystem.

This feature enhancement can be tackled after #89786.

[jbehrensnx]

@jilaypandya I disagree. All step-dir drivers that I know of expect a 50% duty cycle, which is why that should be the default.