Quais são algumas preocupações de design para comunicação SPI fora da placa?


8

Visão geral:

Estou me comunicando entre 3 placas PCB personalizadas com dspic33 nelas usando SPI. Eu tenho um mestre e dois escravos, mas estou enviando os mesmos dados para os dois escravos (e deixando que eles escolham no que prestar atenção).

Configuração de hardware:

Os dois escravos construíram controladores de motor BLDC e o Mestre está controlando esses controladores por SPI. Os fios são executados a cerca de um metro do mestre para cada escravo e os cabeçalhos são típicos cabeçalhos SAMTECH de passo de 0,1 ". Cada controlador de motor possui seu próprio regulador de 3,3 volts que executa a eletrônica dsPIC / LV. Eu uso um regulador de controlador de motor (vamos chamá-lo de A) para também ligar o SPI master DSPIC. Para o outro controlador de motor (vamos chamá-lo de B), eu apenas corro as linhas e o terra do SPI do mestre. O clk do SPI está funcionando a 100KHz

Chegando ao ponto (finalmente):

Sem motores funcionando, tudo funciona bem, todos os dados são transmitidos conforme o esperado para os dois escravos. No entanto, quando eu ligo os motores, o Bslave não obtém mais os dados corretos. Ele está pegando relógios extras ou largando-os, suponho que isso aconteça com o barulho extra. De qualquer forma, suas somas de verificação começam a falhar. O Aslave funciona como um campeão, não importa o quê.

1) Você esperaria que todos esses dispositivos precisassem funcionar com a mesma fonte de 3,3 volts? Nesse caso, você pode me convencer falando sobre o laço de indutância mais longo e a magia negra como essa.

2) Você tem algum tipo de regra geral sobre a rapidez com que posso esperar executar o SPI clk e ter sucesso com uma configuração de hardware como a acima?


É necessária simulação para estimar a rapidez com que o relógio será capaz de rodar. Supondo que você tenha placas de camada dupla ou única, uma boa regra é rotear um traçado de terra ou um plano de cobre de terra (na camada oposta) sob ou adjacente às linhas SPI para diminuir o ruído acoplado aos traços.
Steinar

Respostas:


5

Eu executei o SPI (2MHz clock) cerca de 5m de uma caixa para outra e não hesitei em projetar o relógio e os dados para obter uma saída balanceada. O cabo (personalizado) entre os dois também usava par trançado e tela nos dados e no relógio.

Também enviei energia isolada para a caixa remota por meio de conversores dc para dc. Eu não tive tempo suficiente para errar, então possivelmente minha solução foi um exagero, mas, ei, funcionou. Meu raciocínio por trás dessa decisão é que eu não queria picos de "consumo atual" descendo pelas telas do par trançado. As telas não estavam conectadas ao terra no final do envio do PC. Trate os sinais digitais como preciosos sinais analógicos para obter o melhor desempenho - sempre tenha a tela encerrada na extremidade de recebimento e se você (por qualquer motivo) terminar de má vontade (também) na extremidade de envio.

Era para transmitir 128 canais de sinais analógicos de baixa velocidade para uma caixa de interrupção de um PC. Eu suspeito que, se eu precisasse, eu poderia operar isso no relógio de 20MHz.


Quando você diz "tela", você quer dizer "blindagem" quando se refere ao cabo personalizado?
perfil completo de JYelton

1
@JYelton no Reino Unido é chamado de tela. Em que país você está?
Andy aka

Estou nos EUA. Uma das minhas melhores amigas é britânica, por isso costumamos ter discussões incomuns sobre a escolha de palavras. :) Uma "tela" para mim é um monitor ou monitor, ou o pano de malha que mantém as moscas fora de casa quando a janela está aberta.
perfil completo de JYelton

@JYelton. Aha um pano de malha que mantém as coisas de fora. Soa como uma tela para mim LOL
Andy aka

Escolhido como resposta porque é a única resposta em que 1) e 2) foram abordados. Embora, como muitos sugeriram, se eu fosse redesenhar a placa, provavelmente mudaria de protocolo em vez de sinalizar diferencial. Eu acredito que isso iria funcionar embora. Nesse caso, estou apenas usando o SPI porque estava prontamente disponível no meu protótipo.
Matt

5

O SPI não é diferente de qualquer outra interface elétrica. Preste atenção aos problemas comuns de integridade do sinal (blindagem, área de loop, impedância, terminação do sinal etc.) e você pode executá-lo a uma distância razoável. O que é uma distância razoável, depende do que você está fazendo com ela e quão bem você pode controlar os vários fatores.

Você pode executá-lo 3 pés? Certamente. Você deveria? Bem, há coisas melhores para usar. Como outros já apontaram, existe o RS-4xx que pode funcionar bem. Você também pode executar o SPI, mas use a sinalização diferencial sobre o cabo como RS-4xx. Isso consumirá mais fios, mas essas são as quebras. Você também pode fazer o RS-485 normal, usando um UART e similares.

Pessoalmente, executei o SPI em cabos de 1 pé, dentro de um chassi, a taxas de até 32 MHz sem problemas. Também executei o I2C acima de 4 pés a 100 KHz em um ambiente EMI alto e o SPI é muito melhor que o I2C - para que isso possa ser feito. Mas se você não prestar atenção aos detalhes, poderá facilmente encontrar problemas. Mas, honestamente, você precisa prestar atenção nos detalhes, independentemente do que você usa.


Muitas interfaces como RS232 são relativamente imunes a coisas como toque e superação, desde que quaisquer efeitos resultantes de uma transição de linha sejam resolvidos dentro de meio período de tempo. Mesmo se uma linha não puder suportar altas taxas de transmissão, diminuir a taxa de transmissão ajudará. Por outro lado, se coisas como toque causam problemas com o SPI a qualquer velocidade, desacelerá-lo pode não ajudar, a menos que se possa reduzir a inclinação das transições de linha.
Supercat2 /

Esta é uma boa resposta, especialmente o número de sistemas que você implementou. Acho que vou tentar resistores em série no lado do motorista para ver se isso ajuda. No entanto, receio que o ruído esteja causando relógios extras ... então, nesse caso, pode não ajudar.
Matt

5

Considere cuidadosamente seu esquema de aterramento. Proteja as linhas de dados, se ajudar, e aterre a blindagem corretamente. Não execute dados e relógio no mesmo par trançado. Use isolamento galvânico, se necessário. Fora isso, não existem regras básicas que eu saiba.

O SPI foi projetado para (1) comunicação de curto alcance, geralmente dentro de uma PCB e (2) no ambiente sem muito EMI. Talvez, os únicos ônibus com desempenho pior que o SPI na presença de EMI sejam I 2 C e 1 fio. Existem barramentos que foram projetados para comunicação de longo alcance na presença de EMI (RS-485, CAN, Ethernet).

É possível estender e reforçar a SPI. Aqui está uma nota de aplicação , que mostra um barramento SPI com linhas diferenciais.


Vou tentar proteger as linhas. No que diz respeito ao isolamento galvânico, quando não conecto o aterramento, o dispositivo escravo nunca registra nenhum dos relógios enviados pelo mestre.
Matt

1

Existem algumas maneiras de minimizar os efeitos do ruído nas linhas de sinal. A maneira mais fácil é rotear um avião de cobre ou um traço de cobre adjacente aos traços de sinal. Isso minimiza a indutância dos traços e da área do loop.

Em alta frequência, as correntes de retorno gostam de percorrer um caminho de menor impedância adjacente às próprias linhas de sinal. Suponho que você tenha um terra comum entre seus circuitos, mas isso pode estar causando problemas para a sinalização de alta frequência se o seu terra comum for simplesmente uma conexão de terra de "energia" entre os circuitos. Isso causará uma área de loop muito grande para as correntes de sinal, o que pode permitir muita injeção de ruído devido ao acoplamento magnético perdido.

Se possível, conecte uma conexão de aterramento extra entre os aterramentos adjacentes às linhas de sinal SPI, além de manter um plano de aterramento de cobre ou um traçado roteado adjacente às linhas dentro das placas também. Pode fazer um mundo de diferença em como o circuito é suscetível aos motores.


Não entendo a frase "entre os motivos adjacentes às linhas de sinal SPI". Especificamente, a palavra adjacente não está clara para mim.
Matt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.