stepper_controller: introduce api

[jilaypandya]

This PR is the reference implementation for this RFC: #68547

This commit introduces api for stepper motor control where stepper motors are childs of a stepper motor controller
This PR is created in response to the following review.

Rather than going for the bus:motor approach as done in this PR, this PR goes for the child binding approach.

Device Tree Looks largely the same in both approaches.

&spi-controller { status = "okay"; tmc5041: tmc5041@0 { status = "okay"; compatible = "trinamic,tmc5041"; reg = <0>; #address-cells = <1>; #size-cells = <0>; motor_controller_0: motor_controller_0 { status = "okay"; micro-step-res = <256>; stall-guard-setting = <12>; }; motor_controller_1: motor_controller_1 { status = "okay"; stall-guard-setting = <34>; }; }; }; 

Bindings

Example trinamic,tmc5041.yaml

description: TRINAMIC TMC5041 compatible: "trinamic,tmc5041" include: [spi-device.yaml] properties: "#address-cells": default: 1 const: 1 "#size-cells": default: 0 const: 0 child-binding: include: - name: stepper-motor-controller.yaml property-allowlist: - micro-step-res - reg properties: stall-guard-setting: type: int default: 0 description: | The signed value controls StallGuard2 level for stall output and sets the optimum measurement range for readout. A lower value gives a higher sensitivity. Zero is the starting value working with most motors. For instance, in case of tmc5041, range is -64 to +63 A higher value makes StallGuard2 less sensitive and requires more torque to indicate a stall. 

[fabiobaltieri]

is this mean to reset the internal position data to zero? unclear to me from the description

[jilaypandya]

The idea is to reset all the registers to some default values. These register values could be entered through DTS, for now i have kinda hardcoded most of them in tmc5041_motor_reset. Use case could also be extended to reset some internal values as well

[fabiobaltieri]

sounds more like a "set limits" than "calibration", different name maybe?

[jilaypandya]

yep, you are right the calibration function basically sets the end limits currently. probably something like detect_end_limits would be more apt.

[fabiobaltieri]

not quite following, when is this going to get called?

[jilaypandya]

A callback calibrate_func would have to be registered using this function. Once registered, upon calling stepper_motor_calibratethe pre-registered calibrate_funcwould be called. The approach is comparable to https://docs.zephyrproject.org/latest/hardware/peripherals/gpio.html#c.gpio_init_callback

[dipakgmx]

@fabiobaltieri : The idea behind this function is to perform referencing actions. Every time the motor controller (say, in this case, the trinamic 5041) starts up, the position is unknown. Ideally, one would travel to both the end stops, and say, on reaching the lower end stop, set the coordinate system, by resetting the current position to 0. Since, this is very hardware dependent (cause, one could either travel to both the end stops and detect a block, or using limit switches for detecting the end-stop), this referencing routine (here called as the ´calibrate´ function) is provided.

[fabiobaltieri]

sorry I still don't understand the whole mechanics of this, reading the driver code now, tmc5041_motor_set_position can set MOTOR_POSITION_MIN and MOTOR_POSITION_MAX, then tmc5041_motor_register_calibrate_func registers a callback but that only gets called from tmc5041_motor_calibrate, and all three are API functions so they are called by application? Or maybe a motion control algorithm, anyway I don't quite see the point, seems like a very complicated way of getting back the data that the application knew in the first place, or maybe it's just a bad example and there's cases where you read back the information from the controller? but then why bother with the callback, just return the data directly from the calibrate function

[fabiobaltieri]

I don't think these should be exposed, if the device has some device specific properties that are worth exposing beyond the API, then the driver should just implement some extra driver specific functions. There's few instances of that in the code base, check sensors for examples.

[jilaypandya]

yep. That's correct, these could be moved

[fabiobaltieri]

Does this information really needs to be here? I'd imagine that this is could be set in the devicetree, configured at init time and then everything else just talks in either steps or mm.

[jilaypandya]

There is a provision to set these in device tree as well. These are here in order to change microsteps during runtime.

[fabiobaltieri]

I see some position control stuff, would it make sense for this API to be used for servos as well? Just thinking that the name may be more generic and not include stepper in it? Maybe motor_control or something

[fabiobaltieri]

It'd be cool to have a "dumb" enable/position/step gpio based driver as a sample, just as a minimum example and for something we folks can play at home with :-)

[jilaypandya]

yep for sure, I'll add one for the well known ULN2003 driver from arduino kit

[jilaypandya]

@fabiobaltieri I have added a driver for controlling stepper motor with gpios. Currently i tested it with 4 pins. One could expand this driver though in the future.

[fabiobaltieri]

@jilaypandya tagging as RFC since this is introducing a new API and should probably go through the whole https://docs.zephyrproject.org/latest/contribute/proposals_and_rfcs.html#rfcs dance, but let's hear more comments before bringing it to the arch wg.

[fabiobaltieri]

just a couple styling nitpicks from me, great work

[DaAwesomeP]

I am unfortunately running up against a deadline and am not going to get a review in a reasonable amount of time, so please don't wait for me! Great work everyone; this is really exciting!

[wkhadgar]

LGTM! Just some really minor tweaks

[jilaypandya]

compliance checks should turn green, once this PR #77517 is merged

main concerns addressed, will let other reviews follow