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

Question

Estoy trabajando para conseguir un SPI de interconexión del módulo de radio en Linux embebido sistema. Este módulo concreto (RFM12B) ya está portado a la Raspberry Pi. Ahora estoy trabajando en OMAP4 de los sistemas basados en.

Me di cuenta de que en la Raspberry Pi, SPI del Reloj genera constante de 50% de ciclo de trabajo. En mi OMAP4 tablas, varía entre 2 o 3 valores. Los valores en las capturas de pantalla son: 33.3%, 42.9%, 40.0%, y el 42,9%. Mi analizador lógico es medir a 16MHz, mientras que el SPI del reloj corren un poco más de 2 mhz.

Simplemente estoy enviando un texto al azar, como el de abajo:

echo "HELLO!!" > /dev/spidev1.0

Estoy muy confundida porque creo que esto podría ser la causa de desbordamiento de búfer y diferencias, eventualmente, llegar CRC16 fracaso en el extremo receptor.

Answer 1

Ver aliasing en su captura, no jitter de reloj, el caso de la herramienta equivocada para el trabajo.

Un 2 mhz reloj tiene un 500ns período, por lo que es alto para 250ns. Con un 16Mhz lógica analizador está tomando muestras cada 62.5 ns, por lo que idealmente le gustaría ver 4 muestras, 4 bajo de muestras de la repetición.

Ahora, considere el efecto de un exiguo 0,5% de diferencia en la frecuencia de la CPU del oscilador, por lo que la red de divisor de abajo en el bus SPI ahora se ejecuta con un 251.25 ns período. Nota: la frecuencia no cambian a través del tiempo, es todavía un cristal ideal, pero la onda que estamos tratando de capturar no es un múltiplo exacto de la captura de reloj 62.5 ns. Esto le da aliasing con los patrones de 4/4, 3/5, 4/4, 5/3,... como el hi/low ratio en su captura, mientras observa la relación de fase entre los dos relojes a la deriva dentro y fuera.

Su analizador aún es buena para la captura de las señales SPI (por encima de Nyquist, etc), pero no es adecuado para juzgar el reloj de la estabilidad. Para ello, utilice un ámbito activa en uno de los bordes para ver la estabilidad de la otra orilla y un calibrado contador de frecuencia para comprobar la frecuencia absoluta.

Answer 2

Puesto que el SPI es un protocolo síncrono la frecuencia exacta en cualquier un punto en el tiempo no importa. Todo está codificado a los bordes del reloj, por lo que la sincronización exacta entre bordes realmente no importa - dentro de los límites del dispositivo por supuesto.

Answer 3

Hay un número de maneras en que los SPI señales pueden ser generados. En algunos casos, un dispositivo de hardware que puede ser instruido para enviar el contenido de un cierto rango de memoria para el puerto SPI sin procesador de intervención. En tales casos, no será generalmente uniforme de la secuencia de impulsos de reloj, aunque es posible que haya una "pausa" después de cada octava. En algunos casos, un procesador tendrá que cargar cada byte en una palanca de cambios que es capaz de aceptar al menos un byte "en avance" de la que se desplaza. El resultado en estos casos a menudo se verá como que desde el puro hardware caso, excepto que en ocasiones puede ser al azar lagunas después de múltiplos de ocho relojes de si el software falla ocasionalmente para cargar el siguiente byte antes de que el actual byte se desplaza hacia fuera, pero dependiendo del procesador del momento en el que podría no ocurrir nunca. En los casos anteriores, el uso de retraso de activación de funciones en un ámbito puede ser útil al examinar regularmente los datos con formato, porque todo lo que siempre (o casi siempre) a pasar en una hora consistente en relación con el comienzo de un marco.

Las cosas no son siempre tan agradable, aunque. Es bastante común que los dispositivos de hardware que puede enviar los 8 bits de forma automática, pero requieren de un software que esperar hasta que uno de los del grupo de los 8 se envía antes de enqueueing la siguiente. Esto crea grupos de 8 regularmente espaciados impulsos de reloj, con una cantidad de espacio entre ellos. A menudo, esto excluye el uso de retraso-barrido de funciones, pero por el otro lado a menudo hace que la identificación de inicio y parada de cada byte más fácil de lo que sería si todos los pulsos eran uniformes. La última posibilidad es que el software puede ser la generación de un SPI de la señal mediante el uso de una secuencia de "configuración de puerto de alta" y "puerto" bajo de comandos. Que es lo que parece estar sucediendo en el ejemplo anterior.

En la mayoría de los casos, el dispositivo maestro en un bus SPI (la RasPi en este caso) es libre de usar cualquier combinación de largo y corto pulsos se considere oportuno, con sujeción únicamente a las limitaciones en ciertos mínimo de pulso de los tiempos y, en ocasiones, la máxima del pulso de los tiempos, que a menudo son órdenes de magnitud por encima de los mínimos (por ejemplo, un dispositivo puede tener un mínimo de ancho de pulso y el pulso de la separación de 250ns cada uno, pero un máximo de tiempo entre los pulsos de 1ms--más de tres órdenes de magnitud de diferencia). Siempre que el pulso de los tiempos de estancia dentro de la muy amplia, dibujado los límites (y en muchos casos no habría límite máximo) la comunicación debe ser confiable.

La única vez que la pérdida de datos es probable que con el SPI es cuando el dispositivo esclavo es un procesador. El SPI esclavo de hardware incorporado en muchas CPUs requiere que cuando un byte llega, el procesador debe actuar antes de que el maestro comienza a enviar el siguiente byte para evitar la pérdida de datos, pero no proporciona ningún medio por el cual el esclavo puede decir que el maestro está listo; en consecuencia, los esclavos a menudo necesitan utilizar cinco líneas para comunicarse con el maestro (reloj, MOSI, MISO, CS, y un manual implementado el "listo" de la línea) o bien requieren que el maestro añadir un retardo después de cada byte suficiente para acomodar el peor de los casos el tiempo de respuesta del esclavo.