Cách tìm dòng UART miễn phí để gửi dữ liệu

Tôi có một số bảng giao tiếp với nhau với Rs485. Họ có ATMegaloạt vi điều khiển như atmega168phoặc atmega8. Mỗi bảng có thể tự do gửi dữ liệu bất cứ lúc nào và tôi có giới hạn dẫn đến việc tôi không thể sử dụng Modbus . Số lượng bảng có thể dao động từ 5 đến 10.

Vấn đề của tôi là: Làm thế nào một bảng có thể tìm thấy nếu dòng UART miễn phí gửi dữ liệu và nếu phát hiện ra rằng xe buýt đang bận, hãy đợi cho đến khi xe buýt miễn phí và sau đó gửi dữ liệu riêng?

Có cờ đặc biệt hoặc đăng ký nào có thể tự động hoặc thay đổi thủ công và để cho bảng khác thấy rằng Line đang bận không?

Chào mừng bạn đến với thách thức lớn nhất với các hệ thống truyền thông bán song công.

RS-485 không phải là một giao thức, nó là một tiêu chuẩn xác định các thuộc tính điện cho liên kết vi sai bán song công (*). Không có gì trong đặc tả về cách dữ liệu được gửi qua liên kết đó, hoặc trên thực tế cách liên kết được sử dụng.

Vì các bộ thu phát RS-485 như vậy không có tín hiệu / cờ "bận" / bất cứ thứ gì, cũng như các bộ vi điều khiển được tích hợp trong trình điều khiển RS-485, cũng không sử dụng lõi UART được kết nối với bộ thu phát ngoài.

Tất cả việc thực hiện kiểm soát luồng và điều khiển hướng được dành cho bất kỳ giao thức nào bạn sử dụng. Có tồn tại một số giao thức nổi tiếng sử dụng trình điều khiển RS-485, chẳng hạn như Modbus. Bạn cũng có thể thực hiện bất kỳ giao thức nào bạn có thể nghĩ đến.

Để giúp bạn thực hiện, đây là một vài ý tưởng cho các giao thức:

1. Bạn có một giao thức loại chủ-nô lệ. Trong đó có một nút chính điều phối bus và các nút tớ mà mỗi nút có một số định danh duy nhất.

   Các nút tớ không được phép gửi bất kỳ dữ liệu nào cho đến khi nút chủ đặc biệt gửi các lệnh được gửi đến chúng. Khi một nô lệ được xử lý, nó có thể trả lời bất kỳ lệnh nào theo một cách được xác định trước - nói một gói phản hồi có độ dài cố định.

   Trong trường hợp này, bạn tránh các vấn đề của nhiều thiết bị muốn nói chuyện cùng một lúc vì chủ có mặt để điều phối mọi thứ.

2. Bạn có thể sử dụng một số hình thức lập lịch, theo đó mỗi thiết bị trên xe buýt có một vị trí cố định để gửi dữ liệu tới bất kỳ thiết bị nào khác. Khi khe cắm của nó hết, nó phải dừng gửi và cho phép thiết bị tiếp theo nói chuyện.

   Việc lập lịch trình có thể được thực hiện bởi chính các thiết bị mà không cần sự phối hợp bên ngoài. Thiết bị đầu tiên nói chuyện, và sau đó gửi một thông báo nói rằng nó đã được thực hiện. Thiết bị tiếp theo (ví dụ: thiết bị có ID cao hơn tiếp theo) sẽ biết rằng nó có thể hoạt động. Trong trường hợp một thiết bị không phản hồi, bạn có thể có một khoảng thời gian chờ, theo đó mỗi thiết bị tiếp theo trong lịch trình sẽ có thể nói - tôi đã không nghe thấy từ thiết bị trước tôi một lúc, vì vậy phải đến lượt tôi.

(*) Tôi tin rằng nó cũng xác định phiên bản song công hoàn toàn bằng hai liên kết vi sai.

Nó rất giống với liên lạc vô tuyến của quân đội hoặc cảnh sát. Một giao thức được yêu cầu. Master nô lệ là dễ dàng và tốt cho hầu hết các trường hợp. Nhưng một lựa chọn khác là làm điều đó giống như con người:

1. Nghe.
2. Nếu ai đó lên tiếng- hãy đợi.
3. Nếu bạn nghĩ rằng không ai nói - bạn có thể nói.
4. Chờ xác nhận.
5. Nếu không có xác nhận nhận được - hãy nói lại.
6. Nếu bạn muốn phát sóng, hãy yêu cầu tất cả các đài xác nhận nghe.
7. Nếu bạn muốn nói chuyện với ai đó không thể nghe thấy bạn, hãy hỏi xem có ai khác có thể chuyển tiếp không.

Và như thế. Có thể rất thú vị để thực hiện. Chúc may mắn!

Dưới đây là một vài khả năng để giải quyết vấn đề nan giải của bạn.

1. Triển khai hệ thống chuyển mã thông báo. Khi một thiết bị có mã thông báo, nó được phép truyền trong một khoảng thời gian giới hạn. Sau đó, nó chuyển mã thông báo đến thiết bị tiếp theo. Quy định cho các nút bị thiếu không thể nhận và chuyển mã thông báo phải được thực hiện.
2. Nhìn vào dòng nhận. Nếu bận, tạo độ trễ ngẫu nhiên và thử lại. Độ trễ ngẫu nhiên giúp đảm bảo rằng không một nút nào có thể độc quyền các cửa sổ truyền. Va chạm vẫn có thể xảy ra nhưng tính năng tổng kiểm tra có thể xác định xem gói tin nhận được có còn nguyên vẹn không. Nếu nó không còn nguyên vẹn, người nhận có thể yêu cầu truyền lại.

Làm thế nào một bảng có thể tìm thấy nếu dòng UART là miễn phí để gửi dữ liệu,

Câu trả lời chung là nếu không có một loại giao thức nào đó, nó không thể thực hiện một cách đáng tin cậy như vậy. bạn thường dựa vào bộ điều khiển hoặc trọng tài để xem liệu một dòng có bận hay không. Một điều đơn giản sẽ là chân OD kéo một đường chỉ báo xuống trước khi truyền và giải phóng nó sau đó. Bằng cách đọc dòng đó, một máy phát có thể xác định xem xe buýt có sẵn hay không.

một hệ thống ít tin cậy hơn nhưng đơn giản hơn là tích hợp điện áp bus (ví dụ thông qua mạng ar / c).

và nếu nó phát hiện ra rằng xe buýt đang bận, hãy đợi cho đến khi xe buýt miễn phí và sau đó gửi dữ liệu của chính nó?

phương pháp chung là chờ một khoảng thời gian ngẫu nhiên và thử lại.

Tôi giải quyết vấn đề này bằng các thiết kế của mình như thế này:

thay vì sử dụng 2 chân cho comm, tôi sử dụng 3 chân. Trong khoảng cách ngắn, nó hoạt động. Pin thứ 3 là chỉ báo bận dòng. Pin này được kéo lên từ phía chủ. Khi ai đó (MCU hoặc bất cứ điều gì) muốn nói chuyện:

• kiểm tra trạng thái pin này (INPUT).
• nếu pin ở mức CAO thì làm cho pin ở mức thấp (OUTPUT)
• và nói chuyện.
• Khi tin nhắn được chuyển sẽ giải phóng chân (INPUT) (trở kháng cao) sau đó pin sẽ ở mức cao.
• Nếu pin thấp thì đợi một lúc rồi quay lại để kiểm tra chu kỳ pin.

Đây là một cách thực hiện câu trả lời của Gregory Kornblum.

Bạn có thể sử dụng ngăn xếp giao thức BACnet nguồn mở cho giao tiếp vi điều khiển trên RS485 nếu bạn không muốn sử dụng modbus. Về cơ bản, nó chỉ chuyển một mã thông báo xung quanh cho biết mỗi thiết bị khi nó có thể gửi, tương tự như cấu trúc liên kết vòng mã thông báo và Ethernet. Dưới đây là một vài liên kết để giúp bạn bắt đầu:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Kiểm soát dòng phần mềm

Cả phần mềm và kiểm soát dòng phần cứng đều cần phần mềm để thực hiện nhiệm vụ bắt tay. Điều này làm cho thuật ngữ kiểm soát dòng phần mềm có phần sai lệch. Điều đó có nghĩa là với điều khiển luồng phần cứng, các đường bổ sung có mặt trong cáp truyền thông báo hiệu các điều kiện bắt tay. Với điều khiển luồng phần mềm, còn được biết đến dưới tên điều khiển luồng XON-XOFF, các byte được gửi đến người gửi bằng các đường truyền thông tiêu chuẩn.

Sử dụng kiểm soát dòng phần cứng ngụ ý, rằng phải có nhiều dòng hơn giữa người gửi và người nhận, dẫn đến một cáp dày hơn và đắt tiền hơn. Do đó, kiểm soát luồng phần mềm là một giải pháp thay thế tốt nếu không cần thiết để đạt được hiệu suất tối đa trong truyền thông. Kiểm soát luồng phần mềm sử dụng kênh dữ liệu giữa hai thiết bị làm giảm băng thông. Việc giảm băng thông trong hầu hết các trường hợp tuy nhiên không đáng ngạc nhiên rằng đó là một lý do để không sử dụng nó.

Hai byte đã được xác định trước trong bộ ký tự ASCII được sử dụng với điều khiển luồng phần mềm. Các byte này được đặt tên là XOFF và XON, vì chúng có thể dừng và khởi động lại truyền. Giá trị của XOFF là 19, nó có thể được mô phỏng bằng cách nhấn Ctrl-S trên bàn phím. XON có giá trị 17 được gán tương đương với Ctrl-Q.

Sử dụng kiểm soát dòng phần mềm là dễ dàng. Nếu việc gửi các ký tự phải được hoãn lại, XOFF ký tự được gửi trên dòng, để khởi động lại giao tiếp, XON được sử dụng. Gửi ký tự XOFF chỉ dừng liên lạc theo hướng của thiết bị đã phát hành XOFF.

Phương pháp này có một vài nhược điểm. Một điều đã được thảo luận: sử dụng byte trên kênh truyền thông chiếm một số băng thông. Một lý do khác là nghiêm trọng hơn.

Bắt tay chủ yếu được sử dụng để ngăn chặn tràn bộ đệm của bộ thu, bộ đệm trong bộ nhớ được sử dụng để lưu trữ các byte nhận được gần đây. Nếu xảy ra lỗi tràn lan, điều này ảnh hưởng đến cách xử lý các ký tự mới trên kênh liên lạc. Trong trường hợp xấu nhất khi phần mềm được thiết kế tồi, các nhân vật này sẽ bị ném đi mà không kiểm tra chúng. Nếu một nhân vật như vậy là XOFF hoặc XON, luồng giao tiếp có thể bị tổn hại nghiêm trọng. Người gửi sẽ liên tục cung cấp thông tin mới nếu XOFF bị mất hoặc không bao giờ gửi thông tin mới nếu không nhận được XON.

Điều này cũng giữ cho các đường truyền thông nơi chất lượng tín hiệu là xấu. Điều gì xảy ra nếu thông báo XOFF hoặc XON không được nhận rõ ràng do nhiễu trên đường dây? Phòng ngừa đặc biệt cũng cần thiết là thông tin được gửi không chứa các ký tự XON hoặc XOFF dưới dạng byte thông tin.

Do đó, giao tiếp nối tiếp sử dụng điều khiển luồng phần mềm chỉ được chấp nhận khi tốc độ truyền thông không quá cao và xác suất xảy ra lỗi tràn bộ đệm hoặc hư hỏng dữ liệu là rất nhỏ.

CSMA tốc độ cao

Đối với tốc độ cao như ý nghĩa của nhà cung cấp dịch vụ ethernet CSMA , nhiều truy cập, phát hiện / tránh va chạm, với bộ đếm thời gian dự phòng ngẫu nhiên đã được phân tích để đánh bại xác suất ngẫu nhiên để tối ưu hóa.