Re: Poor man's PWM

From	Hans-Bernhard Bröker <HBBroeker@t-online.de>
Newsgroups	comp.arch.embedded
Subject	Re: Poor man's PWM
Date	2020-01-29 16:34 +0100
Message-ID	<h9dn02Fg7j5U1@mid.dfncis.de> (permalink)
References	<r0o0mu$c6l$1@dont-email.me> <h9as3cFsikkU1@mid.dfncis.de> <r0qvlf$crv$1@dont-email.me>

Show all headers | View raw

Am 29.01.2020 um 04:54 schrieb Don Y:
> Hi Hans-Bernhard,
> 
> On 1/28/2020 6:43 AM, Hans-Bernhard Bröker wrote:
>> Am 28.01.2020 um 01:53 schrieb Don Y:
>>> But, instead of having N different times at which the IRQ
>>> might be signalled (for the N+1 different duty cycles) in
>>> each refresh interval, I plan on having log2(N) times, each
>>> delimiting an period "twice" as long as the previous.  This
>>> keeps the hardware cheaper than dirt 
>>
>> I rather much doubt that.  If there are indeed "few" intensity levels, 
>> i.e. 16 rather than 1024, this approch will at most reduce the overall 
>> software-PWM interrupt rate by a factor of 4;
> 
> Which means the timer can be four times FASTER!

No, it really doesn't.  Reducing the overall interrupt rate is, at most, 
the top of this iceberg.  The aspect that invariably drives CPU speed 
requirements, and thus cost, here is the peak interrupt rate, and your 
proposal doesn't affect that at all: you still have two interrupts to 
serve at 1/(16 * f) for PWM output frequency of f Hertz.

Also, your proposal will actually _increase_ the overall number of 
interrupts* for cases where you have to turn on one LED twice in the cycle.

> Obviously you're not a hardware person.  

Enjoying yourself throwing ad-hominems around, much?

> E.g., with a 10KHz *peak* IRQ rate, you'd have 100us to respond to THAT
> IRQ and get the next data ready -- simply COPYING it from a FIXED
> LOCATION to another FIXED I/O LOCATION -- for the timer to transfer
> to the LED "(hammer) drivers" coincident with the *next* IRQ.

Those 100 us are not the problem.  It's the latency of the interrupt 
routine, and its raw processing time.  The actual time between turning 
on and off that output has to be the same every time round, to within a 
few percents, or the thing will flicker abominablly, particularly at 
duty cycle '1'.  That means interrupt timing (including run-time of the 
handler itself) has to be stable down to a few us.

>> Overall, hardware that can implement this scheme will thus hardly be 
>> any cheaper than hardware that can implement the usual one.

> Really?  How much for 20 PWM channels?  200?  2000?  (I have a 2000 LED
> "moving message" sign at my feet, here -- wanna bet it DOESN'T have
> 2000 PWM channels?  Or, 2000 programmable current sources?)

That puts just as much burden on your scheme as it would on a 
straight-forward one.  Those 100us will appear mighty short if you were 
to do any work involving 2000 independent inputs on a cheap-ish micro.

PWM generation is rightfully delegated to dedicated hardware units, 
whether inside the CPU or outside.  SW is, ultimately, the wrong tool 
for this job.

>> Your plan also destroys any possibilities to distribute those EM 
>> emissions (and power supply loads) more evenly by staggering the PWM 
>> cycles of several LEDs. That aspect becomes more important as the 
>> loads get heavier, of course: 20 mA LEDs are a piece of cake, 20 
>> Ampere heaters not so much.
> 
> They are *indicators*, not *illuminators*.
> 
> I'm going to give you 20 (or 200 or 2000) DEDICATED PWM channels.  How 
> are YOU
> going to stagger theur cycles?  

By distributing their starting points evenly across the base cycle. 
Possibly, in a higher-level routine, keep a watch out for any time slot 
that has higher workload than others, and shift that around.

And at 2000 LEDs, your _are_ talking about quite an illuminator if you 
turn them all on. Avoiding wildly fluctuating loads to the power supply 
does become a factor to consider in that case, particularly if you want 
that supply to stay cheap.

Ultimately one might not need ISRs at all, if just about all that chip 
is going to do is turn on and off LEDs.  It could busy-loop on a 
time-sorted priority queue of switching events instead.

Thread

Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-27 17:53 -0700
  Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-27 19:29 -0800
    Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 20:11 -0700
      Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 20:11 -0800
  Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-28 11:29 +0100
    Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 20:34 -0700
      Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 20:32 -0800
      Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-29 12:53 +0100
  Re: Poor man's PWM Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-28 14:43 +0100
    Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 12:03 -0800
    Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 20:54 -0700
      Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 21:54 -0800
        Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 00:17 -0700
          Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 23:40 -0800
            Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 00:54 -0700
            Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 00:04 -0800
              Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 02:17 -0700
        Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-29 13:21 +0100
          Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-29 09:51 -0800
            Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 10:07 -0800
              Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-29 10:14 -0800
                Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 10:28 -0800
                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-29 11:40 -0800
                Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 10:25 +0100
                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-30 08:06 -0800
                Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 21:21 +0100
                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-30 15:08 -0800
                Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-31 01:17 +0100
                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-30 17:21 -0800
                Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-31 10:59 +0100
                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-02-01 10:18 -0800
            Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 10:20 +0100
              Re: Poor man's PWM Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-01-30 10:13 +0000
          Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 09:57 -0800
            Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 10:29 +0100
      Re: Poor man's PWM Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-29 16:34 +0100
  Re: Poor man's PWM Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-28 17:39 +0200
    Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 19:58 -0700
      Re: Poor man's PWM Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-29 18:54 +0200
  Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 00:17 -0700
    Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-29 13:39 +0100
      Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 10:08 -0800
  Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-04-27 20:13 -0700

csiph-web