But most people find themselves using more servos than there are PWM channels available.
I believe it would be useful to have a 'center servo' program that uses PWM - just because it is more accurately linked to the processor clock.
Whereas the current program is susceptible to various things: especially code optimization - which is probably why you supply a compiled HEX file rather than source code.
I find that servos which have been exactly centered using the current 'delay' routine and are then connected via PWM do tend to behave differently. So I guess it comes down to which is more accurate: PWM or delay cycles - my bet would be on the first.
Accurate 'centering' is key to then allowing the same servo to be driven via PWM or via delays - and you need to expect that they will behave the same in both scenarios. This hasn't been my experience - which tends to end up with servos tied up to certain boards.
Given the relative cheapness of an ATMega8 then I have a dedicated board which only has the headers for the PWM output pins. I use another board to program it - so I don't even need the AVR/ISP connector pins. I use this board for nothing else other than for centering servos via PWM. It may seem like a luxury but at least I know that all my servos have been set the same way.
Does it matter what the delay cycle is after the pulse sent to the servo?
I know that most of you guys hate C++ but this is an example of where it really helps. The standard $50 code will just waste time in order to make sure that signals aren't sent to the servo too quickly. In C++, as per my library in the tutorials, I keep track of when the last command was sent and so will ignore any new commands that occur in the rest of the cycle time. So rather than ALWAYS wasting 20ms it can return immediately to allow the rest of your code to work at full speed and will only issue a new command to the servo once the 20ms 'breathing period' has elapsed.