¿Por qué algunas de mis señales 'tiemblan' (tienen jitter)?


9

Tengo un bus SPI de 2 MHz, pero una cosa que he notado es que algunas de mis señales a menudo 'tiemblan'. Sí, mi disparador está configurado correctamente, así que no creo que el problema esté ahí.

Puedes ver lo que quiero decir aquí: (esto es con el modo de persistencia activado). Este es el reloj de mi bus SPI.

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

El SPI funciona bien. He transferido cientos de megabytes en varias placas y hasta ahora no he visto ningún problema. Pero todavía estoy interesado en saber cuál podría ser el problema aquí. Además, ¿debería molestarme en arreglarlo incluso si funciona?

Las medidas se tomaron directamente en la fuente con un clip de tierra MUY pequeño.

Este es un esquema simplificado de mi circuito. Por supuesto, la placa tiene más dispositivos SPI, pero a los fines de esta pregunta, esto es exacto porque la placa aún no tiene nada soldado, excepto el uC y la tarjeta SD.

ingrese la descripción de la imagen aquí

El maestro (AVR Mega 128) está ejecutando su oscilador RC interno; no sé si esto sería relevante, pero dado que las señales cambian con el tiempo, es posible que la fluctuación del oscilador RC también termine en el bus SPI. Solo pensé en mencionarlo. También se me ocurrió que durante estas mediciones ejecuté el controlador en un bucle infinito. Aquí está el código:

while(1)
{
    setFirstBitOnDriver(driver); // this sends a 8-bit command on the SPI bus.
    GLCD_SetCursorAddress(40); // Change cursor position on the display.
    GLCD_WriteText("LED: "); 
    for(wire=0;wire<72;wire++)
    {
        itoa(wire+1,str,10);
        GLCD_WriteText(str);
        GLCD_SetCursorAddress(44);
        _delay_ms(10);
        shiftVectorOnDriver(driver); // another command on SPI. 8-bit wide.
    }
}

El jitter / shiver podría ocurrir cuando el interno se ejecuta 72 veces y luego se cierra. Dado que lleva un tiempo adicional ejecutar las primeras tres líneas, podría ser que cada 73a forma de onda llegue en un momento ligeramente diferente debido al tiempo de procesamiento adicional. Si tuviera que apostar, supongo que esta es la causa de mi problema (si pudiera, lo confirmaría en este instante, ¡pero mis tablas en el trabajo y la próxima semana están apagadas!) Pero aún me gustaría recibir opiniones / respuestas de SE sobre este asunto.

Pero teniendo en cuenta que el uC se está ejecutando a 8 Mhz, no tiemblo debido al software, sería en nanosegundos, sino en microsegundos. Pero en la segunda figura se ve una línea plana. Esto ocurre por un breve segundo donde las formas de onda completas cambian en el tiempo y son invisibles en la pantalla. Supongo que esto se debe al bucle y la fluctuación en la primera imagen se debe al oscilador RC.


2
cual es tu gatillo
markrages

@markrages, el disparador se establece en 1,48 V en CH1 - borde ascendente.
Sábado

2
Una suposición es que el uC (mi suposición) que genera la señal de reloj SPI está utilizando un PLL que funciona acortando o alargando algunos ciclos de reloj para mantenerse bloqueado en la referencia. Cuando aparecen esos ciclos de reloj cortos o largos, genera jitter en la traza de su alcance porque los bordes que está viendo vienen antes / después en relación con el borde que activó.
El Photon

1
O el SPI se genera en su bucle principal, pero a veces hay una interrupción que retrasa la ejecución del bucle principal, por lo que nuevamente ve diferencias en el período del bucle.
El Photon

2
La palabra es "jitter", pero se puede decir "temblor" ;-)
stevenvh

Respuestas:


6

Lo que muestra su alcance es un ejemplo clásico de jitter , lo que significa un error en el tiempo de un evento (flanco ascendente o descendente), independientemente de si hay algún ruido de voltaje en la señal.

Pero, ¿qué puede causar la inquietud en su sistema?

  • Como especula, si el reloj principal uC está nervioso, es muy probable que la fluctuación se transfiera directamente a la salida del reloj desde el periférico SPI.

    Una derivación inadecuada (debe tener una derivación masiva adicional en su placa además de los dos condensadores de 100 nF que ha dibujado) podría provocar fluctuaciones en el circuito del reloj de CC.

    El ruido de la fuente de alimentación introducido por otros circuitos en su placa también podría tener este efecto (pero se reduciría con más derivaciones).

  • El jitter podría ser inherente al rendimiento del periférico SPI de uC. Tiene que generar el reloj SPI con referencia al reloj del sistema. Si usa un divisor simple (4 a 1 en el caso del reloj del sistema de 8 MHz y el reloj SPI de 2 MHz) no esperaría ver mucha fluctuación adicional (aunque la fluctuación del reloj del sistema pasaría directamente). Pero si usa un esquema más complejo, como un PLL, ese circuito podría estar variando los anchos de pulso del reloj SPI para mantenerse sincronizado con el reloj del sistema, y ​​lo vería como un jitter. Un circuito PLL también podría ser particularmente sensible al ruido de la fuente de alimentación.

Si la amplitud de la fluctuación de fase se limita a una pequeña fracción del período del reloj, como parece estar aquí, no hay razón para que esta fluctuación de fase cause errores en el bus SPI (de acuerdo con su observación de que el bus SPI parece funcionar como se esperaba) .


Tengo una tapa de derivación de 100nF. en cada par vcc / gnd en cada chip. ¿Aún sugerirías más? Si es así, ¿100nF o 1uF adicionales?
Saad

Si esta inquietud es el peor "problema" de rendimiento en su placa, no necesita cambiar nada. Dependiendo de cuántos otros circuitos hay en su sistema y lo que están haciendo, unas pocas tapas adicionales de derivación de 1, 10 y / o 100 uF repartidas por la placa son una práctica de diseño común. Estos no están localizados en un chip específico, proporcionan omisión "masiva" para toda la placa.
El Photon

Sí, tengo dos tantalios 47u en el tablero para este propósito. Así que debería estar bien en la parte de derivación.
Saad

2
SPI es totalmente sincrónico. Ninguna cantidad de jitter hará que SPI falle.
markrages

@markrages, en la situación de OP, eso es cierto. Sin embargo, en principio, una cantidad de fluctuación de fase realmente extrema podría, por ejemplo, reducir el intervalo entre el borde ascendente y el borde descendente lo suficiente como para violar el tiempo de configuración de la parte esclava y hacer que falle la interfaz. Sin embargo, la inquietud tendría que ser igual a casi la mitad del período de reloj para que esto suceda.
El Photon

6

Esto me parece una señal de inquietud. El período del reloj varía minuciosamente, lo suficiente como para que la persistencia del alcance haga que el borde se vea 'manchado'.

No sé si su alcance Rigol tiene la capacidad de calcular estadísticas cuando mide. Si lo hace, puede ajustar su punto de activación para que su borde de activación aparezca en el borde izquierdo de la pantalla, ajustar la base de tiempo para mostrar un período completo y medir la variación de frecuencia a lo largo del tiempo para tener una idea de la variación. (La inquietud puede verse peor de lo que es cuando el borde del gatillo está fuera de la pantalla).

Si desea reducir las fuentes de jitter, comenzaría con el oscilador RC. Vea si tiene una opción para usar un método de reloj diferente (como un cristal), impleméntelo y vuelva a medir la fluctuación.


¡Lo probará con un oscilador externo tan pronto como se abra el trabajo!
Saad

6

Las imágenes de alcance pueden ser engañosas, y debe observar todos los parámetros para interpretar los datos correctamente. La primera imagen muestra un jitter de 10 ns, y eso no sería tan bueno si el disparador estuviera justo a la izquierda de la pantalla. Pero abajo a la derecha dice disparador + 1.78 µs, por lo que 10 ns es en realidad solo el 0.5% del intervalo de tiempo. Ese nivel de fluctuación puede deberse al oscilador RC. Espere que la fluctuación de fase se reduzca en al menos un orden de magnitud con un oscilador de cristal.

Dice que aún no ha encontrado ningún problema en la transferencia de datos SPI. Eso es gracias a la relatividad del 0.5%. Si desea MOSI 1 µs antes del pulso CLK, la fluctuación de fase del 0.5% causará una fluctuación de fase de 5 ns, esto no violará los tiempos de configuración y retención.

Si necesita tranquilidad, simplemente configure la base de tiempo de modo que pueda ver un tiempo de bits completo, tanto el canal MOSI como el CLK. Notará que la fluctuación de fase apenas será visible y que los bordes sucesivos permanecen bien separados.


Steven, ¿podrías explicar por qué es importante la posición del gatillo? ¿Cómo obtuviste la cifra del 0,5%?
Saad

2
@Saad: el punto de activación es tiempo = 0. Lo que se muestra en la pantalla ocurre 1.78 us = 1780 ns más tarde. Y la fluctuación de 10 ns (más o menos) es la variación de esos 1780 ns, entonces 10 ns / 1780 ns = 0.56%. Se ve tan mal porque está enfocado en ese borde descendente, pero el borde de referencia (el disparador) estará a decenas de metros a la izquierda. Entonces, si se aleja para poder ver el pulso completo, la fluctuación se verá mucho más pequeña. Si el punto de activación quedara a la izquierda de la pantalla, digamos a -100 ns, entonces la fluctuación de fase de 10 ns sería del 10%.
stevenvh

1

La inquietud es una forma de ruido. Si considera que los tiempos entre llegadas entre los bordes de los pulsos son una especie de señal, entonces si esos bordes no fluctúan en absoluto, ¡significa que su sistema exhibe una señal libre de ruido!

Las ondas cuadradas a menudo se generan mediante el umbral en una onda más continua, con algún circuito de tipo disparador Schmidt que tiene un comportamiento de histéresis. Los osciladores de cristal o RC no emiten "nativamente" ondas cuadradas.

Entonces, si esa onda de entrada tiene algo de ruido de voltaje, ese ruido se traducirá en ligeros cambios en la activación, ya que el voltaje alcanza a veces alcanza cualquier umbral cada vez más temprano.

Y así, el ruido de un tipo (ruido de voltaje) se convierte en ruido de otro tipo (ruido de temporización).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.