Giao tiếp giữa nhiều bộ vi điều khiển

Tôi muốn bắt đầu triển khai một hệ thống bao gồm N vi điều khiển (N> = 2 MCU), nhưng tôi muốn biết các khả năng để cho phép chúng giao tiếp với nhau.

Lý tưởng nhất là các bộ vi điều khiển (N-1) được đặt bên trong ngôi nhà đóng vai trò là khách hàng, trong khi bộ vi điều khiển cuối cùng ("máy chủ") được kết nối với PC thông qua USB. Vấn đề tôi gặp phải bây giờ là làm thế nào để kết nối các bộ vi điều khiển (N-1) này với "máy chủ". MCU khách hàng thực hiện các tác vụ rất đơn giản, do đó, có thể không phải là một giải pháp tốt để sử dụng ARM để thực hiện các công việc đơn giản như vậy chỉ vì chúng cung cấp CAN / PHY-MAC .

Giao tiếp sẽ không xảy ra nhiều hơn một lần trong hầu hết các thiết bị và theo yêu cầu cho người khác. Tốc độ không quá quan trọng (tin nhắn ngắn): 1 Mbit / s Tôi nghĩ là CÁCH quá mức cho mục đích của tôi.

MCU tôi dự định sử dụng là như sau.

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (Có thể là Atmel AVR UC3 - 32-bit)

Tôi muốn tránh PIC nếu có thể (lựa chọn cá nhân), đơn giản vì có ít khả năng lập trình chúng hơn (tất cả các công cụ trên có ít nhiều công cụ nguồn mở cũng như một số công cụ chính thức).

Tôi biết một số ARM cung cấp chức năng CAN và không chắc chắn về những cái khác.

Ngay bây giờ tôi đã đưa ra những khả năng này:

1. GPIO đơn giản để gửi dữ liệu (giả sử> 16 bit ở mức CAO để biểu thị bắt đầu tin nhắn,> 16 bit ở mức THẤP để biểu thị kết thúc tin nhắn). Tuy nhiên, nó phải ở tần số chuẩn << (tần số_client, tần số máy chủ) để có thể phát hiện tất cả các bit. Chỉ cần một cáp cho mỗi MCU khách hàng.
2. RS-232 : Tôi nghĩ rằng đây là giao thức truyền thông được sử dụng phổ biến nhất, nhưng tôi không biết nó có quy mô như thế nào. Tôi đang xem xét tới 64 MCU khách hàng ngay bây giờ (có thể muộn hơn)
3. USB: AFAIK nó giống như RS-232, nhưng tôi không nghĩ nó có khả năng mở rộng rất tốt trong trường hợp này (mặc dù USB hỗ trợ rất nhiều thiết bị - 255 nếu tôi nhớ chính xác - nó có thể quá phức tạp cho ứng dụng này)
4. RJ45 / Ethernet: đây là thứ tôi thực sự thích sử dụng, vì nó cho phép truyền qua khoảng cách xa mà không gặp vấn đề gì (ít nhất là với cáp được bảo vệ> cáp Cat 6 ). Vấn đề là chi phí (PHY, MAC, máy biến áp, ...). Tôi không biết nếu bạn thực sự có thể hàn nó tốt ở nhà mặc dù. Bằng cách này, tôi sẽ không cần MCU khách hàng
5. Wireless / ZigBee : các mô-đun rất đắt tiền, mặc dù đó có thể là cách để tránh "spaghetti" phía sau bàn
6. Các mô-đun / thu phát RF: Tôi đang nói về những người trong dải tần 300 MHz - 1 GHz, vì vậy chúng sẽ khó hàn ở nhà. Các mô-đun đều được tích hợp sẵn, nhưng chúng khá đắt như ZigBee (ít nhất là các mô-đun của RF tại Mouser, tại Sparkfun dường như có những cái rẻ hơn).
7. CÓ THỂ? Nó có vẻ là rất mạnh mẽ. Mặc dù tôi không có kế hoạch sử dụng nó trong các ứng dụng ô tô, nó vẫn có thể là một lựa chọn tốt.
8. I²C / SPI / UART ? Một lần nữa - tốt hơn nên tránh "spaghetti" với các dây cáp nếu có thể
9. PLC không thực sự là một lựa chọn. Hiệu suất giảm khá nhanh khi chiều dài tăng và phụ thuộc vào tải điện dung của mạng điện. Tôi nghĩ rằng giá cả cũng giống như Ethernet.

Hơn nữa, giao thức nào sẽ "tốt hơn" trong trường hợp truyền đồng thời (giả sử trường hợp hiếm hoi là ngay lập tức hai thiết bị bắt đầu truyền: giao thức nào cung cấp "hệ thống quản lý xung đột" / "hệ thống quản lý xung đột" tốt nhất?

Tóm lại : Tôi muốn nghe điều gì có thể là giải pháp tốt nhất cho hệ thống máy khách phân tán thực hiện giao tiếp dữ liệu rất nhẹ, xem xét cả tính linh hoạt (số lượng thiết bị tối đa, hệ thống quản lý xung đột / xung đột, ...), giá cả , dễ dàng thực hiện tại nhà (hàn), ... Tôi muốn tránh chi 20 đô la cho chỉ mô-đun giao tiếp, nhưng đồng thời có 30 dây phía sau bàn sẽ hút.

Giải pháp tôi đang hình ảnh ngay bây giờ là thực hiện giao tiếp cơ bản giữa các MCU gần bằng GPIO hoặc RS-232 ( giá rẻ !) Và sử dụng Ethernet / ZigBee / Wi-Fi trên một MCU trên mỗi "vùng" để liên lạc với máy chủ ( đắt tiền , nhưng nó vẫn rẻ hơn rất nhiều so với một mô-đun Ethernet trên mỗi MCU của máy khách).

Thay vì cáp, nó cũng có thể sử dụng sợi quang / sợi quang. Mặc dù các chuyển đổi bổ sung là cần thiết và tôi không chắc liệu đó có phải là giải pháp tốt nhất trong trường hợp này hay không. Tôi muốn nghe thêm chi tiết về họ.

CAN âm thanh áp dụng nhất trong trường hợp này. Khoảng cách bên trong một ngôi nhà có thể được xử lý bởi CAN với tốc độ 500 kbits / giây, nghe có vẻ nhiều băng thông cho nhu cầu của bạn. Nút cuối cùng có thể là giao diện USB sang CAN. Điều đó cho phép phần mềm trong máy tính gửi tin nhắn CAN và xem tất cả các tin nhắn trên xe buýt. Phần còn lại là phần mềm nếu bạn muốn trình bày nó với thế giới bên ngoài như một máy chủ TCP hoặc một cái gì đó.

CAN là phương tiện liên lạc duy nhất mà bạn đã đề cập thực sự là một chiếc xe buýt, ngoại trừ việc tự di chuyển bằng các đường I / O. Tất cả những cái khác là điểm tới điểm, bao gồm ethernet. Ethernet có thể được tạo ra để trông giống như một chiếc xe buýt với các bộ chuyển mạch, nhưng các kết nối riêng lẻ vẫn được điểm tới điểm và có được cấu trúc liên kết bus logic sẽ rất tốn kém. Chi phí phần sụn trên mỗi bộ xử lý cũng nhiều hơn đáng kể so với CAN.

Phần hay của CAN là các lớp giao thức thấp nhất được xử lý trong phần cứng. Ví dụ, nhiều nút có thể cố gắng truyền cùng một lúc, nhưng phần cứng đảm nhiệm việc phát hiện và xử lý các va chạm. Phần cứng đảm nhiệm việc gửi và nhận toàn bộ các gói, bao gồm cả việc tạo và xác nhận tổng kiểm tra CRC.

Lý do của bạn để tránh PIC không có ý nghĩa gì. Có rất nhiều thiết kế cho các lập trình viên ngoài kia để xây dựng của riêng bạn. Một là LProg của tôi , với sơ đồ có sẵn từ dưới cùng của trang đó. Tuy nhiên, việc xây dựng của riêng bạn sẽ không có hiệu quả về chi phí trừ khi bạn coi trọng thời gian của mình ở mức một xu / giờ. Nó cũng không chỉ là về lập trình viên. Bạn sẽ cần một cái gì đó hỗ trợ với gỡ lỗi. Microchip PicKit 2 hoặc 3 là những lập trình viên và trình gỡ lỗi có chi phí rất thấp. Mặc dù tôi không có kinh nghiệm cá nhân với họ, tôi nghe thấy những người khác sử dụng chúng thường xuyên.

Thêm:

Tôi thấy một số đề xuất cho RS-485, nhưng đó không phải là ý kiến ​​hay so với CAN. RS-485 là một tiêu chuẩn chỉ dùng điện. Đây là một bus khác biệt, do đó cho phép nhiều nút và có khả năng chống ồn tốt. Tuy nhiên, CAN có tất cả những điều đó, cộng với nhiều hơn nữa. CAN cũng thường được thực hiện như một xe buýt vi sai. Một số ý kiến ​​cho rằng RS-485 đơn giản để giao tiếp với điện. Điều này đúng, nhưng CAN cũng vậy. Dù bằng cách nào một con chip làm điều đó. Trong trường hợp CAN, MCP2551 là một ví dụ điển hình.

Vì vậy, CAN và RS-485 có khá nhiều lợi thế giống nhau về mặt điện. Ưu điểm lớn của CAN là ở trên lớp đó. Với RS-485 không có gì ở trên lớp đó. Bạn sẽ phải tự mình. Có thể thiết kế một giao thức liên quan đến trọng tài xe buýt, xác minh gói, thời gian chờ, thử lại, v.v., nhưng để thực sự có được quyền này thì khó khăn hơn nhiều so với hầu hết mọi người nhận ra.

Giao thức CAN xác định các gói, tổng kiểm tra, xử lý va chạm, thử lại, v.v. Không chỉ đã có sẵn và nghĩ ra và thử nghiệm, nhưng lợi thế thực sự lớn là nó được triển khai trực tiếp trên silicon trên nhiều bộ vi điều khiển. Các giao diện phần sụn cho thiết bị ngoại vi CAN ở mức độ gửi và nhận gói. Để gửi, phần cứng thực hiện phát hiện colllision, backoff, retry và CRC. Để nhận, nó thực hiện phát hiện gói, điều chỉnh độ lệch của đồng hồ và xác thực tổng kiểm tra CRC. Có, thiết bị ngoại vi CAN sẽ mất nhiều phần sụn hơn so với UART, như thường được sử dụng với RS-485, nhưng tổng thể sẽ mất ít mã hơn vì silicon xử lý rất nhiều chi tiết giao thức cấp thấp.

Nói tóm lại, RS-485 là từ thời kỳ cũ và không có ý nghĩa gì đối với các hệ thống mới ngày nay. Vấn đề chính dường như là những người đã sử dụng RS-485 trong quá khứ bám vào nó và nghĩ rằng CAN là "phức tạp" bằng cách nào đó. Các mức CAN thấp rất phức tạp, nhưng bất kỳ triển khai RS-485 có thẩm quyền nào cũng vậy. Lưu ý rằng một số giao thức nổi tiếng dựa trên RS-485 đã được thay thế bằng các phiên bản mới hơn dựa trên CAN. NMEA2000 là một ví dụ về tiêu chuẩn dựa trên CAN mới hơn như vậy. Có một tiêu chuẩn ô tô khác là J-J1708 (dựa trên RS-485) hiện đã bị lỗi thời khá nhiều với OBD-II và J-1939 dựa trên CAN.

Tôi muốn giới thiệu bộ điều khiển với CAN vì tính năng này có nghĩa chính xác cho mục đích kết nối mạng của bộ điều khiển.

RS232 có thể được thực hiện dễ dàng nhưng sẽ gặp khó khăn thực sự nếu bạn cố gắng thực hiện giao tiếp nhiều hơn 2 nút (vì nó không được xây dựng cho mục đích này).

Ethernet cũng có thể là một lựa chọn ngọt ngào vì bạn đã đề cập đến một số kết nối máy chủ và máy khách, điều này là tự nhiên đối với việc triển khai Ethernet.

RS-485 sử dụng nhiều dây có thể hoạt động tốt ở đây, nếu có khả năng nối cùng một dây với tất cả các thiết bị.

Ví dụ, nếu nó được sử dụng với cáp mạng loại 5e truyền thống, bạn có thể có hai cặp để truyền dữ liệu theo cả hai hướng (sử dụng mô-đun song công hoàn toàn), có một cặp hoặc thậm chí là một dây làm mặt bằng chung và phần còn lại để đàm phán thiết bị nào sẽ truyền trong thời điểm nào. RS-232 phức tạp hơn một chút, nhưng các mô-đun rẻ hơn CAN và Ethernet và giới hạn cáp là 1200 m. Nhược điểm là bạn sẽ phải tạo giao thức giải quyết xung đột của riêng mình. Có thể có thiết bị muốn truyền kiểm tra một dây chuyên dụng và xem nó có cao không. Nếu không, hãy đưa nó lên cao và bắt đầu liên lạc và nếu có, hãy đợi trong một khoảng thời gian ngẫu nhiên. Tôi vẫn không chắc điều này sẽ hoạt động tốt như thế nào trên quãng đường dài.

Tôi sẽ chọn xe buýt RS-485 hoạt động với dữ liệu Mã hóa Manchester .

RS-485 vì:

• Rẻ
• Dễ thực hiện
• Là sử dụng lo điện
• Cho phép khoảng cách xa (lên đến 1200 mét)
• Tốc độ dữ liệu cao (tối đa 10 Mb / giây)
• Khả năng miễn dịch cao
• Có những bộ thu phát cho phép tối đa 256 thiết bị trên cùng một xe buýt
• Số phần thấp

Mã hóa Manchester vì:

• Dễ thực hiện
• Tự đồng bộ

Đối với tính toàn vẹn dữ liệu, thông báo có thể bao gồm độ dài và trường CRC.

Ví dụ về hàm 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_INITvà CRC_POLYlà các giá trị tùy ý được sử dụng để tính CRC.

Ví dụ về một thông báo có các trường độ dài và CRC:

Hãy để tôi so sánh lựa chọn ưa thích của bạn, Ethernet, với lựa chọn ưa thích của tôi, CÓ THỂ.

Các thành phần cần thiết:

• Ethernet: Đầu nối RJ45, từ tính, chip Phy (trừ khi được tích hợp vào MCU). Cũng cần các công tắc và cáp từ công tắc đến từng nút. Mỗi PCB cần khá nhiều tụ điện và điện trở kết thúc, có thể cả ferrites nữa. Cần thiết kế PCB tốt.
• CAN: Chip thu phát (giá rẻ), bất kỳ đầu nối, cáp giá rẻ nào cũng có thể nhảy từ nút này sang nút tiếp theo trong một vòng quanh trang web. Chỉ cần một tụ điện cho bộ thu phát và một điện trở kết thúc ở mỗi đầu của xe buýt.

Bạn đang nói về vi điều khiển $ 1. Chi phí xe buýt nhiều hơn MCU. Bạn sẽ phải cộng tổng chi phí của từng giải pháp để biết cái nào thực sự rẻ hơn. Thêm chi phí của MCU, đầu nối, bộ thu phát, linh kiện thụ động, PCB, cáp, v.v.

LPC11C24 từ NXP cũng đã tích hợp bộ thu phát CAN và CANOpen được hỗ trợ trong ROM (không ăn mất dữ liệu Flash 32 K của bạn). Bảng LPCXpresso 11c24 là 20 EUR (đã cung cấp không gian cho đầu nối DB9), vì vậy bạn thực sự chỉ cần thêm dây :-)

Đăng lại từ một câu hỏi tương tự khác. Chi phí thấp giao tiếp đơn giản giữa hai vi điều khiển

TLDR : Không đặc biệt rẻ nhưng phù hợp đáng tin cậy trong một số trường hợp sử dụng.

Nhìn bên ngoài hộp, có thể có một số giải pháp khác ở đây, chẳng hạn như con chip mà tôi đã va vào gần đây. Tất nhiên, tất cả phụ thuộc vào những gì bạn muốn làm. Một cái gì đó giống như UART xuất hiện trong tâm trí nếu bạn có cả hai MCU trên cùng một bảng hoặc thậm chí có kế hoạch bảo vệ chúng bằng tay nếu được tách ra.

Giải pháp tổng thể và thiết bị cho các ứng dụng IO-Link

L6360   Master
L6362A  Device

Khi nào bạn sẽ xem xét một giải pháp như thế này:

1. Các chip biên giới được bảo vệ hoàn toàn, điều này rất quan trọng nếu bạn có mỗi MCU trên một bảng riêng biệt và xử lý các chân tiếp xúc, ví dụ như đầu nối vít.
   • Đảo cực
   • Quá tải với chức năng cắt
   • Nhiệt độ quá cao
   • Thiếu điện áp và quá điện áp
   • Dây mở GND và VCC
2. Khả năng tương tác. Nếu ai đó sẽ thiết kế phía bên kia, tất cả những gì anh ta cần biết là chuyển dữ liệu qua IO-Link.
3. Điều chỉnh tích hợp Vcc(in) 7~30v, Vdd(out) 3.3/5v

Nghe có vẻ thú vị đối với tôi, vì vậy tôi nghĩ tôi sẽ đưa nó ra khỏi đó.

Nó phụ thuộc vào quy mô của ứng dụng của bạn và vi điều khiển của bạn. Bạn đã đề cập đến Atmel tiny / mega, chúng khá nhỏ. Trong trường hợp của họ, I2C / SPI / UART có lợi thế là chúng được triển khai trong phần cứng và do đó rất dễ sử dụng.