Komunikasi antara beberapa mikrokontroler


20

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.


2
Ada PIC dengan fungsionalitas CAN dan ada alat resmi gratis untuk memprogramnya dengan dokumentasi.
AndrejaKo

@AndrejaKo PIC tidak benar-benar memiliki kompiler open source seperti AVR atau setidaknya MSP430s. Memang benar bahwa mereka sering menyediakan lebih banyak fitur daripada MCU yang saya sebutkan di atas dengan harga yang sama. Saya tidak terlalu suka perbedaan besar antara keluarga 12/16/18/24/32 dan beberapa dari mereka tidak memiliki kompiler gratis sama sekali (saya pikir ini PIC18).
user51166

2
Sebenarnya PIC18 memang memiliki kompiler gratis dan begitu juga yang lain. Bonus utama dari keluarga lain adalah mereka bekerja dengan GCC. Di perkemahan open source, ada kompiler Small device C yang harus mendukung perangkat PIC 16 dan PIC 18.
AndrejaKo

2
Jika Anda belum berpengalaman dengan salah satu UC yang Anda sebutkan, berhati-hatilah bahwa ARM jauh lebih sulit untuk memulai daripada dari misalnya PIC atau AVR, terutama jika Anda ingin menjadi open source. Dengan ARM, vendor tidak mendesain inti, dan juga umumnya tidak menyediakan IDE, yang dapat membuat semuanya menjadi sedikit lebih kompleks. Sangat menyenangkan memiliki mis. Microchip menyediakan dan mendukung segala hal dalam hal PIC.
Oli Glaser

@ OliGlaser Yah ... walaupun memang benar bahwa alat open source untuk ARM bisa sedikit sulit digunakan (saya sudah mencoba papan STM32 Discovery dan tidak bekerja dengan baik), banyak vendor menawarkan IDE yang - dengan pro & kontra - berbasis gerhana dan terbatas-bebas: LPCXpresso (NXP) dan Code Composer Studio (TI) misalnya (bukan open-source, tetapi setidaknya didukung). AVR di sisi lain cukup baik didukung di sisi open source, serta di ATMEL STUDIO 6. Tidak ada pengalaman dengan PIC sama sekali. Hanya kode AVR (assembler) dan ARM (C, pada NDS).
user51166

Jawaban:


22

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.


membangun papan kustom saya sendiri berguna ketika mengintegrasikan MCU dengan perangkat keras yang ada di sekitarnya. Untuk tujuan pengembangan saya setuju kit pengembangan adalah cara yang lebih baik. Alasan saya untuk menghindari PIC adalah kurangnya kompiler open source (ada beberapa gratis, tetapi tidak untuk PIC18 misalnya) daripada kurangnya skema publik yang tersedia, meskipun mereka menyediakan beberapa fitur tambahan yang mungkin tidak Anda temukan di MCU lain (Ethernet, BISA, ...). Dan I2C adalah bus AFAIK.
user51166

@ user51166 - Ada kompiler PIC18 gratis yang disediakan oleh microchip. Lihat halaman produk MPLAB XC Compiler . Ini juga mencantumkan kompiler untuk 16bit dan 32bit UC.
PetPaulsen

@ user51166 Ada juga kompiler C18 gratis juga.
AndrejaKo

@PetPaulsen Strange. Saya cukup yakin saya melihat sebulan yang lalu sebuah halaman yang mendaftar semua kompiler tersedia secara bebas untuk diunduh (PIC16 / 24/32), dengan pengecualian PIC18 yang bukan karena masalah lisensi yang mereka miliki. Mungkin itu diselesaikan dengan transisi MPLAB C Compiler -> MPLAB XC Compiler meskipun saya tidak yakin. Selain itu, mereka "hanya" menawarkan edisi freeware yang tidak mengoptimalkan kode Anda, bukan kompilator open source sepenuhnya. Masih lebih baik daripada tidak sama sekali;)
user51166

@ pengguna: Saya percaya semua kompiler Microchip memiliki versi gratis yang hanya berbeda dari yang lengkap karena beberapa optimasi dinonaktifkan. Assembler, pustakawan, linker, dan simulator semuanya termasuk dalam paket MPLAB gratis. Sebenarnya tidak ada masalah di sini.
Olin Lathrop

6

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.


Apa kelebihan CAN over Ethernet misalnya? Lebih murah mungkin, tapi selain itu, apa lagi?
user51166

@ user51166 - CAN bukan hanya lebih murah tetapi jauh lebih murah. Ini tidak hanya lebih mudah, tetapi juga lebih mudah.
Rocketmagnet

@Rocketmagnet: tolong jelaskan sedikit lebih banyak. Dalam kebanyakan kasus Anda tetap memerlukan IC terintegrasi (meskipun PIC dan ARM dan lainnya? Sering mengintegrasikan fitur BISA, mereka agak mahal). Dari sudut pandang perangkat keras saya tidak melihat bagaimana ini bisa jauh lebih murah karena IC dapat ditemukan untuk $ 0,5-1,0 sepotong. Saya kira maksud Anda lebih mudah dari sudut pandang perangkat lunak, bukan? BISA memiliki jarak maksimum ~ 500 meter yang tentunya cukup dalam kasus saya, tetapi - hanya untuk informasi - akankah ada alternatif serupa untuk jarak yang lebih jauh (mungkin serat optik)?
user51166

4

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.


Tidak perlu khawatir tentang jarak yang terlalu jauh, saya tidak berencana mencapai lebih dari 100m saat ini.
user51166

Mengapa BTW hari ini stackexchange tidak menerima @ <username>? Setiap kali saya meletakkan satu, itu akan sepenuhnya dihapus (bukan hanya simbol @) ...
user51166

@ user51166 - Pembuat jawabannya secara otomatis diberitahu, sehingga "\ @ - noise" dihapus secara otomatis. (My \ @ user51166 tidak dihapus, karena Anda bukan pembuat jawaban ini)
PetPaulsen

Yang menarik adalah saya tidak menerima pemberitahuan untuk semua komentar di sini.
AndrejaKo

4

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:

Contoh pesan


Ada saran untuk transceiver yang bagus, mungkin murah?
user51166

Lebih jauh seperti yang disarankan @AndrejaKo RS-485 tampaknya tidak menawarkan protokol resolusi konflik.
user51166

Pilihan transceiver tergantung pada tegangan yang ingin Anda gunakan. Resolusi konflik harus dibuat dalam perangkat lunak dengan pemeriksaan CRC, pemantauan garis atau keduanya.
Bruno Ferreira

Jika Anda memiliki satu master, Anda juga bisa mengimplementasikan semacam pengalamatan, atau mengubah transmisi berbasis.
Bruno Ferreira

Bukan benar-benar master. Hanya "server" yang bertindak seperti antarmuka ke PC melalui USB. Namun, klien harus mengirim pesan kepadanya secara otomatis ...
user51166

3

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.


0

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 :-)


0

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

masukkan deskripsi gambar di sini

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.


-3

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.


3
OK, tapi bagaimana ini mengatasi masalah OP? IIC adalah bus, tetapi benar-benar tidak cocok sama sekali untuk jarak jauh seperti melintasi rumah. Itu tunggal berakhir dan impedansi yang relatif tinggi. SPI adalah bus, tetapi dikendalikan oleh satu master dengan jalur pilih slave terpisah untuk setiap perangkat. Anda dapat menerapkan setiap baris sebagai pasangan diferensial dengan driver dan penerima saluran, tetapi Anda masih memiliki master titik ke titik untuk memilih masalah. UART secara ketat menunjuk ke titik. Tidak jelas bagaimana Anda bermaksud menggunakannya dalam situasi OP.
Olin Lathrop
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.