working with stepper motor

[alxkos]

Hello, i'm working with a stepper motor drv8825 with 32microsteps
the code is super simple:

from machine import Pin
from time import sleep_us, ticks_us
MOTOR_EN_PIN        = 9
MOTOR_DIR_PIN       = 12
MOTOR_STEP_PIN      = 11
en = Pin(MOTOR_EN_PIN, Pin.OUT, value=1)
st = Pin(MOTOR_STEP_PIN, Pin.OUT)
dr = Pin(MOTOR_DIR_PIN, Pin.OUT)
dr.on()
en.off()
spd = 500
leng = 200 * 32 * 1
t0 = ticks_us()

for j in range(leng):
    st.on()
    sleep_us(spd)
    st.off()
    sleep_us(spd)
en.on()

but the pulses are wrong.
because loop with delays is wrong.

even simple code like this:

from time import ticks_us, sleep_us
for i in range(100):
    t2 = ticks_us()
    sleep_us(1)
    t = ticks_us() - t2
    print(t)

gives me range from 105-120us

trying this code:

for i in range(100):
    t2 = ticks_us()
    st.on()
    sleep_us(150)
    st.off()
    sleep_us(150)
    t = ticks_us() - t2
    print(t)

gives 380-410us. not close to 300.

the lowest delay i can set is 31us. and it gives 140-190us and not 62

does this mean that we cant use micropython in microsteps mode?
how can i "calculate" a speed this way?

thanks

[robert-hh]

These numbers are worse than I would expect. Repeating the tests I get much better figures (code below), but the principle limitations stay. The numbers I get:

a: Short loop,
ESP32 w/o spiram: 5us, with 30 to 50us at the first loop iteration
ESP32 with spiram: 25us with 40-25 us at the first loop iteration
ESP32C3 w/o spiram: 5us wit h 20us at the first loop iteration
ESP32S3 with Octal Spiram: 3 us with at the first loop iteration and sometimes 50us in between
Pyboard V1.1: 6us with sometimes 15 us
PYboard D SF6: Mix of 4us and 6us
SAMD51: 9 us or 14 us

b: Loop with Pin I/O and longer wait times:
ESP32 w/o spiram: 303us, with 390us at the first loop iteration
ESP32 with spiram: 330us with 390us at the fisrt loop iteration
ESP32C3 w/o spiram: 304us wit h 340s at the first loop iteration
ESP32S3 with Octal Spiram: 300 us with at the first loop iteration and sometimes 330us in between
Pyboard V1.1: 314us with sometimes 325us
PYboard D SF6: 309us with sometimes 317us
SAMD51: 318us - 324us

This is for the short loops. The inherent problems are cache misses of the code with a serial attached memory and garbage collection. In case of a cache miss, the page with the missing code has to be reloaded. Garbage collection in critical phases can be both disabled and, if not disabled, avoided.

Modified code. Note that calling ticks_ms() takes time as well. e.g. for ESP32 removing the sleep_us(1) statement result in a time of 3 us.

from time import ticks_us, sleep_us

def tickloop(n=100): 
    for i in range(n):
        t2 = ticks_us()
        sleep_us(1)
        t = ticks_us() - t2
        print(t)

tickloop(24)

from time import ticks_us, sleep_us
from machine import Pin
st=Pin(5, Pin.OUT)

def tickloop(n=100):
    for i in range(n):
        t2 = ticks_us()
        st(1)
        sleep_us(150)
        st(0)
        sleep_us(150)
        t = ticks_us() - t2
        print(t)

tickloop(24)

[jimmo]

@alxkos

does this mean that we cant use micropython in microsteps mode?

microstepping is a property of the stepper driver (i.e. how many pulses of the step pin correspond to one full cycle of the A and B lines).

But if your issue is that the pulses are too slow, then note that your loop can be optimised slightly I think to avoid some attribute lookups

def run(p, n, us):
    s = sleep_us
    for j in range(n):
        p(1)
        s(us)
        p(0)
        s(us)

Because it's inside a function, the variables are all now local (rather than having to be looked up in globals). This includes the sleep_us function, which is cached in the local variable s. It uses the "call" syntax for pin (i.e. the pin looks like a function) which is faster than looking up the on / off attributes and calling them.

You could also add @native to this function to speed it up a bit more.

See https://www.youtube.com/watch?v=hHec4qL00x0 for more tips like this.

There are other ways to generate pulse trains though. See e.g. esp32.RMT, or even you could use the SPI clock line.