Back in 1995 Charlie discovered a way to drive large led matrices using a small number of pins. His technique makes use of the fact that many microcontrollers have tri-state outputs, and the fact that diodes pass current in only one direction.
This app note by Maxim describes how to implement charlieplexing to drive 8 digit 7 segment display with decimal points using only 9 pins. There are some drawbacks to this approach though, a 450Hz frequency is required to drive the segments. And since the duty cycle is considerably shorter, currents per a single segment have to be higher to achieve the same brightness.
The complexity of this design makes it almost impossible to route the board on a single layer. But all in all when pins are in short supply this is one way to lighten the pin count.
This is the best, brief introduction I’ve read on Charlieplexing. It gets right to the shortcomings of the technique in the second and third paragraphs. Charlieplexing became quite popular in the DIY world, but I think that many folks did not realize how quickly the approach suffers. Try this with hundreds of LEDs instead of “only” 64! It’s a great way to maximize a limited number of pins, but I think it’s important to keep those limitations in mind.
Here’s another limitation to add to the list: It seems that Charlieplexing requires custom code for each combination of LEDs. I anticipate that it would be much harder to implement a generic piece of firmware which would allow a non-programmer to wire up their own random collection of LEDs to pins.
In contrast, the more typical LED matrix, with its scanned columns and segregated rows, is much easier to implement in a generic piece of firmware. Thus, the non-programmer can enter in a variable number of column bits, and a variable number of row bits, and so long as there are enough I/O pins it should work with a generic firmware loop that checks for the specific boundaries. The DIYer can even skip random column+row intersections in their wiring without excessive tradeoffs in brightness or scan rate.
I suppose it would be possible to write firmware that scanned an arbitrary ground of Charlieplexed LEDs, but the consequences of skipping a particular intersection when wiring would be more dire, or the software would have to be significantly more complex to skip over the holes in the Charlie “matrix” to keep the brightness up.