Searching \ for '[EE] Clock speed for display multiplexing' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/timers.htm?key=clock
Search entire site for: 'Clock speed for display multiplexing'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Clock speed for display multiplexing'
2008\07\03@212314 by Tomás Ó hÉilidhe

picon face
(I'm trying to understand this as I go along so please cut in with a
simple "Yeah that's right" / "No that's wrong")

My uC is the PIC16F887.

According to the datasheet:
   [  When the clock speed is 20 MHz, the time per instruction is 200
ns  ] (not a verbatim quote)

So if I use the internal oscillator to give me 8 MHz, then the time per
instruction is 500 ns.

On my board I have two display multiplexers that run concurrently, and
they're both managed in software by the 887.

Now what I want to figure out is:
   Is the time per instruction negligible when compared to the time for
which I will keep a single LED lit? If 500 ns is indeed negligible, then
upgrading from 8 MHz to 20 MHz will garner no improvement. So OK I'm
gonna try figure that out now. (Again please cut it with "Yes good" and
"No bad").

When an LED is flashing so quickly that it appears to be solidly lit, I
think there's three factors:
1) How long it's on for
2) How long it's off for
3) How bright it is when it's on

If it's on for 1 microsecond and then off for 2 microseconds, then this
will definitely give the appearance that it's solidly lit. I think you
would describe this as having a "duty cycle" of one third. That right?
(Is "duty cycle" the term that everyone uses for this, and am I using it
right?). Also another thing that has to be taken into account is the
actual absolute length of time for which it is on and also for which it
is off. I mean you could have a duty cycle of 9 tenths but this won't do
you much good if the LED is on for 9 seconds because you'll see the
display go off for a whole second every 10 seconds.

I have two display multiplexers on my board but they're near-identical
so I'll only describe one of them. Here goes:
   * There's 30 different stages, so that means the duty cycle will be
1 thirtieth.

I think the next thing I have to do is decide on the pulse width, i.e.
how long I will keep each LED on for. (Is "pulse width" the term
everyone uses for this, and am I using it right?)

Before I can decide on a maximal pulse width, I think I'll have to
decide on a minimal refresh rate. If my refresh rate is too slow, then
I'll see the display flickering. I know that the minimal refresh rate
for motion picture is about 24 Hz, but I'm presuming this hasn't got
much to do with flashing LED's. Also, I'm guessing that if I have
brighter LED's, that I can get away with a slightly lower refresh rate
(persistence of vision and all that). I really haven't got much of a
clue on what should be my minimal refresh rate, but I'm going to start
off with a guess of 50 Hz because that's roughly twice the refresh rate
of motion picture.

So let's say my minimal refresh rate is 50 Hz. 50 Hz equates to 20
milliseconds per flash of the entire display. So if I've got 20
milliseconds to flash the entire display, and if I've got 30 stages in
the display, then that means I've got a maximum of 666 microseconds for
which to keep each stage lit. (If you see an error in any of my
calculations then please cut in).

Now, in an ideal world, the program for my multiplexer would consist of
the following:
   * Light LED0 for 666 us
   * Light LED1 for 666 us
   * Light LED2 for 666 us
   * Light LED3 for 666 us
   ...
   ...
   * Light LED28 for 666 us
   * Light LED29 for 666 us

Unfortunately though, my program will have to waste a little bit of time
doing some processing to light the LED's. I'm guessing that the code for
handling each LED stage will be about 10 instructions maybe. And since
I've got two display multiplexers, that means 20 instructions.

   20 instructions at 8 MHz    =    20 x 500 ns    =    10 us

So that means the program for my multiplexer will have to become
something like:

   * Do processing for LED0 (take about 10 us)
   * Light LED0 for 656 us
   * Do processing for LED1 (take about 10 us)
   * Light LED1 for 656 us
   * Do processing for LED2 (take about 10 us)
   * Light LED2 for 656 us
   ...
   ...
   * Do processing for LED28 (take about 10 us)
   * Light LED28 for 656 us
   * Do processing for LED29 (take about 10 us)
   * Light LED29 for 656 us

Now... if my calculations are right so far, then that means that each
*individual* LED will be on for 656 us and then off for 19.980 ms. This
gives a duty cycle of 1 in 31.457.

So coming back to the "three factors" that I mentioned earlier:  If my
clock is 8 MHz, that means:
   * Each LED is on for 656 us.
   * Each LED if off for 19.98 ms. (Overall duty cycle is 1 in 31.457)
   * (I haven't figured out what LED's I'm using yet but I'm gonna try
get really bright ones)

Now I want to compare this to a clock speed of 20 MHz. The difference
will be that 20 instructions will take about 4 us instead of 10 us. So
that means:

   * Do processing for LED0 (take about 4 us)
   * Light LED0 for 662 us
   * Do processing for LED1 (take about 4 us)
   * Light LED1 for 662 us
   * Do processing for LED2 (take about 4 us)
   * Light LED2 for 662 us
   ...
   ...
   * Do processing for LED28 (take about 4 us)
   * Light LED28 for 662 us
   * Do processing for LED29 (take about 4 us)
   * Light LED29 for 662 us

This means each LED is on for 662 us and then off for 19.318 ms. This
give a duty cycle of 1 in 30.181. So now my "three factors" are:

   * Each LED is on for 662 us.
   * Each LED is off for 19.318 ms. (Overall duty cycle is 1 in 30.181).
   * (don't know brightness)

So having done these calculations, it seems to me that:
       * If the processing for each LED is about 10 instructions
then:
       * No human being will notice a difference in moving from 8 MHz
to 20 MHz

Do you think this is an accurate assessment?

Also, of course, if I've made any mistakes then please politely point
them out (don't be an Olin about it though). If I seem to misunderstand
anything, or if you'd just like to enlighten me about something, then
please go ahead.

Lastly:  I do electronics as a hobby. I'm not being paid for it, and I'm
not being paid to do this project. I don't post here looking for advice
as if it's a "service"; I post here because I know there'll be helpful
people who'll respond to me just for the joy of it.
   Why am I talking about this? Well there's certain people here, eg.
Olin, that drag the moral down by coming out with quips such as "Don't
expect someone to take a look if they're not being paid". It's
unfortunate that we have such caustic souls among us, but what can you
do. So to clarify: This post is aimed at friendly, helpful people. If
you're not friendly, or if you don't like being helpful just for the
sake of being helpful, then please just don't respond.

2008\07\04@011047 by Tamas Rudnai

face picon face
Hi Tomas,

> This means each LED is on for 662 us and then off for 19.318 ms. This
> give a duty cycle of 1 in 30.181. So now my "three factors" are:
>
>   * Each LED is on for 662 us.
>   * Each LED is off for 19.318 ms. (Overall duty cycle is 1 in 30.181).
>   * (don't know brightness)

I think it's a bit too much of calculations here. If you have 30 LEDs and 1
LED lighted up a time then you should have 1:30, as simple as that.

Anyway, you should design a better way to handle that many LEDs, instead of
one pin by one organise those LEDs into a matrix, for example 6x5 so you can
have 1:5 multiplexing instead. Have you ever seen piclist techref? Over
there I found this article:

http://www.piclist.com/techref/io/led/8x7s8pin.htm

It's about to drive eight 7 segment displays using a single port. The author
multiplexes the displays, not the LEDs individually of course (1:8
multiplexing).

BTW: Just put 3 different LEDs so you will have an idea of brightness etc.
Write a simple firmware that multiplexes those 1:3. Change the frequency.
Find out the lowest frequency it still seems to be constant to your eyes
when you looking at it straight. Now look a bit sideways so you can see
those only in the edge of your vision - you should see the LEDs flickering -
you can do the same trick in shops where they put loads of tellys in a
matrix, you can pick the 100Hz ones very easy this way. Anyway, with this
firmware you can put timings for the "ghost LEDs" so you do not have to
solder 30 LEDs, just put a delay to simulate their time slights.

Sometimes an experiment like this tells you more than thousand words.

Tamas






On Fri, Jul 4, 2008 at 2:22 AM, Tomás Ó hÉilidhe <spam_OUTtoeTakeThisOuTspamlavabit.com> wrote:

{Quote hidden}

>

2008\07\04@013949 by Per Linne

flavicon
face
I regret that you've gotten this all wrong. Mr Olin Lathrop has been
and is one of the most helpful persons on this list. He has, as far
as I know, also designed some very cunning LED driving products.
You should appreciate his highly professional advice.

It is beyond me that you are allowed to go on with these direct
insults, directed to this one person without being warned by
the list administration.

What is it with some of you people!?

PerL


{Original Message removed}

2008\07\04@050653 by Alan B. Pearce

face picon face
>When an LED is flashing so quickly that it appears to be solidly lit,
>I think there's three factors:
>1) How long it's on for
>2) How long it's off for
>3) How bright it is when it's on

Yes you are correct here.

>If it's on for 1 microsecond and then off for 2 microseconds, then
>this will definitely give the appearance that it's solidly lit. I
>think you would describe this as having a "duty cycle" of one third.

Correct again.

>That right? (Is "duty cycle" the term that everyone uses for this,
>and am I using it right?).

I believe so, it is certainly the way I have always used the term.

>Also another thing that has to be taken into account is the actual
>absolute length of time for which it is on and also for which it is
>off. I mean you could have a duty cycle of 9 tenths but this won't do
>you much good if the LED is on for 9 seconds because you'll see the
>display go off for a whole second every 10 seconds.

Correct. However there are some other factors that come into play here,
which I will mention later.

>I have two display multiplexers on my board but they're near-identical
>so I'll only describe one of them. Here goes:
>    * There's 30 different stages, so that means the duty cycle will be
>1 thirtieth.

Yes.

>I think the next thing I have to do is decide on the pulse width, i.e.
>how long I will keep each LED on for. (Is "pulse width" the term
>everyone uses for this, and am I using it right?)

Yes that would be the correct term.

{Quote hidden}

Yes and no. You are correct that one of the first decisions is minimum
refresh rate, but some of your other statements about refresh rate are not
correct. The minimum rate will be around 50/60Hz for any LED.

>So let's say my minimal refresh rate is 50 Hz. ... then that means
I've got a maximum of 666 microseconds for which to keep each stage lit.

Yes but ... If you have this many LEDs with only a single LED on at a time
then the current through each LED needs to be approaching 30 times its
steady state (i.e. non multiplexed) current to get similar perceived
brightness. This will hamper you in other ways, like needing driver
transistors capable of handling much higher currents, extra supply bypassing
to handle the higher switching currents, and this all assumes the LEDs can
handle this high a current. To verify this you need to look at the maximum
pulsed current spec on the LED data sheet, which will also give a maximum
pulse width and duty cycle for this current level.

>Unfortunately though, my program will have to waste a little bit of
>time doing some processing to light the LED's. I'm guessing that the
>code for handling each LED stage will be about 10 instructions maybe.
>And since I've got two display multiplexers, that means 20 instructions.
...

Well, the time isn't really 'wasted' it is doing useful work - assuming you
have culled the code down to the best coding for the function. And just
because you have two LED stages, it doesn't necessarily mean twice the code
to handle them. For example if the LED change is being done in an interrupt
routine, then the entry and exit code for the interrupt is effectively
shared with both sets of LEDs are updated in the same interrupt.

>Now... if my calculations are right so far, then that means that each
>*individual* LED will be on for 656 us and then off for 19.980 ms. This
>gives a duty cycle of 1 in 31.457.

No - the LED is turned off at the same time as the next one is turned on,
you don't turn the on one off at the start of the code and turn the next one
on at the end. In a properly organised interrupt routine the on time will
always be the same for each LED, plus/minus the interrupt latency variation,
with no dead time between the one turning off and the other turning on.

>Now I want to compare this to a clock speed of 20 MHz. The difference
>will be that 20 instructions will take about 4 us instead of 10 us. So
>that means:

No the clock speed of the processor has no effect on the pulse width of the
LED (assuming the timer interrupt is correctly set up for the different
clock speed). All that the clock rate will change is the amount of time the
processor spends in the interrupt routine, and the time from the timer
interrupt to when the LEDs change - but as this is always the same for a
given clock speed the user will not be aware of this.


2008\07\04@051728 by Jinx

face picon face
Tomas, I sincerely believe you've been given enough information
for a week's worth of breadboarding experiments, and there are
enough practical LED strobing examples out on the web to look
at and pull apart. Trying some code with some LEDs will answer
all your questions, and more, as people can help remotely only to
a certain extent

2008\07\04@065826 by olin piclist

face picon face
Tomás Ó hÉilidhe wrote:
> (I'm trying to understand this as I go along so please cut in with a
> simple "Yeah that's right" / "No that's wrong")

Yet *another* thread on the same project.  As various people have already
mentioned, it's hard to follow what is going on since you pop up with a new
thread without anything getting resolved in the old threads.

So where are the results of your LED voltage, current, and brightness tests?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

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