Implementing DC motor driver logic controlled by I2C

Developers
1

Hi all!

This thread is related to a previous discussion: Implement shutdown behavior for SX1509 and I2C in general? - #5 by koconnor.
As a recap of that thread, I am working on a rewinder system based on an array of DC motors, intended to be driven by SX1509 from I2C.

I had been testing my I2C shutdown interface for the past couple of days, but found a new issue with my approach.
My SX1509 sends PWM signals to a DC motor H-bridge driver DRV8833. This driver controls a motor by two inputs xIN1 and xIN2. as in the logic table below:

Screenshot 2024-02-01 at 5.15.24 AM
Screenshot 2024-02-01 at 5.15.24 AM727×245 7.91 KB

The problem is, if I control two pins from klipper using two standard PWM output_pins or SX1509’s PWM pins, I have to send two MCU commands to drive the motor. This is problematic because if I switch from fast decay (xIN1=0, xIN2=0) to slow decay (xIN1=1, xIN2=1), klipper’s queue system is slow enough for the driver to enter a transient state such as (xIN1=0, xIN2=1) — this creates an abrupt motor movement.

My current temporary solution is that I created a new MCU command i2c_write_batch, which takes in a list of data so that I perform an individual I2C write for each datum in this single MCU command. This way, I can let the SX1509 set both pins in one shot. This is a bit hacky IMO and restricts the usage of DRV8833 to only be driven by SX1509. But, it seems like the alternative is to create something like stepper.c; however, that would on the flip side restrict the usage of DRV8833 to regular GPIO pins. So I am torn.

If I would like my rewinder system to be usable by others, what would it take me to convince klipper to accept a PR for this use case?
In particular, would klipper accept a PR that:

  • adds MCU command(s) such as i2c_write_batch , for driving multiple pins in one shot.
  • adds relevant MCU command for shutting down I2C pins.
  • adds relevant python modules to drive the DRV8833 from the SX1509 IC.

Would the combination of DRV8833+SX1509 to be “too specific” and will never be able to make it into main klipper?
Would it be better if I implement DRV8833 logic for both I2C controller and regular GPIO?

Thank you!

2

Hi,

As a rule, I can’t say whether or not a future PR will be merged. The only way to know is to perform a review of that PR.

That said, your proposal seems like it may have trouble fitting the general “100 users” guideline as mentioned at Contributing to Klipper - Klipper documentation . In general, we try to keep the main Klipper repo geared towards mainstream hardware.

As mentioned previously, an alternative solution that would not have long-term software maintenance concerns would be to deploy an mcu instead of an i2c expander.

Separately, the mechaduino branch I wrote a few years back has code for supporting typical H-Bridge style chips - Mechaduino experiment .

Cheers,
-Kevin