SPI ou I2C: para usar em um ônibus longo


36

Estou pensando em um projeto que exigiria vários AVRs conversando entre si por um ônibus. Eles seriam separados por até 6 pés.

Parece que tanto o I2C quanto o SPI podem permitir que uma série de micros se comunique através de um barramento, mas não vi nada falando sobre quanto tempo isso levaria. Alguém já tentou conectar esses protocolos a distâncias de vários metros?


Eu executei o barramento I2C através de um cabo em uma ocasião. Em retrospectiva, eu deveria ter usado CAN ou RS-485 (tinha microcontroladores nas duas extremidades).
Nick Alexeev

Respostas:


19

Como já foi dito, o SPI e o I2C podem ser usados ​​em longas distâncias, desde que os resistores pull-up, as frequências do relógio e assim por diante.

As principais alternativas (que proporcionam melhor imunidade ao ruído) são RS485 e CAN . Ambos usam linhas diferenciais para minimizar problemas de ruído e são mais adequados para esse comprimento de transmissão de dados do que I2C ou SPI. No entanto, acho que muitos AVRs não vêm com periféricos CAN integrados, o que facilita o uso do CAN.

Eu diria que a coisa mais importante a considerar ao escolher um barramento é garantir que o protocolo usado para comunicação entre dispositivos inclua um CRC ou equivalente, para que você possa determinar se uma mensagem foi recebida corretamente (a CAN tem isso como parte do o pacote). Considerando isso, também é útil ter uma resposta do tipo ACK / NACK como parte do protocolo, para que uma mensagem corrompida possa ser retransmitida.


Parece que qualquer um deles funcionará. Estou pensando principalmente nesses dois protocolos específicos, porque a maioria dos AVRs os suporta nativamente, sem adicionar componentes extras. Caso contrário, RS485 ou CAN seria uma boa escolha.
edebill

Se você não está restrito a pacotes de furos passantes, o ST possui seus poderosos e econômicos microcontroladores STM32 e STM8 com CAN, o NXP possui uma gama de microcontroladores LPC17xx e há alguns outros por aí também. A CAN está se tornando cada vez mais comum (e acessível) em muitos microcontroladores.
perfil completo de DrAl

1
De fato, existem alguns AVRs com receptores CAN embutidos, mas, assim como os outros fornecedores, é apenas um subconjunto limitado de seus chips.
David #

1
Microchip tem alguns PICs com CAN. microchip.com/wwwproducts/Devices.aspx?dDocName=en010302 . Admito, porém, que eles são um pouco "descolados" para programar, especialmente nas bibliotecas C18 / C30 da Microchip. Na revisão de código, observamos um código de biblioteca muito difícil de ler devido a detalhes de implementação - um buffer de transmissão usado como buffer de recebimento, nomes de sinalizadores que são realmente o oposto do que eles representam. Certamente não é algo que eu recomendaria para alguém novo no desenvolvimento de microcontroladores.
J. Polfer

2
CAN e RS-485 são realmente maçãs e laranjas. CAN define o protocolo de nível de bits, bem como a camada elétrica física (PHY). O RS-485 é apenas uma especificação de camada física, não especifica nada sobre o protocolo. Depende completamente de você encontrar ou implementar um protocolo real sobre o RS-485 PHY. O CAN foi projetado para ambientes com alto ruído, usado principalmente nas indústrias automobilística e de manufatura. Seu protocolo é um sistema de passagem de mensagens bastante complexo e possui uma sobrecarga muito alta (baixa taxa de dados real), mas possui alta integridade de dados.
Mar

10

Vários pés não devem ser problemáticos, basta usar fios torcidos, se puder. O SPI é muito mais fácil de armazenar em buffer (se necessário) do que o I2C, pois os sinais do SPI são todos unidirecionais, enquanto os sinais do I2C estão em linhas compartilhadas.

os microcontroladores AVR podem lidar com os modos escravo I2C e SPI, bem como os modos mestre? (você precisaria de ambos)


2
fios trançados ?? NUNCA torça os dados I2C e as linhas do relógio! Com o SPI, isso provavelmente é menos problemático, mas eu nunca torceria as linhas de sinal a menos que seja um par balanceado; nesse caso, torcer é uma idéia muito boa.
Wouter van Ooijen

Nunca diga nunca; Eu levaria acoplamento capacitivo menor (por causa da torção) entre os dados + anyday relógio em vez de acoplamento indutivo menor a eletrônica de potência ruidosos (por causa de não torcer)
Jason S

4
Desculpe, eu definitivamente discordo. No estado 1, as linhas têm uma impedância bastante alta. Visto feito, visto falhar. A melhor opção é ter linhas de terra de baixa corrente entre ou melhor nos dois lados das linhas I2C.
Wouter van Ooijen

10

Para o I2C em longas distâncias, você pode procurar algumas soluções "I2C bus repeteater". Lembre-se de que qualquer distância máxima encontrada para a comunicação I2C ou SPI refere-se principalmente à distância total do barramento e não à distância entre dois nós em um barramento.

Você pode procurar no RS485 esses tipos de problemas. É um protocolo de barramento serial que se comunica através de linhas diferenciais; portanto, ao usar fios trançados, as chances de ruído são minimizadas. Distâncias muito longas podem ser alcançadas dessa maneira. A desvantagem seria que você precisaria de um IC codificador RS485 extra (como um MAX485, não muito caro) em seu circuito.


O RS485 é definitivamente um bom caminho a seguir.
Scott Murphy

lembre-se de que o RS485 tem dois aspectos diferentes do RS232 que são um tanto independentes: os níveis lógicos diferenciais físicos e o aspecto do multimaster. Você pode escolher + escolher esses; usamos tradutores LVDS e RS485 com UART (RS232) para ponto a ponto sem entrar nas partes multiponto do RS485.
Jason S

2
btw RS485 não é um protocolo! define apenas a camada física. Dito isto, você pode definitivamente usar SPI sobre RS485 !!! Seria uma solução interessante manter as comunicações no modo SPI, se necessário (suponho que seja, pode estar conectado a um ADC remoto ou similar). Usando SPI sobre RS485 será necessário para verificar tarifas O transceptor série são compatíveis com os datarates SPI propostas
Smashtastic

8

Uma vantagem ainda não mencionada do SPI sobre o I2C é que todos os fios do SPI são unidirecionais e sempre são conduzidos alto ou baixo. Isso permite uma comunicação muito mais rápida do que é possível com o I2C, reduz a suscetibilidade ao ruído e permite que portões simples sejam usados ​​como repetidores. Outra opção útil é a comunicação assíncrona simples (um fio em cada direção). A única desvantagem que vejo para assíncrona a comunicação é que ela geralmente exige que os dois lados estejam "acordados", com um relógio estável, para trocar dados.

Para um projeto meu, usei um protocolo SPI de 3 fios levemente modificado e achei os resultados satisfatórios. Envio dados de bitmap de exibição (em que a corrupção ocasional de dados não seria grande coisa) a 10mbps e outros dados a 2,5mbps sem dificuldade.


Essa é uma resposta muito antiga, mas você diria a que distância estava enviando seu protocolo SPI modificado? (Esse é o ponto da pergunta ...)
Daniel Griscom

@DanielGriscom: Cerca de um metro e meio, sobre cabos não muito impressionantes, mas às vezes mais.
supercat 5/04

6

Embora o I2C e o SPI sejam projetados para viagens de curta distância (algumas polegadas), ambas podem ser utilizadas em viagens mais longas com cabo adequado e atenção à capacitância geral do barramento.

Embora eu tenha pouca experiência com SPI, o I2C não é terrivelmente difícil, pois você sempre precisa calcular o tamanho adequado para o seu resistor de pull-up. Além disso, existem buffers I2C dedicados e baratos que são bastante fáceis de usar. No entanto, você ainda precisará usar um resistor de pull-up de tamanho adequado para sua rede.

Eu usei o I2C para conectar em rede entre dois AVRs a uma distância de 8 pés, usando apenas resistores pull-up e cabo trançado de alta qualidade, bem blindado.


você deve observar w / I2C com cabos multicondutores, a capacitância pode fazer com que o barramento diminua significativamente.
27610 Jason S

6

Como muitos sugeriram, o I2C e o SPI são mais usados ​​para distâncias curtas. Embora seja possível implementar uma solução com essas interfaces, eu recomendo que você procure uma solução "mais padrão" diferente (por exemplo, Ethernet, RS485, CAN, etc.). - Especialmente se você planeja usar cabos para atingir a distância de 6 pés entre microcontroladores.


6

Apenas um FYI, a interface entre o controle remoto sem fio Nintendo Wii e seu companheiro Nunchuck usa o I2C através de um cabo com cerca de um metro de comprimento. Existem também cabos de extensão de 3 pés que estendem o comprimento total para cerca de 6 pés. Não é exatamente o mesmo da sua configuração (apenas dois dispositivos conectados juntos), mas é um exemplo de I2C através de um cabo em um produto de consumo amplamente usado.


4

Trabalhei em um projeto envolvendo cerca de 80 nós baseados em AVR em uma rede em estrela que se comunica pelo I2C. Foi uma bagunça total e não funcionou no final. A atualização de todos os nós levou segundos e uma conexão defeituosa eliminaria toda a rede. A última vez que falei com o cara que criou os nós, ele disse que parou de usar o I2C para projetos como este. Infelizmente, não sei por que especificamente o I2C foi inadequado aqui.


1
O I2C é muito mais lento que o SPI ... também poderia ter sido o modo como o seu projeto gerenciava a arbitragem em caso de colisão ... ou a capacitância pode ter sido alta o suficiente com todos os nós para que você apenas tivesse que usar um clock lento.
Jason S

2

Deve ser fácil com essas distâncias curtas. O que você pode fazer é descobrir o que essas distâncias e seu cabeamento significam em termos de capacitância e impedância de linha e ver que tipo de frequências (tempos de subida / descida) você pode obter através delas. Além de certo ponto, é melhor tratá-los como linhas de transmissão. Se parecer ruim, você pode realmente mudar para outra linha serial como EIA-232 ou 422. Isso pode significar um chip extra nas duas extremidades, mas vai se estender muito. Se você realmente precisa ir rápido e longe, precisará de algo mais (ethernet, não conte rádio ou laser :).


2

Se você pode controlar a velocidade do relógio e não precisar de transferência de dados em alta velocidade, tente desacelerar o relógio. Isso o tornará menos suscetível ao ruído.

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.