This task of yours is pretty much MCU-101. Almost everyone who has done anything with an MCU will have tackled this problem early in their learning period. It's classic and dates back 50 years or more. But people of all ages have faced this, so you'll get lots and lots of replies -- everyone of every age has had to do this at least once in their lives. And there are many web pages on the topic. More than enough to fill out a lifetime of reading, I suspect.
But perhaps the most solid book on the topic that dates back to about 1980 or so is from Hewlett-Packard and is called, "Optoelectronics: Fiber-Optics Applications Manual", 2nd edition. If you can find a copy, I'd highly recommend getting it as a reference text. It covers everything from louvers to polarization to longevity and includes scanning/multiplexing and/or direct drive.
Today, there are dozens of suppliers of hundreds of LED driver ICs. It's a real pain to manage hundreds or thousands of LED segments. Everyone knows it is and IC manufacturers have come out in droves to help out.
You will need (or want) to limit the current in each LED. That's either a resistor or else a current source/sink circuit. That by itself is a pain.
So you have a few approaches:
- Buy an IC for it. Some of the ICs will do all of the needed work to run some number of 7-segment displays for you. You can download the LED details you want into the IC and just let it run around in circles for you. They often include details like: LED shorted or LED open status, programmable or settable LED current limit, and so on.
- Multiplex your displays in software. Here you can run the displays one at a time, real fast, so that it appears that they are all on. However, you will need to run them at higher current so that their brightness "appears" about right. So this means a higher current and you need to check the datasheets to make sure they can handle the boost.
- Run out lots and lots of I/O pins so as to completely cover all the LED segments. This means an MCU with gobs of I/O pins. But if you have them available, then you do not need to multiplex and you can just use very simple software means.
You can get fancy. Sometimes you can work out details where not all of the LEDs have to be completely controllable, independent from each other. In other words, perhaps there are some "dependencies" that you can exploit. You may have two LEDs that are both on or both off but never any other case. You can make simplifications like that and get by with less. You can wire up LEDs in opposite polarity and run one, or the other, but not both at once using just two I/O pins. You should look up the ugly term, Charlieplexing, and find out more about various distinct arrangements that can actually be rather different from each other but are lumped under that term just the same.
Master this area and you've got half the battle won.
When I teach MCUs to students there are two starting subjects:
- Switch inputs: monitoring and debouncing dozens of inputs at once, including long-hold and short-hold times to differentiate various modes.
- LED outputs: displaying, multiplexing, and varying under software control the apparent brightness.
When a student has mastered both, I can pretty much release them into the wild and they will get along pretty well.
