Split Stepper Motion Controller <-> Stepper Driver

[jilaypandya]

Is your enhancement proposal related to a problem? Please describe.

Currently Stepper API combines Motion Controller and Stepper Driver under a single api with following functions.

Current API

However, as one can see in the block diagram of TMC5041(Dual controller/driver for up to two 2-phase bipolar stepper motors with Integrated motion controller with SPI interface) is a controller with MotionController + Stepper Driver.

Additionally all the STEP/DIR Drivers such as the tmc2209 are just stepper drivers which has a "Software Motion Controller" integrated within them.

TMC5041 Split between motion_controller and stepper_driver

As one can see there is one motion_controller pe stepper_driver

Describe the solution you'd like

Hence the cleaner approach would be to seperate "Motion Controller" from the actual "Stepper Driver" with the following API structure.
Proposed Split

Describe alternatives you've considered

Additional context

Further context can be understood by the following image, here TMC429 is a Stepper Motion Controller Driver, whereas TMC2660 Stepper Driver.

Stepper Motion Controller	Stepper Driver	Notes
TMC429	TMC2660	TMC2209 and other step/dir driver might be compatible as well
zephyr,stepper-control (workqueue/counter/ramp)	TMC22xx, DRV84xx, A4979	zephyr stepper control driver is a sw driver
TMC50XX Stepper Motion Controller	TMC5XXX Stepper Driver	TMC5XXX Series are a combined packagage (something like TMC429 + TMC2660 packed together)

DTS
There are two Approaches as how the DTS could look like

&spi1 {
        /** SPI Settings **/
	tmc50xx: tmc50xx@0 {
		compatible = "adi,tmc50xx";
		reg = <0>;
		spi-max-frequency = <DT_FREQ_M(1)>; /* Maximum SPI bus frequency */

		#address-cells = <1>;
		#size-cells = <0>;

		clock-frequency = <DT_FREQ_M(10)>; /* Internal/External Clock frequency */

		tmc_stepper_controller: tmc_stepper_controller@0 {
			compatible = "adi,tmc50xx_stepper_control";
			reg = <0>;

			/* ADI TMC ramp generator as well as current settings */
			vstart = <1000>;
			vstop = <10>;
			a1 = <10000>;
			v1 = <50000>;
			d1 = <14000>;

			tmc5xxx_stepper_custom: tmc5xxx_stepper {
				compatible = "adi,tmc5xxx_stepper_driver";
				/* common stepper controller settings */
				micro-step-res = <256>;
				/* ADI TMC stallguard settings specific to TMC50XX */
				activate-stallguard2;
			};
		};
	};
};

/ {
	gpio_stepper: gpio_stepper {
		compatible = "zephyr,gpio-stepper";
		status = "okay";
		micro-step-res = <2>;
		gpios = <&gpioa 9 GPIO_ACTIVE_HIGH>,	/* D8 */
			<&gpioc 7 GPIO_ACTIVE_HIGH>,	/* D9 */
			<&gpiob 0 GPIO_ACTIVE_HIGH>,	/* D10 */
			<&gpioa 7 GPIO_ACTIVE_HIGH>;	/* D11 */
	};
};


/ {
	stepper_control: stepper_control {
		compatible = "zephyr,stepper-control";
		status = "okay";
		stepper = <&gpio_stepper>;
		step-tick-ns = <1000000>;
	};
};

[jilaypandya]

Could you share your opinion on this?
@bjarki-andreasen @dipakgmx @fabiobaltieri @faxe1008

[dipakgmx]

Guess, we are coming close to the MFD approach suggested back then from the first stepper RFC.

[bjarki-andreasen]

I like it, this way we can have a common "soft stepper controller" which works with various and numerous stepper drivers, could remove a bit of duplicate code from the "stepper driver drivers" :)

[jbehrensnx]

First of all, I am in favor of restructuring the current stepper api in this way.
By effectively inverting the whole step-dir implementation, it is actually possible to extend it beyond just adding new timing sources, see my PRs #87800 and #88342. This should make integrating them easier.
It is, in my opinion, also better structured from a logical and architectural perspective.
New stepper drivers should also be easier to implement.

One point that needs further discussion is, in my opinion, a stepper controller api capability to configure the acceleration profile. Yes, currently only one exists, but more will come, see PRs #88342 and and #88564 as examples. While a controller specific option for fine control is useful and makes sense to exist, it somewhat goes against the generalist driver intention of Zephyr.
In addition, most users will probably just want to set a speed and either an acceleration time or a maximum acceleration. The stepper controller driver should then translate this into its specific acceleration profile configuration.

One point I disagree with is the step-function for drivers. It is in my opinion unnecessary, the first indication for this can already be found in the fact that the tmc50xx doesn't implement it.
Most stepper controllers will not use it, in fact the only usefulness it has is, that it allows the existing workqueue and counter controllers (the latter not yet being modified) use the gpio bitbang driver. For the step-dir drivers a gpio-pin is driven, which can be done directly in the controller.
In addition, controlling the step pin in software is something that most practical real world applications will not do, instead having the step pin driven by a timer (see PR #87800) or using another hardware method. Something like this would also be used for any serious implementation that requires driving the h-bridges directly.
And spi-based stepper-drivers (like tmc50xx) feature either an integrated controller or are intended to be used with an additional hardware stepper controller like the TMC429, again making the step function unnecessary (and highly unperformant in that case).

EDIT: Concerning devicetree, either the second option, or preferably, having the stepper controller as the parent node with the stepper drivers as child nodes (aka the inverse of the first approach). The actual first approach is a bad idea, both from an architectural point, but also from the fact that a controller can possibly control multiple drivers.

[jbehrensnx]

Also @jilaypandya as the maintainer, could you possibly contact people from Analog Devices and TI on the Zephyr Project? They are both Zephyr members and developers/producers of stepper drivers/controllers we have written drivers for, so getting feedback from their experts would be useful. I feel like the significant planned changes to the api offer a good opportunity for this.

If stepper support in Zephyr is not on their agenda, that is good to know, but raising awareness and possibly getting them involved would be useful.

[faxe1008]

Generally makes sense to me, need to browse the reference PR some more. Regarding the naming I'd suggest stepper_motion_controller_api (adding motion in there somewhere), since imo it signals that the stepper driver itsself provides the base building blocks and configuration and any motion triggering etc. shall be done by that driver.

Also a thing that I was wondering about is whether or not this can be generic enough to accomodate for DC motors and make it rather a subsystem then a driver? Allow for things like encoders for position detection etc. Maybe thats too amibitious tho.

[jbehrensnx]

Also a thing that I was wondering about is whether or not this can be generic enough to accomodate for DC motors and make it rather a subsystem then a driver? Allow for things like encoders for position detection etc. Maybe thats too amibitious tho.

Probably to ambitious for know. I think it is better we get a good stepper motion control api for know. I think we need to wait at least for a dc-motor api and possibly for a dc-motion-control api before we think about a general api. Plus for a general motion api we will want experts of that field to get involved as well.

[jbehrensnx]

Another thing that needs to be considered is fault/error handling. Both the ti84xx and the tmc2209 drivers as well as the tmc2130 driver (I am currently working on the latter), as well as many more, have fault-gpio-pins. In addition the tmc drivers have (driver specific) error bit in their spi read values.
We need some way for controllers to manage this. One idea would be to have separate driver and controller event handling, with the controller attaching itself to the driver event handling and processing it.

[jilaypandya]

I like it, this way we can have a common "soft stepper controller" which works with various and numerous stepper drivers, could remove a bit of duplicate code from the "stepper driver drivers" :)

Reducing duplication of Code was one of the motivation :)

Generally makes sense to me, need to browse the reference PR some more. Regarding the naming I'd suggest stepper_motion_controller_api (adding motion in there somewhere), since imo it signals that the stepper driver itsself provides the base building blocks and configuration and any motion triggering etc. shall be done by that driver.

stepper_motion_control_api how does that sound :) ?

One point I disagree with is the step-function for drivers. It is in my opinion unnecessary, the first indication for this can already be found in the fact that the tmc50xx doesn't implement it.

TMC429(Motion Controller) -- s/d -> TMC2260(Driver), I have already added that block diagram in the RFC.
TMC5072-LA 2-Axis Stepper Motor Controller/Driver I2C, SPI, Step/Dir - TMC5072 Datasheet.

I will start now with the refactoring of drivers step-by-step ;-)

[jbehrensnx]

Had an offline discussion with a colleague about the proposed changes. Some of the things that came up:

• There were arguments that while using a proper controller driver there is no need for using a dedicated driver-driver, as a controller should handle these things(enable/disable, handling microstep resolution) as part of motion control. The physical driver specific parts might be handled by a specific module.
• Again affirming that the step-function needs to be dropped as any serious real world use case will not use it and instead generate the step signal another way.
• Consequence of this is that any step-dir-controller driver will need to drive the step pin directly - at which point it can be argued that it is a stepper-driver-driver and not a controller any longer, as anything that directly configures a physical stepper driver or controls its pins is a driver driver (which means that a stepper controller is a physical stepper driver driver).
• Discussion about using the new architecture simply for step-dir drivers, with the proposed controller being a stepper-driver-driver and the proposed driver-driver being a config module plugged into the driver-driver that is used for configuration. While this option offers better extendability than the old one, there is the question about the driver self-configuring while it is running (e.g. current regulation during acceleration and coasting). There was no clear conclusion if the current or the possible new architecture would be better for this.