Searching \ for '[PIC] Slow PWM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/ios.htm?key=pwm
Search entire site for: 'Slow PWM'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Slow PWM'
2011\06\21@210238 by Barry Gershenfeld

picon face
I have, what was to be a simple controller, that suddenly got an additional
job of controlling an LED backlight.  Dimming is done via PWM, and the spec
states a max frequency around 250 Hz.  It's a PIC18LF45K22, and seems to be
like the rest of the 18F family.  Hardware PWM runs from a timer--such as
TMR2--with an optional prescale.  If we let the timer run to a full count
(256) and invoke the maximum prescale (16), then at 8 MHz we get a period of
488 Hz.  If I drop the clock down to 4 MHz that puts us under the 250 Hz max
requirement.  But now I'm running at 4MHz on a processor that can go as high
as 64 (it has a PLL inside).   Now, a typical processor that reads
pushbuttons, blinks lights, and occasionally sequences some power supplies
probably doesn't need to run faster than 4MHz.  But it's also going to be an
i2c slave, and it would be nice to have some extra speed when handling i2c
commands.

It may or may not turn out to be that important, but I wanted to explore the
options when it comes to generating low-rate PWM.  I'm always surprised at
how limited the dividers are with this.  If there's anything that would be
easy to do inside the chip, it would be to divide some slow clocks down to
even slower clocks.  So, here are the options I came up with.

1. PWM hardware, CPU at 4 MHz, and live with it.
2. PWM in software.  The can work at really low PWM rates, but if you put
125 steps into a 250 Hz signal you now need a precision of 32 microseconds,
and if any latency stretches your pulses, that really shows up, especially
at low brightness.
3. Fix the Windows driver that was supposed to do the PWM in the first
place. Definitely out of my area :)
4. Go on the PICList and find out I missed something and that it really can
go slower.  They do keep adding features to these things.
5. Cascade two timers somehow.  Some seem to have external inputs, but not
sure I see any outputs.  Maybe someone's been through this before.  I can't
do it this time because the boards are already being made, and the pins are
used up

2011\06\21@215448 by Brent Brown

picon face
On 21 Jun 2011 at 18:02, Barry Gershenfeld wrote:
> I have, what was to be a simple controller, that suddenly got an additional
> job of controlling an LED backlight.  Dimming is done via PWM, and the spec
> states a max frequency around 250 Hz.

Wondering what factor(s) dictate the max spec of 250Hz? A minimum spec would be important to minimise flicker. Even so LED flicker can be noticeable well above 250Hz in some conditions. If there is no good reason why not then higher freq would be better and your problem goes away.

-- Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz

2011\06\21@215750 by IVP

face picon face
> 2. PWM in software

Barry, I have a PIC running at 40MHz that puts out 6-bit PWM
from 100Hz to 279Hz

http://www.piclist.com/techref/microchip/HV_PWM_Proto.htm

Both frequency and duty cycle are pot-controlled

There is plenty of spare processing power and could be expanded
to 7-bit or faster/slower speeds

One pot sets the reload value for TMR0, the other sets the ratio
of 'off' and 'on'

Jo

2011\06\22@003109 by RussellMc

face picon face
> Barry, I have a PIC running at 40MHz that puts out 6-bit PWM
> from 100Hz to 279Hz
>
> http://www.piclist.com/techref/microchip/HV_PWM_Proto.htm

I'd suspect that somebody confused what was meant by max and min along
the way. It seems more likely that somebody wanted a non-flicker spec.
Also, they are liable to have been thinking in terms of PWM frame rate
rather than smallest bit rate - and this may have been set
empirically. At  250 Hz you are 5 x 50 Hz PAL TV interlaced frame rate
which is ~~ flicker free on typical pictures. 25 Hz (true frame rate)
is too low for most people.

Joe's hardware solution is sure to be better than the following, but:

Software PWM using an IRQ timer is trivially easy.
Upper limit depends on IRQ frequency and PWM resolution.
Lower frequency is essentially unlimited.
You can run multiple PWMs with mini al extra code size and RAM for an
extra counter or compare register per PWM.

For naive implementation code is little more than:

On_IRQ
 increment counter ; with rollover to zero
 if counter = 0 then set all PWM output bits high.
 for all channels
    if counter >= channel_value set relevant PWM bit low.


2011\06\22@014841 by IVP

face picon face
> LED flicker can be noticeable well above 250Hz in some conditions

I've got LED displays refreshed at 300Hz and that they aren't
static is obvious if you move your head or roll your eyes. Refresh
at higher frequency would still be noticeable as LEDs have no
persistence

Jo

2011\06\22@020819 by IVP

face picon face
> At  250 Hz you are 5 x 50 Hz PAL TV interlaced frame rate
> which is ~~ flicker free on typical pictures. 25 Hz (true frame
> rate) is too low for most people.

Even so, there's still flicker. The moths got into a bag of oats in
the larder and bred. We had a plague of them for a few days
and their wings were strobed as they flew in front of the TV (a
traditional phosphor screen). Interesting to see them apparently
float when in fact they were flapping like mad

7-segment latches would be flicker-free

eg 4543

http://home.clear.net.nz/pages/joecolquitt/counter.gif

Jo

2011\06\22@032242 by Brent Brown

picon face
> > LED flicker can be noticeable well above 250Hz in some conditions
>
> I've got LED displays refreshed at 300Hz and that they aren't
> static is obvious if you move your head or roll your eyes. Refresh
> at higher frequency would still be noticeable as LEDs have no
> persistence

Likewise I've done 4 digit x 7 seg LED muxed displays at about 3 kHz (3kHz/4 digits = 750Hz) and the effect is still there.

I've wondered about white LED's which I think use a phosphor (could be wrong there) ~ does anyone know if that adds any measureable/useful amount of persistence? So far I haven't seen any spec on this in datasheets.

-- Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  .....brent.brownKILLspamspam@spam@clear.net.nz

2011\06\22@034402 by Michael Watterson

face picon face
On 22/06/2011 02:02, Barry Gershenfeld wrote:
> It may or may not turn out to be that important, but I wanted to explore the
> options when it comes to generating low-rate PWM.  I'm always surprised at
> how limited the dividers are with this.  If there's anything that would be
> easy to do inside the chip, it would be to divide some slow clocks down to
> even slower clocks.  So, here are the options I came up with.

Do it in SW with a software counter driven by timer interrupt. You only need PWM HW for higher speeds. You then can be as slow as you like.

I tend to have one timer ISR for whatever needs most frequent attention and then a bunch of software counters for less frequent tasks. These can set a flag read by main "do forever" loop if the response time isn't critical. The main loop must reset the flag

2011\06\22@043551 by alan.b.pearce

face picon face
> The moths got into a bag of oats in the larder and bred.

Sure it wasn't your wallet Joe ??? ;))))
-- Scanned by iCritical.

2011\06\22@050820 by IVP

face picon face
>> The moths got into a bag of oats in the larder and bred.
>
> Sure it wasn't your wallet Joe ??? ;))))

Well, they could've got in when I opened it that one time ...........

Shouted the whole bar a drink

"Half a shandy and 2 dozen straws please. And I'll have the
straws when you're finished so don't go chewing the ends"

Tight ? Moi

2011\06\22@050934 by RussellMc

face picon face
> I've wondered about white LED's which I think use a phosphor (could be wrong
> there) ~ does anyone know if that adds any measureable/useful amount of
> persistence? So far I haven't seen any spec on this in datasheets.

The large majority of White LEDs use blue LED and yellow phosphor.
BUT the phosphor response time is extremely fast.
<<  1 uS range which is well above what is useful here.

R

_________________

Relevant comment here.
Bottom of page.
     http://cr4.globalspec.com/thread/64849/White-LED-with-Shortest-Response-Time



Just to put a number on it, it's easy to push LED response down into
the 40ns territory, but I experienced frustration trying to get them
to turn off faster than 20ns. This was true even when strongly
reversing the current within under 5ns.

Below 20ns it becomes a matter of finding the right LED. I've seen
claims of results down to a few ns, but they didn't report what part
they were using. I tried many parts and wavelengths, etc., without
success. It's like the proverbial fish that got away.

But laser diodes, OTOH, are very fast. They're happy to respond in
under 1ns, so it becomes a matter of the driving electronics and fast
low-impedance wiring, etc. But it might be painful trying to create an
apparent white light with multiple laser diodes of different
wavelengths. They also naturally make beams rather than flooded light,
greatly restricting their applicability for ordinary lighting.

White LEDs are often driven with dc-dc converters to control the
current. The voltage step-up types, which can drive several 3V LEDs in
series, are especially convenient. But most of these are fairly slow.
One exception is TI's TPS61166 (link), which can turn the LED on or
off in well under 1us.

TI's motivation for such a fast response time is to insure a linear
light-level vs PWM duty cycle, e.g., down to the 1% region, even with
high PWM frequencies like 40kHz. For example, 1% of a 40kHz 25us
period is 0.25us, so they would benefit from a response time faster
than that. Although their boost-converter runs at 1.2MHz, this is not
fast enough for the desired switching rate, so the TPS61166 adds an
additional series FET switch to drive the stack of LEDs.

You can add an external MOSFET to an ordinary boost converter, to
obtain the same fast result as TI's part. It doesn't appear that
distributors are stocking the TPS61166, so that may be the best
approach

2011\06\22@110728 by Denny Esterline

picon face
>
> For naive implementation code is little more than:
>
> On_IRQ
>  increment counter ; with rollover to zero
>  if counter = 0 then set all PWM output bits high.
>  for all channels
>     if counter >= channel_value set relevant PWM bit low.
>
>
>        R
>

Not just to argue with Russel (I couldn't compete in volume alone :-) but
I've seen lots of people implement soft PWM with this type of scheme, and
it's always seemed... I was going to say "stupid" but perhaps "silly" is a
better choice, though political correctness may force me to temper that to
"less than optimum".

With this scheme you have a _ton_ of interrupts. 8 bit resolution gets you
256 interrupts per PWM cycle - which obviously limits the upper frequency
and burdens the processor for other tasks. I've always preferred a variable
timer reload approach:

On_IRQ
If (state_variable)
 Set Pin on
 load timer with "on time"
 state_variable = !state_variable
else
 Set Pin off
 load timer with (period time - on time)
 state_variable = !state_variable


Obviously that's only a skeleton with some parts "left as an exercise for
the student". With this approach you only have two interrupts per PWM cycle,
so obviously much lower overhead. Granted it does require a dedicated timer,
but I've never found that to be too much of a bother.

And this approach scales very well for some applications. Hobby RC servo
control for example. I have one application controlling more than a dozen of
them with the same timer.

-Denn

2011\06\22@114555 by Michael Watterson

face picon face
On 22/06/2011 16:07, Denny Esterline wrote:
> I've seen lots of people implement soft PWM with this type of scheme, and
> it's always seemed... I was going to say "stupid" but perhaps "silly" is a
> better choice, though political correctness may force me to temper that to
> "less than optimum".
>
> With this scheme you have a_ton_  of interrupts. 8 bit resolution gets you
> 256 interrupts per PWM cycle - which obviously limits the upper frequency
> and burdens the processor for other tasks. I've always preferred a variable
> timer reload approach:

Not if you are doing something else that needs the fixed rate higher speed interrupt. Which is common. Like a Multiplexed LED display or ADC or Frequency counter or simple DSP

Your proposal is a useful alternate scheme.

it's also advantageous to have only one interrupt. But that's another story

2011\06\22@145234 by Sergey Dryga

flavicon
face
Barry Gershenfeld <gbarry42 <at> gmail.com> writes:

>
> I have, what was to be a simple controller, that suddenly got an additional
> job of controlling an LED backlight.  Dimming is done via PWM, and the spec
> states a max frequency around 250 Hz.  It's a PIC18LF45K22, and seems to be

You can use TMR2/4/6 with postscaler to generate interrupts.  Load PRx register
with value for pulse or blank.  This will generate only 2 interrupts per cycle. Another way is to use CCP module with 16-bit registers (page 182 of the
datasheet), this will give you a better resolution by avoiding post-scaler. In
the special event IRQ load correct values for the duration of pulse or blank.  
Sergey Dryga
http://beaglerobotics.com



2011\06\22@210904 by Barry Gershenfeld

picon face
On Tue, Jun 21, 2011 at 6:53 PM, Brent Brown <brent.brownspamKILLspamclear.net.nz>wrote:

>
> Wondering what factor(s) dictate the max spec of 250Hz? A minimum spec
> would
> be important to minimise flicker. Even so LED flicker can be noticeable
> well above
> 250Hz in some conditions. If there is no good reason why not then higher
> freq
> would be better and your problem goes away.
>

I know that no text can ever be aligned properly, but here's a cut/paste
from the data sheet.
Parameter        Symbol  Min.  Typ.    Max.    Unit
PWM frequency  fPWM  200  300     400        Hz

I have to follow the spec, lest some PICLister rise up and smite me for
straying beyond the ratings.
Also to ensure it works.


On Tue, Jun 21, 2011 at 6:57 PM, IVP <.....joecolquittKILLspamspam.....clear.net.nz> wrote:

> > 2. PWM in software
>
> Barry, I have a PIC running at 40MHz that puts out 6-bit PWM
> from 100Hz to 279Hz
>
> There is plenty of spare processing power and could be expanded
> to 7-bit or faster/slower speeds
>

I'm not certain what I was looking at there, or how you determine that the
output would be sufficiently stable to not be seen in my specific
application....but what you did remind me is, that if I dump the hardware
PWM idea, I can go back to higher processor speeds and most of these
software methods ought to work out fine.

BTW, I, too, have made pulse generators out of junked LCD+PIC boards we have
kicking around here.  After watching them rent omigosh-priced function
generators to do things like make tones and simulate buttons being pushed, I
went and made my own.  That's how I confirmed what the lower frequency limit
was--I could try it.  Never could come up with an easy power supply for
them, though.  Until now.  I have abandoned my purist
USB-is-not-a-power-supply views and joined the ranks of the lowlife laptop
fan and light-em-up-plug-in-sushi makers, and now I hang surplus USB cords
on everything I want to power.

Also wonder how you got from "Jinx" to "IVP".



On Tue, Jun 21, 2011 at 9:30 PM, RussellMc <EraseMEapptechnzspam_OUTspamTakeThisOuTgmail.com> wrote:

>
> On_IRQ
>  increment counter ; with rollover to zero
>  if counter = 0 then set all PWM output bits high.
>  for all channels
>     if counter >= channel_value set relevant PWM bit low.
>

Looks suspiciously like a software rendering of the PIC PWM peripheral.  Or
a good explanation of same to anyone who hasn't grasped how the Microchip
one works.  I did do something like this some years ago on a PIC12C671 for a
fan, where the rep rate was 10 Hz.  But even if there was any jitter in the
pulse width, the fan would have hidden it completely.   Today's adventure
involves a light source, the human eye, and that irascible brain that's
attached to it.



On Tue, Jun 21, 2011 at 10:48 PM, IVP <joecolquittspamspam_OUTclear.net.nz> wrote:

>
> I've got LED displays refreshed at 300Hz and that they aren't
> static is obvious if you move your head or roll your eyes.
>

Along with those danged automobile tail lights.


[Here the topic strays off into speculation about persistence times for
LED's possible phosphors, psycho-visual effects, and, of course, wallet
moths.  Until...]

On Wed, Jun 22, 2011 at 8:07 AM, Denny Esterline <@spam@desterlineKILLspamspamgmail.com>wrote:

{Quote hidden}

This is another interesting idea that I would probably try if given enough
time--which, it seems, I'm not.  I've always been a bit concerned with
reloading timers and accounting for the extra time before the program gets
to the load-timer part.  Exacerbated by the fact that I write the firmware
using a certain language whose name is a single letter that occurs early in
the alphabet.


On Wed, Jun 22, 2011 at 8:45 AM, Michael Watterson <KILLspammikeKILLspamspamradioway.org>wrote:

>
> Not if you are doing something else that needs the fixed rate higher
> speed interrupt. Which is common. Like a Multiplexed LED display or ADC
> or Frequency counter or simple DSP
>

That's true.  I've always had a 1ms interrupt running and used it to signal
everything else when to run.  But a maybe best-case need for a 50 us
interrupt might be a bit much for the poor thing.  I may have to look at
Denny's suggestion after all.


On Wed, Jun 22, 2011 at 11:52 AM, Sergey Dryga <RemoveMEsergeyTakeThisOuTspamdryga.us> wrote:

{Quote hidden}

Haven't grokked this entirely but a read through the timers section once
again will probably explain this.  I like the apparent "hack" to get a
16-bit timer.

I appreciate the thought you guys have put into this.

Barr

2011\06\22@211649 by Xiaofan Chen

face picon face
On Wed, Jun 22, 2011 at 11:07 PM, Denny Esterline <spamBeGonedesterlinespamBeGonespamgmail.com> wrote:
> Not just to argue with Russel (I couldn't compete in volume alone) :-)

Nice one.

Of course the meaning of "volume" here is interesting. He must think
very fast, type very fast and his command of English is really good.


-- Xiaofa

2011\06\22@213306 by Xiaofan Chen

face picon face
On Thu, Jun 23, 2011 at 9:09 AM, Barry Gershenfeld <TakeThisOuTgbarry42EraseMEspamspam_OUTgmail.com> wrote:
> BTW, I, too, have made pulse generators out of junked LCD+PIC boards we have
> kicking around here.  After watching them rent omigosh-priced function
> generators to do things like make tones and simulate buttons being pushed, I
> went and made my own.  That's how I confirmed what the lower frequency limit
> was--I could try it.  Never could come up with an easy power supply for
> them, though.  Until now.  I have abandoned my purist
> USB-is-not-a-power-supply views and joined the ranks of the lowlife laptop
> fan and light-em-up-plug-in-sushi makers, and now I hang surplus USB cords
> on everything I want to power.
>

USB can be a power supply and it can be a power supply complies to USB-IF
standards if you can spend a bit of money.

Check the USB Charging Specification here.
http://www.usb.org/developers/devclass_docs


-- Xiaofan

2011\06\22@214744 by Brent Brown

picon face
> > Wondering what factor(s) dictate the max spec of 250Hz? A minimum spec
> > would
> > be important to minimise flicker. Even so LED flicker can be noticeable
> > well above
> > 250Hz in some conditions. If there is no good reason why not then higher
> > freq
> > would be better and your problem goes away.
> >
>
> I know that no text can ever be aligned properly, but here's a cut/paste
> from the data sheet.
> Parameter        Symbol  Min.  Typ.    Max.    Unit
> PWM frequency  fPWM  200  300     400        Hz
That is curious. I still can't think of a good reason why there should be a maximum spec. Maybe higher freq square wave backlight current couples more easily into LCD controller chip and causes problems. Or perhaps the LCD module has built in PWM control of the LED backlight, maybe to effect constant current operation so you don't need to add external series resistor, or there may even be a command so you can control LED current? If so, very cool.

-- Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  RemoveMEbrent.brownspamTakeThisOuTclear.net.nz

2011\06\22@215308 by IVP

face picon face
> I'm not certain what I was looking at there

Generally to show that a PIC can appear to be very busy yet still have
spare time on its hands. Would there be any noticeable difference if
you went 5-bit instead of 7-bit ? Or even 4-bit ? As far as a dimmer
goes I'm not sure there would be

High speed isn't necessarily needed for I2C because it's firmware-
driven, unlike the UART, so all you have to do is pick up the SSPIF
and process the data, which could be done within the dimming interrupts,
which my circuit showed an example of (pot values -> LCD)

> or how you determine that the output would be sufficiently stable to
> not be seen in my specific application

Stability isn't really the issue with LEDs, it's the lack of persistence
when dynamically driven. The odd momentary disturbance, eg delaying
a refresh by a few 10s of usec, would probably not be visible

Do you know how or why this range came about ?

> PWM frequency  fPWM  200  300     400        Hz

One scenario I can imagine is that at high-speed PWM, high-current
pulses are needed to maintain the same relative brightness as would be
had at slower or static drive, which can lead to heating of the LED die
and reduce lifetime. Seems a tenuous scenario though

> Also wonder how you got from "Jinx" to "IVP".

'Jinx' was a bit of an in-joke in a group of friends. No matter what
I got involved in, it failed. Which led to quite some soul-searching. I
decided it wasn't my efforts, it was the lack of everybody else's. And
I still think that

The joke wore thin so I dropped it. Not that it's made the slightest
bit of difference ;-(((( Still hand-to-mouth. Yet to be associated with
even one moderately-successful ongoing product, much to my great
disappointment. However, I am looking at on-line trading, maybe
that'll pan out, under the name 'inventerprises

2011\06\23@020556 by RussellMc

face picon face
>> On_IRQ
>>  increment counter ; with rollover to zero
>>  if counter = 0 then set all PWM output bits high.
>>  for all channels
>>     if counter >= channel_value set relevant PWM bit low.

> I've seen lots of people implement soft PWM with this type of scheme, and
> it's always seemed... I was going to say "stupid" but perhaps "silly" is a
> better choice, though political correctness may force me to temper that to
> "less than optimum".

> With this scheme you have a _ton_ of interrupts. 8 bit resolution gets you
> 256 interrupts per PWM cycle - which obviously limits the upper frequency
> and burdens the processor for other tasks. I've always preferred a variable
> timer reload approach:

Definitely true for many values of "'stupid". But not all. I think :-)
[NB - I have NO problem with "seems stupid" in that context (or almost
any other :-))
Sufficient to the morrow be the evil thereof ... . If we can kill
stupid before the morrow it never happened, so :

I assume that all the following is obvious and trivial but it may
promote some relevant discussion:

If you have a fastish timer tick and spare processing capacity (and
you seem to easily be able to handle both in your scenario) then you
can handle all sorts of useful things this way.
Not only as many timers as you want but in-program delays anywhere and
almost everywhere you want (set register to N, test on subsequent
loops and ignore until zero, reload when / if required ) and more. A
super simple transparentish Mickey Mouse* non pre-emptive , better be
cooperative or else RTOS [tm] that takes literally a few lines of code
to get going. Presumably many people do almost exactly this.
..
I thought about adding complexity or comment in the pseudo code and
decided not to.
"Delays" can be handled by DSNZ, INC  in the IRQ routine (or DNZ if
you have it)(or code equivalent).  A background client simply loads a
value and the IRQ routine progressively zeros it. IRQ overhead is one
DSNZ and one INC (or one DNZ) per delay. PWM is almost the same.

At say 4 bit resolution and 400 Hz the slowest IRQ period is 1/(2^4 x
400) = 156 uS
For 6 bit resolution it's ~= 40 uS and for 8 bit it's ~ 10 uS.
Once upon a time a 10 uS (9.765625 ...) timer IRQ would have been
unthinkable and even now it's not a zero load, but system overhead for
an empty IRQ routine can be a few percent of  total time. This may be
very bearable. Using only 6 bit resolution drops you down to around 1%
+/- depending on how fast a clock you are using and on a system where
you the processor is  twiddling its  thumbs (ARM not implied) it can
be a really useful powerful tool.

More stupid :-) :

Blinky LED. Sure.  Turn off power after xxx to peripheral Y? sure -
load a register and if it ever goes to zero kneecap the power.
Somewhere else in the system if a client routine wants the power kept
on it will reload the register. etc. Emergency power down (non
sequenced) - kill the timer and it triggers the routine next time
through the loop without the code ever talking directly. (Complexity
and implications and timer boundary condition handling and
who-has-the-"token" issues left as an exercise for the student).

The background routine can shuffle cooperatively through their tasks
at a rate that is completely independent of the IRQ rate. You can
easily add relative prioritization of background tasks by group etc.
eg Delay 1 is set to 50 counts. Delay 2 is set to 500 counts ( > 8 bit
timer in this example and often in reality.) Say IRQ is 20 uS.
Call all P0 tasks in order. These execute round-robin with the
expectation that they will never sum to > (here) 1 mS in total
processor demand.
If Delay 2 expired call P2 tasks and reset Delay 2. Note that you may
want to check P0 tasks before you call P2's. Note that if you want
isochronousish P0 behaviour (eg UART sampling)  the the two timers may
need to be interlocked etc etc .
If Delay 3 expired call all P3 tasks and reset Delay 3. (Same caveats but worse)

Obviously, if total possible period taken by P2 tasks exceeds maximum
allowed latency of P1 tasks then some interleaving or other mechanism
is required. eg bit flags or whatever.
Computed COMEFROM  ? :-)

Part of my brain was about to launch into  comments on task
partitioning and interleaving and handoff mechanisms to not exceed
desired worst case latency in a non-preemptive better-be-cooperative
adhoc multitasking mess.  But, what say I stop at saying that once you
have a general purpose timer tick with IRQ driven timers, you get
easily implemented with a few bytes per decision point  task control
and it can work rather well.

The above rather assumes but is not limited to assembler. If working
in a HLL you'd want the IRQ routines manually checked if not assembler
coded. Lots of room for doing non-ideal things there.

Again, presumably many people do variations of the above, but as it is
an outgrowth of the 'stupid' approach, I mention it.


..
     Russell

* I understand that in some cultures "Mickey Mouse" means "pretty
good". That's not so here :-).

2011\06\23@205313 by Barry Gershenfeld

picon face
This must be where Denny and Xiaofan were referring to "volume" :)

Well, without trying to quote the gist of what you said, and at the risk of
leaving
out certain details, I'll say that a lot of what you said is how I write my
firmware.

The 1ms interrupt does nothing except set flags corresponding to intervals
of
10ms, 100ms, and 1 second.  Down in the main loop, functions are called when
the associated flag tests true.  It's very simple, it's very neat, and
main() remains
very small.  You can disable entire functionality by commenting out that
function.
Actually, I name those things "services".  They are things like "read the
buttons",
"read the temperatures", "manage the blinky lights", "see if the serial
interrupt has
collected something with a carriage return on the end of it",  etc.

It is very much as you describe:

A
> super simple transparentish Mickey Mouse* non pre-emptive , better be
> cooperative or else RTOS [tm] that takes literally a few lines of code
> to get going. Presumably many people do almost exactly this.
>

If I want a 50 ms task, I don't even bother to create a 50ms event, I just
call it every 10ms and have it execute every 5th time.

The "better be cooperative" part is spot-on, and the time that a task gets
to run can be pushed around a bit, but as long as you follow the "spare
processing capacity" method, each task will run every n milliseconds;
even if it's plus or minus some, the aggregate rate will be as promised.
This won't work for signal sampling, of course, but it works for nearly
everything else.

For all this simplicity, there's just not much to worry about besides making
sure two tasks aren't trying to write their own answers to a common variable
and stuff like that.  Modern "college boy" schemes, such as threading, can
be useful but seem to carry a lot of overhead with complexity, gotchas; and
a lot of code I see usually manages to disable just about all the features
so
that they don't get into trouble.

Exec summary. Yes. It's being done.  Works well.  In C, even.

Leaving out details, fast timers, and things regarding a PWM backlight.
Separate
message to follow.

BG

Keep reading, below.

On Wed, Jun 22, 2011 at 11:05 PM, RussellMc <apptechnzEraseMEspam.....gmail.com> wrote:

>
> * I understand that in some cultures "Mickey Mouse" means "pretty
> good". That's not so here :-).


* In the USA you will get a cease & desist letter, or at best be required
to attribute the trademark to "its respective company".  A memorable
news bit from Saturday Night Live (TV show) went like this:

"George Lucas told the Reagan administration to stop using 'Star Wars' to
describe its Strategic Defense Initiative"
"In a related story, Disney told the US Postal Service to stop using 'Mickey
Mouse' to describe its mail system.

2011\06\23@205929 by Barry Gershenfeld

picon face
On Wed, Jun 22, 2011 at 6:47 PM, Brent Brown <EraseMEbrent.brownspamclear.net.nz>wrote:

> > I know that no text can ever be aligned properly, but here's a cut/paste
> > from the data sheet.
> > Parameter        Symbol  Min.  Typ.    Max.    Unit
> > PWM frequency  fPWM  200  300     400        Hz
>
> That is curious. I still can't think of a good reason why there should be a
> maximum
> spec.
>

Me neither.  And it may just be sloppy specsmanship.  "Ah, just tell 'em a
couple hundred hertz.  No one needs to go faster than that, anyway."  But
that gives me the choice of assuming I know more than they do, and risking
having some problem occur later on.  Not this time.

As to conjectures about the dimming PWM, there are two factors I see that
have to be kept in mind. One is that this product may be used at night, and
the user may want to make the screen very dim.  So, while it seems to make
sense that I don't really need 7 or 8 bits of resolution across the full
brightness range, I may well need to run at 1% duty at the dim end, somehow..


Factor number two is that 1% at 200 Hz is 50us, and if I introduce a 10us
disturbance into that pulse, it's wrong by 20%, and that will be visible as
a flicker.

I like the idea of the timers being used for the high and low portion of the
cycle.  I even believe that it may be less important to keep the frequency
exact, as long as the "on" duty time doesn't jump around.  That's relevant
because I'm concerned about reloading the timers to account for variable
software overhead

2011\06\23@212308 by Kerry Wentworth

flavicon
face
Barry Gershenfeld wrote:
> As to conjectures about the dimming PWM, there are two factors I see that
> have to be kept in mind. One is that this product may be used at night, and
> the user may want to make the screen very dim.  So, while it seems to make
> sense that I don't really need 7 or 8 bits of resolution across the full
> brightness range, I may well need to run at 1% duty at the dim end, somehow.
>
>
> Factor number two is that 1% at 200 Hz is 50us, and if I introduce a 10us
> disturbance into that pulse, it's wrong by 20%, and that will be visible as
> a flicker.
>
> I like the idea of the timers being used for the high and low portion of the
> cycle.  I even believe that it may be less important to keep the frequency
> exact, as long as the "on" duty time doesn't jump around.  That's relevant
> because I'm concerned about reloading the timers to account for variable
> software overhead.
>   You could set up a 10mS interrupt interval, and in the interrupt set up a CCP to turn off the backlight after an appropriate delay.

PWM=750;
int_rtcc()
{
   turn on backlight;
   set CCP to turn off backlight in PWMuS;
}

Kerry

2011\06\23@215258 by IVP

face picon face

> Factor number two is that 1% at 200 Hz is 50us

I'd suggest 50us would be very very dim indeed and I really do
doubt the occassional few usec disturbance would be discernible

After all, it's 4950us until the next 'on' refresh, so the "20%" error
isn't part of the 'on' pulse. The disturbance could well be in the 'off'
time. If I were doing it, and the s/w has noted a delay is in effect,
then you might have something like

pulse - 4960us - pulse - 4940us - pulse

where the s/w compensates for the 10us delay by shortening the
next interval by 40us. The overall error is 0.2% in the position of
the pulse within the 5000us period. Assuming only 1 LED is lit
that is ; you'd take off processing time for selecting and lighting
each additional LED

As this is all being done under interrupt, there shouldn't be any
noticeable delay anyway with a fast processor. 40MHz is a cycle
time of 100ns, 500 instructions per 50us

Easy to test with a single LED

Jo

2011\06\23@220056 by IVP

face picon face

> Factor number two is that 1% at 200 Hz is 50us

I'd suggest 50us would be very very dim indeed and I really do
doubt the occassional few usec disturbance would be discernible.

After all, it's 4950us until the next 'on' refresh, so the "20%" error
isn't part of the 'on' pulse. The disturbance could well be in the 'off'
time. If I were doing it, and the s/w has noted a delay is in effect,
then you might have something like

pulse - 4960us - pulse - 4940us - pulse

where the s/w compensates for the 10us delay by shortening the
next interval by 10us (if the timing has that resolution). The overall
error is 0.2% in the position of the pulse within the 5000us period.
Assuming only 1 LED is lit that is ; you'd take off processing time
for selecting and lighting each additional LED

Even if the resolution is 50us that's still only a 1% shift in position

However, to notice this displacement, you'd need to be looking at
the display, in which case you'd have to factor in the eye's persistence
of vision - at that dimness and at 200Hz

As this is all being done under interrupt, there shouldn't be any
noticeable delay anyway with a fast processor. 40MHz is a cycle
time of 100ns, 500 instructions per 50us

Easy to test with a single LED of equal brightness

Jo

2011\06\23@235240 by RussellMc

face picon face
> However, to notice this displacement, you'd need to be looking at
> the display, in which case you'd have to factor in the eye's persistence
> of vision - at that dimness and at 200Hz

"The dark adapted eye can see a single photon" :-).

FWIW while that is true almost by definition, it's misleading.
Can and will are <> at that level.
While you can safely say "you will be able to see an LED operated at 1
mA" and only have pedants disagree, the single photon is hit and miss
where hit < to << miss.
ie it has to strike a receptor and the receptor has to fire (as is
their job to do when struck with single photons) and you brain has to
be attuned to what you are looking for.

All that said, it's a stunningly amazing capability. Which may or may
not have high relevance to seeing 50 uS LED pulses at 1% duty cycle.

________________

Short:

If it's a typical small LCD backlight then the use of a PWM derived DC
driven display with a linear pass element and current sensing  seems
dandy.
If it's a 100 W backlight  this may produce excessive heat.

Go on volume up:

If hardware choice were free (which may be) and pins plentiful and
power budget irrelevant you could do a two stage dim. Stage on is say
4 bits and is filtered to DC. Stage two is say 4 more bits off the
first DC level. 8 bits with 2 x 4 bit slowwwwwwwwwwwwwwww PWM
channels. 8 bit equivalent. More or less. See below re display
response to decreasing DC levels.

Or, while the spec says stupidlow <= PWM freq <= stupidhigh  or
whatever, do they actually say what the engineer has to or may do with
the PWM twixt PWM pin and LED? If not then filtering to ~~~ DC would
remove aforementioned spurious effects. Note that LED response to DC
filtered PWM is very very much not the same as to the PWM source.
However, sufficient unto the software is the functionality thereof.

If you can make your feedback work on LED current rather than PWM %
(which is trivially easy if they let you add an opamp and a
transistor)(sense resistor current matches DC filtered PWM level) then
you are back to linear response with DC drive.

Looking back now at spec door after the solution has bolted the above
seems to match items 5 and 4 of your spec and power level was not
mentioned (if eye/brain are cooperating). If it's a 100 W backlight
this may produce excessive heat. If it's a typical small LCD backlight
then the use of a PWM derived DC driven display with a linear pass
element  and current sensing  seems dandy.



           Russel

2011\06\24@011812 by Jesse Lackey

flavicon
face
I missed the description of the LED backlight, if any, but if there is a dc/dc involved (say a boost to run several white LEDs in series constant-current), then that dc/dc is being PWMed to control dimming, and it very well could have a low max PWM frequency.

J

Brent Brown wrote:
> On 21 Jun 2011 at 18:02, Barry Gershenfeld wrote:
>> I have, what was to be a simple controller, that suddenly got an additional
>> job of controlling an LED backlight.  Dimming is done via PWM, and the spec
>> states a max frequency around 250 Hz.
>
> Wondering what factor(s) dictate the max spec of 250Hz? A minimum spec would
> be important to minimise flicker. Even so LED flicker can be noticeable well above
> 250Hz in some conditions. If there is no good reason why not then higher freq
> would be better and your problem goes away.

2011\06\24@095738 by C H

picon face
Jesse Lackey wrote:
> I missed the description of the LED backlight, if any, but if there is a
> dc/dc involved (say a boost to run several white LEDs in series
> constant-current), then that dc/dc is being PWMed to control dimming,
> and it very well could have a low max PWM frequency.
>

"constant-current" means there is a resistor in the feedback loop. You
can place, say, 4 resistors and switch them accordingly using your
PIC

2011\06\24@171700 by Barry Gershenfeld

picon face
The backlight appears to be just some LED's, controlled by two switches.
One, turns the light off.  The other, well, turns the light off...one's
called a shutdown line and the other is the PWM line.   Allowable voltage is
"5 min, 7.4 typ., and 20.0 max."  125 mA at 7v and 240 mA at 20.  If anyone
really wants to pick it apart, they can find LQ050W1LA0A on Sharp's site and
get the data sheet.

Just keep in mind that the hardware design isn't going to change.  Not on
this cycle, anyhow.


On Thu, Jun 23, 2011 at 6:21 PM, Kerry Wentworth <
RemoveMEkwentworthEraseMEspamEraseMEskunkworksnh.com> wrote:

>
> You could set up a 10mS interrupt interval, and in the interrupt set up
> a CCP to turn off the backlight after an appropriate delay.


I didn't see the point of this initially; now I do.  The idea of doing the
"on" period in hardware is
attractive.  If the timer/CCP really can reset the pin like that.  Some more
reading of
the CCP section to follow

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...