[sdiy] 7-segment LED displays with 4511 driver chip - max current?

rsdio at audiobanshee.com rsdio at audiobanshee.com
Sat Aug 8 20:14:16 CEST 2015


On Aug 7, 2015, at 12:04 AM, Rick Jansen <rick.jansen at xs4all.nl> wrote:
> On 07/08/2015 08:17, rsdio at audiobanshee.com wrote:
>> On Aug 5, 2015, at 10:29 PM, Rick Jansen <rick.jansen at xs4all.nl> wrote:
>> > On 06 Aug 2015, at 00:01, rsdio at audiobanshee.com wrote:
>> >> Those three BCD chips will use 12 GPIO pins, unless you add more chips to expand I/O. With those same 12 GPIO pins, you can drive 36 LEDs in a simple matrix. That's enough for three 7-segment displays plus 15 more LED indicators. Or, you could use 10 GPIO pins and a cheap 2-to-4 decoder chip to drive 32 LEDs with 11 to spare beyond the three 7-segment displays.
>> > 
>> > The 4511 has a latch that can remember the state of the digit. So you need 4 pins for the BCD value, plus one pin per LE signal to make that 4511 change state. Three 4511's cost 7 pins that way. I do have enough space in the I2C bus, so I will add an extra PCF8574 for that. One bit spare for blanking the upper digit even, if 0! :-)
>> 
>> Sometimes, the absolute lowest pin count solution is not the best. An I2C GPIO expander will take more time to update than direct AVR GPIO pins. Also, I2C is a very slow protocol, and the more things you add to your bus, the lower the total available communications bandwidth to each one.
>> 
>> If you have 7 or 8 GPIO pins to spare, then I still recommend the simply LED matrix with a 2-to-4 decoder. 8 pins will get you 24 LEDs in any pattern you want, with 25% duty cycle for each LED.
>> 
>> Personally, I find it interesting to see how circuit design trends have changed since the early days of digital synth design. Old designs are more efficient, and cost even less today, while new designs tend to suffer from congested I/O and even slower firmware. That's the only reason I recommend the simpler designs. Of course, they're only an option when you haven't run out of GPIO pins!
>> 
>> Brian
> I2C may be relatively slow, but this is a user-interface thingy, and we humans are very very slow, compared to I2C. Well, I am.
> I'll see how I fare. I really like I/O extension of the Arduino with the PCF8574 chips, and the way that one pin change gives you an interrupt. (Shift registers don't do that.) 
> 
> Max 2x8x8 = 128 signals! 
> 
> PCF8574 drives (individual, not 7-seg) LEDs very nicely too. One disadvantage I find that the PCF8574 outputs can only sink current well, so they're not very good for driving an external bus with positive signal voltages. But a 74HC541 buffer solves that too. (Unbelievable how many different chips I still had lying around..)
> 
> rick  (now studying how you can have an Arduino track a whole bunch of rotary encoders, like 16, and read them individually…)
My comments about time, bandwidth, and slow code were all oriented towards a matrix LED circuit, where timing is critical if you want to avoid ghosting or other variation in brightness.

If you dedicate an expander pin to each LED, then you don't need an interrupt. You can just change the state of that pin whenever you like, and the latency will never be perceived. Ditto when combining the serial I/O expansion with a latching device like the BCD decoders. The latch makes sure that an LED does not change unless you want it to. Your code can be much simpler with this circuit. The downside is that you need several external chips, and you basically only have one LED per pin.

The advantage of a scanned matrix is that you can have many more LEDs than pins. But the disadvantage is that your timing has to be constant, or else the brightness will vary. I've seen many amateur firmware designs where the LEDs will get dim whenever something happens - like turning a knob or handling an increase in data processing. So, when I talked about the limited bandwidth of serial I/O expansion and the additional code needed to update external GPIO as opposed to direct GPIO, I was referring to the need to have precise timing when cycling through the rows and column of an LED matrix, which needs to happen tens or preferably hundreds of times per second. The advantage with the matrix is that you often need no external chips at all.

You are correct about human perception of latency. Changing an individual LED from "off" to "on" will probably never be perceived as "delayed" because we humans aren't counting nanoseconds in real time. However, we can perceive the subtle changes in brightness if a scanned LED matrix varies in its timing. Also, even if the timing is constant, a matrix LED service interrupt that takes too long will just waste available CPU compared to an interrupt that has less to do.

Speaking against my own recommendation towards the LED matrix circuit, I will say that some of these serial I/O expanders have excellent LED control. I recently worked with one where you have an individual "Dim" register for each pin, which sets the current for an individual LED. That's a difficult feature to pull off in a scanned LED matrix, due to the shared Column and Row signals. So, some serial I/O expansion has clear advantages. I doubt you'll need to change the brightness of one segment separately from another in a 7-segment display, but you might want other LEDs to change brightness.

Brian



More information about the Synth-diy mailing list