Sharing Motor driver control lines

Hi Gerry,

Let me see if I understand correctly. You want to share every single control line (i.e. nENABLE, nSLEEP, USMx, DIR, STEP, VREF, etc) and then use nRESET to control one stepper at a time. Basically, the caveats you have mentioned are in essence the items to watch for and what may turn problematic (or not) at a later time.

So I wonder, why not share everything, but STEP? That is, you tell both devices to do exactly the same thing while one stepper is moving, and then a completely different thing while the other is moving.

For example, lets imagine a set of conditions for DRV8811 A in which you are in full step with DIR HI and you let motor A run by sending pulses to its STEP pin. Then, at a later time when motor B is to move, you stop the STEP A signal and now you change to a complete set of variables such as 8 degrees of microstepping and DIR LO. Motor B moves while you are sending pulses to the STEP pin. 

The thing to keep in mind is that none of these control signals become apparent to the respective device until the next rising edge at its respective input. In other words, while DRV8811 A is being actuated with full step and DIR HI, DRV8811 B will not see these control line values as it is not being clocked. In the same fashion, when you start to clock DRV8811B, DRV8811 A will not see these conditions. The only thing that I must mention is that for this work flawlessly, you need to return DRV8811 A to its previous set of conditions before you start stepping it. If you change the lines after the rising edge, you will get a jump, even it this is done microseconds after. The STEP input is rising edge tolerant so you need to make sure the lines are set before the next rising edge.

Another point to have in mind is that this method can only work if both motors are to operate with the same winding current, if you are sharing VREF. If VREF is controlled through a voltage divider, then each device can behave independently and there is no need to take this into consideration.

Either way, with this method you will never lose the position in the lookup table and the motor will always resume where it was left of without jerky motion, as long as your application can live with always enabled steppers.

Best regards,

Jose Quinones

Thank You Jose.

Let me summarize.  In my application, Motor A does most of the work, motor B has no load, and can be off.   When Motor A is done, Motor B does a quick cleanup, but motor A needs to be powered to provide some holding torque.  Then, either the work cycle repeats, or both motors can be turned off. 

I like the separate STEP signal idea, and I have a timer output to support it.  

Vref will be separate as the motors are not identical and have different current requirements. Motor A has control for 2 levels already.  Motor B will be fixed.

SLEEPn I am not using, and is pulled up high.

RESETn, DIR, USM0,1 can be shared, as long as the software keeps track of which motor is in action.

ENABLEn - I have a separate control line for this, so I can power off Motor B while Motor A is running.

This leaves the HOMEn behavior.  I will use a separate input for this.  But I do have a question.  The data sheet lists this as an Output, not tristate or open drain.  The ENABLEn description says: "Logic high to disable device outputs, logic low to enable outputs".  Since HOMEn is an output, but is not Open Drain or tristate, what will be it's disabled state, or does it not get disabled?

Gerry Belanger

Gerry,

I experimented with one of our boards and saw that HOMEn is not disabled by ENABLEn being high.

Thanks,

Matt

Matt,

Speaking of HOMEn, I did not find any specification in the data sheet for the propagation delay from a step edge to a change on HOMEn. 

I need to know this to determine if I will be able to read it in my ISR for the timer which set the step signal.

GerryB

Hi GerryB,

The STEP input has a deglitch of 1 us. Once the deglitch is complete, the nHOME output will reflect the current state.

BTW, never caught your question on nHOME and output disablement when nENABLE is deasserted. Although nHOME is an output, the disablement of outputs when nENABLE is HI refers to Power Outputs, or H Bridge outputs. nHOME is considered a system output, not an H Bridge output.

Hope the info helps. Best regards,

Jose Quinones

Thanks Jose. 

That is the information I need to architect my driver.  We are using a TI ARM at 720MHz.  A timer expiration triggers the step edge and an interrupt.

With my original scheme, it looks like we could get into and out of the ISR before HOMEn gets updated.

I will go to my plan B.  A little more complex, but it will solve the problem.

Thanks!

Gerry Belanger