bit-banging pwm considerations

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There seems to be two ways to do your own pwm generation, and I was
wondering if anyone had any comments on the suitability of them in various
situations.

To simplify things, let's suppose the duty cycle is represented as a value
between 0 and 256. Also, each pwm channel will have a counter, c, which holds
a non-negative integer. The pwm update routine will be executed at some
frequency f. The update routines for each method is as follows:

Method 1: Increment c by 1 on each pwm cycle. If c < d, set the output for the
channel to 1; otherwise set it to 0.

Method 2: Increment c by d. If c >= 256, set the output to 1; otherwise set it
to 0. Reduce c modulo 256.

Is there any reason to choose one method over the other? How about if you're
driving LEDs vs. a motor?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Method 1 is PWM, yeah. I have experimented with that, I think it was 8-channel software PWM on one 8-bit port.

Method 2 is actually called PPM, so technically it is not PWM. So if you are driving LED:s, that is fine, but a R/C servo will not like that, because it requires all the 1's and 0's to be continuous. A DC motor with a H bridge, I don't see why it would not work, but certainly 50%PPM has higher frequency than 50%PWM.

Actually method 2 would be used better to use this way: if you just increment C by D, and if the new C is smaller than old C, you set the output to one, else zero. This is because you can't check an 8-bit variable to be >=256.

Another method of converting 2 to PWM is that you increase C by D, and if C has it's MSB on, then the output is 1. If MSB=off, output=off too.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
as a value between 0 and 256.

0..255?

Why not use the hardware PWM? It needs no processing time and is the more reliable and jitterfree solution.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, software PWM is good for applications that can tolerate it. For example, this is an easy way to dim 16 leds or something like that, which cannot be done with hardware PWM, unless some external hardware is made to support that (like a latch or shift register with PWM connected to OE, but then all the LEDs have same brightness).

Even when I drove some R/C servos with hardware PWM, the servos jittered all the time, even if the PWM value was stable, so I think with those servos, I could have used software PWM too.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well, software PWM is good for applications that can tolerate it. For example, this is an easy way to dim 16 leds or something like that, which cannot be done with hardware PWM, unless some external hardware is made to support that (like a latch or shift register with PWM connected to OE, but then all the LEDs have same brightness).
I agree.

Quote:
Even when I drove some R/C servos with hardware PWM, the servos jittered all the time, even if the PWM value was stable, so I think with those servos, I could have used software PWM too.
I don´t think the jitter improves by using software_PWM, does it?

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MegaUSBFreak wrote:
Quote:
as a value between 0 and 256.

0..255?

It's 256 because the way I've described the algorithm a full on state requires d = 256 (for both methods).

Also, Jani - thanks for the negative check tip. I don't think I need to worry about performance, but if I did I'd probably write the routine is assembly so I could take advantage of things like the carry flag. OTOH, being able to represent the full on state in one byte is an attractive idea.

MegaUSBFreak wrote:

Why not use the hardware PWM? It needs no processing time and is the more reliable and jitterfree solution.

The reason is I'm interested in implementing a lot of PWM channels.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For lamp dimming, 16 levels is ok, and 70hz rep rate prevents flicker, so you could interrupt at 70x16 times a sec (1100 times a sec), and turn on every channel at that level. At interrupt 16 turn all channels off that arent on full, ready for next dimming cycle.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you plan to use LEDs, you might want to consider making the pwm steps non-linear. I once made 16 pwm channels in an AVR, and quickly learned that an exponential relation was much more suitable for LEDs. But not for normal lightbulbs, motors or most other stuff.
Making exponential software pwm does complicate things a bit, but it is by no means impossible. If you want to have a look at my 16-channel, 256 step, 100 Hz pwm project, just go here:
http://www.ejberg.dk/ledfade2/index.html

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Making exponential software pwm does complicate things a bit
Even if you have precalculated values in a table and then just read the values?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Even if you have precalculated values in a table and then just read the values?

That's why I said it only complicated it a bit.

Another thing entirely is interrupt load minimizing. Having 256 levels, but only 16 outputs, means that at most 16 of the 256 timer interrupts actually do something useful. So 240 interrupts can be ignored, so why waste time on them in the first place? I calculate which interrupts are needed, and then only arm those in the timer. Now THAT complicate things more than just a bit :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

svuppe - thanks for the tip on driving leds.

Another thing I picked up someplace is that initially setting the counters to evenly dispersed values within 0..256 (or whatever range you're using) helps to even out the power demand.