Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29138
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Poor man's PWM |
| Date | 2020-01-28 14:43 +0100 |
| Message-ID | <h9as3cFsikkU1@mid.dfncis.de> (permalink) |
| References | <r0o0mu$c6l$1@dont-email.me> |
Am 28.01.2020 um 01:53 schrieb Don Y: > With "few" intensity levels desired, I plan to drive LED > with a crude PWM signal directly from an IRQ (i.e., push > bits out a hardware port at each IRQ). > > 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; and the hardware still has to be capable of handling each of those interrupts fast enough, consistently, that you there will be no flickering caused by the shortest possible time slot being prolonged or shortened by delays in interrupt processing. This puts a load on the overall design that this scheme cannot reduce. Overall, hardware that can implement this scheme will thus hardly be any cheaper than hardware that can implement the usual one. > Then, at the level above the driver, build a schedule for which > intervals to activate the LED. Building this schedule doesn't actually come for free, either. > What problems might I encounter with this approach? (I'm > mainly worrying about visual artifacts) The most obvious one, which would earn me a stern veto from the HW department at may outfit, is an increase in the overall number of LED switching edges, increasing, among other things, EM emissions. 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.
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