SPI atau I2C: yang digunakan untuk bus gondrong


36

Saya merenungkan sebuah proyek yang akan membutuhkan beberapa AVR berbicara satu sama lain melalui bus. Mereka akan dipisahkan sebanyak 6 kaki.

Sepertinya I2C dan SPI dapat membiarkan serangkaian mikroskomunikasi berkomunikasi melalui bus, tetapi saya belum melihat apa pun yang berbicara tentang berapa lama itu. Adakah yang mencoba menghubungkan protokol-protokol ini dalam jarak beberapa kaki?


Saya telah menjalankan bus I2C melalui kabel pada satu kesempatan. Kalau dipikir-pikir, saya seharusnya menggunakan CAN atau RS-485 sebagai gantinya (punya mikrokontroler di kedua ujungnya).
Nick Alexeev

Jawaban:


19

Seperti yang dikatakan orang lain, SPI dan I2C dapat digunakan jarak jauh selama resistor pull-up, frekuensi clock dan sebagainya.

Alternatif utama (yang akan memberikan kekebalan kebisingan yang lebih baik) adalah RS485 dan CAN . Keduanya menggunakan jalur diferensial untuk meminimalkan masalah kebisingan dan lebih cocok untuk panjang transmisi data ini daripada I2C atau SPI. Namun, saya tidak berpikir banyak (ada?) AVR datang dengan peripheral CAN built-in, yang membuat BISA menggunakan lebih mudah.

Saya akan mengatakan bahwa hal yang paling penting untuk dipertimbangkan ketika memilih bus adalah untuk memastikan bahwa protokol yang Anda gunakan untuk berkomunikasi antar perangkat termasuk CRC atau setara sehingga Anda dapat menentukan apakah pesan telah diterima dengan benar (CAN memiliki ini sebagai bagian dari paket). Mempertimbangkan hal ini, juga berguna untuk memiliki respons tipe ACK / NACK sebagai bagian dari protokol sehingga pesan yang rusak dapat dikirim kembali.


Sepertinya salah satu akan bekerja. Saya terutama memikirkan dua protokol khusus ini karena sebagian besar AVR mendukungnya secara asli, tanpa menambahkan komponen tambahan. Jika tidak, RS485 atau CAN akan menjadi pilihan yang baik.
edebill

Jika Anda tidak dibatasi untuk paket through-hole, maka ST memiliki mikrokontroler STM32 dan STM8 yang hemat biaya dan kuat dengan CAN, NXP memiliki berbagai mikrokontroler LPC17xx dan ada beberapa lainnya di luar sana. CAN menjadi semakin umum (dan terjangkau) pada banyak mikrokontroler.
DrAl

1
Memang ada beberapa AVR dengan penerima CAN built in, tetapi sama seperti vendor lain, itu hanya dalam subset terbatas dari chip mereka.
davr

1
Microchip memiliki beberapa PIC dengan CAN. microchip.com/wwwproducts/Devices.aspx?dDocName=en010302 . Saya akui, mereka agak "funky" untuk diprogram, terutama di perpustakaan C18 / C30 milik Microchip. Dalam ulasan kode, kami telah mengamati beberapa kode perpustakaan yang sangat sulit dibaca karena rincian implementasi - buffer pengiriman yang digunakan sebagai buffer penerima, nama bendera yang sebenarnya kebalikan dari apa yang mereka wakili. Tentu bukan sesuatu yang saya rekomendasikan untuk seseorang yang baru dalam pengembangan mikrokontroler.
J. Polfer

2
CAN dan RS-485 benar-benar apel dan jeruk. BISA mendefinisikan protokol level bit serta lapisan listrik fisik (PHY). RS-485 hanyalah spesifikasi lapisan fisik, ia tidak menentukan apa pun tentang protokol. Anda sepenuhnya dapat menemukan atau menerapkan protokol aktual di atas RS-485 PHY. CAN dirancang untuk lingkungan dengan kebisingan tinggi, sebagian besar digunakan dalam industri mobil dan manufaktur. Protokolnya adalah sistem pengiriman pesan yang agak rumit dan memiliki overhead yang sangat tinggi (kecepatan data aktual rendah) tetapi memiliki integritas data yang tinggi.
Tandai

10

Beberapa kaki seharusnya tidak bermasalah, cukup gunakan kabel bengkok jika Anda bisa. SPI jauh lebih mudah untuk buffer (jika Anda perlu) daripada I2C karena sinyal SPI semuanya searah, sedangkan sinyal I2C berada di jalur bersama.

dapatkah mikrokontroler AVR menangani mode I2C dan SPI slave serta mode master? (Anda akan membutuhkan keduanya)


2
kabel bengkok ?? JANGAN PERNAH memutar data I2C dan garis jam! Dengan SPI ini mungkin bukan masalah, tapi saya tidak akan pernah memelintir garis sinyal kecuali pasangan yang seimbang, dalam hal ini memutar adalah ide yang sangat bagus.
Wouter van Ooijen

Jangan pernah bilang tidak akan pernah; Saya akan mengambil kopling kapasitif kecil (karena memutar) antara data + jam anyday bukannya kopling induktif kecil untuk elektronik daya berisik (karena tidak memutar)
Jason S

4
Maaf, saya sangat tidak setuju. Dalam keadaan 1 garis memiliki impedansi yang agak tinggi. Setelah selesai, terlihat gagal. Pilihan terbaik adalah memiliki garis tanah arus rendah antara atau bahkan lebih baik di kedua sisi garis I2C.
Wouter van Ooijen

10

Untuk I2C jarak jauh Anda mungkin ingin mencari beberapa solusi "I2C bus repeater". Ingatlah bahwa jarak maksimum apa pun yang mungkin Anda temukan untuk komunikasi I2C atau SPI sebagian besar mengacu pada total jarak bus dan bukan jarak antara dua node dalam bus.

Anda mungkin ingin melihat ke RS485 untuk masalah seperti ini. Ini adalah protokol bus serial yang berkomunikasi melalui jalur diferensial, jadi ketika menggunakan kabel yang terpilin, kemungkinan kebisingan diminimalkan. Jarak yang sangat jauh dapat dicapai dengan cara ini. Kelemahannya adalah bahwa Anda akan memerlukan IC encoder RS485 tambahan (seperti MAX485, tidak terlalu mahal) di sirkuit Anda.


RS485 jelas merupakan cara yang baik untuk hal seperti itu.
Scott Murphy

perlu diingat bahwa RS485 memiliki dua aspek berbeda dari RS232 yang agak independen: tingkat logika diferensial fisik, dan aspek multimaster. Anda dapat memilih + memilih ini, kami telah menggunakan penerjemah LVDS dan RS485 dengan UART (RS232) untuk point-to-point w / o masuk ke bagian multidrop RS485.
Jason S

2
btw RS485 bukan protokol! ia mendefinisikan layer fisik saja. Karena itu, Anda pasti dapat menggunakan SPI melalui RS485 !!! Ini akan menjadi solusi yang rapi untuk menjaga komunikasi dalam mode SPI jika diperlukan (saya berasumsi, mungkin terhubung ke ADC jarak jauh atau serupa). Menggunakan SPI lebih dari RS485 Anda perlu memeriksa laju perubahan tegangan transceiver yang kompatibel dengan datarate SPI yang diusulkan
smashtastic

8

Satu keuntungan yang belum disebutkan tentang SPI dibandingkan I2C adalah bahwa semua kabel SPI searah dan selalu didorong tinggi atau rendah. Hal ini memungkinkan komunikasi yang jauh lebih cepat daripada yang dimungkinkan dengan I2C, mengurangi kerentanan terhadap kebisingan, dan memungkinkan gerbang sederhana untuk digunakan sebagai pengulang. Pilihan lain yang bermanfaat adalah komunikasi async sederhana (satu kabel setiap arah). Satu-satunya downside saya dapat melihat komunikasi async adalah bahwa pada umumnya memerlukan kedua belah pihak untuk "terjaga", dengan jam yang stabil, untuk bertukar data.

Untuk proyek saya sendiri, saya menggunakan protokol SPI 3-kawat sedikit dimodifikasi dan telah menemukan hasil yang memuaskan. Saya mengirim tampilan data bitmap (di mana korupsi data sesekali tidak menjadi masalah besar) pada 10mbps dan data lainnya pada 2,5mbps tanpa kesulitan.


Ini adalah jawaban yang sangat lama, tetapi apakah Anda akan mengatakan sejauh apa Anda mengirim protokol SPI yang dimodifikasi? (Itulah pertanyaannya ...)
Daniel Griscom

@DanielGriscom: Sekitar 3 kaki biasanya, lebih dari pemasangan kabel yang tidak terlalu mengesankan, tetapi kadang-kadang lebih lama.
supercat

6

Sementara I2C dan SPI dirancang untuk jarak pendek (beberapa inci), keduanya dapat digunakan pada jarak yang lebih panjang dengan kabel yang tepat dan memperhatikan kapasitansi bus secara keseluruhan.

Sementara saya memiliki sedikit pengalaman dengan SPI, I2C tidak terlalu sulit mengingat bahwa Anda selalu perlu menghitung ukuran yang tepat untuk resistor pull-up Anda. Selain itu, ada buffer I2C yang berdedikasi dan murah yang cukup mudah digunakan. Namun, Anda masih harus menggunakan resistor pull-up berukuran tepat untuk jaringan Anda.

Saya telah menggunakan I2C untuk jaringan antara dua AVR pada jarak 8 kaki, hanya menggunakan resistor pull-up dan kabel twisted yang berkualitas tinggi, terlindung dengan baik.


Anda harus berhati-hati dengan I2C dengan kabel multikonduktor, kapasitansi dapat menyebabkan bus melambat secara signifikan.
Jason S

6

Seperti yang banyak disarankan, I2C dan SPI paling baik digunakan untuk jarak pendek. Meskipun dimungkinkan untuk mengimplementasikan solusi dengan antarmuka ini, saya sangat menyarankan Anda mencari solusi "standar lebih" yang berbeda (misalnya Ethernet, RS485, CAN, dll). - Terutama jika Anda berencana menggunakan kabel untuk mencapai jarak 6 kaki antara mikrokontroler.


6

Hanya FYI, antarmuka antara remote Nintendo Wii nirkabel dan pendamping Nunchuck-nya menggunakan I2C melalui kabel yang panjangnya sekitar 3 kaki. Ada juga kabel ekstensi 3 kaki yang memperpanjang total panjang sekitar 6 kaki. Tidak persis sama dengan pengaturan Anda (hanya dua perangkat yang terhubung bersama), tetapi ini adalah contoh I2C melalui kabel dalam produk konsumen yang banyak digunakan.


4

Saya bekerja pada proyek yang melibatkan sekitar 80 node berbasis AVR dalam jaringan bintang yang berkomunikasi melalui I2C. Itu berantakan total dan tidak berhasil pada akhirnya. Mendapatkan pembaruan untuk semua node membutuhkan waktu beberapa detik dan satu koneksi yang salah akan membuat seluruh jaringan terputus. Terakhir saya berbicara dengan orang yang membuat node, dia bilang dia berhenti menggunakan I2C untuk proyek seperti ini. Sayangnya saya tidak tahu mengapa secara khusus I2C tidak memadai di sini.


1
I2C jauh lebih lambat daripada SPI ... bisa juga dalam bagaimana proyek Anda mengelola arbitrase jika terjadi tabrakan ... atau kapasitansi mungkin cukup tinggi dengan semua node yang Anda hanya perlu menggunakan clock rate yang lambat.
Jason S

2

Seharusnya mudah dengan jarak pendek itu. Apa yang dapat Anda lakukan adalah mencari tahu apa arti jarak dan kabel Anda dalam hal kapasitansi dan impedansi saluran dan lihat frekuensi seperti apa (naik / turunnya waktu) yang dapat Anda lewati. Di luar titik tertentu, yang terbaik adalah memperlakukannya sebagai saluran transmisi. Jika terlihat buruk, Anda memang bisa beralih ke beberapa seri serial lain seperti EIA-232 atau 422. Itu mungkin berarti chip tambahan di kedua ujungnya tetapi akan meregang jauh. Jika Anda benar-benar harus bergerak cepat dan jauh, Anda akan membutuhkan sesuatu yang lebih (ethernet, jangan hitung radio atau laser :).


2

Jika Anda dapat mengontrol kecepatan jam dan Anda tidak memerlukan transfer data berkecepatan tinggi, Anda harus mencoba memperlambat jam. Ini akan membuatnya kurang rentan terhadap kebisingan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.