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.
Yes, I guess that's right. Anything above maybe four digits might run up against current limits on the segment driver pins. So no free lunch.
It's amazing to me that neither my version nor the odgen/Nusa version of segment multiplexing appears anywhere on Youtube, or anywhere else that I can find. I may not be searching for the right thing, but everything I see on multiplexing 7-segment displays switches one full digit at a time, either directly from the MCU with all the resistors and transistors, or through various decoders or shift registers. I think Dave should do a video on this. :-)
Search for "Led matrix multiplexing" for the concepts.
7-segment digits are just a bunch of LED's with one of the matrix dimensions enforced in the package.
You can do the same thing for input with a switch matrix.
I finished coding this for the TI MSP430G2452 and breadboarded the circuit for testing, and it works well. I used the ogden-Nusa method of multiplexing two segments at a time. With a 488 Hz (2ms) interrupt rate, that makes the refresh rate about 70 Hz, which is more than enough to prevent any flicker.
So as described earlier, I have no resistors on the segment lines, and a 470 ohm resistor on each common cathode line. Using Vishay's TDSR1360 displays produces bright segments, but at 3.3V and the displays reading "88", current is only 2.5ma per common cathode line, or 5ma in total to drive the displays, which I think is quite good. The Vishay displays appear to be very high efficiency red. I tried using old normal displays, and they are considerably less bright.
I was going to enable each segment line via the direction register, but that would have left all the unselected pins floating, and enabling pullups might cause problems. So in the end I just left all the segment pins as outputs, with all but one being low at any time, which was no more difficult to code.
I was planning for the code to determine whether the displays are CA or CC, so that one software version would support both automatically. But I couln't figure out a way to do that without adding hardware.
With a 488 Hz (2ms) interrupt rate, that makes the refresh rate about 70 Hz, which is more than enough to prevent any flicker.
Congrats! Also thank you for update - it is always good to know final results.
I was planning for the code to determine whether the displays are CA or CC, so that one software version would support both automatically. But I couln't figure out a way to do that without adding hardware.
Right. It would be easy if voltage drop of indicator LED's would be <=0.5V or so, but it is not. You can try this (not verified) idea: Take one segment pin with ADC input capabilities (from port P1), configure it as input with pull-up and enable ADC operation on this pin as well. Set common pin to '1' and measure voltage, set to '0' and measure again. If voltage follows common pin state - you got common cathode. If it's state does not follow then you either decide that indicator is common anode or faulty. You may repeat with pull-down to be sure that you got common cathode. [disclaimer] I am never used ADC on input with pull-up/down enabled, but IMHO it shall work according to Port1 schematics in DS.
You can try this (not verified) idea: Take one segment pin with ADC input capabilities (from port P1), configure it as input with pull-up and enable ADC operation on this pin as well. Set common pin to '1' and measure voltage, set to '0' and measure again. If voltage follows common pin state - you got common cathode. If it's state does not follow then you either decide that indicator is common anode or faulty. You may repeat with pull-down to be sure that you got common cathode. [disclaimer] I am never used ADC on input with pull-up/down enabled, but IMHO it shall work according to Port1 schematics in DS.
Yes, I think that would probably work for the TI chips, but this will probably end up on an Atmel, or maybe even something else, so I'd like to keep the logic as general as possible at this point. But I may take another look at this idea when it gets to its final home.
Other ideas that come to mind:
If you have a spare input it's easy: solder pad configuration. Resistor pads if you want pick-and-place friendly. Install/omit 0-ohm resistor as required.
User/Factory configurable EEPROM flag by some scheme such as holding down the switch during power-up (easy, but appears broken if done by accident) or shorting the two digit common pins together (unlikely to be an accident) during power-up.
Of course, unless you replace LED's or upgrade software in the field, software configuration with two compiled versions of the binary works well too.
I continue to find no written description or videos on this multiplex-by-segment ("MBS") system, and I think I will make a video on it because it is (what Auzzie-ism would Dave use?) really neat.
If all lines are driven by the MCU, MBS doesn't reduce the total number of lines required. Its advantage is the elimination of the seven resistors on the segment driver lines, and the transistors on the CC or CA driver lines, needed in a multiplex-by-digit system.
But if available GPIO pins are in short supply, either system may need to use an additional chip to fan out to the seven segments from a small number of GPIO outputs. Since MBS simply cycles through each of the segment lines one at a time, turning it ON no matter what is being displayed, the options for the decoder chip are expanded.
A 74xx138 3-to-8 decoder would work, but would require three GPIOs. However an 8-bit shift register would also work, and since we don't need the latching feature of the HC595, an HC164 could be used, which would require only two pins - data and clock. It would be initialized at power-up by clocking in eight zeros, so a Clear pin driver wouldn't be needed.
For common cathode displays, the most interesting option I've found is the ancient and lowly CD4017 decade counter with decoded outputs. Of course the HC version would be used, but this simply turns on one of 10 outputs on each clock cycle, which is exactly what's needed. This would also require two GPIO pins - clock and reset (active high). It has 10 outputs, but after 7 clocks (8 if using the decimal point), you would toggle the reset line instead of the clock, and that would leave the 0 output high, all others low.
Then I wondered if you could get away with just using the clock line. Using outputs 0 through 6 for the segments, you could wire the 7 output to the reset pin, which would reset the chip and leave the 0 output high. But that leaves the problem of the power-on state of the 4017, which I believe is unpredictable. There would need to be a way to generate an active high reset when Vcc comes up, or a way to read the current value of the 0 output without dedicating a GPIO pin to do that. Well, I'm still working on that, but if you could reduce the 7 GPIO segment pins to 1, Bob would definitely be your uncle.
Edit: I think the answer for single-pin driving of the HC4017 is to use the 4017's /CE pin as the falling-edge clock pin connected to the GPIO pin of the MCU, and connect a high-value resistor from that pin to the 0 output pin. Then you switch the GPIO pin between doing a HI/LO clock cycle in output mode and reading the pin in input mode, and stopping when the 0 output reads Hi. When that happens, set the output bit Hi to match what's already on the pin, then change direction to output. That prevents an unwanted clock tick from occurring. Something like 220K if that's not too much for driving the floating GPIO pin in input mode. You just want the largest resistor that still works reliably. Uncle Bob.
Following up on using the HC4017, attached is a schematic that I think will work. It's for common cathode only.
For two 7-segment digits, a total of three GPIO pins are used. Each additional digit would each require another GPIO pin and resistor. The number of digits is limited by the output drive of the HC4017. If I read the datasheet correctly, an output can source up to 25ma. That should be enough for 4-6 digits, depending on how efficient they are.
As threatened, I've made a video on this "by-segment" method of multiplexing 7-segment displays. It's posted on my local OSH group's Youtube channel. About 13 minutes. Credit to ogden and Nusa at the end of the video.
There's also a Github repo with Arduino Nano sketches illustrating coding methods.
https://github.com/gbhug5a/7-Segment-Displays-Multiplex-by-SegmentFor the version using the 74HC4017 to drive the segment lines, I ended up clocking on the Clock pin, which is rising edge. Pic attached.
As previously discussed here, the main point of this method is to eliminate the seven resistors on the segment lines and the transistors on the CA or CC lines, so that only a single resistor on each CA/CC line is needed. In addition, when using the 74HC4017, the total number of processor port pins needed to drive the displays is reduced to three for a two-digit display, and in general the number of port pins equals the number of digits, plus one. The 4017 option works for common cathode only.
Thanks for everyone's help with this, particularly ogen and Nusa.