[sdiy] 7-segment LED displays with 4511 driver chip - max current?
jason at tribbeck.com
Sun Aug 9 11:20:49 CEST 2015
With the '595 you can shift the values in, and then tell it to transfer the
shift register to the output register. This means you can pre-shift the
pattern into the register, change the row, and then shift the pattern to
If you're clever with your design, you could make the row change and the
output transfer use the same signal - so there would not be much in the way
of delay. And if you're using SPI, then you could use the CS signal
connected to the RCLK signal (which does the transfer) - it's a positive
edge triggered input...
Although if you are concerned about the power going through GND (or +5V),
then I would look at the NPIC6C596, which is similar to the '596 (which is
an open-collector version of the '595) - this is designed for higher
current LED drives, and is functionally identical to the '596, and doesn't
cost that much (quick look at Farnell, and the NPIC6C596 price is £0.64;
74HC595 is £0.43).
Unfortunately, it's not pin-compatible (and I prefer the pin layout of the
And I'm using an HC595 and NPIC6C596 together in an LED matrix, so I shift
16 bits and then clock both at the same time - the HC595 drives a ULN2981
for the rows, and the NPIC6C596 drives the columns directly. I will be
bit-banging the signals, because the PIC I'm using doesn't have SPI (it's
the smallest one I could find with a UART).
Although there is the NPIC6C595 which is open-drain, which I've only just
considered using for driving the rows directly...
On Sat, 8 Aug 2015 at 22:28 <rsdio at audiobanshee.com> wrote:
> On Aug 8, 2015, at 10:43 AM, Tim Ressel <timr at circuitabbey.com> wrote:
> > My go-to for this would be a 74HC595 shift register. I would multiplex
> the displays, either with 2 '595s or with a single and use 3 proc lines to
> drive the display common pins. Multiplexing might be off-putting if you
> haven't done it before, but it is really quite easy. '595s are groovy
> because you can clock them fast, and you can use SPI or bit-banging to
> drive them. With an Atmel AVR at 20 MHz and SPI you should be able to get
> in and out of the display routine in a few micro seconds. Also with
> multiplexing only one display is on at a time, thus reducing total current
> The '595 is certainly popular, but not without drawbacks.
> Example: When scanning a multiplexed matrix of LEDs, each step requires
> that either all Rows be disabled or the whole Column must be disabled
> before the next Row and Column are enabled. This is a synchronous
> operation, because you have to wait for the disable to take effect before
> you enable the next set, otherwise you see ghosting of incorrect LED
> coordinates. The problem with those shift registers is that it takes some
> number of cycles before the value written to the SPI peripheral actually
> appears on the chip's outputs. This usually means that you have to burn CPU
> cycles before you can take the next step (enable must wait for disable to
> However, if you have an interrupt-driven queue for an SPI shift register,
> then you could feasibly queue up a sequence of commands that would work,
> but you end up with more interrupts per matrix scan step.
> Bit-banging is certainly a waste of CPU cycles, so I hope that a new
> hardware design would not rely on that technique.
> Often, there are spare CPU cycles available to be wasted, so in some sense
> it doesn't matter. But whenever you're talking about a battery-powered
> device, or even a USB-powered device running from a laptop, the wasteful
> circuit designs just end up draining your battery faster.
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Synth-diy