Protokol umum untuk transfer data dari satu sistem ke sistem lainnya?

18

Apa protokol umum untuk mengirim informasi dari satu sistem ke sistem lainnya? Sebagai contoh, katakanlah kita memiliki beberapa informasi yang dikumpulkan dari mikrokontroler selama jangka waktu yang ingin kita kirim ke mikrokontroler lain. Saya pernah mendengar tentang antarmuka SPI dan I2C, tetapi saya tidak jelas ketika Anda menggunakan satu metode di atas yang lain dan bagaimana Anda menerapkannya. Apakah ada metode lain selain SPI dan I2C yang umum? Apakah proses implementasi serupa untuk mikrokontroler yang berbeda? Apakah pada dasarnya parsing byte data yang saya lakukan pada mikrokontroler penerima?

i2c spi data

— O_O
sumber

4

Apa hal nyata yang ingin Anda lakukan?

— starblue

Hanya memikirkan bagaimana cara mendapatkan bagian-bagian sistem yang berbeda untuk menyampaikan data satu sama lain dalam sebuah kotak kecil, sehingga jarak dapat diasumsikan sangat pendek. Alasan untuk memiliki bagian yang berbeda dalam sebuah kotak adalah untuk menyederhanakan fungsi sehingga masing-masing bagian memiliki fungsi sendiri (mudah-mudahan itu masuk akal ..)

— O_O

2

bukan itu yang biasa disebut sistem. Itu lebih dari apa yang saya definisikan sebagai sub-sistem. Mereka membentuk bagian dari apa yang dapat Anda anggap sebuah sistem tunggal menyelesaikan satu set tugas. Ini semantik, tetapi saya pikir banyak jawaban Anda sangat luas karena mereka tidak memiliki ide yang sempurna tentang apa yang Anda cari dari pertanyaan itu.

— Kortuk

1

sesuai dengan apa yang dikatakan Kortuk, ada baiknya mendefinisikan masalah. Satu pertanyaan penting untuk Anda tanyakan pada diri sendiri adalah apakah Anda mungkin ingin mengganti subsistem individual dengan implementasi berbeda dari fungsi yang sama, atau apakah ini adalah desain satu kali seperti apa adanya. Jika Anda menggunakan bus sungguhan, dan mengekspos detail implementasi subsistem ke CPU Anda, maka perubahan subsistem memerlukan perubahan w / untuk controller Anda, sedangkan jika Anda menggunakan antarmuka komunikasi, tidak masalah bagaimana Anda menerapkan (penggantian) ) subsistem, selama memenuhi protokol pesan yang sama.

— JustJeff

Tidaklah mudah untuk membagi fungsionalitas di beberapa perangkat tanpa alasan lain selain memisahkan tugas. Komunikasi dan sinkronisasi lebih kompleks daripada memiliki dua proses dalam mikro yang sama. Sekarang, jika proses ini memiliki profil latensi yang sangat tidak kompatibel (satu harus memperbarui dengan cepat sementara yang lain dapat mengambil beberapa waktu untuk menyelesaikan potongan), maka mungkin ada alasan yang sah untuk memecahnya. Bahkan kemudian, solusi yang lebih umum adalah menggunakan interupsi atau mencari cara untuk memecah tugas yang lebih lama lebih jauh. Dengan apa yang telah Anda jelaskan, saya cenderung berpikir Anda harus memikirkan kembali hal ini.

— darron

10

SPI dan I2C agak mirip, karena mereka benar-benar lebih banyak digunakan untuk melampirkan perangkat periferal ke cpu atau cpu, daripada untuk benar-benar mentransfer data antar sistem. USB adalah antarmuka lain yang tampaknya orang ingin perlakukan sebagai sistem komunikasi, yang notabene adalah bus lampiran periferal.

Komunikasi antar sistem tidak persis seperti memasang perangkat ke bus. Lampiran bus memungkinkan prosesor untuk secara langsung menggedor register dalam suatu perangkat, sedangkan antarmuka komunikasi memungkinkan Anda untuk mengirim / menerima aliran data. Perangkat yang terhubung pada bus umumnya memerlukan driver perangkat, sedangkan dengan komunikasi, tidak masalah apa yang terhubung di ujung lain, sejauh menyangkut komputer host.

Tentu saja, ini menjadi batas yang lebih berbahaya sepanjang waktu. Hal-hal seperti PCI dan ISA adalah bus yang tidak dapat disangkal; I2C, SPI, USB bisa dibilang bus; sedangkan RS232, RS485, dan ethernet jelas merupakan antarmuka komunikasi. Tapi kemudian ada hal-hal seperti CAN bus dan 1553, yang pasti tentang memindahkan data, tetapi dengan cara yang sangat terlibat.

— JustJeff
sumber

CANbus sangat terlibat, dan ethernet tidak? CAN sangat mudah untuk bekerja untuk pesan bolak-balik yang sederhana. Mereka adalah chip khusus dan sebagian besar keluarga mendukung internal untuk pengontrol mikro mereka.

— Kortuk

@Kortuk - sejauh 232 seperti memiliki simetri peer-to-peer, sementara 1553 atau CAN dapat memaksakan hubungan master / slave, ya. Saya tidak percaya saya mengatakan bahwa ethernet itu sederhana, hanya saja itu tidak memaksakan perbedaan alat pengontrol bus / bus pada titik akhir.

— JustJeff

juga, pengungkapan penuh - pendapat saya tentang CAN sepenuhnya dari paparan tangensial; ini merupakan perangkat opsional yang tidak digunakan pada beberapa sistem yang telah saya kerjakan, tetapi setelah ratusan melewati dokumentasi, Anda menyerap sedikit tentang opsi yang tidak digunakan hanya dengan osmosis. Jadi saya bekerja dengan asumsi bahwa CAN adalah tipe arsitektur pengontrol / perangkat yang dikendalikan.

— JustJeff

Saya pikir bus memiliki arti berbeda dalam konteks yang berbeda. Dari tingkat skematis, antarmuka apa pun dengan banyak sinyal dapat dianggap sebagai bus. Saat Anda pindah ke level yang lebih tinggi dengan abstraksi yang lebih banyak, bus mengubah makna. Sedikit lebih tinggi, bus biasanya berarti ada atau dapat beberapa perangkat terlibat. RS485 multipoint jelas merupakan bus, misalnya. Jauh lebih tinggi, dari sudut pandang perangkat Linux, RS485 menjadi antarmuka comm lagi dan diturunkan dari menjadi bus ... sampai Anda menambahkan lapisan protokol Anda sendiri di atasnya mengubahnya kembali menjadi bus. Pada setiap level memiliki makna yang berbeda.

— darron

11

Tidak ada satu cara untuk mengirim data, ada banyak cara untuk berkomunikasi tergantung pada jarak, kecepatan data, lingkungan, aplikasi ...

Lapisan terendah adalah lapisan fisik , yang sebenarnya menggerakkan bit di sekitar.

SPI dan I²C adalah untuk jarak pendek di dalam perangkat, di mana tidak ada banyak suara yang dapat mengganggu transmisi.
Untuk komunikasi yang tidak terlalu cepat jarak jauh hingga beberapa puluh meter komunikasi serial melalui RS-232 adalah pilihan yang baik.
Jika ada lebih banyak noise atau sinyal diferensial jarak yang lebih panjang digunakan, misalnya dalam RS-485. Untuk pengiriman data yang lebih cepat ada Ethernet, yang menjadi semakin populer.
Lalu ada juga berbagai standar nirkabel.

Di atas lapisan fisik ada lebih banyak lapisan yang mengatur bagaimana data dikirim, untuk mendeteksi dan memperbaiki kesalahan dalam transmisi, perutean dalam jaringan, dan banyak hal lainnya. Sebagai contoh, protokol internet adalah tumpukan yang agak rumit dari beberapa lapisan, biasanya di atas protokol Ethernet.

— starblue
sumber

7

UART serial sederhana dapat digunakan (satu baris Tx dan satu Rx tanpa jam diskrit) dan dapat dengan mudah disesuaikan untuk melintasi antara berbagai potensi (bahkan sirkuit primer dan sekunder) dengan optoisolator atau isolator magnetik .

Sejauh protokol berjalan, apa pun dengan byte perintah yang ditentukan dan semacam skema checksum akan bekerja dengan baik. Sebenarnya tidak ada protokol standar yang mencakup semua jenis komunikasi. I2C memiliki standar pensinyalan (mendefinisikan pengalamatan, berhenti, mulai, dll.) Tetapi protokol dari apa yang sebenarnya dikomunikasikan sepenuhnya terserah pengembang.

PMBus , misalnya, adalah protokol komunikasi catu daya yang menggunakan I2C sebagai media fisiknya.

— Adam Lawrence
sumber

6

Sebenarnya tidak ada protokol "umum", yang akhirnya Anda gunakan sangat bergantung pada aplikasi. Agar kami dapat memberikan jawaban yang lebih baik, kami perlu memahami persyaratan Anda sedikit lebih baik. Anda menyebutkan bahwa Anda ingin memiliki pengontrol mikro terpisah yang berbicara satu sama lain sebagai subsistem.

Beberapa pertanyaan tentang aplikasi ini:

Apakah akan ada lebih dari 2 pengendali mikro dalam proyek ini?
Apa persyaratan kecepatan dan throughput Anda? Seberapa cepat informasi perlu sampai di sana dan seberapa sering Anda mengirim / menerima data?

Jika Anda menjawab TIDAK untuk pertanyaan 1:

Jika hanya ada 2 mikrokontroler di proyek ini, Anda pasti dapat menggunakan UART di antara mereka. Jika keduanya perlu memulai komunikasi, gunakan kontrol aliran, jika tidak sepele untuk mengirim data dalam satu arah. Sebagian besar harus "cukup cepat" mengingat Anda memilih salah satu dari angka baud yang lebih tinggi. I2C dan SPI biasanya hanya baik untuk arsitektur master / slave.

Jika Anda menjawab YA (lebih dari 2 pengendali) untuk pertanyaan 1:

Jika ada lebih dari 2 pengendali mikro dalam proyek Anda, yang mana yang memulai komunikasi? Apakah hanya satu pengontrol utama (mis. Arsitektur master-slave)? Atau apakah ada subsistem yang dapat berbicara kapan saja?
Apakah ada kebutuhan untuk subsistem untuk berbicara satu sama lain? mis: untuk perangkat A, B dan C: A dapat mengirim ke B dan C, dan B dapat mengirim ke A dan C, dll.

Jadi sekarang Anda membutuhkan sesuatu yang lebih skalabel di mana Anda dapat menjatuhkan perangkat yang dapat dialamatkan ke bus umum. Jawaban untuk pertanyaan tindak lanjut ini akan membantu Anda memutuskan antara I2C dan SPI (master-slave) atau sesuatu seperti CAN (multi-master).

Kontroler mikro Anda kemungkinan besar memiliki periferal UART, yang lainnya (terutama CAN) mungkin hanya tersedia pada chip yang lebih tinggi. Dalam kedua kasus tersebut, harus ada banyak dokumentasi tentang cara menggunakan periferal ini untuk memindahkan byte.

— Jon L
sumber

5

Sebagaimana dicatat oleh @Jon, satu masalah dalam memilih antarmuka komunikasi adalah apakah satu entitas akan selalu bertanggung jawab untuk memulai komunikasi, atau apakah lebih dari satu entitas mungkin begitu bertanggung jawab. Masalah terkait adalah apakah satu entitas akan selalu siap untuk menerima komunikasi yang tidak diminta. SPI sering digunakan dalam aplikasi di mana satu sisi akan selalu siap untuk menerima komunikasi. Sesuatu seperti register geser 74HC595, misalnya, tidak pernah "sibuk". Sementara SPI baik untuk komunikasi antara mikrokontroler dan perangkat keras yang seharusnya dikendalikan oleh mikro, namun sebenarnya tidak baik untuk komunikasi antara dua mikrokontroler. Ketika dua prosesor dengan perangkat keras I2C menggunakannya untuk berkomunikasi, perangkat lunak dapat memakan waktu selama yang diinginkan (dalam batasan yang sangat murah hati) untuk menangani apa yang terjadi, tanpa menyebabkan kehilangan data. Jika prosesor mengambil 100 mikrodetik untuk memproses setiap byte yang masuk, itu akan sangat membatasi throughput, tetapi pengirim akan memperlambat cukup untuk penerima untuk menjaga. Satu-satunya cara yang umumnya dapat terjadi dengan SPI adalah jika seseorang memiliki kawat terpisah untuk berjabat tangan.

I2C benar-benar protokol yang luar biasa. Keterbatasan terbesar yang menghentikannya dari menjadi protokol yang paling sempurna yang bisa dibayangkan adalah

Kecepatannya agak terbatas; SPI bisa lebih cepat, dan bahkan UART kadang-kadang bisa sedikit lebih cepat
(2) Meskipun sangat nyaman bahwa I2C hanya membutuhkan dua kabel, kedua kabel harus mampu komunikasi dua arah kolektor dua arah. Ini membuatnya sulit untuk mengirim I2C melalui repeater.

Secara pribadi, saya ingin melihat vendor kontrol mendukung varian tiga-kawat SPI yang termasuk berjabat tangan. Saya tidak mengetahui adanya pengontrol yang melakukannya.

— supercat
sumber

Lucu Anda harus menyebutkan ini ... Saya harus mengubah antarmuka SPI menjadi antarmuka I2C non-bidirectional (byte pertama adalah alamat) untuk memungkinkan lebih banyak perangkat untuk berpartisipasi di bus daripada yang saya pilih chip untuk . Ini berfungsi jika perangkat budak Anda semuanya FPGA. :) Saya juga berharap ada sesuatu di antara dua standar sinkron utama itu.

— darron

Oh, saya kira saya harus mengklarifikasi bahwa output memungkinkan pada slave jangan ditegaskan sampai byte alamatnya diterima dan mereka tetap di sana sampai chip tunggal pilih deasserted ... jadi itu jelas sedikit berbeda dari SPI normal + level tinggi protokol. Namun, ini benar-benar kompatibel dengan SPI standar dari sudut pandang perangkat utama. (Seperti mikroprosesor)

— darron

@dron: Keren. Saya bertanya-tanya apa yang harus terjadi bagi industri untuk mulai menggunakan bus komunikasi tiga-kawat standar terbuka di mana kabel secara aktif didorong tinggi dan rendah? Saya kira ada sedikit konflik antara menghindari pull-up pasif dan memungkinkan perangkat apa pun untuk memberi sinyal interupsi, meskipun itu dapat diatasi dengan menambahkan pin interupsi yang dapat ditransfer ke master atau tidak pada kenyamanan budak (implementasi saya saat ini dari protokol hanya memiliki satu budak, sehingga dapat menggunakan kabel pengembalian data untuk memberi sinyal secara asinkron ketika ingin diservis).

— supercat

@dron: Untuk menghindari keharusan menggunakan pin pilihan-chip, master memberi sinyal start-of-command dengan mengirimkan dua sisi yang naik pada kabel data saat jam rendah; slave dapat menunjukkan apakah byte data terakhir mereka valid dengan mengeluarkan nilai status ketika jam dan data keduanya rendah (idle); jika tidak mereka menunjukkan bahwa mereka ingin perhatian ketika jam rendah dan data tinggi. Jika saya merancang perangkat keras utama untuk protokol ini, saya akan menambahkan kemampuan untuk mengirim pulsa 8 jam di mana kabel data dicerminkan jam, dan dalam perangkat keras budak termasuk hitungan asinkron dari jumlah tepi yang meningkat selama ...

— supercat

@dron: ... satu byte data. Jika lima atau lebih besar, byte akan diabaikan (budak akan menganggap master tertarik untuk menerima byte data, tetapi tidak ada yang ingin dikatakan). Itu tidak akan hampir sama pentingnya, meskipun, memiliki budak melaporkan status byte terakhir ketika jam rendah (yang akan, jika perangkat budak adalah prosesor, biarkan master tahu bahwa budak belum siap dan telah melewatkan 'peluang transaksi' terakhir

— supercat

3

Tanpa urutan tertentu, instance lapisan fisik paling populer untuk 2 CPU dalam kotak yang sama tampaknya:

SPI daisy-chain (seperti yang digunakan oleh JTAG)
pilih-kawat-per-budak SPI
"TTL-level RS-232" alias "komunikasi serial start-stop asynchronous" (langsung menghubungkan pin TX UART dari satu CPU ke pin RX UART dari CPU lain)
I2C
Data 8-bit + strobo (seperti port paralel port printer IEEE 1284)
shared-memory (hanya satu CPU yang menggerakkan bus alamat / data / kontrol sekaligus)

Instance layer fisik ini (serta instance layer fisik lainnya untuk 2 CPU dalam kotak terpisah) biasanya menyediakan aliran byte ke perangkat lunak yang mengimplementasikan level yang lebih tinggi dari sistem komunikasi.

Pemrogram pintar menulis perangkat lunak sedemikian rupa sehingga ketika orang perangkat keras memutuskan untuk merobek satu instance layer fisik dan menggantinya dengan instance layer fisik yang sama sekali berbeda, mereka hanya perlu menulis ulang beberapa fungsi untuk memberi makan aliran output byte mereka ke perangkat keras dan membaca kembali aliran byte dari perangkat keras, dan semua hal protokol tingkat tinggi terus bekerja tidak berubah.

Protokol untuk mengirim informasi dari satu CPU ke CPU lain hampir selalu melibatkan menafsirkan aliran byte sebagai serangkaian paket:

pembukaan
tajuk
(mungkin lolos) data serial
cuplikan

Beberapa orang tampaknya menikmati membuat protokol yang sepenuhnya baru, kustom, tidak kompatibel dengan mencampur-dan-mencocokkan (2) salah satu dari banyak jenis struktur header dengan (3a) salah satu dari banyak jenis data bersambung dengan (3b) salah satu dari banyak jenis lolos dari data bersambung dengan (4) salah satu dari banyak jenis trailer.

Beberapa protokol paling sederhana untuk merangkum data ke dalam sebuah paket meliputi:

Protokol yang sedikit lebih rumit untuk merangkum data ke dalam sebuah paket meliputi:

Ada daftar panjang protokol di

Anda dapat menikmati membaca "Protokol Desain Cerita Rakyat" oleh Radia Perlman yang menjelaskan bagaimana desain protokol bisa salah.

— davidcary
sumber

3

Tidak ada protokol 'umum' tunggal. Pilihan dapat (misalnya) bergantung pada:

jarak
throughput yang dibutuhkan
ketersediaan periferal khusus
tingkat kebisingan
butuhkan untuk isolasi optik
criticality (tingkat kegagalan yang dapat ditoleransi)
avialable daya CPU di kedua ujungnya
pin I / O tersedia di kedua ujungnya

Dalam banyak kasus, Anda harus menghilangkan lapisan fisik (level sinyal) dari lapisan tautan data (+/- cara data dikodekan) (periksa model OSI, turunkan lapisan 2 ..4). Lapisan phyiscal yang memungkinkan misalnya:

5V atau 3.3V atau bahkan 1.8V TTL sederhana
salah satu di atas tetapi buka-kolektor bukannya push-pull
pensinyalan tegangan tegangan seimbang (sering digunakan dengan FPGA)
balanced higer volatge (RS485, RS432)
tegangan tunggal berakhir lebih tinggi (RS232)
balanced trafo-coupled (berbagai versi ethernet, audio PDIF)
optik (ethernet optik, toslink)

Anda dapat menggunakan satu baris untuk membawa data dan info jam, atau membaginya menjadi beberapa baris. Yang terakhir dulu populer, tetapi saat ini kebanyakan protokol baru / cepat cenderung menggunakan satu baris (atau sepasang garis yang bertindak sebagai satu).

Ada banyak cara untuk menyandikan data dan jam pada suatu garis. RS232 secara tradisional menggunakan NRZ, ada pengkodean Machester, dan berbagai format menggunakan pada harddisk dengan nama penasaran baris 2.7 RLL.

Singkatnya: ada banyak trilyun cara untuk melakukan komunikasi antar sistem. Dan saya bahkan belum menyebutkan konektor atau aspek tingkat yang lebih tinggi seperti deteksi dan pemulihan kesalahan, pengodean data, kompresi, dan enkripsi ...

— Wouter van Ooijen
sumber