Por que alguns dos meus sinais 'tremem' (têm tremulação)?

Eu tenho um barramento SPI de 2 MHz, mas uma coisa que notei é que alguns dos meus sinais frequentemente 'tremem'. Sim, meu gatilho está configurado corretamente, então não acho que o problema esteja lá.

Você pode ver o que quero dizer aqui: (isso está com o modo persistência ativado). Este é o relógio do meu ônibus SPI.

O SPI funciona bem. Transferi centenas de megabytes em várias placas e ainda não vi um problema. Mas ainda estou interessado em saber qual poderia ser o problema aqui. Além disso, devo me preocupar em corrigi-lo, mesmo que funcione?

As medições foram feitas na fonte com um clipe de terra MUITO pequeno.

Este é um esquema simplificado do meu circuito. Obviamente, a placa possui mais dispositivos SPI, mas, para os fins desta pergunta, isso é preciso, pois a placa ainda não possui nenhuma solda, exceto o uC e o cartão SD.

O mestre (AVR Mega 128) está fugindo de seu oscilador RC interno - não sei se isso seria relevante, mas como os sinais mudam no tempo, é possível que o tremor do oscilador RC também esteja terminando no barramento SPI. Só pensei em mencionar. Também me ocorreu que, durante essas medições, eu executei o controlador em um loop infinito. Aqui está o 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.
    }
}

O tremor / tremor pode ocorrer quando o interno é executado por 72 vezes e depois sai. Como leva um tempo adicional para executar as três primeiras linhas, pode ser que cada 73ª forma de onda chegue em um momento ligeiramente diferente devido ao tempo de processamento adicional. Se eu tivesse que apostar, acho que essa é a causa do meu problema (se pudesse, eu o confirmaria neste instante, mas meus conselhos estão no trabalho e a próxima semana está fora!) Mas eu ainda gostaria de opiniões / respostas da SE sobre este assunto.

Mas, considerando que o uC está rodando a 8 Mhz, não faço jitter devido ao software, porque em nanossegundos, mas em microssegundos. Mas na 2ª figura uma linha plana é visível. Isso ocorre por um breve segundo em que todas as formas de onda mudam no tempo e ficam invisíveis na tela. Suponho que isso se deva ao loop e o tremor na primeira foto se deva ao oscilador RC.

O que o seu escopo mostra é um exemplo clássico de instabilidade , o que significa um erro no tempo de um evento (borda ascendente ou descendente), independentemente de haver algum ruído de tensão no sinal.

Mas o que pode causar a instabilidade no seu sistema?

• Como você especula, se o relógio principal do uC estiver instável, esse instante provavelmente será transferido diretamente para a saída do relógio do periférico SPI.

  Desvio inadequado (você deve ter desvio adicional em massa na sua placa, além dos dois capacitores de 100 nF que você desenhou) pode causar tremulação no circuito de clock do uC.

  O ruído da fonte de alimentação introduzido por outros circuitos na sua placa também pode ter esse efeito (mas seria reduzido por mais desvios).

• O tremor pode ser inerente ao desempenho do periférico SPI do uC. Ele precisa gerar o relógio SPI com referência ao relógio do sistema. Se ele usa um divisor simples (4 para 1 no caso do relógio do sistema de 8 MHz e do relógio SPI de 2 MHz), você não esperaria ver muito jitter adicionado (embora o jitter do relógio do sistema passasse direto). Mas se ele usar um esquema mais complexo, como um PLL, esse circuito poderá variar as larguras de pulso do relógio SPI para se manter sincronizado com o relógio do sistema, e você o verá como tremulação. Um circuito PLL também pode ser particularmente sensível ao ruído da fonte de alimentação.

Se a amplitude da instabilidade estiver limitada a uma pequena fração do período do relógio, como parece estar aqui, não há razão para que essa instabilidade cause erros no barramento SPI (de acordo com sua observação de que o barramento SPI parece funcionar conforme o esperado) .

Isso parece sinal de jitter para mim. O período do relógio varia minuciosamente, o suficiente para que a persistência do escopo faça com que a borda pareça 'manchada'.

Não sei se o seu escopo Rigol tem a capacidade de calcular estatísticas quando é medido. Caso isso aconteça, você pode ajustar seu ponto de disparo para que o limite do gatilho apareça na borda esquerda da tela, ajuste a base de tempo para mostrar um período completo e medir a variação de frequência ao longo do tempo para ter uma ideia da variação. (O tremor pode parecer pior do que quando a borda do gatilho está fora da tela.)

Se você quiser diminuir as fontes de instabilidade, eu começaria com o oscilador RC. Veja se você tem a opção de usar um método de relógio diferente (como um cristal), implementá-lo e medir novamente a instabilidade.

Imagens de escopo podem ser enganosas, e você precisa examinar todos os parâmetros para interpretar os dados corretamente. A primeira imagem mostra um tremor de 10 ns, e isso não seria tão bom se o gatilho estivesse apenas no lado esquerdo da tela. Mas no canto inferior direito, ele diz disparar + 1,78 µs, de modo que 10 ns é na verdade apenas 0,5% do intervalo de tempo. Esse nível de instabilidade pode ser devido ao oscilador RC. Espere que o jitter seja reduzido em pelo menos uma ordem de grandeza com um oscilador de cristal.

Você diz que ainda não encontrou nenhum problema na transferência de dados SPI. Isso é graças à relatividade de 0,5%. Se você usar MOSI 1 µs antes do pulso CLK, o tremor de 0,5% causará um tremor de 5 ns, isso não violará os tempos de configuração e de espera.

Se você precisar de segurança, defina a base de tempo de forma que possa ver um tempo de bits completo, tanto no canal MOSI quanto no CLK. Você notará que o tremor dificilmente será visível e que as arestas sucessivas permanecerão bem separadas.

Jitter é uma forma de ruído. Se você considerar os tempos de chegada entre as bordas dos pulsos como um tipo de sinal, se essas bordas não tremerem, isso significa que o sistema exibirá um sinal sem ruído!

Ondas quadradas são frequentemente geradas por limiar em uma onda mais contínua, com algum circuito do tipo Schmidt-trigger que possui comportamento de histerese. Os osciladores de cristal ou RC não "nativamente" emitem ondas quadradas.

Portanto, se essa onda de entrada tiver algum ruído de voltagem, esse ruído será traduzido em pequenas mudanças no disparo, pois a voltagem atinge às vezes atinge um dos limiares mais cedo e outras vezes.

E assim, ruído de um tipo (ruído de tensão) se transforma em ruído de outro tipo (ruído de temporização).