Komunikasi antara beberapa mikrokontroler

Saya ingin mulai menerapkan sistem yang terdiri dari N mikrokontroler (N> = 2 MCU), tetapi saya ingin tahu kemungkinan untuk membiarkan mereka berkomunikasi satu sama lain.

Idealnya, mikrokontroler (N-1) ditempatkan di dalam rumah bertindak sebagai klien, sedangkan yang terakhir ("server") terhubung ke PC melalui USB. Masalah yang saya miliki saat ini adalah bagaimana menghubungkan mikrokontroler (N-1) ini ke "server". Klien MCU melakukan tugas yang sangat sederhana, sehingga mungkin bukan solusi yang baik untuk menggunakan ARM untuk melakukan pekerjaan sederhana seperti itu hanya karena mereka menyediakan CAN / PHY-MAC .

Komunikasi tidak akan terjadi lebih dari sekali setiap beberapa menit untuk sebagian besar perangkat dan atas permintaan orang lain. Kecepatannya tidak terlalu kritis (pesan pendek): 1 Mbit / s Saya pikir WAY berlebihan untuk tujuan saya.

MCU yang saya rencanakan untuk digunakan adalah sebagai berikut.

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (Kemungkinan Atmel AVR UC3 - 32-bit)

Saya ingin menghindari PIC jika memungkinkan (pilihan pribadi), hanya karena ada lebih sedikit kemungkinan untuk memprogram mereka (semua di atas memiliki lebih atau kurang alat open source serta beberapa alat resmi).

Saya tahu beberapa ARM menyediakan fungsionalitas CAN dan tidak begitu yakin tentang yang lain.

Saat ini saya menemukan kemungkinan-kemungkinan ini:

1. GPIO sederhana untuk mengirim data (misalnya> 16 bit pada TINGGI untuk menunjukkan awal pesan,> 16 bit pada RENDAH untuk menunjukkan akhir pesan). Namun harus pada frekuensi standar << (frequency_client, frequency_server) untuk dapat mendeteksi semua bit. Hanya perlu satu kabel per MCU klien.
2. RS-232 : Saya pikir ini adalah protokol komunikasi yang paling umum digunakan, tetapi saya tidak tahu seberapa baik skala itu. Saya sedang mempertimbangkan hingga 64 klien MCU sekarang (mungkin lebih nanti)
3. USB: AFAIK ini sebagian besar seperti RS-232, tapi saya tidak berpikir itu berskala sangat baik dalam hal ini (meskipun USB mendukung banyak perangkat - 255 jika saya ingat dengan benar - mungkin terlalu rumit untuk aplikasi ini)
4. RJ45 / Ethernet: ini adalah apa yang saya benar-benar ingin gunakan, karena memungkinkan transmisi jarak jauh tanpa masalah (setidaknya dengan terlindung> kabel Cat 6 ). Masalahnya adalah biaya (PHY, MAC, transformator, ...). Saya tidak tahu apakah Anda benar-benar dapat menyoldernya dengan baik di rumah. Dengan cara ini saya tidak perlu MCU klien
5. Nirkabel / ZigBee : modul sangat mahal, meskipun mungkin cara untuk menghindari "spageti" di belakang meja
6. Modul / transceiver RF: Saya berbicara tentang mereka yang menggunakan pita 300 MHz - 1 GHz, jadi mereka harus menyolder di rumah. Modul-modulnya semuanya built-in, tetapi harganya cukup mahal seperti ZigBee (setidaknya modul RF di Mouser, di Sparkfun sepertinya ada yang lebih murah).
7. BISA? Tampaknya sangat kuat. Meskipun saya tidak berencana untuk menggunakannya dalam aplikasi otomotif, itu mungkin masih merupakan alternatif yang baik.
8. I²C / SPI / UART ? Sekali lagi - lebih baik hindari "spageti" dengan kabel jika memungkinkan
9. PLC sebenarnya bukan pilihan. Performa menurun cukup cepat seiring bertambahnya panjang dan tergantung pada beban kapasitansi jaringan listrik. Saya pikir harga-bijaksana hampir sama dengan Ethernet.

Lebih jauh lagi, protokol mana yang akan "lebih baik" dalam hal transmisi simultan (mari kita asumsikan kasus langka bahwa pada saat yang sama dua perangkat mulai mentransmisikan: protokol mana yang memberikan "sistem manajemen konflik" / "sistem manajemen tabrakan" yang terbaik?

Singkatnya : Saya ingin mendengar apa yang mungkin menjadi solusi terbaik untuk sistem klien terdistribusi yang melakukan komunikasi data sangat ringan, mempertimbangkan fleksibilitas (jumlah perangkat maksimum, sistem manajemen konflik / benturan, ...), harga , mudah dibuat di rumah (solder), ... Saya ingin menghindari menghabiskan $ 20 hanya pada modul komunikasi, tetapi pada saat yang sama memiliki 30 kabel di belakang meja akan payah.

Solusi yang saya gambarkan sekarang adalah melakukan komunikasi dasar antara MCU dekat dengan GPIO atau RS-232 ( murah !) Dan menggunakan Ethernet / ZigBee / Wi-Fi pada satu MCU per "zona" untuk berkomunikasi dengan server ( mahal , tetapi masih jauh lebih murah dari satu modul Ethernet per MCU setiap klien).

Alih-alih kabel itu mungkin dimungkinkan untuk menggunakan serat optik / serat optik. Meskipun konversi tambahan diperlukan, dan saya tidak yakin apakah itu akan menjadi solusi terbaik dalam kasus ini. Saya ingin mendengar detail tambahan tentang mereka.

BISA terdengar yang paling berlaku dalam hal ini. Jarak di dalam sebuah rumah dapat ditangani oleh CAN dengan kecepatan 500 kbits / s, yang terdengar seperti banyak bandwidth untuk kebutuhan Anda. Node terakhir bisa berupa antarmuka USB ke CAN. Itu memungkinkan perangkat lunak di komputer untuk mengirim pesan CAN dan melihat semua pesan di bus. Sisanya adalah perangkat lunak jika Anda ingin menyajikan ini ke dunia luar sebagai server TCP atau sesuatu.

CAN adalah satu-satunya sarana komunikasi yang Anda sebutkan yang sebenarnya adalah bus, kecuali untuk menggulirkan Anda sendiri dengan jalur I / O. Yang lainnya adalah point to point, termasuk ethernet. Ethernet dapat dibuat agar terlihat secara logis seperti bus dengan sakelar, tetapi koneksi individual masih menunjuk ke titik dan mendapatkan topologi bus logis akan mahal. Firmware overhead pada setiap prosesor juga jauh lebih banyak daripada CAN.

Bagian yang bagus tentang CAN adalah bahwa beberapa lapisan protokol terendah ditangani dalam perangkat keras. Sebagai contoh, banyak node dapat mencoba untuk mentransmisikan pada saat yang sama, tetapi perangkat keras menangani mendeteksi dan menangani tabrakan. Perangkat keras menangani pengiriman dan penerimaan seluruh paket, termasuk pembuatan dan validasi CRC checksum.

Alasan Anda untuk menghindari PIC tidak masuk akal. Ada banyak desain untuk programmer di luar sana untuk membangun Anda sendiri. Salah satunya adalah LProg saya , dengan skematis tersedia dari bagian bawah halaman itu. Namun, membangun milik Anda sendiri tidak akan hemat biaya kecuali jika Anda menghargai waktu Anda dengan uang receh / jam. Ini juga tentang lebih dari sekedar programmer. Anda akan membutuhkan sesuatu yang membantu dengan debugging. Microchip PicKit 2 atau 3 adalah programer dan pengadu biaya yang sangat rendah. Meskipun saya tidak memiliki pengalaman pribadi dengan mereka, saya mendengar orang lain menggunakannya secara rutin.

Ditambahkan:

Saya melihat beberapa rekomendasi untuk RS-485, tapi itu bukan ide yang baik dibandingkan dengan CAN. RS-485 adalah standar listrik saja. Ini adalah bus diferensial, sehingga memungkinkan untuk beberapa node dan memiliki kekebalan noise yang baik. Namun, BISA memiliki semua itu juga, ditambah lebih banyak lagi. CAN juga biasanya diimplementasikan sebagai bus diferensial. Beberapa berpendapat bahwa RS-485 adalah antarmuka sederhana untuk elektrik. Ini benar, tetapi begitu juga BISA. Either way chip tunggal melakukannya. Dalam kasus CAN, MCP2551 adalah contoh yang baik.

Jadi CAN dan RS-485 memiliki kelebihan yang hampir sama secara elektrik. Keuntungan besar CAN adalah di atas lapisan itu. Dengan RS-485 tidak ada yang di atas lapisan itu. Anda sendirian. Dimungkinkan untuk merancang protokol yang berhubungan dengan arbitrase bus, verifikasi paket, batas waktu, coba lagi, dll, tetapi untuk benar-benar mendapatkan hak ini jauh lebih rumit daripada yang disadari kebanyakan orang.

Protokol CAN mendefinisikan paket, checksum, penanganan tabrakan, retries, dll. Tidak hanya itu sudah ada dan dipikirkan dan diuji, tetapi keuntungan yang sangat besar adalah bahwa ia diimplementasikan secara langsung dalam silikon pada banyak mikrokontroler. Firmware berinteraksi dengan perangkat CAN pada tingkat pengiriman dan penerimaan paket. Untuk pengiriman, perangkat keras melakukan pendeteksian colllision, backoff, retry, dan generasi checksum CRC. Untuk menerima, ia melakukan deteksi paket, penyesuaian kemiringan jam, dan validasi checksum CRC. Ya perangkat CAN akan membutuhkan lebih banyak firmware untuk dikendarai daripada UART seperti yang sering digunakan dengan RS-485, tetapi ini membutuhkan kode yang jauh lebih sedikit secara keseluruhan karena silikon menangani begitu banyak detail protokol tingkat rendah.

Singkatnya, RS-485 berasal dari masa lalu dan tidak masuk akal untuk sistem baru saat ini. Masalah utama tampaknya adalah orang-orang yang menggunakan RS-485 di masa lalu berpegang teguh padanya dan berpikir BISA "rumit" entah bagaimana. Level CAN yang rendah memang rumit, tetapi begitu pula implementasi RS-485 yang kompeten. Perhatikan bahwa beberapa protokol terkenal berdasarkan RS-485 telah digantikan oleh versi yang lebih baru berdasarkan CAN. NMEA2000 adalah salah satu contoh standar berbasis CAN yang lebih baru. Ada standar otomotif lain J-J1708 (berdasarkan RS-485) yang sekarang sudah usang dengan OBD-II dan J-1939 yang berbasis CAN.

Saya akan merekomendasikan controller dengan CAN karena fitur ini dimaksudkan untuk tujuan jaringan controller.

RS232 dapat diimplementasikan dengan mudah tetapi itu akan menjadi sangat menantang jika Anda mencoba menerapkan komunikasi lebih dari 2 node (karena itu tidak dibuat untuk tujuan ini).

Ethernet juga bisa menjadi pilihan yang manis karena Anda menyebutkan beberapa interkoneksi host dan klien yang alami untuk implementasi Ethernet.

RS-485 menggunakan beberapa kabel dapat bekerja dengan baik di sini, jika ada kemungkinan untuk menghubungkan kabel yang sama ke semua perangkat.

Jika misalnya itu digunakan dengan kabel jaringan kategori 5e tradisional, Anda bisa memiliki dua pasangan yang berfungsi untuk transmisi data di kedua arah (menggunakan modul dupleks penuh), memiliki satu pasang atau bahkan mungkin kawat tunggal sebagai landasan bersama dan sisanya untuk bernegosiasi perangkat mana yang akan mentransmisikan pada saat itu. Ini sedikit lebih rumit daripada RS-232, tetapi modul lebih murah daripada CAN dan Ethernet dan batas kabel 1.200 m. Kelemahannya adalah Anda harus membuat protokol resolusi konflik sendiri. Mungkin ada perangkat yang ingin mengirimkan cek satu kabel khusus dan lihat apakah tinggi. Jika tidak, bawa tinggi dan mulai berkomunikasi dan jika ya, tunggu periode waktu acak. Namun saya masih tidak yakin seberapa baik ini akan bekerja pada jarak yang jauh.

Saya akan memilih bus RS-485 yang bekerja dengan data Pengkodean Manchester .

RS-485 karena:

• Murah
• Mudah diimplementasikan
• Apakah menggunakan kekuatan lo
• Memungkinkan untuk jarak jauh (hingga 1200 meter)
• Kecepatan data tinggi (hingga 10 Mbps)
• Kekebalan tinggi terhadap gangguan
• Ada transceiver yang memungkinkan hingga 256 perangkat di bus yang sama
• Jumlah bagian yang rendah

Pengkodean Manchester karena:

• Mudah diimplementasikan
• Disinkronkan sendiri

Untuk integritas data, pesan dapat menyertakan panjang dan bidang CRC.

Contoh fungsi CRC:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITdan CRC_POLYmerupakan nilai arbitrer yang digunakan untuk menghitung CRC.

Contoh pesan dengan bidang panjang dan CRC:

Biarkan saya membandingkan pilihan pilihan Anda, Ethernet, dengan pilihan pilihan saya, BISA.

Komponen yang dibutuhkan:

• Ethernet: konektor RJ45, magnet, chip Phy (kecuali terintegrasi ke MCU). Juga perlu sakelar dan kabel dari sakelar ke setiap simpul. Setiap PCB membutuhkan beberapa kapasitor dan termistor resistor, mungkin juga ferrites. Membutuhkan desain PCB yang bagus.
• BISA: Chip transceiver (murah), konektor apa saja, kabel murah dapat melompat dari satu simpul ke simpul berikutnya di sekitar situs. Hanya perlu satu kapasitor untuk transceiver, dan satu terminating resistor di setiap ujung bus.

Anda sedang berbicara tentang $ 1 mikrokontroler. Ada jauh lebih banyak untuk biaya bus daripada MCU. Anda harus menambahkan total biaya setiap solusi untuk mengetahui mana yang sebenarnya lebih murah. Jumlahkan biaya MCU, konektor, transceiver, komponen pasif, PCB, kabel, dll.

LPC11C24 dari NXP juga memiliki transceiver CAN yang terintegrasi, dan CANOpen didukung dalam ROM (tidak menggerogoti 32K data Flash Anda). Papan LPCXpresso 11c24 adalah 20 EUR (telah menyediakan ruang untuk konektor DB9), jadi Anda benar-benar hanya menambahkan kabel :-)

Repost dari pertanyaan serupa lainnya. Komunikasi sederhana berbiaya rendah antara dua mikrokontroler

TLDR : Tidak terlalu murah tapi cocok untuk beberapa kasus penggunaan.

Melihat di luar kotak, mungkin ada beberapa solusi lain di sini seperti mengikuti chip yang saya temui belakangan ini. Tentu saja, semua tergantung pada apa yang ingin Anda lakukan. Sesuatu seperti UART muncul di benak Anda jika Anda berdua MCU di papan yang sama atau bahkan berencana untuk ESD melindunginya secara manual jika dipisahkan.

Solusi Master dan Perangkat untuk Aplikasi IO-Link

L6360   Master
L6362A  Device

Kapan Anda akan mempertimbangkan solusi seperti ini:

1. Chip batas datang sepenuhnya dilindungi yang akan menjadi penting jika Anda memiliki masing-masing MCU pada papan yang terpisah dan berurusan dengan pin yang terbuka misalnya terminal sekrup.
   • Membalik polaritas
   • Overload dengan fungsi cut-off
   • Suhu lebih tinggi
   • Tegangan rendah dan tegangan lebih
   • Kawat terbuka GND dan VCC
2. Interoperabilitas. Jika ada orang lain yang akan merancang sisi lain yang perlu dia ketahui adalah menyalurkan data melalui IO-Link.
3. Regulator terintegrasi Vcc(in) 7~30v, Vdd(out) 3.3/5v

Kedengarannya menarik bagi saya, jadi saya pikir saya akan meletakkannya di sana.

Itu tergantung pada skala aplikasi Anda dan mikrokontroler Anda. Anda menyebutkan Atmel mungil / mega, mereka cukup kecil. Dalam kasus mereka, I2C / SPI / UART memiliki keuntungan karena mereka diimplementasikan dalam perangkat keras sehingga mudah digunakan.