การสื่อสารระหว่างไมโครคอนโทรลเลอร์หลายตัว

ฉันต้องการเริ่มต้นใช้งานระบบที่ประกอบด้วย N microcontrollers (N> = 2 MCUs) แต่ฉันต้องการทราบถึงความเป็นไปได้ที่จะให้พวกเขาสื่อสารกัน

โดยอุดมคติแล้วไมโครคอนโทรลเลอร์ (N-1) จะอยู่ภายในบ้านทำหน้าที่เป็นลูกค้าในขณะที่ตัวสุดท้าย ("เซิร์ฟเวอร์") หนึ่งตัวเชื่อมต่อกับพีซีผ่านทาง USB ปัญหาที่ฉันมีตอนนี้คือวิธีการเชื่อมต่อไมโครคอนโทรลเลอร์ (N-1) เหล่านี้เข้ากับ "เซิร์ฟเวอร์" ลูกค้า MCUs ดำเนินการง่ายมากดังนั้นมันอาจจะไม่เป็นทางออกที่ดีที่จะใช้อาวุธให้ทำงานง่ายๆเช่นเพียงเพราะพวกเขาให้ CAN / PHY-MAC

การสื่อสารจะไม่เกิดขึ้นมากกว่าหนึ่งครั้งทุกๆสองสามนาทีสำหรับอุปกรณ์ส่วนใหญ่และตามความต้องการของผู้อื่น ความเร็วไม่สำคัญมาก (ข้อความสั้น): 1 Mbit / s ฉันคิดว่าเป็นวิธีที่เกินราคาสำหรับวัตถุประสงค์ของฉัน

MCUs ที่ฉันวางแผนจะใช้มีดังต่อไปนี้

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (อาจเป็นไปได้ Atmel AVR UC3 - 32-bit)

ฉันต้องการหลีกเลี่ยงPICหากเป็นไปได้ (ตัวเลือกส่วนบุคคล) เพียงเพราะมีความเป็นไปได้น้อยในการเขียนโปรแกรม (ทั้งหมดข้างต้นมีเครื่องมือโอเพนซอร์ซมากขึ้นหรือน้อยลงรวมถึงเครื่องมือทางการบางอย่าง)

ฉันรู้ว่า ARM บางตัวมีฟังก์ชั่นCANและไม่แน่ใจเกี่ยวกับคนอื่น

ตอนนี้ฉันมากับความเป็นไปได้เหล่านี้:

1. GPIO ง่าย ๆ ในการส่งข้อมูล (พูด> 16 บิตที่ HIGH เพื่อระบุจุดเริ่มต้นของข้อความ> 16 บิตที่ LOW เพื่อระบุจุดสิ้นสุดข้อความ) อย่างไรก็ตามจะต้องอยู่ที่ความถี่มาตรฐาน << (frequency_client, frequency_server) เพื่อให้สามารถตรวจจับบิตทั้งหมด ต้องการเพียงหนึ่งสายต่อ MCU ลูกค้า
2. RS-232 : ฉันคิดว่านี่เป็นโปรโตคอลการสื่อสารที่ใช้กันมากที่สุด แต่ฉันก็ไม่รู้ว่ามันจะขยายขนาดได้ดีแค่ไหน ฉันกำลังพิจารณา MCU ลูกค้าสูงสุด 64 คนในขณะนี้ (อาจจะมากกว่านี้ในภายหลัง)
3. USB: AFAIK ส่วนใหญ่เหมือนกับ RS-232 แต่ฉันไม่คิดว่ามันจะขยายได้ดีในกรณีนี้ (แม้ว่า USB รองรับอุปกรณ์จำนวนมาก - 255 ถ้าฉันจำได้อย่างถูกต้อง - มันอาจซับซ้อนเกินไปสำหรับแอปพลิเคชันนี้)
4. RJ45 / Ethernet: นี่คือสิ่งที่ฉันชอบที่จะใช้เพราะช่วยให้สามารถส่งสัญญาณในระยะทางไกลโดยไม่มีปัญหา (อย่างน้อยก็มีสายเคเบิลCat 6ที่มีฉนวนหุ้ม) ปัญหาคือค่าใช้จ่าย (PHY, MAC, หม้อแปลง, ... ) ฉันไม่รู้ว่าคุณสามารถประสานกับบ้านได้ดีหรือไม่ วิธีนี้ฉันไม่ต้องการไคลเอนต์ MCU
5. ไร้สาย / ZigBee : โมดูลมีราคาแพงมากแม้ว่ามันอาจเป็นวิธีที่จะไปเพื่อหลีกเลี่ยง "สปาเก็ตตี้" หลังโต๊ะ
6. โมดูล RF / เครื่องส่งสัญญาณ: ฉันพูดถึงพวกมันในย่านความถี่ 300 MHz - 1 GHz ดังนั้นพวกเขาควรจะบัดกรีที่บ้านยาก โมดูลทั้งหมดมีในตัว แต่ก็ค่อนข้างแพงเท่า ZigBee (อย่างน้อยโมดูลของ RF ที่ บริษัท Mouser ที่ Sparkfun นั้นมีราคาถูกกว่า)
7. สามารถ? ดูเหมือนว่าจะแข็งแกร่งมาก แม้ว่าฉันจะไม่ได้วางแผนที่จะใช้ในแอพพลิเคชั่นยานยนต์ แต่มันก็อาจเป็นทางเลือกที่ดี
8. I²C / SPI / UART ? อีกครั้ง - หลีกเลี่ยง "สปาเก็ตตี้" ด้วยสายเคเบิลถ้าเป็นไปได้
9. PLCไม่ใช่ตัวเลือกจริงๆ ประสิทธิภาพจะลดลงอย่างรวดเร็วเมื่อความยาวเพิ่มขึ้นและขึ้นอยู่กับโหลดความจุของเครือข่ายพลังงาน ฉันคิดว่าราคาที่ชาญฉลาดนั้นใกล้เคียงกับ Ethernet

นอกจากนี้โพรโทคอลใดที่จะ "ดีกว่า" ในกรณีที่มีการส่งสัญญาณพร้อมกัน (สมมติว่าเป็นกรณีที่หาได้ยากที่อุปกรณ์สองทันทีเริ่มส่งสัญญาณเดียวกัน: โปรโตคอลใดที่ให้ระบบการจัดการความขัดแย้งที่ดีที่สุด

เพื่อสรุป : ฉันต้องการฟังสิ่งที่อาจเป็นทางออกที่ดีที่สุดสำหรับระบบไคลเอนต์แบบกระจายที่ทำการสื่อสารข้อมูลที่เบามากโดยพิจารณาทั้งความยืดหยุ่น (จำนวนสูงสุดของอุปกรณ์ระบบการจัดการความขัดแย้ง / การชนกัน, ... ) ราคา ง่ายต่อการทำที่บ้าน (บัดกรี), ... ฉันต้องการหลีกเลี่ยงการใช้จ่าย $ 20 เพียงแค่โมดูลการสื่อสาร แต่ในเวลาเดียวกันการมี 30 สายหลังโต๊ะจะดูด

โซลูชันที่ฉันถ่ายภาพในขณะนี้คือการสื่อสารขั้นพื้นฐานระหว่าง MCU ใกล้โดย GPIO หรือ RS-232 ( ราคาถูก !) และใช้ Ethernet / ZigBee / Wi-Fi บนหนึ่ง MCU ต่อ "โซน" เพื่อสื่อสารกับเซิร์ฟเวอร์ ( แพง)แต่ยังคงราคาถูกกว่าโมดูลอีเธอร์เน็ตหนึ่งโมดูลต่อไคลเอนต์ MCU แต่ละตัว)

แทนที่จะใช้สายเคเบิลก็อาจเป็นไปได้ที่จะใช้ใยแก้วนำแสง / เส้นใยแสง แม้ว่าจะต้องมีการแปลงเพิ่ม แต่ฉันไม่แน่ใจว่าจะเป็นทางออกที่ดีที่สุดในกรณีนี้หรือไม่ ฉันต้องการฟังรายละเอียดเพิ่มเติมเกี่ยวกับพวกเขา

สามารถฟังได้มากที่สุดในกรณีนี้ ระยะทางในบ้านสามารถจัดการได้โดยที่ 500 kbits / s ซึ่งฟังดูเหมือนแบนด์วิธมากมายสำหรับความต้องการของคุณ โหนดสุดท้ายสามารถเป็น off USB ของชั้นวางเพื่อเชื่อมต่อกับ CAN ที่ช่วยให้ซอฟต์แวร์ในคอมพิวเตอร์สามารถส่งข้อความ CAN และดูข้อความทั้งหมดบนบัส ส่วนที่เหลือเป็นซอฟต์แวร์ถ้าคุณต้องการนำเสนอสิ่งนี้กับโลกภายนอกในฐานะเซิร์ฟเวอร์ TCP หรืออะไรบางอย่าง

CAN เป็นการสื่อสารเพียงอย่างเดียวหมายความว่าคุณพูดถึงว่าเป็นรถบัสจริง ๆ ยกเว้นการรีดด้วยสาย I / O ของคุณเอง ส่วนคนอื่น ๆ นั้นชี้ไปที่จุดรวมถึงอีเธอร์เน็ต อีเธอร์เน็ตสามารถสร้างให้ดูเหมือนเป็นรถบัสที่มีเหตุผล แต่การเชื่อมต่อส่วนบุคคลยังคงชี้ไปที่จุดและการรับโลจิคัลบัสทอพอโลยีจะมีราคาแพง โอเวอร์เฮดของเฟิร์มแวร์สำหรับโปรเซสเซอร์แต่ละตัวนั้นมีค่ามากกว่า CAN อย่างมาก

ส่วนที่ดีเกี่ยวกับ CAN คือจัดการเลเยอร์โพรโทคอลที่น้อยที่สุดในฮาร์ดแวร์ ตัวอย่างเช่นหลายโหนดสามารถลองส่งในเวลาเดียวกัน แต่ฮาร์ดแวร์ดูแลการตรวจจับและจัดการกับการชนกัน ฮาร์ดแวร์จะดูแลการส่งและรับแพ็กเก็ตทั้งหมดรวมถึงการสร้างการตรวจสอบ CRC และการตรวจสอบความถูกต้อง

เหตุผลของคุณในการหลีกเลี่ยงภาพที่ไม่สมเหตุสมผล มีหลายการออกแบบสำหรับโปรแกรมเมอร์ออกมีสำหรับการสร้างของคุณเอง หนึ่งคือLProgของฉันโดยมีแผนผังพร้อมใช้งานจากด้านล่างของหน้านั้น อย่างไรก็ตามการสร้างของคุณเองจะไม่คุ้มค่าเว้นแต่คุณจะให้ความสำคัญกับเวลาเป็นเงิน / ชั่วโมง มันเป็นอะไรที่มากกว่าแค่โปรแกรมเมอร์ คุณจะต้องมีสิ่งที่ช่วยในการดีบัก Microchip PicKit 2 หรือ 3 เป็นโปรแกรมเมอร์และผู้ดีบักราคาถูกมาก แม้ว่าฉันจะไม่มีประสบการณ์ส่วนตัวกับพวกเขา แต่ฉันได้ยินจากคนอื่น ๆ ที่ใช้พวกเขาเป็นประจำ

ที่เพิ่ม:

ฉันเห็นคำแนะนำบางอย่างสำหรับ RS-485 แต่นั่นไม่ใช่ความคิดที่ดีเมื่อเทียบกับ CAN RS-485 เป็นมาตรฐานไฟฟ้าเท่านั้น มันเป็นรถบัสที่แตกต่างกันดังนั้นจะอนุญาตให้มีหลายโหนดและมีภูมิคุ้มกันทางเสียงที่ดี อย่างไรก็ตามสามารถมีทุกอย่างพร้อมกับอีกมาก CAN มักจะนำมาใช้เป็นบัสที่แตกต่างกัน บางคนโต้แย้งว่า RS-485 นั้นง่ายต่อการเชื่อมต่อกับระบบไฟฟ้า นี่เป็นเรื่องจริง แต่ก็เป็นเช่นนั้นได้ ไม่ว่าจะเป็นชิปตัวเดียวก็ทำได้ ในกรณีของ CAN MCP2551 เป็นตัวอย่างที่ดี

ดังนั้น CAN และ RS-485 จึงมีข้อดีเหมือนกันทางไฟฟ้า ข้อได้เปรียบที่สำคัญของ CAN อยู่เหนือเลเยอร์นั้น ด้วย RS-485 ไม่มีอะไรเหนือชั้นนั้น คุณเป็นของคุณเอง มันเป็นไปได้ที่จะออกแบบโปรโตคอลที่เกี่ยวกับการอนุญาโตตุลาการบัส, การตรวจสอบแพ็คเก็ต, หมดเวลา, ลองใหม่และอื่น ๆ แต่จริงๆแล้วการได้รับสิทธินี้เป็นเรื่องยุ่งยากมากกว่าที่คนส่วนใหญ่ตระหนัก

โปรโตคอล CAN กำหนดแพ็คเก็ต, checksums, การจัดการการชน, ลองใหม่และอื่น ๆ ไม่เพียง แต่มันมีอยู่แล้วและคิดออกและทดสอบ แต่ข้อได้เปรียบที่ใหญ่จริงๆคือมันถูกนำมาใช้โดยตรงในซิลิคอนบนไมโครคอนโทรลเลอร์หลายตัว ส่วนต่อประสานเฟิร์มแวร์กับอุปกรณ์ต่อพ่วง CAN ที่ระดับการส่งและรับแพ็กเก็ต สำหรับการส่งฮาร์ดแวร์ทำการตรวจสอบ colllision, การแบคออฟ, ลองใหม่และการสร้างเช็กซัม CRC สำหรับการรับจะทำการตรวจจับแพ็คเก็ตปรับนาฬิกาเอียงและตรวจสอบการตรวจสอบ CRC ใช่อุปกรณ์ต่อพ่วง CAN จะใช้เฟิร์มแวร์ในการขับมากกว่า UART เช่นมักใช้กับ RS-485 แต่ใช้รหัสน้อยกว่ามากเนื่องจากซิลิคอนจัดการกับรายละเอียดโปรโตคอลระดับต่ำมาก

ในระยะสั้น RS-485 นั้นมาจากยุคอดีตและไม่เข้าท่าสำหรับระบบใหม่ในปัจจุบัน ปัญหาหลักน่าจะเป็นคนที่ใช้ RS-485 ในอดีตที่ยึดติดกับมันและคิดว่าสามารถ "ซับซ้อน" อย่างใด ระดับต่ำของ CAN มีความซับซ้อน แต่การใช้งาน RS-485 ใด ๆ ที่มีความสามารถ โปรดทราบว่าโปรโตคอลที่รู้จักกันดีหลายตัวที่ใช้ RS-485 นั้นถูกแทนที่ด้วยเวอร์ชันที่ใหม่กว่าซึ่งอ้างอิงตาม CAN NMEA2000 เป็นหนึ่งในตัวอย่างของมาตรฐาน CAN-based ที่ใหม่กว่า มีมาตรฐานยานยนต์อีก J-J1708 (อิงจาก RS-485) ที่ล้าสมัยไปแล้วในปัจจุบันด้วย CAN-based OBD-II และ J-1939

ฉันอยากจะแนะนำคอนโทรลเลอร์ที่มี CAN เนื่องจากคุณสมบัตินี้มีจุดประสงค์เพื่อการเชื่อมต่อเครือข่ายคอนโทรลเลอร์

สามารถนำไปใช้งานได้อย่างง่ายดาย RS232 แต่มันจะกลายเป็นความท้าทายอย่างแท้จริงถ้าคุณพยายามที่จะใช้การสื่อสารมากกว่า 2 โหนด (เพราะมันไม่ได้ถูกสร้างขึ้นเพื่อวัตถุประสงค์นี้)

อีเธอร์เน็ตก็เป็นทางเลือกที่น่าสนใจเช่นกันเนื่องจากคุณกล่าวถึงการเชื่อมต่อระหว่างโฮสต์และไคลเอนต์ซึ่งเป็นเรื่องปกติสำหรับการใช้งานอีเธอร์เน็ต

RS-485 ที่ใช้สายไฟหลายเส้นสามารถทำงานได้ดีที่นี่หากมีความเป็นไปได้ในการเชื่อมสายเดียวกันกับอุปกรณ์ทั้งหมด

ตัวอย่างเช่นมันใช้กับสายเคเบิลเครือข่ายประเภท 5e แบบดั้งเดิมคุณสามารถมีสองคู่ให้ทำงานสำหรับการรับส่งข้อมูลในทั้งสองทิศทาง (โดยใช้โมดูลดูเพล็กซ์เต็มรูปแบบ) มีคู่หนึ่งคู่หรืออาจเป็นสายเดี่ยวเป็นพื้นทั่วไปและที่เหลือ อุปกรณ์ใดกำลังจะส่งสัญญาณในช่วงเวลาใด มันค่อนข้างซับซ้อนกว่า RS-232 แต่โมดูลนั้นราคาถูกกว่า CAN และ Ethernet และความยาวของสายเคเบิลคือ 1200 ม. ข้อเสียคือคุณจะต้องสร้างโปรโตคอลการแก้ไขข้อขัดแย้งของคุณเอง อาจมีอุปกรณ์ที่ต้องการส่งตรวจสอบสายหนึ่งและดูว่ามันสูง หากไม่เป็นเช่นนั้นให้นำมาไว้ในระดับสูงและเริ่มการสื่อสารและหากเป็นเช่นนั้นให้รอช่วงเวลาแบบสุ่ม ถึงกระนั้นฉันก็ยังไม่แน่ใจว่ามันจะทำงานได้ดีในระยะทางไกล

ฉันจะเลือกรถบัส RS-485 ที่ทำงานด้วย ข้อมูลการเข้ารหัสของแมนเชสเตอร์

RS-485 เพราะ:

• มีราคาถูก
• ใช้งานง่าย
• คือการใช้พลังงานแท้จริง
• ช่วยให้ระยะทางไกล (สูงถึง 1200 เมตร)
• อัตราการส่งข้อมูลสูง (สูงสุด 10 Mbps)
• ภูมิคุ้มกันสูงต่อการรบกวน
• มีตัวรับส่งสัญญาณที่อนุญาตให้มีได้ถึง 256 อุปกรณ์บนบัสเดียวกัน
• ส่วนที่ต่ำ

การเข้ารหัสแมนเชสเตอร์เพราะ:

• ใช้งานง่าย
• สามารถซิงโครไนซ์ได้เอง

สำหรับความถูกต้องของข้อมูลข้อความอาจมีความยาวและฟิลด์ CRC

ตัวอย่างของฟังก์ชั่น 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_INITและCRC_POLYเป็นค่าโดยพลการที่ใช้ในการคำนวณ CRC

ตัวอย่างของข้อความที่มีความยาวและฟิลด์ CRC:

ให้ฉันเปรียบเทียบตัวเลือกที่คุณต้องการอีเธอร์เน็ตกับตัวเลือกที่ฉันต้องการ

ส่วนประกอบที่จำเป็น:

• อีเธอร์เน็ต: ขั้วต่อ RJ45, แม่เหล็ก, ชิป Phy (เว้นแต่จะรวมอยู่ใน MCU) ยังต้องการสวิตช์และสายเคเบิลจากสวิตช์ไปยังแต่ละโหนด PCB แต่ละตัวต้องการตัวเก็บประจุค่อนข้างน้อยและยกเลิกตัวต้านทานซึ่งอาจเป็นเฟอร์ไรต์ด้วย ต้องการการออกแบบ PCB ที่ดี
• CAN: ชิปตัวรับส่งสัญญาณ (ราคาถูก), ตัวเชื่อมต่อใด ๆ , สายเคเบิลราคาถูกสามารถข้ามจากโหนดหนึ่งไปยังอีกโหนดหนึ่งได้ในวงรอบไซต์ ต้องการตัวเก็บประจุเพียงตัวเดียวสำหรับตัวรับส่งสัญญาณและตัวต้านทานหนึ่งตัวที่ปลายบัส

คุณกำลังพูดถึงไมโครคอนโทรลเลอร์ $ 1 มีค่าใช้จ่ายต่อบัสมากกว่า MCU คุณจะต้องรวมค่าใช้จ่ายทั้งหมดของแต่ละวิธีเพื่อให้ทราบว่าราคาใดถูกกว่าจริง เพิ่มค่าใช้จ่ายของ MCU ตัวเชื่อมต่อตัวรับส่งสัญญาณส่วนประกอบแบบพาสซีฟ PCB สายเคเบิลและอื่น ๆ

LPC11C24 จาก NXP ยังมีตัวรับส่งสัญญาณ CAN ที่รวมอยู่ในตัวและ CANOpen รองรับใน ROM (ไม่ได้กินแฟลชข้อมูล 32 K ของคุณ) LPCXpresso 11c24 board คือ 20 EUR (ให้พื้นที่สำหรับขั้วต่อ DB9) ดังนั้นคุณเพียงแค่เพิ่มสาย :-)

โพสต์จากคำถามอื่นที่คล้ายกัน การสื่อสารที่เรียบง่ายราคาประหยัดระหว่างไมโครคอนโทรลเลอร์สองตัว

TLDR : ไม่ถูกโดยเฉพาะอย่างยิ่ง แต่พอดีกับความน่าเชื่อถือในบางกรณีการใช้งาน

เมื่อมองออกไปนอกกรอบอาจมีวิธีแก้ไขปัญหาอื่น ๆ ที่นี่เช่นชิปต่อไปที่ฉันชนเข้ากับเมื่อเร็ว ๆ นี้ แน่นอนมันทั้งหมดขึ้นอยู่กับสิ่งที่คุณต้องการจะทำ บางอย่างเช่น UART เป็นสิ่งที่คำนึงถึงหากคุณมีทั้ง MCUs บนบอร์ดเดียวกันหรือแม้แต่การวางแผน ESD ป้องกันด้วยตนเองหากแยก

โซลูชันหลักและอุปกรณ์สำหรับแอปพลิเคชัน IO-Link

L6360   Master
L6362A  Device

เมื่อใดที่คุณจะพิจารณาโซลูชันเช่นนี้

1. ชิปชายแดนได้รับการปกป้องอย่างเต็มที่ซึ่งสำคัญหากคุณมี MCU แต่ละตัวบนบอร์ดแยกต่างหากและจัดการกับหมุดสัมผัสเช่นขั้วเกลียว
   • ขั้วกลับ
   • โอเวอร์โหลดด้วยฟังก์ชั่นตัด
   • Overtemperature
   • แรงดันและแรงดันเกิน
   • สายเปิด GND และ VCC
2. การทำงานร่วมกัน หากมีคนอื่นกำลังออกแบบด้านอื่น ๆ ทั้งหมดที่เขาต้องรู้ก็คือการส่งข้อมูลผ่าน IO-Link
3. บูรณาการควบคุม Vcc(in) 7~30v, Vdd(out) 3.3/5v

ฟังดูน่าสนใจสำหรับฉันดังนั้นฉันคิดว่าฉันจะเอามันออกไป

ขึ้นอยู่กับขนาดของแอพพลิเคชันและไมโครคอนโทรลเลอร์ของคุณ คุณพูดถึง Atmel จิ๋ว / เมก้าพวกมันค่อนข้างเล็ก ในกรณีของพวกเขา I2C / SPI / UART มีข้อได้เปรียบที่พวกเขานำมาใช้ในฮาร์ดแวร์และใช้งานง่าย