Can I multiplex a 2-digit 7-segment display one segment at a time?

[Peabody]

I'm working on a project which will display a duty cycle percentage from 00 to 99, using two 7-segment common cathode digits.  I have enough IO lines for the seven segments and two cathode drives, and had planned to multiplex the two digits in the usual way.  That would require 7 resistors for the segments as well as an NPN transistor and base resistor on each cathode.

I'll use an MSP430 MCU, and the code will be written in assembler.  So it occurred to me that the code would be simple enough to fire each of the 14 segments one at a time.  Since only one segment would ever be on at a time, that would let me replace the 7 anode resistors and the cathode transistors with just one resistor on each cathode.

But of course that would mean that the average brightness would be pretty low, and the effective refresh rate for an individual segment pretty low as well.  Tentatively, the background refresh rate is 488 Hz, which would refresh each segment at about 35 Hz, but I could speed that up if necessary.

This would be great for the parts count, but I suspect this may be a bridge too far.  Has anyone here ever tried something like this, even with one digit?  Can I test the brightness issue by multiplying the resistor by 14 and seeing if the segment is still visible?  That would be 6.8K instead of 470 ohms.  Or is that not really equivalent to 470 ohms 1/14 of the time?  Seems like it might not even turn on using 6.8K.  And this is all 3.3V by the way.

The other potential complication is that if this thing works, it will probably be redone using an Arduino, and I'm not sure the efficient assembler code could be duplicated in C.  Still, it would be nice to do without all those resistors and transistors.

What do you think?

[ogden]

I'll use an MSP430 MCU, and the code will be written in assembler.  So it occurred to me that the code would be simple enough to fire each of the 14 segments one at a time.  Since only one segment would ever be on at a time, that would let me replace the 7 anode resistors and the cathode transistors with just one resistor on each cathode.

This is not where you save on code simplicity. Look at segment multiplex as PWM. For 7 segments it (on/off) is at 1:7 rate, for 14 segments accordingly 1:14. Blinking will be more noticeable and it will be twice as dim.

[Nusa]

(For real fun, look up charlieplexing. Sadly, that doesn't work so well when individual led's are tied to common cathodes.)

First off, how many I/O lines do you actually have for this purpose? If it's 14 or more, you don't even have to multiplex.

Second, realize the sizing of resistors in the circuit needs to change with the duty cycle, except when the goal is to dim the display. If the duty cycle is low enough, you may not need resistors at all!

Third, while assembly is less portable than C, C is usually just as efficient when done right. Whether it's portable will depend more on the compatibility of assumptions you made about the hardware than anything else.

[Peabody]

(For real fun, look up charlieplexing. Sadly, that doesn't work so well when individual led's are tied to common cathodes.)

First off, how many I/O lines do you actually have for this purpose? If it's 14 or more, you don't even have to multiplex.

Second, realize the sizing of resistors in the circuit needs to change with the duty cycle, except when the goal is to dim the display. If the duty cycle is low enough, you may not need resistors at all!

Third, while assembly is less portable than C, C is usually just as efficient when done right. Whether it's portable will depend more on the compatibility of assumptions you made about the hardware than anything else.

I did look at some videos on charlieplexing, but they all related to individual LEDs.  I didn't see anything related to 7-segment displays.

With 7 + 2 I/O lines assigned to the display, I have one pin left over.  It's a 20-pin MCU, with 16 I/O pins, but I also have a rotary encoder, a momentary switch, an LED, a buzzer, and an SSR trigger.  So I don't have another 7 pins for the display.

I had forgotten that the resistors could be much lower value, and the current much higher, for brief periods of time.  And the point here is not so much to save on power but rather to save on parts.  So if it's not too blinky, this may actually work.  I think it's at least worth writing some code to test it.  But between the MSP430G2553 processor and the TDSR1350 digits, I'm still looking at something under 10ma.  That's common anode, isn't it, not common cathode.  Sorry, I misremembered that.

My comment on Arduino was just based on my experience with others who use them a lot.  I don't see much bit-wise activity in their code, and it appears that a main focus of Arduino is to separate you as much as possible from the actual registers.  Assembler, for me at least, is the opposite of that on both counts.  In my code for this, there will be no MAIN other than to set up the interrupt, then go to sleep.  Everything will happen in the interrupt service routine, and the processor will sleep in between.  I don't see that kind of stuff in Arduino sketches.  But of course that doesn't mean it can't be done.

[mikerj]

I did look at some videos on charlieplexing, but they all related to individual LEDs.  I didn't see anything related to 7-segment displays.

A forum member, matseng posted an instructable that permits a level of charliplexing on 7 segment displays, 9 pins will allow you to drive up to 8 digits at the cost of some code complexity.  This isn't very useful if you are only driving two digits, but worth remembering.  If you need to save pins then you could drive the displays with a couple of shift registers.

[Nusa]

You might find this article useful: https://tinkerlog.com/2009/04/05/driving-an-led-with-or-without-a-resistor/

Charlieplexing was for fun; I already said it wouldn't work well in your case, and why. Common cathode or anode, same issue.

Arduino is one of those poorly defined words that one has to define from context, since the speaker usually doesn't tell you what they actually mean when they say it. In this case the contexts mentioned were hardware and C. The arduino hardware is is typically, but not always, a member of the ATMega family, most commonly the ATMega328. There is nothing "special" about this microcontroller simply because it's classified as an Arduino processor. You can write assembly for it, if that's what you choose. Or C. Or anything else you can find a compiler for.

But now that you've mentioned software, the arduino hand-holding software libraries are entirely optional. You don't have to use them. If you want to talk directly to ports instead of using library routines, just do it. Nothing special about it, other than you may have to know more about the hardware you're using. Ditto for the arduino IDE; you don't have to use it. And once you're talking directly with hardware, C and assembly are comparable in efficiency. Including for interrupt handlers.

But yes, many aspects of the arduino IDE and libraries suck. For beginners and anyone who isn't pushing the limits that doesn't matter. That's why it's as successful as it is; because it works for simple projects.

[spec]

Tentatively, the background refresh rate is 488 Hz, which would refresh each segment at about 35 Hz, but I could speed that up if necessary.

It is advisable with fast responding lights to refresh not less than 60Hz to avoid viewer distress.

Just in case: the eyes response is logarithmic so you can reduce the average power of a LED without a corresponding impression of less brightness.

I would suggest that you do a feasibility test  with just one segment and a signal generator or 555 or MCU generating the pulse. That way you will see the effect. By the way, it would be best to pass the maximum specified current through each segment to maximize the light output.

I would be surprised, with just 14 segments, if there was a problem.

[Kasper]

Have you tried using a resistor on the cathode instead of on each segment with normal multiplexing? That would probably make '1'  brighter than '8' but if you give a shorter pulse for '1' than for '8', you could dim '1' to be more similar to '8'. Haven't tried this myself, just an idea.

[Peabody]

Ok, I worked up a quick and dirty test using the MSP430 controller.  I just did one segment, and confirmed with my scope that it was ON 1/14 of the time - 2ms out of 28ms.  I found that it was plenty bright enough using a 470 ohm resistor.  It was even acceptable using a 1K, but I prefer the brighter look.  There is no discernable flicker at all.

So I consider this to be a complete success.  And the current draw will be a constant 7ma, or an average of 0.5ma per segment.  Not bad at all.  I kinda suspect that this worked out as well as it did mainly because of the fancy Vishay TDSR1350 7-segment display.  Looking at the datasheet, it is indeed a low current part.  A more normal display might not do so well, but I think pretty much anything would work with the right resistor.  I was particularly pleased with the lack of flicker.  The persistence of human vision works to our advantage.

So in the full version, I'll have the seven segments of both digits directly connected to I/O pins, with no resistors, and the two common anode pins connected to I/O pins through 470 ohm resistors.  That's a reduction from 9 resistors and 2 transistors to 2 resistors and no transistors.  Not bad.

If I get time tomorrow, I'll see what would happen if it were four digits multiplexed the same way, with each segment ON 2ms out of 56ms.

[ogden]

So in the full version, I'll have the seven segments of both digits directly connected to I/O pins, with no resistors, and the two common anode pins connected to I/O pins through 470 ohm resistors.  That's a reduction from 9 resistors and 2 transistors to 2 resistors and no transistors.  Not bad.

7 resistors and 2 transistors are way cheaper than pins of microcontroller you literally waste. Also as already noted - if you really have enough pins to connect every segment, then don't multiplex.

If I get time tomorrow, I'll see what would happen if it were four digits multiplexed the same way, with each segment ON 2ms out of 56ms.

    Better shift your focus of innovation into another area and stop inventing ineffective wheels.

[Peabody]

So in the full version, I'll have the seven segments of both digits directly connected to I/O pins, with no resistors, and the two common anode pins connected to I/O pins through 470 ohm resistors.  That's a reduction from 9 resistors and 2 transistors to 2 resistors and no transistors.  Not bad.

7 resistors and 2 transistors are way cheaper than pins of microcontroller you literally waste. Also as already noted - if you really have enough pins to connect every segment, then don't multiplex.

I didn't say that clearly enough.  I'm only using 7 pins for the segments.  The respective segments of both digits are connected to the same pins.  The digit is selected via the common cathod or anode.  So I'm using a total of 9 pins to drive two digits.

[Peabody]

If I get time tomorrow, I'll see what would happen if it were four digits multiplexed the same way, with each segment ON 2ms out of 56ms.

I did further testing and found that this doesnt work for three digits or four digits, at least at the 2ms ON time.  Both produced substantial flicker.

I also tested 1/16 in case the decimal point is needed, and found a hint of flicker there as well.  So it appears that two digits of seven segments each (1 of14 segments at a time) is right at the edge of what works at 2ms ON time.

[Nusa]

Flicker fusion sensitivity is going to vary among humans, so you may or may not be a good measure of the average human. Fatigue is a factor, so the well-rested are more sensitive. Metabolic rate is a factor, so the young are more sensitive. Rods are much more sensitive than cones, so peripheral vision is more sensitive. Also, flicker is easier to detect in brighter displays.

I'd aim for 30 Hz as a minimum refresh rate. Higher would be better.

[ogden]

I didn't say that clearly enough.  I'm only using 7 pins for the segments.  The respective segments of both digits are connected to the same pins.  The digit is selected via the common cathod or anode.  So I'm using a total of 9 pins to drive two digits.

Well, then you need 2:7 multiplex scan, not 1:14. If this is too difficult task for you to code, then you shall reconsider your occupation [kidding]

[Peabody]

I didn't say that clearly enough.  I'm only using 7 pins for the segments.  The respective segments of both digits are connected to the same pins.  The digit is selected via the common cathod or anode.  So I'm using a total of 9 pins to drive two digits.

Well, then you need 2:7 multiplex, not 1:14. If this is too difficult task for you to code, then you shall reconsider your occupation [kidding]

I don't understand your comment.  The whole point of this exercise was to see if I could multiplex one *SEGMENT* at a time, not one digit at a time.  So I am NOT doing 2:7 multiplexing.  Two digits have a total of 14 segments, and I'm cycling through them one at a time - the individual segments of the first digit followed by the individual segments of the second digit, one segment at a time.  So every digit is turned on 1/14 of the total time.  This isn't too difficult for me to code.  And by the way, saying "kidding" doesn't make it any less insulting.

[Nusa]

I didn't say that clearly enough.  I'm only using 7 pins for the segments.  The respective segments of both digits are connected to the same pins.  The digit is selected via the common cathod or anode.  So I'm using a total of 9 pins to drive two digits.

Well, then you need 2:7 multiplex, not 1:14. If this is too difficult task for you to code, then you shall reconsider your occupation [kidding]

I don't understand your comment.  The whole point of this exercise was to see if I could multiplex one *SEGMENT* at a time, not one digit at a time.  So I am NOT doing 2:7 multiplexing.  Two digits have a total of 14 segments, and I'm cycling through them one at a time - the individual segments of the first digit followed by the individual segments of the second digit, one segment at a time.  So every digit is turned on 1/14 of the total time.  This isn't too difficult for me to code.  And by the way, saying "kidding" doesn't make it any less insulting.

Perceived insult aside, the guy had a point even if you missed it. Since you have independent control of the anode/cathode (whichever it was) lines, you can probably update the same segment on both digits at the same time. Current limits of the segment pins permitting.

[ogden]

I don't understand your comment.  The whole point of this exercise was to see if I could multiplex one *SEGMENT* at a time, not one digit at a time.

Yes, do *segment* at a time, but for *both* digits at the same time - so you scan all the segments of all digits in 7 steps, not 14. Also transistors are not that necessary, I/O's of msp430 are more than capable.

And by the way, saying "kidding" doesn't make it any less insulting.

Sensitive?  Sorry then.

[Peabody]

Further testing has shown that if I increase the interrupt rate from 500 Hz to 1KHz, which reduces the ON period from 2ms to 1ms, I can do four digits (1/28) with no blinking detectable by me.  But of course it's not as bright since each segment is only ON 1/28 of the time instead of 1/14.  Reducing the resistor value can restore brightness - up to a point.

So basically this just maintains the blink rate at about 35Hz for four digits, which as others have said appears to be the controlling factor for flicker regardless of how long the blink actually lasts.  Well I'm sure there's a limit to that at some point, but as the ON time gets shorter, the eye interprets this primarily as just less bright so long as the frequency remains the same.

The bottom line for all of this appears to be that if you fire one segment at a time, you don't need resistors on all the segment lines, and you don't need transistors or base resistors on the common anode/cathode lines.  You just need one resistor on each common anode/cathode line.   And if you have flexibility as to the refresh frequency, you can make this work for four digits or more without flicker and without any power consumption penalty versus multiplexing one entire digit at a time.

The coding is only a little more complicated.  You would still load the segment lines' I/O port OUT register with the segment pattern to be displayed, and set the common anode/cathode pin for that digit, but then just shift a bit in the port's DIRECTION register to the left on each interrupt.  Then do the other digit the same way.

Thanks very much for everyone's comments and suggestions.

[Peabody]

Perceived insult aside, the guy had a point even if you missed it. Since you have independent control of the anode/cathode (whichever it was) lines, you can probably update the same segment on both digits at the same time. Current limits of the segment pins permitting.

I'm still missing it.

If the top segment on one digit is supposed to be ON, but the same segment on the other digit is supposed to be OFF, I don't see how I can update both at the same time if both are connected to the same I/O pin.  I only have seven I/O pins for the segments.

Could you please explain it again?

[Peabody]

I don't understand your comment.  The whole point of this exercise was to see if I could multiplex one *SEGMENT* at a time, not one digit at a time.

Yes, do *segment* at a time, but for *both* digits at the same time - so you scan all the segments of all digits in 7 steps, not 14. Also transistors are not that necessary, I/O's of msp430 are more than capable.

And by the way, saying "kidding" doesn't make it any less insulting.

Sensitive?  Sorry then.

As I just said to Nusa, I don't see how I can do what you're suggesting if the segments on the two digits are connected to the same I/O pin.  Perhaps you could explain how I would do that.

Sensitive?  Perhaps.  But I would just never say what you said to anyone, kidding or not.  And by the way, it's not my occupation.

[Nusa]

Defining ON as whichever state for each pin is required to light the segment. OFF as either the other state or tri-state, as appropriate.

Segment A ON, Anode 1 ON, Anode 2 ON = segment A lit on both digits.
Segment A ON, Anode 1 OFF, Anode 2 ON = segment A lit on digit 2 only
Segment A ON, Anode 1 ON, Anode 2 OFF = segment A lit on digit 1 only
Segment A ON, Anode 1 OFF, Anode 2 OFF = segment A off on both digits.

Four possibilities for each cycle. Get it now?

[Peabody]

Defining ON as whichever state for each pin is required to light the segment. OFF as either the other state or tri-state, as appropriate.

Segment A ON, Anode 1 ON, Anode 2 ON = segment A lit on both digits.
Segment A ON, Anode 1 OFF, Anode 2 ON = segment A lit on digit 2 only
Segment A ON, Anode 1 ON, Anode 2 OFF = segment A lit on digit 1 only
Segment A ON, Anode 1 OFF, Anode 2 OFF = segment A off on both digits.

Four possibilities for each cycle. Get it now?

Yes.  I do.  Thanks for spelling it out for me.  Sorry to be so dense.  The coding would be more complicated, but it would indeed update both at the same time.  It's kinda like charlieplexing in a way.

Thanks very much.

[ogden]

As I just said to Nusa, I don't see how I can do what you're suggesting if the segments on the two digits are connected to the same I/O pin.  Perhaps you could explain how I would do that.

Ok. I'll try to explain. Default/off state of two anode pins is '1' and 7 cathode pins '0'. You just loop through all the segments by setting according anode pin to '1. After anode pin set done, you check if digit "A" segment needs to be lit - if yes, then you change it's cathode pin state to '0 otherwise set it '1'. You do the same with cathode pin of digit "B" as well. Same logic for more than two segments digits. Dunno if it explains or not - but be my guest anyway.

[Peabody]

Yes, I understand now.  Thanks very much.  And this method has the advantage that you can have any number of digits without changing the timing or inducing flicker.  And still only one resistor per common A or C pin.  So yes, this is better.  I guess it should have been obvious, but it wasn't.

[Nusa]

Yes, I understand now.  Thanks very much.  And this method has the advantage that you can have any number of digits without changing the timing or inducing flicker.  And still only one resistor per common A or C pin.  So yes, this is better.  I guess it should have been obvious, but it wasn't.

The number of digits would be limited by how much current your segment pins can sink/source (usually they can sink more than they can source) with the resistor value chosen for the anodes/cathodes. And of course by how many pins are available to use.