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

9

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.

insira a descrição da imagem aqui

insira a descrição da imagem aqui

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.

insira a descrição da imagem aqui

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.

Saad
fonte
2
qual é o seu gatilho?
Markrages
@markrages o gatilho é ajustado em 1,48V no CH1 - borda ascendente.
Saad
2
Um palpite é que o uC (minha suposição) que gera o sinal do relógio SPI está usando uma PLL que funciona diminuindo ou prolongando alguns ciclos do relógio para manter-se bloqueado na referência. Quando esses ciclos de relógio curtos ou longos surgem, gera tremulação no rastreamento do seu escopo, porque as arestas que você está vendo vêm mais cedo / mais tarde em relação à aresta da qual você disparou.
O fóton
11
Ou o SPI é gerado no seu loop principal, mas às vezes há uma interrupção que atrasa a execução do loop principal, então novamente você vê diferenças no período do loop.
O Photon
2
A palavra é "jitter", mas você pode dizer "arrepio" ;-)
stevenvh

Respostas:

6

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) .

O fóton
fonte
Eu tenho um limite de desvio de 100nF. em cada par vcc / gnd em cada chip. Você ainda sugeriria mais? Em caso afirmativo, tampas adicionais de 100nF ou 1uF?
Saad
Se esse tremor é o pior "problema" de desempenho da sua placa, não é necessário alterar nada. Dependendo de quantos outros circuitos estão em seu sistema e o que eles estão fazendo, algumas tampas adicionais de desvio de 1, 10 e / ou 100 uF espalhadas pela placa são uma prática comum de projeto. Eles não são localizados em um chip específico, eles fornecem um desvio "em massa" para toda a placa.
The
Sim, tenho dois túmulos de 47u no quadro para esse fim. Então, eu deveria estar bem na parte do desvio.
Saad
2
O SPI é totalmente síncrono. Nenhuma quantidade de instabilidade fará com que o SPI falhe.
markrages
@markrages, na situação do OP, isso é verdade. Em princípio, porém, uma quantidade realmente extrema de instabilidade de período pode, por exemplo, reduzir o intervalo entre a borda ascendente e a borda descendente o suficiente para violar o tempo de configuração da parte escrava e causar falha na interface. O tremor teria que ser igual a quase metade do período do relógio para que isso acontecesse.
O Photon
6

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.

Adam Lawrence
fonte
Tentará com um oscilador externo assim que o trabalho for aberto!
Saad
6

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.

stevenvh
fonte
Steven, você poderia explicar por que a posição do gatilho é importante? Como você conseguiu o valor de 0,5%?
Saad
2
@Saad - O ponto de disparo é time = 0. O que é mostrado no visor acontece 1.78 us = 1780 ns depois. E o jitter de 10 ns (mais ou menos) é a variação desses 1780 ns, então 10 ns / 1780 ns = 0,56%. Parece tão ruim porque foi ampliada a borda descendente, mas a borda de referência (o gatilho) estará dezenas de metros à esquerda. Portanto, se você diminuir o zoom para visualizar o pulso total, o tremor parecerá muito menor. Se o ponto de disparo acabou de sair da tela, digamos a -100 ns, o tremor de 10 ns seria 10%.
Stevenvh 20/08/2012
1

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).

Kaz
fonte