Rectangular LEDS FAQ

Current control can be done with one transistor in an emitter follower configuration. A current setting resistor is used in the emitter leg and the LED is used in the collector leg. You need to set the voltage on the base and therefore the current control resistor with a pair of resistors from the control output.

What is the two transistor circuit like?

As someone else mentioned, you don't need fancy equipment to use surface mount parts.

The problem with paralleling LEDs is that the I vs. V curve varies, so each one will have a different current. But if you use a current limiting resistor that gets them close. Driving from 5 volts puts more voltage drop on the resistor which gets you closer. You can only perceive a limited amount of variation. Almost no one uses true constant current sources for driving LEDs.

Consider a PCB. Once you have one you can make the design available for others to order through Oshpark

I don't know what a PICAXE is, but I assume it is either a Microchip MCU or a board using a Microchip MCU. PICs are not the only MCU on the market. In fact, the lower end PICs have a very odd and uneven instruction set. But whatever, the processor is not so important. The I/O is what this is about. Consider my other post about using an MCU to do multiplexing with DAC control of the LED brightness.

Similar, but the lower resistor of the PD is replaced by the second transistor, who's base goes to the emitter of the first. Current control is *much* better, and you potentially only lose 0.6V + VCEsat of the first transistor. As the second transistor is dissipating only a tiny amount of energy there is no drift due to heating, which there would be with a single transistor.

Sounds pretty pointless to me. The one transistor circuit is already an improvement over just a simple current limiting resistor. I doubt anyone will notice the difference in any of the three options to be honest.

BTW, take a look at the original clock. It uses a few lightbulbs behind a piece of plastic. In at least one picture some of the bulbs are burnt out which is clearly discernible. Lol, maybe the OP wants realism.

And while we're on the subject, 23 LEDs can be multiplexed (simply) by using just 10 outputs--for a 5x5 matrix with two voids.

Or with only 10 outputs in a 5x5 matrix...

Yes I eventually worked out that was what he was trying to do, but I don't see any advantage over treating the LEDs as a linear array and, for instance, simply using I2C to zap a row of bits into a set of 74HC594s.

Yep, and if I was to use, PCF8574 or its 16 bit bigger brother I think I'd have to do that: if I read it correctly, these specialist LED driver chips can only drive one LED per output pin.

Yes, exactly. It doesn't matter logically whether you drive the set of four in a block via a single pin, possibly via an external current source, or treat the LEDs in it as separate: treating them as separate just meand more bits to send via I2C, but having 23 connection to the display rather than 59 minimises the wiring problem.

Agreed, but if as seems likely, switchable constant current sources are only needed for the blocks, I'd only need 12 of them and one control connection per block.

Yes, I'd thought of cutenesses like using an ambient light sensor to control the brightness. That would be easier to handle by using specialist LED driver chips since many of them have controllable duty cycles.

Not necessarily. If specialist LED driver chips are used, its possible to check the light level every second or so and, if it changes, zap the driver chips with a command to change the duty cycle for all LEDs.

I think I'll start by getting a handful of LEDs and a 74HC594 to experiment with and decide where to go after that. I think I ought to know a little about I2C and/or SPI in any case.

True, and would give me an excuse for finding out about PICAXE MPU chips as well. BTW, how do most people get RS-2332 out of an RPi? Bit-banging or an extender board and a UART?

Yep - its a DIP package containing a PIC MPU, RAM, EEPROM, I/O and a BASIC interpreter. The package size and i/o capabilities vary depending on model. They are cheap, small and available. IMO they're worth knowing about:

That said, I haven't (yet) used a PICAXE, bit I have used the logically very similar Parallax STAMP BS-2 and like everything about them except the price:

I am. This approach could well help with the other job I'd like this particular RPi to do, particularly as PICAXE's can act as master or slave on an I2C bus and some have onboard DAC/ADC capabilities.

Use the PI's UART and a TTL to RS232 level-shifter like a MAX3232 chip. You can get small boards with the chip and associated capacitors on for around a quid on ebay. I use one of those boards to connect a Pi to an old VT terminal.

Connect "TTL" GND, Tx, Rx and 3.3V to Pi, then "RS232" GND, Tx and Rx to whatever needs it.

Of course, if the device will happily work with 3.3V logic levels you can just connect it directly.

I don't know why you say that. The only limitation is the voltage the driver can tolerate when off.

When you are multiplexing all the LEDs have to be very similar if not the same. They share a set of high and low drivers.

I'm not sure what you mean about the "wiring problem". Why wouldn't this all be on the same PCB?

Not sure what you are saying here.

You aren't grasping the nature of multiplexing. It requires driving each LED for a short time, faster than the eye can see meaning at least

Uh, the rPi has a UART built in. The output is 3.3 volt which means to talk to a PC you need an RS-232 driver/receiver chip. To talk to an MCU needs nothing since that is also 3.3 volt I/O.

The Pi has a UART built-in. Only Tx & Rx though and it's 3.3v - /dev/ttyAMA0.

The somewhat easier way is to use a USB/RS232 adapter and let that handle the voltage differences, etc.

Gordon

No - but my wiringPi driver will only support 4 cascaded as one unit. It would not be hard to change the code to support more, or have multiple units of 4 - each block of 4 needs 3 GPIO pins on the Pi though.

The wiringPi driver allows you to regard them as individually bit-addressable devices - it takes care of the shifting, etc. for you, so you can simply digitalWrite (pin, 1); to set one output pin value and the rest remain unchanged.

You can program them from C/C++ or my RTB (BASIC).

(or the command-line via the gpio utility)

Cheers,

Gordon

On Sun, 30 Nov 2014 00:48:14 +0000 (UTC), Martin Gregorie declaimed the following:

Does Parallax still make BASIC Stamps, or are they just selling off old stock (granted -- the processor is just a pre-programmed PIC, so that shouldn't be a problem; it's the carrier board and accessory chips that may be running low). I've got a few lying around too, including a serial port (not USB) experimenters boards. Yeah -- expensive compared to ...

Maybe a Propeller? They've been used to make the DefCon badges for a few years

Small Arduino...

Or -- possibly overkill... A Texas Instruments TIVA C 123 Launchpad

All overkill just to drive a bunch of LEDs off a Pi. Really - if you already have the Pi in the first place for other tasks, then driving LEDs is fairly trivial - multiplexed, charlieplexed, via IO expander chips or even just directly. Pi model A/B has 17 usable IO pins, the A+ and B+ have 26 usable ones and via IO expanders - virtually unlimited. (if you can manage the wiring!)

Gordon

Or if multiplexing change the PWM (mark/space ratio) lot easier and lot less circuitry to use as the Pi has a clk output and various libraries have PWM capability. For 5 or more multiplex points on 1 to

If really fancy you could use different PWM widths for different 'columns'.

Bith the 594 and 595 have the same number of outputs, so for 23 outputs you need 3 oof either one. The difference between them is whether the output latch has a common clear or common output enable. I would suggest using 595 with the OE (Output Enable) then drive the output enable from a clock output to give you a form of global brightness control from a PWM signal.

For each independent LED output (i.e. after grouping) use half a 7474, all in a line. Connect each D to the previous Q, but the first D goes to one output pin of the Pi. Connect all of the Clocks in parallel, perhaps through a simple buffer, to another Pi output pin. Connect the Q or Qbar of each D-type to a driver for a LED group.

Once a minute, and at startup, write a data bit to the first output pin and pulse the second one, repeat as fast as possible until every lamp group has its new data bit. I guess you can easily do that in a millisecond, which you will not see on the display. You can use a pair of switches to do that much more slowly for initial test.

To use fewest output pins, i.e. one, encode the data as long and short pulses, trigger a monostable giving a middling delay from the rising edge, and use the falling output of that to clock your D-type chain.

It may be that a well-chosen type of 7474 can switch enough current to drive a modern LED adequately. If they cannot switch a group of LEDs, just use extra half-7474s for those stages.

Actually, IIRC, you can probably get multi-stage shift register chips with all outputs exposed. But I liked the 7474, when I built circuits.

Actually, the rPi is very poor at I/O. Trying to multiplex a device with some dozens of LEDs to control will take a *lot* of the I/O capability and likely much of the processor... if it can even be done!

I looked into using the SPI for something high speed once and found it was only good for about 6 kSPS operation. The I2C driver may run a bit faster, but I believe the OP wants this to run in the background with minimal impact on the rest of the OS.

Maybe others are not so sensitive to it, but I find LEDs flashing to slowly to be very bothersome. When I drive at night I can spot the Cadillacs from a certain age very easily. Their tail lights are strobed too slowly so that when I move my view they create a trail of dots. Very disconcerting. It fools my peripheral vision into believing there are a lot more cars on the road than there really are. I certainly wouldn't want that in a clock.

It's trivial.

I posted this earlier:

That's 128 LEDs via 3 ports on 2 mcp23017 I2C GPIO expander cards. Although that video demo only has a few LEDs on at a time, I can assure you that the code behind it is multiplexing all 128 LEDs. Each "pixel" is a green + red LED - it's pretending to be a

It's using only a few % of the CPU to do that. Most of the time its waiting on the I2C bus - I am running it at 1Mhz in that demo.

This:

is playing tones via software toggling of a GPIO pin. It's stuttering as I'm only playing the tone for 1/10 of a second before checking for a touch release.

This:

is software PWM over 12 LEDs.

And so on.

Yes - and the reason behind that is nothing to do with anything but the Linux kernel driver for SPI having a rather high latency when starting a transfer. If you want to poke the hardware directly, you'll get 20x that.

The max. SPI clock I've used reliably has been 32Mhz.

Gordon