Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

tiny26, motor driver, and ISP

tiny26, motor driver, and ISP

2005-01-30 by ethan@bufbotics.org

I built a circuit that uses an ATtiny26 for control and an SN754410NE
motor driver (ultimately destined for a line-following hobby robot).

It works nicely and I have full control over the motors using pins PB1 &
PB3 to control the enable pins on the motor driver.

I also have an AVRISP dongle that I use for in system programming, via the
6-pin header.  This also works nicely.

BUT, there's one issue.  PB1 serves several purposes, specificially, I use
it as the output to one of the motor enable pins (for PWM output), and PB1
is also MISO and used by the ISP programmer.

SO, during programming, the motor drives wildly.  I've tried some
pull-down resistors on the enable pin of the motor driver, but no joy.

Atmel design note on ISP says that you should use series resistors to
protect the programmer from any other circuitry, but I don't think I'm in
that situation because the motor isnt interfering with programming, its
just making my robot fidget wildly during programming.

Does anybody have a solution?

Unless someone has a common solution, I was thinking of trying to drive
the motor-enable pins through a logical AND of the RESET line and PB1. 
This will drive the motor-enable pin low anytime the reset line is brought
low, and the rest of the time, the value of my PB1 will be the value
output by the AND.

I'd really appreciate any advice or experience you can share.

Ethan
www.bufbotics.org

RE: [AVR-Chat] tiny26, motor driver, and ISP

2005-01-30 by Larry Barello

Don't use the enable line for PWM input.  Use the complementary PWM outputs
to drive the A & B side of the H-Bridge and use the enable line to, well,
enable the driver.
Show quoted textHide quoted text
-----Original Message-----
From: ethan@bufbotics.org


I built a circuit that uses an ATtiny26 for control and an SN754410NE
motor driver (ultimately destined for a line-following hobby robot).

It works nicely and I have full control over the motors using pins PB1 &
PB3 to control the enable pins on the motor driver.

..

Re: [AVR-Chat] tiny26, motor driver, and ISP

2005-01-30 by Ron

Greetings,
Take a look at chip # M74HC4053B1R. It adds a chip to your
project but buys the protection of some connected device
being under control during programming. Ron
----- Original Message -----
Show quoted textHide quoted text
Sent: Sunday, January 30, 2005 9:01 AM
Subject: [AVR-Chat] tiny26, motor driver, and ISP


I built a circuit that uses an ATtiny26 for control and an SN754410NE
motor driver (ultimately destined for a line-following hobby robot).

It works nicely and I have full control over the motors using pins PB1 &
PB3 to control the enable pins on the motor driver.

I also have an AVRISP dongle that I use for in system programming, via the
6-pin header. This also works nicely.

BUT, there's one issue. PB1 serves several purposes, specificially, I use
it as the output to one of the motor enable pins (for PWM output), and PB1
is also MISO and used by the ISP programmer.

SO, during programming, the motor drives wildly. I've tried some
pull-down resistors on the enable pin of the motor driver, but no joy.

Atmel design note on ISP says that you should use series resistors to
protect the programmer from any other circuitry, but I don't think I'm in
that situation because the motor isnt interfering with programming, its
just making my robot fidget wildly during programming.

Does anybody have a solution?

Unless someone has a common solution, I was thinking of trying to drive
the motor-enable pins through a logical AND of the RESET line and PB1.
This will drive the motor-enable pin low anytime the reset line is brought
low, and the rest of the time, the value of my PB1 will be the value
output by the AND.

I'd really appreciate any advice or experience you can share.

Ethan
www.bufbotics.org

Re: tiny26, motor driver, and ISP

2005-01-31 by alan_probandt

...set A=1 and B=0 for a motor.  It'll go clockwise.  Similarly, set 
A=0 and B=1, and I get reverse (counter clockwise).  And the PWM 
signal on the Enable line then turns the motor on for only small 
snippets of time, as defined by the duty-cycle.

  The Pulse Width Modulation signal is switching the A and B lines in 
the same manner as the original design switched the enable.  The PWM 
is controlling the speed of the motor by controlling the amount of 
power that gets to the motor.  A PWM signal that is on 25% of the time 
is driving the motor at 1/4 of the full speed (not sure of the exact 
conversion ratio here).
  The AVR allows the timer to be set with a few instructions to output 
a PWM signal continously on one or two of its pins.  Set up the timer, 
plug in the numbers for the Pulse Width percentage, and start the 
timer.  The AVR can then monitor the motor speed and other sensors for 
a closed-feedback controller loop.
  Putting a PWM on the enable pin MAY have unintentional side effects 
in the H-Bridge driver chip.  The tech support of the chip's maker 
could be questioned, or the company field service engineer.

RE: [AVR-Chat] tiny26, motor driver, and ISP

2005-01-31 by ethan@bufbotics.org

Larry Barello said:
>       Don't use the enable line for PWM input.  Use the complementary PWM
> outputs
>  to drive the A & B side of the H-Bridge and use the enable line to,
> well,
>  enable the driver.
>


Larry,

Thank you for the feedback.  I hadn't thought of using PWM on the A and B
lines.

I'm having a tough time visualizing what'll be happening though.

Here's the mental picture I had of my original "PWM on the Enable Line"
scenario:  I can easily picture what happens when I set A=1 and B=0 for a
motor.  It'll go clockwise.  Similarly, set A=0 and B=1, and I get reverse
(counter clockwise).  And the PWM signal on the Enable line then turns the
motor on for only small snippets of time, as defined by the duty-cycle.
Also in this scenario, I can set A=B and get braking mode.


Now I'm trying to picture Larry's suggestion of using complementary PWM on
A & B lines.  Firstly, I can easily picture the Enable line now.  Its now
used simply for enable/disable, with no "rapid" switching like PWM.  Then
my vision gets cloudy of what's happening on the A & B pins.  My limited
understanding is that pin A will experience an average voltage
proportional to the duty-cycle of the PWM signal.  Pin B will experience
the complementary average voltage.  But what does this actually do for me?
 Doesn't it cause the direction of motor motion to switch really rapidly
(at the PWM frequency)?

I would love it if you would take tht time to explain intuitively what's
happening.

Ethan
www.bufbotics.org

RE: [AVR-Chat] tiny26, motor driver, and ISP

2005-01-31 by Larry Barello

There are several ways to drive a load with an H-bridge.  What I proposed
was something called "Locked Antiphase".  I wrote a paper:
www.barello.net/Papers/Motion_Control  that describes the two common drive
techniques.

If you want to stick with Sign-Magnitude drive just use one the A line for
PWM and use  the B line for forward/reverse.  When in reverse you need to
invert the PWM signal.  That is just a bit set/reset with the AVR (read the
data sheet).

Locked anti-phase works great, but the ripple current through the motor can
be unreasonable if your frequencies are not high enough.  What is high
enough?  Well, it all depends upon your motor.  Cheap motors with iron cores
can be driven with 10-15khz.  Coreless motors need 60-100khz (or just suffer
the high ripple current...) (I am talking about hobby stuff, not big battle
bot or industrial motors...)

Personally, I never use the enable lines anymore.  I aways drive the load. I
have another paper I wrote explaining why (it is pretty high level & moves
fast): www.barello.net/Papers/H-bridge.pdf  Just an FYI: I set up a motor,
H-Bridge and oscilloscope to measure the voltage across the lower FET body
(for current) and was able to demonstrate all the hand drawn charts. They
are really true.

Cheers!
Show quoted textHide quoted text
-----Original Message-----
From: ethan@bufbotics.org [mailto:ethan@bufbotics.org]
Sent: Monday, January 31, 2005 7:34 AM
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] tiny26, motor driver, and ISP



Larry Barello said:
>       Don't use the enable line for PWM input.  Use the complementary PWM
> outputs
>  to drive the A & B side of the H-Bridge and use the enable line to,
> well,
>  enable the driver.
>


Larry,

Thank you for the feedback.  I hadn't thought of using PWM on the A and B
lines.

I'm having a tough time visualizing what'll be happening though.

Here's the mental picture I had of my original "PWM on the Enable Line"
scenario:  I can easily picture what happens when I set A=1 and B=0 for a
motor.  It'll go clockwise.  Similarly, set A=0 and B=1, and I get reverse
(counter clockwise).  And the PWM signal on the Enable line then turns the
motor on for only small snippets of time, as defined by the duty-cycle.
Also in this scenario, I can set A=B and get braking mode.


Now I'm trying to picture Larry's suggestion of using complementary PWM on
A & B lines.  Firstly, I can easily picture the Enable line now.  Its now
used simply for enable/disable, with no "rapid" switching like PWM.  Then
my vision gets cloudy of what's happening on the A & B pins.  My limited
understanding is that pin A will experience an average voltage
proportional to the duty-cycle of the PWM signal.  Pin B will experience
the complementary average voltage.  But what does this actually do for me?
 Doesn't it cause the direction of motor motion to switch really rapidly
(at the PWM frequency)?

I would love it if you would take tht time to explain intuitively what's
happening.

Ethan
www.bufbotics.org






Yahoo! Groups Links

RE: [AVR-Chat] tiny26, motor driver, and ISP

2005-02-01 by ethan@bufbotics.org

Thank you Larry. Those articles give me some good insight.  Now I feel
just confident enough to be a danger to my little robot friend :-)  I
think I'm going to go right in and try Locked Antiphase.  Once I get it
working in my own robot, I may have to ask a few questions since hopefully
by then I'll understand enough to form a lucid question.

I saw in the articles how you described the current consumed at 50%
dutycycle (motor stopped).  Is this ok? Or should the enable pin be
disabled when you want to idle?

One additional question, do you use pull down resistors on any of the
motor driver pins?  My gut is saying to at least pull the enable pins down
(disable) to ensure the robot isn't fidgeting during I/O initialization
and also during the really fast boot time for the tiny26.


You've given me lots of good info today, both on this thread and another
(magic ways to access pin values in C programs).  Thank you.

I'm going to give PWM a try. I've been combing over the ATtiny26 datasheet
all day (picture Spaceballs when they comb the desert) to try to see if I
can get it working on my own.  But, dont be surprised if I fire a few PWM
setup questions to the group :-)

Ethan
www.bufbotics.org

RE: [AVR-Chat] tiny26, motor driver, and ISP

2005-02-01 by Robert Adsett

At 10:05 PM 1/31/05 -0500, ethan@bufbotics.org wrote:
>I saw in the articles how you described the current consumed at 50%
>dutycycle (motor stopped).  Is this ok? Or should the enable pin be
>disabled when you want to idle?


It depends on the motor (the PWM, frequency, the voltage, the ripple 
capacity of your capacitors...).  Generally if the frequency is high enough 
the ripple won't be enough to cause any problems.  Assuming, of course, 
that you can run at that frequency without large switching losses.

You get a couple of advantages running in this mode to offset the ripple 
losses.  The first is that since there is no explicit direction change 
around zero, there is no dead spot as you move from forward to reverse and 
vice versa.  The second is since you are driving the motor at zero rather 
than passively braking it by shorting it you have the potentially of much 
stronger braking around zero.  This second effect compounds on the first so 
that you don't get a fade in torque as you slow to zero and reverse 
directions.  Whether or not these effects are strong enough to notice, like 
the whether the ripple losses are significant, depends on a lot of factors, 
not the least of which is whether torque and control in all four quadrants 
near zero speed is important.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

RE: [AVR-Chat] tiny26, motor driver, and ISP

2005-02-01 by Larry Barello

No, I don't.  In your case, since you are sharing one of the PWM lines with
the programmer, you do want to pull the enable line down while programming.
Show quoted textHide quoted text
-----Original Message-----
From: ethan@bufbotics.org


Thank you Larry. Those articles give me some good insight.  Now I feel
just confident enough to be a danger to my little robot friend :-)  I
think I'm going to go right in and try Locked Antiphase.  Once I get it
working in my own robot, I may have to ask a few questions since hopefully
by then I'll understand enough to form a lucid question.

I saw in the articles how you described the current consumed at 50%
dutycycle (motor stopped).  Is this ok? Or should the enable pin be
disabled when you want to idle?

One additional question, do you use pull down resistors on any of the
motor driver pins?  My gut is saying to at least pull the enable pins down
(disable) to ensure the robot isn't fidgeting during I/O initialization
and also during the really fast boot time for the tiny26.


You've given me lots of good info today, both on this thread and another
(magic ways to access pin values in C programs).  Thank you.

I'm going to give PWM a try. I've been combing over the ATtiny26 datasheet
all day (picture Spaceballs when they comb the desert) to try to see if I
can get it working on my own.  But, dont be surprised if I fire a few PWM
setup questions to the group :-)

Ethan
www.bufbotics.org

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.