Servo responde al probador de servo, no al microcontrolador. Las señales se ven iguales

Primero, un aparte rápido. Parece que tienes un ligero malentendido sobre cómo funcionan los servos. Los servos no están controlados por PWM, y no saben ni les importa que estés enviando pulsos a 49, sea cual sea el Hz. No saben que el pulso es un porcentaje de un período arbitrario. Al servo no podría importarle menos cuál es el tiempo entre pulsos. Digo esto porque pareces inusualmente concentrado en cosas que en realidad no importan.

Los servos ni siquiera saben o no les importa si el voltaje es alto o bajo en un momento dado. Solo les importa una cosa: el tiempo entre un flanco ascendente y un flanco descendente.

El servo se controla detectando un borde de voltaje ascendente y midiendo el tiempo hasta que hay un borde descendente. Los tiempos válidos suelen estar entre 1,0 y 2,0 ms, pero pueden variar de un servo a otro.

Puede controlarlo a 1 Hz, 10 Hz, 50 Hz, 100 Hz. La mayoría responderá a frecuencias de pulso aún más altas, pero nuevamente esto es variable. Lo que estoy tratando de decir es que la frecuencia, el ciclo de trabajo, la duración entre pulsos, todo no podría ser menos relevante para su problema, que es que el servo no responde cuando lo espera.

Lo único que es relevante son los bordes de tu pulso, a los que no has prestado atención. Si quiere resolver esto, comience por mirar las cosas que importan, proporcione capturas de cerca de los bordes de su pulso, ese tipo de cosas. No capturó nada útil en esas capturas de pantalla, por lo que probablemente no parece haber ningún problema o diferencia. Hay muchos problemas o diferencias que nunca serían visibles con lo que ha medido.

Lo que puedo ver es que la captura del tren de pulsos que no funciona está notablemente más sucia, tanto el pulso como el suelo, que cualquiera de los otros. Lo cual es extraño, ya que debería estar llamando a la misma función que los demás. ¿Por qué ese es mucho más ruidoso?

Más importante aún, en la captura que no funciona, mire el 'tiempo de caída'. 809µs? Su osciloscopio cree ver un tiempo de caída que dura 0,8 ms. Eso es malo. Claramente eso es incorrecto, pero el hecho permanece, eso es lo que mide.

Ese es un signo clásico de un borde sucio. Piénsalo. Si este pulso está engañando a su equipo de prueba de gama alta, que es su osciloscopio, para que vea un borde ridículamente largo o un tiempo de caída, o tal vez tan sucio que simplemente no puede detectar correctamente el borde descendente todo el tiempo (o quién sabe), entonces ¿Qué posibilidades tiene ese pobre servo de $ 8 de mierda de recoger un borde descendente decente?

Si un servo no obtiene un pulso válido (por ejemplo, si el flanco descendente tarda demasiado, está demasiado sucio o se pierde) dentro del rango de pulso aceptable, y los servos calculan por los flancos que pueden o no tener algo que haga con lo que considere que son los bordes del pulso, entonces responde como si estuviera apagado.

En otras palabras, no solo no se mueve, sino que no resistirá el movimiento de su eje. Simplemente estará fláccido, exactamente como lo estás viendo.

Ahora, esto plantea la pregunta... ¿por qué llamar a servo.write afectaría la calidad del borde?

Dijiste un clon. ¿Como éste?

Estos clones en particular tienden a comportarse de manera errática debido al desacoplamiento increíblemente pobre. Debería haber condensadores de desacoplamiento en cada pin de alimentación y lo más cerca posible del mega2560. Y en el arduino real, de hecho los hay. Sin embargo, en estos clones, están demasiado lejos, o quizás faltan, es difícil saberlo. Es obvio al mirar el tablero que no se comportará de manera confiable, eso es lo importante.

Entonces, ¿cuál es la diferencia?

Cuando llama a servo.write, empuja la pila más alto que si llama a writeMicroseconds. Dado el puntero de pila de 3 bytes del mega2560 (17 bits), tiene que voltear un montón de bits críticos que no tiene que hacer cuando llama a writemicroseconds. Sé que esto parece una diferencia poco probable, pero he experimentado una buena cantidad de microcontroladores mal desacoplados, y los atmegas en particular parecen exhibir un comportamiento extraño específicamente cuando usan temporizadores y/o empujan o abren la pila. Me sucedió algo similar, solo que la pila se corrompió cuando intentaba controlar los LED con PWM, pero si puse todo en línea sin empujar la pila, funcionó. El desacoplamiento deficiente fue en última instancia el problema.

Esperaría que un desacoplamiento deficiente pueda, por razones conocidas por atmega2560 y nadie más, tener un efecto perjudicial en la calidad del borde de ese pulso, pero solo cuando está empujando la pila justo antes. Este servo simplemente no es capaz de manejar la forma en que se ensucian esos bordes, por lo que no ve pulsos válidos en ese caso. Otros servos obviamente lo manejan.

Desacoplar cosas siempre es extraño e hiperespecífico como este. Por eso es tan importante el desacoplamiento. Mantenga a raya los problemas de pesadilla que la falta de capacitancia puede causarle con tapas de cerámica bonitas y gordas y tan cerca del chip como sea físicamente posible.

Esto puede estar relacionado con la configuración del pin de salida realizada por la rutina .write(). Intente usar una resistencia desplegable de 1K, si no funciona, retírela y utilícela. esto equilibrará el efecto de cualquier resistencia pull-up/pull-down de semana interna que pueda establecer la rutina. Cuando está midiendo la señal con su alcance, la resistencia interna de la sonda actúa como un pull-down.
La mayoría de los servos también liberarán energía al motor interno si la señal no está preestablecida para 10 pulsos seguidos. Esto se utiliza para ahorrar energía.