¿Es normal tener un reloj SPI con un ciclo de trabajo variable?

Verá aliasing en su captura, no fluctuación de reloj, un caso de herramienta incorrecta para el trabajo.

Un reloj de 2Mhz tiene un período de 500ns, por lo que es alto para 250ns. Con un analizador lógico de 16 MHz, está tomando muestras cada 62,5 ns, por lo que lo ideal sería ver 4 muestras altas y 4 muestras bajas repitiéndose.

Ahora considere el efecto de una minúscula diferencia de 0,5% en la frecuencia en el oscilador de la CPU, por lo que la red divisoria hasta el bus SPI ahora funciona con un período de 251,25 ns. Nota: la frecuencia no se desvía con el tiempo, sigue siendo un cristal ideal, pero la forma de onda que intentamos capturar ya no es un múltiplo exacto del reloj de captura de 62,5 ns. Esto le proporciona un alias con patrones de 4/4, 3/5, 4/4, 5/3,... como la relación alta/baja en su captura mientras observa la relación de fase entre los dos relojes entrando y saliendo.

Su analizador sigue siendo bueno para capturar las señales SPI (por encima de Nyquist, etc.), pero no es adecuado para juzgar la estabilidad del reloj. Para eso, use un visor activado en un borde para ver la estabilidad del otro borde y un contador de frecuencia calibrado para verificar la frecuencia absoluta.

Dado que SPI es un protocolo síncrono, la frecuencia exacta en cualquier momento realmente no importa. Todo está conectado a los bordes del reloj, por lo que el tiempo exacto entre los bordes realmente no importa, dentro de los límites del dispositivo, por supuesto.

Hay varias formas en que se pueden generar las señales SPI. En algunos casos, un dispositivo tendrá hardware al que se le puede indicar que envíe el contenido de un cierto rango de memoria al puerto SPI sin la intervención del procesador. En tales casos, generalmente habrá una secuencia uniforme de pulsos de reloj, aunque es posible que haya una "pausa" después de cada octavo. En algunos casos, un procesador necesitará cargar cada byte en un desplazador que sea capaz de aceptar al menos un byte "antes" del que se desplaza. La salida en esos casos a menudo se verá como la del caso de hardware puro, excepto que ocasionalmente puede haber espacios aleatorios después de múltiplos de ocho relojes si el software ocasionalmente no puede cargar el siguiente byte antes de que el byte presente se desplace, pero dependiendo de el procesador' s momento que nunca podría ocurrir. En los casos anteriores, el uso de funciones de activación retardada en un osciloscopio puede ser útil cuando se examinan datos con formato regular, porque todo sucederá siempre (o casi siempre) en un momento constante en relación con el inicio de un cuadro.

Sin embargo, las cosas no siempre son tan agradables. Es bastante común que los dispositivos tengan hardware que pueda enviar 8 bits automáticamente, pero requieren que el software espere hasta que se envíe un grupo de 8 antes de poner en cola el siguiente. Esto crea grupos de 8 pulsos de reloj espaciados regularmente, con espacios aleatorios entre ellos. Esto a menudo impide el uso de funciones de barrido retardado, pero por otro lado, a menudo hace que la identificación del inicio y la finalización de cada byte sea más fácil de lo que sería si todos los pulsos fueran uniformes. La última posibilidad es que el software pueda estar generando una señal SPI mediante el uso de una secuencia de comandos "establecer puerto alto" y "establecer puerto bajo". Eso es lo que parece estar sucediendo en el ejemplo anterior.

En la mayoría de los casos, el dispositivo maestro en un bus SPI (el RasPi en este caso) es libre de usar cualquier combinación de pulsos largos y cortos que crea conveniente, sujeto solo a limitaciones en ciertos tiempos de pulso mínimos y, ocasionalmente, tiempos de pulso máximos que son a menudo órdenes de magnitud por encima de los mínimos (por ejemplo, un dispositivo puede tener un ancho de pulso mínimo y una separación de pulso de 250 ns cada uno, pero un tiempo máximo entre pulsos de 1 ms, más de tres órdenes de magnitud de diferencia). Siempre que los tiempos de los pulsos se mantengan dentro de los límites muy generales (y en muchos casos no habría un límite máximo), la comunicación debería ser fiable.

El único momento en que es probable que se pierdan datos con SPI es cuando el dispositivo esclavo es un procesador. El hardware esclavo SPI integrado en muchas CPU requiere que cuando llega un byte, el procesador debe actuar antes de que el maestro comience a enviar el siguiente byte para evitar la pérdida de datos, pero no proporciona ningún medio por el cual el esclavo pueda decirle al maestro que está listo; en consecuencia, los esclavos a menudo necesitan usar cinco líneas para comunicarse con el maestro (reloj, MOSI, MISO, CS y una línea "lista" implementada manualmente) o requieren que el maestro agregue un retraso después de cada byte suficiente para acomodar el Tiempo de respuesta en el peor de los casos del esclavo.