Currently the Servo library is limited to 12 signals. I have some ideas about greatly expanding that number, which I'll get to in a moment. You need to understand more about how the Servo library and servo control signals work first.
Please keep us updated as you get into this project, especially with photos. The honest reality is I'm not going to touch the Servo library based only on an ambitious plan.... but when you're actually building this project, if you really do connect 20-some servo motors and post good photos, code, measurement and other info, I'll work on the Servo library for you.
Before I get into details, the main point is interrupt latency and the number of hardware timers are what matters, not raw CPU speed. Doubling the CPU speed only helps slightly, in that a faster CPU will have slightly less interrupt latency with the same software. The software design and its use of hardware timer resources is what makes a dramatic difference. Overclocking the CPU isn't very risky, but for this application, the benefit is small.
Normally you don't need to know how servo signals and the Servo library works. You just connect the 1 control signal to a digital pin and use the library to set the angle. Then your main challenge is coding to make all those angles at the right times... and also a big enough power supply so all those motors can work. But if you're going to start thinking and talking about the Servo library design, then you really must understand how servo control signals work.
The signal is a pulse that repeats approximately 44 to 50 times per second. The width of the pulse tells the servo motor what angle you want. A 1.5 ms pulse indicates the middle of the range (90 degrees). The range is 0.544 ms to 2.4 ms.
The Servo library uses a hardware timer. Suppose you've written an angle that corresponds to a 0.9 ms pulse. When it's time to output the pulse, it sets you motor's pin high, then configures the timer to create an interrupt in 0.9 ms. This takes very little CPU time. For the next 0.9 ms, the library does nothing. Your program gets to run with all the CPU time. Then at 0.9 ms, the interrupt occurs and the Servo library drives that pin low. It then moves on to the next servo, setting its pin high and setting the timer to create another interrupt when that next motor's signal needs to end.
This process is repeated for all the motors you're currently using. After the last motor, it compares the total time spent creating all the signals. If you have just 1 motor and it's at 0 degrees, the time will be only 0.544 ms. If less than 20 ms has been spent, it then configures the timer to create an interrupt after 20 ms less the time spent creating the signals. That's important, because many servos can not accept more than 50 pulses per second.
If you have a lot of servos in use and they all had higher angles, the total time spent might already be more than 20 ms. For example, 12 servos all at 2.4 ms will be 28.8 ms. In that case, the Servo library skips the wait time, since it's already spent more than 20 ms. It just begins the pulse to the first servo again. But 12 servos all at their center position is only 18 ms, so the Servo library would wait another 2 ms before beginning the pulse to the first motor.
One simple thing you can do, which I suggested above, is just increase the number from 12 to, well, at that time 16. Now you're using 23? That's quite a few more than 12, but you could give it a try anyway. Now that you understand how this work, you'll know that to really test if 23 will work, you would need to write a little program that creates 23 Servo library objects and sets them all to their maximum 180 degree angle. Even if you only physically connect 1 motor, the library will be creating 23 signals. You could use an oscilloscope or a multimeter in frequency mode to check how often the signals are updating. But it's pretty easy math... 23 signals at 2.4 ms each is a total of 55.2 ms, which is 18.1 Hz.
The big question, which you can answer (and I really hope you will) is whether your servo motors work with an 18.1 Hz update rate? Just edit Servo.h to increase to 23 instead of 12. Then write a little test program, or modify the Servo library sweep example, so it creates 23 instances and sets all the unused ones to the max angle. If your motor works and is responsive, then you're good to go!
I mentioned some ideas earlier. Now I want to be clear, I am indeed willing to rewrite the Servo library on Teensy3. I wrote the version that currently works on Teensy3, patterned after Michael Margolis's design. But other than this long-winded message, I'm really going to be looking for you to get involved before I put in a lot of work. I really hope you do. This first simple test with 23 signals, 1 motor connected, and maybe a multimeter to check the frequency, and most definitely a photo, would be a very good first step.
So if I rewrite Servo, inspired by your project (and your effort to test and post real results here), I would try to use multiple timers. Servo already has this on AVR chips with more than one 16 bit timer. Each 16 bit timer generates 12 outputs. When you use 13, 14, 15, etc, it begins using another timer, effectively creating 2 sets of outputs. The downside to this, on AVR, is each 16 bit timer also creates PWM signals and might be needed for other libraries, so you lose some other functionality for each timer consumed.
On Teensy3, I wanted to avoid this loss of PWM and use of many other libraries. So instead of using the main timers, I used a special programmable delay timer. Currently no other library uses that timer, so on Teensy3 you can use Servo without messing up anything else. I ported Servo and designed it to use that timer early-on, only weeks after Teensy3's release last year. At the time, the IntervalTimer stuff didn't exist, so there was no easy way to share the pool of 4 programmable interval timers. Now, many months later, we do have IntervalTimer and several libraries and projects are using it. The nice thing about IntervalTimer is the 4 hardware timers (none of which are needed for PWM) are in a shared pool.
One idea I've had is redesigning Servo so it could draw upon any unused IntervalTimer capability when you go beyond 12 motors (without slowing the update rates by adding more motors per timer). Since there are 4 of those timers, in theory this could expand to 60 motors using the 4 interval timers and 1 delay block timer. Of course, there's only 34 I/O pins, so you can't possibly have more than 34 motors connected.
Even though this message is already long, one other issue to mention is interrupt latency. Since Servo is setting the pins high and low based on elapsed time when an interrupt occurs, anything that delays response to the interrupt will lengthen the signal (and shorten the next motor's signal). The millis() time update, USB activity, serial port use and other libraries all use interrupts. Software can also disable interrupts, which is critically important while accessing shared data. But other interrupts or disabling interrupts temporarily can cause jitter on your servo outputs. On Arduino, the SoftwareSerial library is the worse. Teensy3 has relatively few libraries that disable interrupts for lengthy times, partly because it's so much faster than AVR, partly because there are more on-chip peripherals and some of the worst libraries on Arduino either don't exist or use alternate ways on Teensy3.
Another feature Teensy3 has, which currently isn't being used, is nested interrupt priority. I've considered having Teensyduino initialize all the interrupts for a default "medium" priority level. Then some libraries like Servo could set higher priority. This hasn't been done yet, mainly because it simply hasn't been much of an issue for anyone. So again, if you're really going to be connecting 20-some motors, please keep in contact and please post good info (eg, photos, code schematics, etc) as you go.
Teensy3 has a tremendous amount of potential to make huge animatronic servo motor projects possible. But it's not the raw CPU speed that truly matters. Careful use of timers and interrupts are the key.... stuff the Servo library does for you. If the current library isn't capable of really supporting a large number of motors, I really would like to work to improve it. But that can only happen if you participate with good updates and info. How much I work on Servo, for the sake of your project, will really depend on how well you post updates and share good info. If you post photos, code, and measurements as you go (without lots of back and forth trying to get the info posted), that will help immensely.
