CircuitPython Support

[survient]

I've tried deploying this library to an Adafruit ESP32-C6 Feather - STEMMA QT that was running Circuit Python but understandably ran into an ocean of failed dependencies, mostly around logging and components related to pyftdi. Adafruit has provided https://github.com/adafruit/Adafruit_CircuitPython_Logging for logging and likely some of the other missing dependencies aren't needed for boards running Circuit Python.

I am unsure of the level of effort, but it would be great to be able to leverage this on Circuit Python.

[Chr157i4n]

There are several things needed to support CircuitPython.
First, an extra GPIO wrapper propably needs to be written for it. Currently, this there is only one available for MicroPython (machine).
https://github.com/Chr157i4n/PyTmcStepper/blob/main/src/tmc_driver/tmc_gpio/_tmc_gpio_board_micropython.py
The same for the SPI/UART com modules:
https://github.com/Chr157i4n/PyTmcStepper/blob/main/src/tmc_driver/com/_tmc_com_uart_micropython.py

In addition, the following if-condition is used, as an example in the logger module, to detect micropython:

MICROPYTHON = sys.implementation.name == “micropython”

A minimal implementation specifically for Micropython is then used. At least the condition must be adapted for Circuitpython, maybe also the minimal implementations.

I will take a look at it tomorrow. I need to flash Circuitpython onto one of my µC first.

[Chr157i4n]

I have now implemented basic CircuitPython support. Unfortunately, CircuitPython has some limitations compared to MicroPython.

math.log2 is not available on my Pico...
https://docs.circuitpython.org/en/stable/shared-bindings/math/#math.log2

Since CircuitPython does not support interrupts, StallGuard cannot be used.

To get it to work, you need to copy the following files/folder to your board:
micropython/lib -> lib
src/tmc_driver -> tmc_driver or lib/tmc_driver
demo_script_xy.py -> code.py

[survient]

Thank you so much! I will test this on my ESP32 when I get a chance.

What model of Pico do you have? I'm happy to do what is needed for you to be able to have a supported board to aid in development.

For interrupts, I have found this article though I'm pretty weak in this area to understand if it would be sufficient for what you need:

https://learn.adafruit.com/cooperative-multitasking-in-circuitpython-with-asyncio/handling-interrupts

[Chr157i4n]

i have a Pico W and a Pico 2 W, but as long as the Micropython/CircuitPython Interpreter is available for that board it should not matter which board you have.
With CircuitPython you need to adapt the pins for your board. On the Pico they are named board.GP18, on the ESP they are propably called board.D18 or something similar.

StallGuard

I know that asyncio needs to be used to support pseudo-interrups. That is quite a downgrade compared to Micropython. Currently a NotImplementedError will be thrown, if you try to use it:

PyTmcStepper/src/tmc_driver/tmc_gpio/_tmc_gpio_board_circuitpython.py

Lines 114 to 119 in 6a099f5

	def gpio_add_event_detect(self, pin, callback):
	"""add event detect (rising edge interrupt)"""
	# CircuitPython doesn't have Pin.irq() - would need asyncio
	raise NotImplementedError(
	"GPIO interrupts not directly supported in CircuitPython."
	)

If you need StallGuard, feel free to create a pull request for it.

Motor movement/timing

However, I have also noticed a strange behavior regarding the timings. The stepper runs significantly slower than it should and occasionally stutters slightly.

I suspect this is related to the get_time_us() function:

PyTmcStepper/src/tmc_driver/platform_utils.py

Lines 10 to 16 in 7e063b3

	def get_time_us():
	"""Get current time in microseconds, compatible with CPython, MicroPython and CircuitPython"""
	if MICROPYTHON:
	return time.ticks_us() # pylint: disable=no-member
	if CIRCUITPYTHON:
	return time.monotonic_ns() // 1000 # pylint: disable=no-member
	return time.time_ns() // 1000

Someone should take another look at this.

[Chr157i4n]

I couldn't find an error.
if I switch to full stepping and a lower speed, it works as expected.
Perhaps Micropython/Circuitpython simply isnt fast enough.

[survient]

I have a DS3231 RTC wired up to my ESP32. Would that be worth doing a comparison of the built-in clock against the external RTC to see if there's any difference in consistency where this problem is showing up? I can see someone reported RTC concerns for Circuit Python here but for a much older version: adafruit/circuitpython#9953

[Chr157i4n]

in the demo script the current default fullstep speed is 250, which are 500 µsteps/sec with mres=2 (even more with higher microstepping resolution). between each step the duration until the next pulse for the next step has to occur is being calculated. At fullspeed this mean, the controller has ~2ms for it.

last_time = time.monotonic_ns() // 1000

for _ in range(100):
    time.sleep(1 // 1000 // 1000)  # sleep for 1 microsecond
    current_time = time.monotonic_ns() // 1000
    print(f"Elapsed time: {current_time - last_time} us")
    last_time = current_time

Elapsed time: 275 us
Elapsed time: 274 us
Elapsed time: 275 us
Elapsed time: 305 us
Elapsed time: 275 us
Elapsed time: 305 us
Elapsed time: 275 us
Elapsed time: 305 us
Elapsed time: 275 us
Elapsed time: 244 us
Elapsed time: 305 us
Elapsed time: 275 us
Elapsed time: 274 us
Elapsed time: 275 us
Elapsed time: 336 us
Elapsed time: 488 us

just reading the time, waiting with time.sleep and then rereading the time takes less than 100µs. In this case the print add more than 100µs to it.
There is some jitter, but its ok. When i put the print outside the time measurement the jitter is negligible:

for _ in range(100):
    last_time = time.monotonic_ns() // 1000
    time.sleep(1 // 1000 // 1000)  # sleep for 1 microsecond
    current_time = time.monotonic_ns() // 1000
    print(f"Elapsed time: {current_time - last_time} us")
    last_time = current_time

Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 30 us
Elapsed time: 91 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us
Elapsed time: 61 us

The compute_new_speed() function takes around 250-300 µs

PyTmcStepper/src/tmc_driver/motion_control/_tmc_mc_step_dir.py

Line 308 in dd315b1

def compute_new_speed(self):

i have found the function causing this:

PyTmcStepper/src/tmc_driver/motion_control/_tmc_mc_step_dir.py

Line 390 in dd315b1

def run_speed(self):

When no step is being made the function take around 150 µs, when a step is being made, it takes around 800µs (which is a bit too slow, but reasonable).
But sometimes it takes up to 9000 µs.