Drivings LED with limited pins

[Bill Sloman]

On Wednesday, 12 March 2014 19:25:08 UTC+11, Jasen Betts wrote:

On 2014-03-12, Bill Sloman <bill.sloman@gmail.com> wrote:
On Wednesday, 12 March 2014 15:35:10 UTC+11, Robert Baer wrote:
Mike Miller wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

Clue: using N pins, one has available 2^N states.
So all you need to use is 5 pins to control those 23 devices, leaving
9 unused states.

You need 5 pins to be able to select any one of these devices. Selection - on its own - isn't quite what the OP is asking for. He wants to "toggle" the LEDs.

Admittedly, just selecting any one LED could serve to "toggle" it between "on" and "off" but since you don't know how they started up (or got reprogrammed by a recent lightning strike) this isn't all that useful. Using one of the nine spare states as a global reset - to turn them all off - would get around that problem. Adding a sixth pin - so you could set the selected LED explicitly "on" or "off" - would make life easier.

you could use one of the spare states to reset all the bits,
and have another spare state near that state for resting.

I just said that "Using one of the nine spare states as a global reset - to turn them all off"

> And then you have a mess of asynchronous logic to handle this...

It doesn't have to be asynchronous. There's nothing to stop you from inspecting the states of the inputs at every rising (or falling) clock edge, and ignoring them for the rest of the time. You probably need to read up on "de-bouncing" switches.

toggling any led then becomes an excursion through hamming space to toggle
the led and then a return through the same hamming space back to the rest
state to un-toggle all the leds you hit on the way to the target.

Which is why most people go for clocked state machines.

It'd make a good programming exercise but little else.
The shift register approach is to be preferred, IIRC there are some
led drivers that can control 30 leds from 2 input pins.

Some of them have been listed in this thread. Some of us have tried to buy them from time to time and tend to prefer more general purpose parts that are likely to stay available for longer.

The shift register approach certainly uses up fewer pins.

--
Bill Sloman, Sydney

 

[Jasen Betts]

On 2014-03-12, Bill Sloman <bill.sloman@gmail.com> wrote:

On Wednesday, 12 March 2014 15:35:10 UTC+11, Robert Baer wrote:
Mike Miller wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

-Mike

Clue: using N pins, one has available 2^N states.
So all you need to use is 5 pins to control those 23 devices, leaving
9 unused states.

You need 5 pins to be able to select any one of these devices. Selection - on its own - isn't quite what the OP is asking for. He wants to "toggle" the LEDs.

Admittedly, just selecting any one LED could serve to "toggle" it between "on" and "off" but since you don't know how they started up (or got reprogrammed by a recent lightning strike) this isn't all that useful. Using one of the nine spare states as global reset - to turn them all off - would get around that problem. Adding a sixth pin - so you could set the selected LED explicitly "on" or "off" - would make life easier.

you could use one of the spare states to reset all the bits,
and have another spare state near that state for resting.

And then you have a mess of asynchronous logic to handle this...

toggling any led then becomes an excursion through hamming space to toggle
the led and then a return through the same hamming space back to the rest
state to un-toggle all the leds you hit on the way to the target.

It'd make a good programming excercise but little else.

the shift register approach is to be preferred, IIRC there are some
led drivers that can control 30 leds from 2 input pins.

--
Neither the pheasant plucker, nor the pheasant plucker's son.


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[John Devereux]

Bill Sloman <bill.sloman@gmail.com> writes:

On Wednesday, 12 March 2014 19:25:08 UTC+11, Jasen Betts wrote:
On 2014-03-12, Bill Sloman <bill.sloman@gmail.com> wrote:
On Wednesday, 12 March 2014 15:35:10 UTC+11, Robert Baer wrote:
Mike Miller wrote:

I want to be able to toggle 23 separate LEDs in my application.
The design challenge is that I only have about 17 pins
available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with
some digital interface (spi/i2c) and then send over data to
toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

Clue: using N pins, one has available 2^N states.
So all you need to use is 5 pins to control those 23 devices, leaving
9 unused states.

You need 5 pins to be able to select any one of these
devices. Selection - on its own - isn't quite what the OP is
asking for. He wants to "toggle" the LEDs.

Admittedly, just selecting any one LED could serve to "toggle" it
between "on" and "off" but since you don't know how they started
up (or got reprogrammed by a recent lightning strike) this isn't
all that useful. Using one of the nine spare states as a global
reset - to turn them all off - would get around that
problem. Adding a sixth pin - so you could set the selected LED
explicitly "on" or "off" - would make life easier.

you could use one of the spare states to reset all the bits,
and have another spare state near that state for resting.

I just said that "Using one of the nine spare states as a global reset - to turn them all off"

And then you have a mess of asynchronous logic to handle this...

It doesn't have to be asynchronous. There's nothing to stop you from
inspecting the states of the inputs at every rising (or falling) clock
edge, and ignoring them for the rest of the time. You probably need to
read up on "de-bouncing" switches.

toggling any led then becomes an excursion through hamming space to toggle
the led and then a return through the same hamming space back to the rest
state to un-toggle all the leds you hit on the way to the target.

Which is why most people go for clocked state machines.

It'd make a good programming exercise but little else.
The shift register approach is to be preferred, IIRC there are some
led drivers that can control 30 leds from 2 input pins.

Some of them have been listed in this thread. Some of us have tried to
buy them from time to time and tend to prefer more general purpose
parts that are likely to stay available for longer.

Oh yes, there is (misos?) MAX7219 for example.

The shift register approach certainly uses up fewer pins.

--

John Devereux

 

[whit3rd]

On Tuesday, March 11, 2014 7:09:00 AM UTC-7, Peter Heitzer wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

A simple solution might be three 74LS138 chips. No multiplexing needed.

That won´t work without some sort of multiplexing as the `138 can only
drive one out of eight a time. 74x259 instead of 74x138 would work.

Yes, the 74HC259 addressable latch can solve this problem easily (more easily than
the 'shift register' approach, which will have transient current through LEDs that
you wanted dark).

There are also I/O expander chips that are intended for such tasks: PCF8574 will give you
bidirectional latched I/O, eight bits at a time, for I2C bus. XRA1405 does sixteen bits
at a time, for SPI bus.

 

[Lasse Langwadt Christense]

Den onsdag den 12. marts 2014 20.07.38 UTC+1 skrev whit3rd:

On Tuesday, March 11, 2014 7:09:00 AM UTC-7, Peter Heitzer wrote:



I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.



A simple solution might be three 74LS138 chips. No multiplexing needed..



That won´t work without some sort of multiplexing as the `138 can only

drive one out of eight a time. 74x259 instead of 74x138 would work.



Yes, the 74HC259 addressable latch can solve this problem easily (more easily than

the 'shift register' approach, which will have transient current through LEDs that

you wanted dark).

not if you use something like a 74HC595

There are also I/O expander chips that are intended for such tasks: PCF8574 will give you

bidirectional latched I/O, eight bits at a time, for I2C bus. XRA1405 does sixteen bits

at a time, for SPI bus.

then you might as well use something like:

http://www.digikey.com/product-detail/en/IS31FL3726-QFLS2-TR/706-1218-1-ND/4286441


-Lasse

 

[Lasse Langwadt Christense]

Den onsdag den 12. marts 2014 20.52.14 UTC+1 skrev Dennis:

On 03/12/2014 02:41 PM, Jan Panteltje wrote:

On a sunny day (Wed, 12 Mar 2014 12:50:32 -0500) it happened Frnak McKenney

frnak@far.from.the.madding.crowd.com> wrote in

FYednU9K2M71A73OnZ2dnUVZ_uudnZ2d@earthlink.com>:



-1m - WHITE

http://www.adafruit.com/products/1376



Enjoy...



I like this one, as i tcan (the ysay?) be driven by Raspberry"

http://www.adafruit.com/products/306



Still a bit expensive to hang 32 strips on the wall as wallpaper...



Jan,



Those strips reportedly use the LPD8806 driver rather than the WS2812.

Are you familiar enough at this point with the LPD8806 to say what it

is about those that's better -- for the R'Pi -- than the WS2812?



No, I have not used this chip, but they say this here:

http://www.adafruit.com/products/1376

qoute

example code for using with the Arduino Uno/Mega microcontroller at 8MHz and 16MHz,

but it will not work with the Raspberry Pi, Basic Stamp, NETduino,

any other interpreted/virtual machine microprocessor or any processor slower than 8 MHz.

For those processors, check our 32 LED/meter digital LED strip which has SPI-like input/output

and works well with Pi, NETduino, and other processors.

end quote

So I looked up that [other] strip, it seems to be about timing, that strip is SPI and not critical like the

arduino only one it seems.





I've skimmed this:



Topic: Individually addressable RGB LED comparison?

http://digistump.com/board/index.php?topic=991.0



but I guess I don't know enough about the R-Pi's pin I/O to know why

-- as the AdaFruit notes indicate -- the WS2812 isn't R'Pi material.



If it is timing, and the Raspi runs Linux, there will be several ms long interruptions due to task switching.

There is however also risc-os for raspberry, I tried it, it runs, but have no clue how to use it,

so I used that SDcard for something else, but that risc-os should not have the taskswitch problem ? Not sure.

I do not think speed is an issure with Raspi.





In things like the Rasberry Pi, Beaglebone, and the others that run

Linux the pin I/O is via a file system. The allocate, open, read/write,

close for a pin make it an order of magnitude slower (real time) than

direct hardware access as in the Arduino.

I'm not expert on linux, but can't you just memmap the gpio registers and
hammer away if you like ?

but the access speed doesn't help when the OS interrupts at random times

if you could prevent it from switching task while you burst out an update I think you could drive a string of WS2812

-Lasse

 

[Frnak McKenney]

On Tue, 11 Mar 2014 19:40:33 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Tue, 11 Mar 2014 12:51:59 -0500) it happened Frnak McKenney
frnak@far.from.the.madding.crowd.com> wrote in
ysidnaiUAJ-i0ILOnZ2dnUVZ_u-dnZ2d@earthlink.com>:

On Tue, 11 Mar 2014 07:21:43 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
On a sunny day (Mon, 10 Mar 2014 15:34:48 -0700 (PDT)) it happened Mike Miller
mikemillernow@gmail.com> wrote in
613c339a-c651-415e-a46c-03c46223c937@googlegroups.com>:

All,

I want to be able to toggle 23 separate LEDs in my application. The
design challenge is that I only have about 17 pins available on my
SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some
digital interface (spi/i2c) and then send over data to toggle
the appropriate pins?

2.) Ideally I don't want to have to do additional firmware
development on a second microcontroller.

Thank you for any ideas.

OK no problem, 32 LEDs:

https://www.sparkfun.com/products/retired/10312

These are the same idea (LED drivers with built-in shift registers),
but alive and well. People have reported driving 1000 LEDs from 3
pins with a fast uC. I have some, but haven't had a chance to use
them yet:

The Magic of NeoPixels
http://learn.adafruit.com/adafruit-neopixel-uberguide

$8 - Breadboard-friendly RGB Smart NeoPixel - Pack of 4
http://www.adafruit.com/products/1312

$17 - Adafruit NeoPixel Digital RGB LED Weatherproof Strip 30 LED
-1m - WHITE
http://www.adafruit.com/products/1376

Enjoy...

I like this one, as i tcan (the ysay?) be driven by Raspberry"
http://www.adafruit.com/products/306

Still a bit expensive to hang 32 strips on the wall as wallpaper...

Jan,

Those strips reportedly use the LPD8806 driver rather than the WS2812.
Are you familiar enough at this point with the LPD8806 to say what it
is about those that's better -- for the R'Pi -- than the WS2812?

I've skimmed this:

Topic: Individually addressable RGB LED comparison?
http://digistump.com/board/index.php?topic=991.0

but I guess I don't know enough about the R-Pi's pin I/O to know why
-- as the AdaFruit notes indicate -- the WS2812 isn't R'Pi material.


Frank
--
...n the nineteenth century, reading novels was criticized for
exactly the same reasons for which watching television is criticized
today. -- Paul Cantor / The Invisible Hand in Popular Culture
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

 

[Jan Panteltje]

On a sunny day (Wed, 12 Mar 2014 12:50:32 -0500) it happened Frnak McKenney
<frnak@far.from.the.madding.crowd.com> wrote in
<FYednU9K2M71A73OnZ2dnUVZ_uudnZ2d@earthlink.com>:

-1m - WHITE
http://www.adafruit.com/products/1376

Enjoy...

I like this one, as i tcan (the ysay?) be driven by Raspberry"
http://www.adafruit.com/products/306

Still a bit expensive to hang 32 strips on the wall as wallpaper...

Jan,

Those strips reportedly use the LPD8806 driver rather than the WS2812.
Are you familiar enough at this point with the LPD8806 to say what it
is about those that's better -- for the R'Pi -- than the WS2812?

No, I have not used this chip, but they say this here:
http://www.adafruit.com/products/1376
<qoute>
example code for using with the Arduino Uno/Mega microcontroller at 8MHz and 16MHz,
but it will not work with the Raspberry Pi, Basic Stamp, NETduino,
any other interpreted/virtual machine microprocessor or any processor slower than 8 MHz.
For those processors, check our 32 LED/meter digital LED strip which has SPI-like input/output
and works well with Pi, NETduino, and other processors.
<end quote>
So I looked up that [other] strip, it seems to be about timing, that strip is SPI and not critical like the
arduino only one it seems.

I've skimmed this:

Topic: Individually addressable RGB LED comparison?
http://digistump.com/board/index.php?topic=991.0

but I guess I don't know enough about the R-Pi's pin I/O to know why
-- as the AdaFruit notes indicate -- the WS2812 isn't R'Pi material.

If it is timing, and the Raspi runs Linux, there will be several ms long interruptions due to task switching.
There is however also risc-os for raspberry, I tried it, it runs, but have no clue how to use it,
so I used that SDcard for something else, but that risc-os should not have the taskswitch problem ? Not sure.
I do not think speed is an issure with Raspi.

 

[Dennis]

On 03/12/2014 02:41 PM, Jan Panteltje wrote:

On a sunny day (Wed, 12 Mar 2014 12:50:32 -0500) it happened Frnak McKenney
frnak@far.from.the.madding.crowd.com> wrote in
FYednU9K2M71A73OnZ2dnUVZ_uudnZ2d@earthlink.com>:

-1m - WHITE
http://www.adafruit.com/products/1376

Enjoy...

I like this one, as i tcan (the ysay?) be driven by Raspberry"
http://www.adafruit.com/products/306

Still a bit expensive to hang 32 strips on the wall as wallpaper...

Jan,

Those strips reportedly use the LPD8806 driver rather than the WS2812.
Are you familiar enough at this point with the LPD8806 to say what it
is about those that's better -- for the R'Pi -- than the WS2812?

No, I have not used this chip, but they say this here:
http://www.adafruit.com/products/1376
qoute
example code for using with the Arduino Uno/Mega microcontroller at 8MHz and 16MHz,
but it will not work with the Raspberry Pi, Basic Stamp, NETduino,
any other interpreted/virtual machine microprocessor or any processor slower than 8 MHz.
For those processors, check our 32 LED/meter digital LED strip which has SPI-like input/output
and works well with Pi, NETduino, and other processors.
end quote
So I looked up that [other] strip, it seems to be about timing, that strip is SPI and not critical like the
arduino only one it seems.


I've skimmed this:

Topic: Individually addressable RGB LED comparison?
http://digistump.com/board/index.php?topic=991.0

but I guess I don't know enough about the R-Pi's pin I/O to know why
-- as the AdaFruit notes indicate -- the WS2812 isn't R'Pi material.

If it is timing, and the Raspi runs Linux, there will be several ms long interruptions due to task switching.
There is however also risc-os for raspberry, I tried it, it runs, but have no clue how to use it,
so I used that SDcard for something else, but that risc-os should not have the taskswitch problem ? Not sure.
I do not think speed is an issure with Raspi.

In things like the Rasberry Pi, Beaglebone, and the others that run
Linux the pin I/O is via a file system. The allocate, open, read/write,
close for a pin make it an order of magnitude slower (real time) than
direct hardware access as in the Arduino.

 

[Bill Sloman]

On Thursday, 13 March 2014 09:24:09 UTC+11, John Fields wrote:

On Tue, 11 Mar 2014 20:56:42 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> wrote:
On Wednesday, 12 March 2014 12:27:17 UTC+11, John Fields wrote:
On Tue, 11 Mar 2014 11:24:51 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> wrote:
On Wednesday, 12 March 2014 00:16:30 UTC+11, John Fields wrote:
On Mon, 10 Mar 2014 16:15:27 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> wrote:
On Tuesday, 11 March 2014 09:36:41 UTC+11, John Larkin wrote:
On Mon, 10 Mar 2014 15:34:48 -0700 (PDT), Mike Miller
mikemillernow@gmail.com> wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

Multiplex them (14 pins), or use a shift register (3 pins.)

The simplest sort of multiplexer would only be able to turn one LED on at any one time (a opposed to toggling any one of 23) but it would only use 10 lines for a 5x5 matrix. You'd connect the anode pins of groups of five LEDs together to a common current-limiting resistor, and connect each of the five resistors back to five PNP open collectors, any one of which (but only one) could be turned on to connect to - say - +5V.

Similarly the cathode pins of groups of five LEDs (one from each of the five different anode groups) would be connected together to one of five common NPN collectors, any one of which (but only one) could be turned on to connect to the 0V rail.

What you haven't touched on is that for apparently equal brightness,
the current through any LED in the array must be at least 23 times
that for an identical LED run static.

True. But obvious. I was talking about using the multiplexed approach to turn on one LED out of the 23, rather than potentially turning on all 23 in sequence.

Yes, of course, but regardless of what you do using TDM, you'll
never get away from the need to increase the current through the
driven LED over its static value in order to elicit that static
brightness dynamically.

If you could get away with only turning on one LED at time, it wouldn't be a problem.

Not true.

It's precisely because of the nature of TDM that the problem exists
in the first place.

If you can get away with turning on only one LED at a time, you aren't time domain multiplexing - or not at least in the way the TDM is conventionally understood.

You can leave your single LED turned on for longer than the flicker fusion period, and you wouldn't want to put more than 20mA through it.

You should have realised that I was mainly objecting to John Larkin's "14 pins" for the multiplexed approach.

Your squabbles with Larkin are of little import to me since what I
was addressing were the inadequacies of TDM for the purpose at hand.

Which I dealt with by suggesting that that scheme wasn't all that attractive if you wanted more than one LED on at one time.

For a 20mA LED, then, that comes to some 460mA at about a 5% duty
cycle; a no-no, I believe.

Only if you want to run the 20mA LED at it's maximum brightness. In many cases a LED can be an adequate indicator at 5% of maximum brightness, and - at least for some LEDs - the limit on pulsed peak current can be higher than the limit on the sustained current. I once used a LED as a stroboscope, at it's pulsed current limit of 80mA. It wasn't very bright, but it was bright enough.

Exactly the strategy used with TDM but, unfortunately, as the number
of LEDs in the array increases, the peak current allowed through the
LEDs reaches a limit even though the apparent brightness may be
unsatisfactory.

But it may not.

That's to be decided once the inadequacies of the system are
identified and suitable compromises made to work around them, if
desired.

In this case, with a single shift register capable of driving the
LEDs to their continuous If spec, touting the use of TDM seems
ill-advised.

Since I wasn't touting it - quite the reverse, if anything - this is being censorious about something that I wasn't saying. Your imperfect comprehension of complex sentences has let you down again.

Also, assuming a 5V supply, 2V LEDs, and two 0.3V Vce(sat) drops for
the row and column drivers leaves 2.4V to be dropped across the
current limiting resistor with 460mA through it.

The 460mA assumes that you need the maximum permissible current through the LED to make it visible.

No, the 460mA assumes that in a muxed array with a 1/23 duty cycle,
the muxed LED will appear to be as bright as an LED rated for 20mA
and excited by a constant current of 20mA.

I don't know what misapprehension you thought that were correcting there,

Hmmm... More's the pity, since it's all there in black and white.

Actually it's all in your unfortunate misunderstanding of what has been posted.

Seems like your grasp of the obvious isn't so remarkable after
all...

While your failure to grasp the obvious point that you are barking up the wrong tree is as obvious as ever.

but you do seem to have missed the point that the 20ma
is the maximum sustained current that you can put through the LED
rather than any kind of recommended operating current.

Not true.

Most - if not all - data sheets list the "absolute maximum" forward
current as the current the LED can sustain for a prolonged period
without damage, and also give the nominal forward current for a
given output, generally under "electrical characteristics" or some
such.

So what? You aren't under any obligation to run it that bright, and for lots of LEDs that brightness is uncomfortably high if the LED is being used an indicator. If it's being used as an illumination source it does make sense to run it at the maximum permissilbe current, but the OP was talking about indicator LEDs, not illuminating LEDs.

There's also a maximum pulse current rating given with the duty
cycle limitations specified.

Many LEDs are a bit too bright when run at their maximum sustained current.

Bob and weave, Mr. Sloman, bob and weave.

Educating you may look like bobbing a weaving to you - but to the rest of us it looks rather more like trying to put food into the mouth of a restless baby.

And it's Dr. Sloman to you.

http://cat.lib.unimelb.edu.au/search~S30?/XA+W+Sloman&SORT=D&searchscope=30/XA+W+Sloman&SORT=D&searchscope=30&SUBKEY=A+W+Sloman/1%2C27%2C27%2CB/frameset&FF=XA+W+Sloman&SORT=D&searchscope=30&1%2C1%2C

The eye's response is logarithmic, not linear and 2ma is often all you
need, particularly with "high brightness" LED's.

Weasel words.

Don't be silly. What I said is inarguably correct, and entirely relevant.. the only weaseling going on here is your mindless enthusiasm for discovering stuff to carp about.

Well, when someone makes fishy statements, what else would you
expect?

Your judgement of what is "fishy", like your reading comprehension, is somewhat less than reliable.

"All you need" doesn't destroy the underpinnings of my argument,

Since you haven't made any kind of argument in the first place, this may even be true.

Existence doesn't wink out because of the "beholder's" blinders.

You put your blinkers on exhibition with somewhat excessive enthusiasm. If you weren't so insistent about telling us that you can't parse complex sentences reliably, we'd probably never have known.

and the eye's response is logarithmic only when the source is
monochromatic, CW, and only the luminosity varies

Don't be any stupider than you have to be.

Ad hominem.

You flatter yourself. Your sentence comprehension is distinctly sub-human.
More seriously you are making a point that depends on your personal misreading of stuff I posted. Pointing out that you - as an individual - have made the same mistake here as you have made in the past, of reading something into a posted text that isn't actually there, is necessarily ad hominem. You made the mistake that I am reacting to.

With a pulsed source, all bets are off unless the luminosity, duty
cycle, and pulse repetition frequency are known.

Twaddle. The eye integrates the photons hitting it. The integration period - search on "flicker fusion frequency" - can be anything from 200msec in dim light to about 15msec in bright light. There are only three different light-absorbing pigments in the eye, so it's all rather simpler than you seem to think.

The link you refer is only concerned with fusion frequency as a
function of several variables; not with the amplitude response of
the eye as a function of source brightness.

Really?

Got a link to prove me wrong?

I don't need to prove you wrong - you do it yourself far too often to make it necessary for me to produce a formal proof of error.

When rational discourse can only lead to disaster, ad hominem seems
to be the course you plot.

As I said, you flatter yourself.

You might educate yourself by reading this link.

http://en.wikipedia.org/wiki/Flicker_fusion_threshold

Thank you.

Quite enlightening, but rather irrelevant.

Then clearly not enlightening enough.

--
Bill Sloman, Sydney

 

[Bill Sloman]

On Thursday, 13 March 2014 10:42:00 UTC+11, Robert Baer wrote:

Bill Sloman wrote:
On Wednesday, 12 March 2014 15:35:10 UTC+11, Robert Baer wrote:
Mike Miller wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

-Mike

Clue: using N pins, one has available 2^N states.
So all you need to use is 5 pins to control those 23 devices, leaving
9 unused states.

You need 5 pins to be able to select any one of these devices. Selection - on its own - isn't quite what the OP is asking for. He wants to "toggle" the LEDs.

Admittedly, just selecting any one LED could serve to "toggle" it between "on" and "off" but since you don't know how they started up (or got reprogrammed by a recent lightning strike) this isn't all that useful. Using one of the nine spare states as global reset - to turn them all off - would get around that problem. Adding a sixth pin - so you could set the selected LED explicitly "on" or "off" - would make life easier.

I leave it to the student to fill in the details.

Which usually means that the instructor hasn't thought about the details.

The instructor has thought of all of the details, including
multiplexing states for an "always on" appearance instead of any combo
being always "static" or latched.
Then again, all of it is trivial...

Instructors do say that. Few believe them.

--
Bill Sloman, Sydney

 

[John Fields]

On Tue, 11 Mar 2014 20:56:42 -0700 (PDT), Bill Sloman
<bill.sloman@gmail.com> wrote:

On Wednesday, 12 March 2014 12:27:17 UTC+11, John Fields wrote:
On Tue, 11 Mar 2014 11:24:51 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> wrote:
On Wednesday, 12 March 2014 00:16:30 UTC+11, John Fields wrote:
On Mon, 10 Mar 2014 16:15:27 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> wrote:
On Tuesday, 11 March 2014 09:36:41 UTC+11, John Larkin wrote:
On Mon, 10 Mar 2014 15:34:48 -0700 (PDT), Mike Miller
mikemillernow@gmail.com> wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

Multiplex them (14 pins), or use a shift register (3 pins.)

The simplest sort of multiplexer would only be able to turn one LED on at any one time (a opposed to toggling any one of 23) but it would only use 10 lines for a 5x5 matrix. You'd connect the anode pins of groups of five LEDs together to a common current-limiting resistor, and connect each of the five resistors back to five PNP open collectors, any one of which (but only one) could be turned on to connect to - say - +5V.

Similarly the cathode pins of groups of five LEDs (one from each of the five different anode groups) would be connected together to one of five common NPN collectors, any one of which (but only one) could be turned on to connect to the 0V rail.

What you haven't touched on is that for apparently equal brightness,
the current through any LED in the array must be at least 23 times
that for an identical LED run static.

True. But obvious. I was talking about using the multiplexed approach to turn on one LED out of the 23, rather than potentially turning on all 23 in sequence.

Yes, of course, but regardless of what you do using TDM, you'll
never get away from the need to increase the current through the
driven LED over its static value in order to elicit that static
brightness dynamically.

If you could get away with only turning on one LED at time, it wouldn't be a problem.

---
Not true.
It's precisely because of the nature of TDM that the problem exists
in the first place.
---

>You should have realised that I was mainly objecting to John Larkin's "14 pins" for the multiplexed approach.

---
Your squabbles with Larkin are of little import to me since what I
was addressing were the inadequacies of TDM for the purpose at hand.
---

For a 20mA LED, then, that comes to some 460mA at about a 5% duty
cycle; a no-no, I believe.

Only if you want to run the 20mA LED at it's maximum brightness. In many cases a LED can be an adequate indicator at 5% of maximum brightness, and - at least for some LEDs - the limit on pulsed peak current can be higher than the limit on the sustained current. I once used a LED as a stroboscope, at it's pulsed current limit of 80mA. It wasn't very bright, but it was bright enough.

Exactly the strategy used with TDM but, unfortunately, as the number
of LEDs in the array increases, the peak current allowed through the
LEDs reaches a limit even though the apparent brightness may be
unsatisfactory.

But it may not.

---
That's to be decided once the inadequacies of the system are
identified and suitable compromises made to work around them, if
desired.

In this case, with a single shift register capable of driving the
LEDs to their continuous If spec, touting the use of TDM seems
ill-advised.
---

Also, assuming a 5V supply, 2V LEDs, and two 0.3V Vce(sat) drops for
the row and column drivers leaves 2.4V to be dropped across the
current limiting resistor with 460mA through it.

The 460mA assumes that you need the maximum permissible current through the LED to make it visible.

No, the 460mA assumes that in a muxed array with a 1/23 duty cycle,
the muxed LED will appear to be as bright as an LED rated for 20mA
and excited by a constant current of 20mA.

I don't know what misapprehension you thought that were correcting there,

---
Hmmm... More's the pity, since it's all there in black and white.

Seems like your grasp of the obvious isn't so remarkable after
all...
---

but you do seem to have missed the point that the 20ma
is the maximum sustained current that you can put through the LED
rather than any kind of recommended operating current.

---
Not true.

Most - if not all - data sheets list the "absolute maximum" forward
current as the current the LED can sustain for a prolonged period
without damage, and also give the nominal forward current for a
given output, generally under "electrical characteristics" or some
such.

There's also a maximum pulse current rating given with the duty
cycle limitations specified.
---

> Many LEDs are a bit too bright when run at their maximum sustained current.

---
Bob and weave, Mr. Sloman, bob and weave.
---

The eye's response is logarithmic, not linear and 2ma is often all you
need, particularly with "high brightness" LED's.

Weasel words.

Don't be silly. What I said is inarguably correct, and entirely relevant. the only weaseling going on here is your mindless enthusiasm for discovering stuff to carp about.

---
Well, when someone makes fishy statements, what else would you
expect?
---

"All you need" doesn't destroy the underpinnings of my argument,

Since you haven't made any kind of argument in the first place, this may even be true.

---
Existence doesn't wink out because of the "beholder's" blinders.
---

and the eye's response is logarithmic only when the source is
monochromatic, CW, and only the luminosity varies.

Don't be any stupider than you have to be.

---
Ad hominem.
---

With a pulsed source, all bets are off unless the luminosity, duty
cycle, and pulse repetition frequency are known.

Twaddle. The eye integrates the photons hitting it. The integration period - search on "flicker fusion frequency" - can be anything from 200msec in dim light to about 15msec in bright light. There are only three different light-absorbing pigments in the eye, so it's all rather simpler than you seem to think.

---
The link you refer is only concerned with fusion frequency as a
function of several variables; not with the amplitude response of
the eye as a function of source brightness.
---

Got a link to prove me wrong?

I don't need to prove you wrong - you do it yourself far too often to make it necessary for me to produce a formal proof of error.

---
When rational discourse can only lead to disaster, ad hominem seems
to be the course you plot.
---

You might educate yourself by reading this link.

http://en.wikipedia.org/wiki/Flicker_fusion_threshold

---
Thank you.

Quite enlightening, but rather irrelevant.

 

[Dennis]

On 03/12/2014 03:28 PM, Lasse Langwadt Christensen wrote:

Den onsdag den 12. marts 2014 20.52.14 UTC+1 skrev Dennis:



In things like the Rasberry Pi, Beaglebone, and the others that run

Linux the pin I/O is via a file system. The allocate, open, read/write,

close for a pin make it an order of magnitude slower (real time) than

direct hardware access as in the Arduino.

I'm not expert on linux, but can't you just memmap the gpio registers and
hammer away if you like ?

The short answer is "yes". The longer answer is "it depends".

Not all of the operations can be done in user mode. For an isolated
system it is probably not a problem running as root. If it is Internet
connected than you have the security problems from running as root.

Also there is the potential problem that the system could have a file
mode access to the mapped area. Again in a controlled, isolated system
if you are mem mapping you can probably assure nothing else is accessing
the area.

From a support standpoint, the file I/O method is defined and
supported. For the memmap solution you are on your own.

but the access speed doesn't help when the OS interrupts at random times

if you could prevent it from switching task while you burst out an update I think you could drive a string of WS2812

-Lasse

 

[Robert Baer]

Bill Sloman wrote:

On Wednesday, 12 March 2014 15:35:10 UTC+11, Robert Baer wrote:
Mike Miller wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

-Mike

Clue: using N pins, one has available 2^N states.
So all you need to use is 5 pins to control those 23 devices, leaving
9 unused states.

You need 5 pins to be able to select any one of these devices. Selection - on its own - isn't quite what the OP is asking for. He wants to "toggle" the LEDs.

Admittedly, just selecting any one LED could serve to "toggle" it between "on" and "off" but since you don't know how they started up (or got reprogrammed by a recent lightning strike) this isn't all that useful. Using one of the nine spare states as global reset - to turn them all off - would get around that problem. Adding a sixth pin - so you could set the selected LED explicitly "on" or "off" - would make life easier.

I leave it to the student to fill in the details.

Which usually means that the instructor hasn't thought about the details.

The instructor has thought of all of the details, including
multiplexing states for an "always on" appearance instead of any combo
being always "static" or latched.
Then again, all of it is trivial...

 

[Robert Baer]

Bill Sloman wrote:

On Wednesday, 12 March 2014 19:25:08 UTC+11, Jasen Betts wrote:
On 2014-03-12, Bill Sloman<bill.sloman@gmail.com> wrote:
On Wednesday, 12 March 2014 15:35:10 UTC+11, Robert Baer wrote:
Mike Miller wrote:

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

Clue: using N pins, one has available 2^N states.
So all you need to use is 5 pins to control those 23 devices, leaving
9 unused states.

You need 5 pins to be able to select any one of these devices. Selection - on its own - isn't quite what the OP is asking for. He wants to "toggle" the LEDs.

Admittedly, just selecting any one LED could serve to "toggle" it between "on" and "off" but since you don't know how they started up (or got reprogrammed by a recent lightning strike) this isn't all that useful. Using one of the nine spare states as a global reset - to turn them all off - would get around that problem. Adding a sixth pin - so you could set the selected LED explicitly "on" or "off" - would make life easier.

you could use one of the spare states to reset all the bits,
and have another spare state near that state for resting.

I just said that "Using one of the nine spare states as a global reset - to turn them all off"

And then you have a mess of asynchronous logic to handle this...

It doesn't have to be asynchronous. There's nothing to stop you from inspecting the states of the inputs at every rising (or falling) clock edge, and ignoring them for the rest of the time. You probably need to read up on "de-bouncing" switches.

toggling any led then becomes an excursion through hamming space to toggle
the led and then a return through the same hamming space back to the rest
state to un-toggle all the leds you hit on the way to the target.

Which is why most people go for clocked state machines.

It'd make a good programming exercise but little else.
The shift register approach is to be preferred, IIRC there are some
led drivers that can control 30 leds from 2 input pins.

Some of them have been listed in this thread. Some of us have tried to buy them from time to time and tend to prefer more general purpose parts that are likely to stay available for longer.

The shift register approach certainly uses up fewer pins.

The serial approach has a problem - needs milk.

 

[josephkk]

On Tue, 11 Mar 2014 06:53:39 -0500, John Fields
<jfields@austininstruments.com> wrote:

On 11 Mar 2014 09:23:54 GMT, "Peter Heitzer"
peter.heitzer@rz.uni-regensburg.de> wrote:

Mike Miller <mikemillernow@gmail.com> wrote:
All,

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?
17 pins are a lot. The simplest solution are 3 8-bit registers like 74HC574.
You need 11 pins; 8 for the data and 1 for any clock to the register.
Drawback is that you need 23 current limiting resistors. Advantage is
that it is static and you dont need a periodical routine for multiplexing.

---
The OP has 17 I/Os available and needs 2 for an 8 bit shift
register's serial data and data clock inputs.

Using a single 8 bit register with bus driver outputs will allow him
to source/sink 8 LEDs, which leaves him with 15 I/Os on the SoC for
the rest of the LEDs.

8 LEDs fed from the shift register, plus 15 from the SoC is 23, so
the simplest solution for a quasi-static display which can address
any or all LEDs in the array would seem to be something like an
HC575 (less than 60 cents in onesies from Digi-Key) plus the current
limiting resistors.

Hmmm. Using 3 would cost no more than 6 pins and has a spare output,
static display, and minimal code cost. A little coding could cut this to
4 pins.

?-)

 

[josephkk]

On Wed, 12 Mar 2014 14:52:14 -0500, Dennis <dennis@none.none> wrote:

On 03/12/2014 02:41 PM, Jan Panteltje wrote:
On a sunny day (Wed, 12 Mar 2014 12:50:32 -0500) it happened Frnak McKenney
frnak@far.from.the.madding.crowd.com> wrote in
FYednU9K2M71A73OnZ2dnUVZ_uudnZ2d@earthlink.com>:

-1m - WHITE
http://www.adafruit.com/products/1376

Enjoy...

I like this one, as i tcan (the ysay?) be driven by Raspberry"
http://www.adafruit.com/products/306

Still a bit expensive to hang 32 strips on the wall as wallpaper...

Jan,

Those strips reportedly use the LPD8806 driver rather than the WS2812.
Are you familiar enough at this point with the LPD8806 to say what it
is about those that's better -- for the R'Pi -- than the WS2812?

No, I have not used this chip, but they say this here:
http://www.adafruit.com/products/1376
qoute
example code for using with the Arduino Uno/Mega microcontroller at 8MHz and 16MHz,
but it will not work with the Raspberry Pi, Basic Stamp, NETduino,
any other interpreted/virtual machine microprocessor or any processor slower than 8 MHz.
For those processors, check our 32 LED/meter digital LED strip which has SPI-like input/output
and works well with Pi, NETduino, and other processors.
end quote
So I looked up that [other] strip, it seems to be about timing, that strip is SPI and not critical like the
arduino only one it seems.


I've skimmed this:

Topic: Individually addressable RGB LED comparison?
http://digistump.com/board/index.php?topic=991.0

but I guess I don't know enough about the R-Pi's pin I/O to know why
-- as the AdaFruit notes indicate -- the WS2812 isn't R'Pi material.

If it is timing, and the Raspi runs Linux, there will be several ms long interruptions due to task switching.
There is however also risc-os for raspberry, I tried it, it runs, but have no clue how to use it,
so I used that SDcard for something else, but that risc-os should not have the taskswitch problem ? Not sure.
I do not think speed is an issure with Raspi.


In things like the Rasberry Pi, Beaglebone, and the others that run
Linux the pin I/O is via a file system. The allocate, open, read/write,
close for a pin make it an order of magnitude slower (real time) than
direct hardware access as in the Arduino.

I do NOT think that a device like would be expressed as a file system, all
kinds of inappropriate overhead would get included. It would show up as a
character device (or device group). Then one open, and writes show up
immediately on the device.

?-)

 

[josephkk]

On Tue, 11 Mar 2014 15:51:28 -0400, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

On Tue, 11 Mar 2014 12:02:51 -0700 (PDT), mrhenkvisser@gmail.com
wrote:

All,

Thank you so much for the awesome posts. Lots of good information and ideas.

I have been working on my schematic late last night and the update is that for the 23 LEDs I have exactly 2 free pins available to drives these. Turns out the I2C peripheral is on these pins (SDA / SCL).

Follow up questions:

1.) I2C Port expander

Looking at this part:

http://www.digikey.com/product-detail/en/TCA6424RGJR/296-23306-2-ND/1832261

I can sink 25 mA and also have enough pins to cover the 23 LEDs.

Looking at the datasheet it is not clear to me if the 25 mA sink is per pin or total sink current for all the pins together.

It is per output, but there is a limitation of 200mA total through
ground. That's absolute maximum, so it would be a good idea not to get
too close to that. If you went with 100mA you'd have 4mA per LED,
which more than enough for a decent LED.

What are you thoughts on this? Any issues that you can think of?


2.) Power Supply issue.

I am powering my device with a CR2045 coin cell battery that will provide a voltage of 3.0V - 2.0V. I have added an LDO regulator to give me a fixed 2.1V. I did this because I am using the ADC on a microcontroller and wanted a fixed reference.

Button cells, as well as having limited capacity, also have pretty
high internal impedance. AA cells might be a better choice.

The I2C port expander operates in the range of 1.65 V - 5.5 V.

Should I give the I2c port expander the direct battery voltage or the regulated voltage?

The device has 2 "power" pins, V(ccp) should go direct to the battery, and
V(cci) should go to the regulator to match the i2c bus voltages.

To turn the LEDs off I should enable the i/o pin to be high impedance. Then when I put this low I should be able to sink 25 mA per pin. Right?

Thanks for you comments.

-Mike

 

[josephkk]

On Mon, 10 Mar 2014 20:18:47 -0500, John Fields
<jfields@austininstruments.com> wrote:

On Mon, 10 Mar 2014 15:34:48 -0700 (PDT), Mike Miller
mikemillernow@gmail.com> wrote:

All,

I want to be able to toggle 23 separate LEDs in my application. The design challenge is that I only have about 17 pins available on my SoC.

What are some options for this?

1.) Use another microcontroller with 23 available pins with some digital interface (spi/i2c) and then send over data to toggle the appropriate pins?

2.) Ideally I don't want to have to do additional firmware development on a second microcontroller.

Thank you for any ideas.

-Mike

2X TLC5926/TLC5927:

http://www.ti.com/lit/ds/slvs677/slvs677.pdf

John Fields

I like this one. Easy to multiplex 2 or even more ways, 16 outputs, small
TDM brightness price (will do 32 LEDs at 2-way).

?-)

 

[Jan Panteltje]

On a sunny day (Wed, 12 Mar 2014 13:28:19 -0700 (PDT)) it happened Lasse
Langwadt Christensen <langwadt@fonz.dk> wrote in
<56ca6bc2-2c58-4631-a331-29a044fe8f02@googlegroups.com>:

I'm not expert on linux, but can't you just memmap the gpio registers and
hammer away if you like ?

yes, I have tried that amd the maximum throughput i get is about 5 MHz toggle on a GPIO pin.
You STILL get interrupts from the taskswitching, the processor can only do one thing at the time.

but the access speed doesn't help when the OS interrupts at random times

if you could prevent it from switching task while you burst out an update I think you could drive a string of WS2812

Yes but the thing would be tied up all the time and not be able to do anything else.
SPI with some memory in the driver chips is so much simpler.
Hardware solution.