leducp commented on PR #10902: URL: https://github.com/apache/nuttx/pull/10902#issuecomment-1761046651
> The idea behind `motor.h` was to create a universal interface for various types of motors so I think it's better to modify it to fit better for stepper motors. You can just add another configuration option for motor interface: > > ``` > config MOTOR_UPPER_HAVE_STEPS > bool "Have steps control" > default n > ``` > > then extend `struct motor_params_s` with: > > ``` > #ifdef CONFIG_MOTOR_UPPER_HAVE_STEPS > uint32_t steps; > int16_t steps_speed; > uint16_t microstep; > #endif > ``` > > Currently `motor.h` uses floats which is not ideal for chips without FPU and I would like to add support for fixedmath someday. But if you need only step control, you can just set `CONFIG_MOTOR_UPPER_HAVE_STEPS` and all float values should be not included. It's possible to control stepper motor also with the FOC algorithm, in this case the concept of 'steps' makes no sense. > > Using `motor.h`, the stepper motor driver can later implement control methods other than step if needed and having the same interface, we can more easily change the type of motor used (better modularity). I understand the idea but I feel that it became a kind of god object anti pattern... The whole motor interface works with a different mindset like start and stop. Moreover, what if one need to control a stepper and a bldc? Both interface will be mixed in the code no? About your last point, if one want to control a stepper as a motor, it have to implement a specific control in the motor interface and not in the stepper one (to match this mindset). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
