Các giao thức dựa trên RS232 tốt để nhúng vào giao tiếp máy tính

Tôi đang làm việc trong một dự án liên quan đến một chút giao tiếp dữ liệu giữa Arduino từ xa và máy tính. Kết nối không dây thông qua một cặp XBees, vì vậy chúng tôi có một liên kết RS232 giữa Arduino và máy tính. Đối với một lượng nhỏ dữ liệu, thật dễ dàng để kết hợp một số giao thức giao tiếp đơn giản. Tuy nhiên, đối với các dự án lớn hơn, một số giao thức truyền thông đơn giản tốt là gì?

Tôi đã xem MODBUS, có vẻ như là một lựa chọn khả thi, nhưng tôi muốn xem liệu có lựa chọn nào khác tốt hơn không.

OP yêu cầu một giao thức nối tiếp cho một tình huống trong đó " không nhiều [dữ liệu] và tốc độ không phải là vấn đề lớn ". MODBUS được đề cập trong OP MODBUS trên RS-485 không phải là giao thức nhanh. Mặc dù đây không phải là thông số kỹ thuật, nhưng điều này đưa ra ý tưởng về thị trường ngách.

Tôi chỉ có thể nghĩ về hai giao thức tiêu chuẩn phổ biến cho phân khúc này:

• Nema 0183 . Giao thức ASCII văn bản thuần túy. Con người có thể đọc được. Chỉ điểm tới điểm. Không hỗ trợ xe buýt nhiều điểm.
• MODBUS đã được đề cập trong OP

Rất thường xuyên, khi các lập trình viên nhúng trong tình huống như OP, họ thiết kế các giao thức truyền thông nối tiếp của riêng họ từ đầu.

Một số giao thức hệ thống nhúng, một số giao thức cực kỳ đơn giản, được liệt kê tại Hệ thống nhúng: Giao thức chung , bao gồm:

• Mạng nhúng nhỏ (TEN)
• Trình thông dịch vi điều khiển cho các hệ thống nhúng được nối mạng (MINES)
• Một giao thức có thể mở rộng khác (YASP)
• Mạng kết nối cục bộ (LIN)
• Bộ điều khiển Servo nối tiếp (SSC)
• Hệ điều hành Robot nối tiếp (rosserial)
• dây
• các lĩnh vực khác nhau
• Modbus
• Mạng khu vực điều khiển (CAN)
• Firmata (Cảm ơn bạn, jippie!)

Có lẽ một trong những giao thức này sẽ phù hợp với ứng dụng của bạn, hoặc chỉ với một số điều chỉnh nhỏ.

Tôi sẽ bỏ phiếu của riêng bạn và giữ nó đơn giản nhất có thể.

Tôi đã xử lý rất nhiều giao thức nối tiếp cho các ứng dụng điều khiển khác nhau và một số điều tôi có thể khuyên bạn nên bao gồm:

• Bắt đầu và dừng các ký tự không được sử dụng ở nơi khác
• Một số loại kiểm tra / kiểm tra lỗi
• Một số phương pháp điều khiển / báo hiệu dòng chảy, đặc biệt nếu bạn cần comms hai chiều.

Như một ví dụ rất cơ bản, bạn có thể chuyển đổi dữ liệu của mình thành các ký tự ASCII và dán nó vào các ký tự start / stop như thế này:

Để gửi giá trị byte 0x7A, dữ liệu được gửi sẽ là (7A), trong đó () là các ký tự bắt đầu / dừng được chọn và 7 và A là hai ký tự ascii. OK nó bổ sung rất nhiều chi phí, nhưng điều đó có nghĩa là bạn có thể gỡ lỗi với phần mềm đầu cuối cơ bản.

Nếu dữ liệu của bạn đi qua XBees, bạn nên đặt các mô-đun vào chế độ API với các ký tự thoát, chia dữ liệu của bạn thành các gói logic và tận dụng thực tế là trong chế độ API, gói được cung cấp cho XBee sẽ còn nguyên vẹn hoặc không có gì. Thiết kế giao thức của bạn xung quanh việc truyền các khối 1-255 byte và để các mô-đun XBee lo lắng về cách phân phối dữ liệu trong mỗi khối. Đừng lo lắng về việc duy trì tính toàn vẹn của các gói riêng lẻ hoặc các phân chia giữa chúng. Các mô-đun Digi sẽ làm tốt công việc chăm sóc điều đó. Điều lớn nhất bạn cần lo lắng là thực tế là ngay cả khi nút truyền gói tin tin rằng nó không được gửi và gửi thay thế, người nhận cuối cùng có thể nhận được nó - thậm chí có thể sau khi nó được thay thế. Mọi thứ có thể dễ dàng nhất nếu bạn thiết kế giao thức của mình sao cho một bên là "chính"; nếu chủ yêu cầu một phần dữ liệu, nô lệ nên gửi nó một lần và không lo lắng về việc chủ có nhận được dữ liệu đó không. Nếu chủ không nhận được dữ liệu mà nó muốn, nó có thể yêu cầu lại.

Slave nên gán một số loại số thứ tự cho dữ liệu và chủ nên gán số thứ tự cho các yêu cầu trạng thái thay đổi nô lệ. Nếu yêu cầu của chủ có dạng "gửi mục đầu tiên có số thứ tự lớn hơn XXX" và mỗi phần của mục dữ liệu của nô lệ bao gồm số thứ tự của chính nó và của mục trước đó (nếu chúng không được đánh số liên tiếp ), các gói đến muộn có thể khiến nô lệ gửi dữ liệu cho chủ, nhưng chủ sẽ không gặp khó khăn gì trong việc bỏ qua các phản hồi đến muộn. Nếu nô lệ nhận được yêu cầu thay đổi trạng thái có số thứ tự thấp hơn yêu cầu trước đó, thì nên bỏ qua yêu cầu đó, vì nó đã được áp dụng ngay cả trước khi nhận được.

Thế còn Firmata ? Nó có hỗ trợ cho các hệ điều hành và ngôn ngữ lập trình khác nhau. Bộ điều khiển Arduino và PICduino được hỗ trợ, nhưng điều đó không quá khó để chuyển sang một vi điều khiển trần.

Tôi đã có một câu hỏi tương tự như vậy và không bao giờ tìm thấy bất cứ điều gì đơn giản và đủ nhỏ cho các AVR nhỏ, v.v. Vì vậy, tôi đã cuộn một cái gì đó lấy cảm hứng từ CAN. Nó được gọi là MIN (Mạng liên kết vi điều khiển):

https://github.com/min-protatio/min

Tôi đã viết về nó ở đây:

https://bestindell.wordpress.com/2015/02/18/micrcontroll-interconnect-network-min-version-1-0/

Có các móc ở đó cho dữ liệu khối, nhưng nó chủ yếu nhắm vào các tín hiệu cho cảm biến / cơ cấu chấp hành. Tôi đã xác định một định dạng JSON để mô tả các tín hiệu và cách đóng gói của chúng trong các khung MIN và hy vọng sẽ có được một bộ phân tích Wireshark sử dụng nó.