Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29142
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Poor man's PWM |
| Date | 2020-01-28 20:11 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <r0qt5s$1th$1@dont-email.me> (permalink) |
| References | <r0o0mu$c6l$1@dont-email.me> <15be1d5b-30cf-4ff1-85a7-cfa2f1de546f@googlegroups.com> |
Hi Rick,
On 1/27/2020 8:29 PM, Rick C wrote:
> On Monday, January 27, 2020 at 7:53:54 PM UTC-5, Don Y wrote:
>> Then, at the level above the driver, build a schedule for which intervals
>> to activate the LED.
>
> What controls the IRQ period? I assume each IRQ will modify a hardware
> timer in the CPU?
The timer will either be a "spare" internal timer or something like an
SOIC8 -- whose *sole* purpose will be to output a set of edges at the
desired interval spacings (amusing to think of "wasting" an entire
MCU just for such a banal task!) The "main" processor can synchronize
to this signal by detecting the longest such interval wrt its internal
"system timebase".
> The "list" items you describe are just bits in the value you wish to specify
> the duty cycle. An 8 bit byte will give you 255 brightness levels with 8
> different period interrupts. A nybble gives 15 brightness levels with 4
> periods. Each bit in the value determines if the LED is off or on during
> the corresponding IRQ. A simple bit mask shifted with each IRQ can be anded
> with each LED value to indicate if that LED should be on during that IRQ.
> When the bit mask reaches zero, start over with the longest IRQ and highest
> order bit mask.
N.B. You always have the "off" intensity available so
8b yields 25_6_ levels, etc.
However, as the number of levels increases, the period
of the shortest inevitably decreases. This has direct
consequences on the *peak* IRQ rate -- which, in turn,
has implications on maximum tolerable latency (and
complexity of the ISR itself). Double-buffering the
outputs (see my reply to Dimiter) eases the timeliness
constraints on the ISR (e.g., 100us at 10KHz)
[Note that there is nothing that forces the periods to
be multiples of 2; that's just the easiest way to
describe this approach. I could, instead, pick intervals
of 2, 3 and 4 to yield duty cycles of {0, 22, 33, 44,
55, 67, 78, 100}%. Or, 2, 2 and 2 to yield {0, 33,
a different 33, yet another 33, 67, a different 67,
yet another 67, 100}%]
Consider, also, you want an implementation that scales
to more than a single LED. So, doing that work *in* the
ISR quickly becomes the bottleneck. Hence "scheduling"
the ISR's actions in the background (as a non-time-critical
activity)
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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