But if you want RGB LEDs, you can drive only ten LEDs with a single 16F630 -- which means you'd need nine to bridge 90cm. That's pretty steep, cost-wise.
So then I thought that by using a microcontroller with more pins, I could increase the number of RGB LEDs I could drive. For instance, using ten pins of my beloved workhorse 16F628A, I could drive 90 leads, which makes for 30 RGB LEDs.
But if I would drive 30 RGB LEDs, why wouldn't I use the same technique to drive 90 monochrome LEDs? Using the same number of microcontrollers, whether it's a monochrome rail or a RGB rail, would be silly. And you know me: I find it a challenge to squeeze the maximum out of the hardware.
I need three bytes per LED that is currently occupying a space anywhere on the segment: one to hold the speed, one to hold the count-down until it has to go to the next space, and one to hold which space it is occupying anyway. This means that I need, at least, 270 bytes of general purpose memory. Of course, I'll also need to keep track of several other parameters, so my actual memory needs will be even higher.
The 16F628A has 'only' 224 bytes of general purpose memory. That's not enough, if every space is occupied. Of course, that will/should never happen. If I choose to limit the number of spaces that can be occupied to 70, then I need 210 bytes to keep track of everything, with 14 bytes to spare!
Sure, I could go for the 16F648A (which has slightly more memory with easier memory organisation for my application), or the 16F87 which has a whopping 368 bytes of general purpose memory. But those are all more expensive: the 16F628A costs $2.20 at Futurlec, and the 16F648A $3.20 and the 16F87 $3.30. Sure, it won't break the bank, and if I ever do need to adress all of the positions, I'll be sure to use those PICs with larger memory. But the 16F628A is in abundant supply (or "easy to source"), and I already know how to use it. And I don't think the limit of 70 positions will ever be reached for a single segment.