El uso de un canal de temporizador de hardware evitará que el procesador tenga que prestar atención constante al puerto de salida del servo (que se produce a expensas de la capacidad de prestar atención a otras tareas de software).
Es probable que también reduzca el jitter o el variación de tiempo a tiempo, lo que puede resultar si el procesador toma una cantidad variable de ciclos de reloj para dejar de hacer lo que estaba haciendo. y hacer un cambio de contexto al código que cambia la salida. Cuanto más complejas sean las otras tareas requeridas del procesador, más probable será que el jitter sea un desafío.
Dicho esto, la mayoría de los servos esperan un pulso solo 50 veces más o menos por segundo, lo que podría llevar solo 100 eventos por segundo al servicio. Un sistema compacto sin otras responsabilidades apremiantes puede hacer eso razonablemente. En contraste, algo más parecido a una PC con un sistema operativo multitarea puede tener problemas para ejecutar eventos con un tiempo regular. Un "sistema operativo en tiempo real" intenta proporcionar lo mejor de ambos mundos: eventos de constante latencia baja y la capacidad de programar una variedad de tareas más abstractas.
En última instancia, no estoy seguro de cómo respondería un servo a un poco de jitter. Es poco probable que el sistema pueda moverse mecánicamente mucho dentro del período de 20 ms entre pulsos, pero tal variación podría evitar que el bucle del servo se asiente y, en cambio, mantenerlo activando el motor de "búsqueda" para una posición adecuada. Sin embargo, muchos servos baratos del tipo que las personas compran para los productos de microcontroladores de hobby pueden terminar haciendo eso solo de todos modos.