Tại sao không có thông tin liên lạc trên tàu như I2C, SPI, v.v. nói chung có kiểm tra lỗi?


7

Một số phương pháp kiểm tra lỗi như kiểm tra chẵn lẻ, tổng kiểm tra, CRC, v.v ... được sử dụng cho liên lạc có dây / không dây. Tuy nhiên, hầu hết các IC có giao diện như I2C, SPI, v.v. không sử dụng phương pháp kiểm tra lỗi.

Hãy tìm kiếm "i2c i / o expander" và mở một biểu dữ liệu ngẫu nhiên. Ví dụ: hãy xem xét PCF8574 từ TI là bộ mở rộng I / O 8 bit. Nếu một bit tương ứng với thanh ghi đầu ra bị lật trong quá trình truyền I2C, IC sẽ điều khiển chân tương ứng đến mức không mong muốn. Tại sao hầu hết các loại IC này không có bất kỳ cơ chế kiểm tra lỗi nào cả? Giả định của tôi là ngay cả khi giao tiếp giữa các IC, tất cả các tín hiệu đều bị nhiễu. Mặc dù xác suất sẽ khá thấp, tiếng ồn có thể gây ra một chút lật.

Đây có thể là lý do?: Không có cơ chế kiểm tra lỗi nào đảm bảo truyền thông hoàn toàn không có lỗi. Họ chỉ có thể giúp chúng tôi giảm xác suất xảy ra lỗi. Rõ ràng là xác suất lỗi bit cho giao tiếp tầm xa cao hơn so với giao tiếp trên bảng. Có thể xác suất lỗi bit cho giao tiếp trên bo mạch nằm trong phạm vi chấp nhận được ngay cả khi không có bất kỳ cơ chế kiểm tra lỗi nào.

Bạn nghĩ sao?


3
Vì lý do tương tự, một con đường không cung cấp đệm trong trường hợp bạn gặp sự cố. Con đường chỉ cung cấp đại lộ để vận chuyển xe của bạn. Bạn có thể đặt bất kỳ thiết bị an toàn trong xe bạn muốn. Các cổng nối tiếp cung cấp một đại lộ để vận chuyển các bit dữ liệu. Tùy thuộc vào nhà thiết kế để cung cấp nhiều lỗi và kiểm tra lỗi như mong muốn.
Dan Laks

tốc độ bạn chạy đồng hồ trên xe buýt và mức điện áp được sử dụng (i2c là bộ thu mở, bạn có thể sử dụng dải điện áp rộng) giúp giảm đáng kể lỗi có thể xảy ra
KyranF

If a bit corresponding to output register is flipped during I2C transmission, the IC will drive the corresponding pin to an undesired level.ồ, cái gì
Người qua đường

@Passerby có nghĩa là, nếu bạn gửi lệnh đến bộ mở rộng I2C IO, để thay đổi trạng thái đầu ra, nếu vì một lý do nào đó, có một điều kiện trong đó một trong các bit đại diện cho chân đầu ra xảy ra có nhiễu trong chu kỳ xung nhịp , đầu ra dự định sẽ khác với những gì IC thực sự đưa ra, nhờ byte lệnh trên I2C có nhiễu
KyranF

1
@DanLaks Tôi thấy quan điểm của bạn. Tôi có thể thêm kiểm tra lỗi nếu tôi đang thiết kế các đơn vị giao tiếp qua cổng nối tiếp. Trong trường hợp I2C, các lệnh và giao thức được cố định bởi nhà cung cấp IC và chúng không bao gồm bất kỳ kiểm tra lỗi nào nói chung.
Alper

Câu trả lời:


11

Bạn phải giả định một số thứ chỉ hoạt động, ngay cả trong một thế giới có kiểm tra lỗi. Tại sao chọn IIC hoặc SPI khi thường có nhiều tín hiệu số hơn trên bảng? Bạn có vẻ ổn với giả định rằng tất cả những điều đó sẽ được hiểu như dự định.

Một mạch được thiết kế đúng trên một bảng được thiết kế đúng nên đáng tin cậy. Hãy nghĩ về một đầu ra CMOS điều khiển đầu vào CMOS trên một bảng. Khác với lỗi thành phần hoàn toàn (là một vấn đề hoàn toàn khác với tham nhũng dữ liệu không thường xuyên), hãy nghĩ về những gì thực sự có thể đi sai. Ở cuối lái xe, bạn đã có một FET với một số đảm bảo tối đa về lực cản kết nối một đường với Vdd hoặc mặt đất. Chính xác những gì bạn tưởng tượng có thể gây ra rằng không có cấp độ phù hợp ở cuối nhận?

Ban đầu, trạng thái có thể không được xác định vì bất kỳ điện dung nào trên đường dây được sạc hoặc xả. Sau đó có thể có tiếng chuông trong dấu vết ngắn. Tuy nhiên, chúng ta có thể tính toán thời gian trường hợp xấu nhất tối đa cho tất cả điều này để giải quyết và dòng đáng tin cậy vượt qua một số ngưỡng ở đầu kia.

Một khi thời gian này đã đạt được và chúng tôi đã chờ đợi cho dù độ trễ lan truyền trường hợp xấu nhất của logic là gì, có rất ít thay đổi tín hiệu. Bạn có thể nghĩ tiếng ồn từ các bộ phận khác của bảng có thể phát ra tín hiệu. Vâng, điều đó có thể xảy ra, nhưng chúng ta cũng có thể thiết kế cho điều đó. Lượng tiếng ồn trong một phần khác của bảng thường được biết đến. Nếu không, thì nó đến từ nơi khác và trong thiết kế phù hợp, nó sẽ được giới hạn ở một số dV / dt tối đa và các đặc điểm khác. Những điều này tất cả có thể được thiết kế cho.

Về mặt lý thuyết, tiếng ồn bên ngoài có thể làm đảo lộn các dấu vết trên một bảng, nhưng cường độ trường sẽ cần phải lớn một cách vô lý đối với một bảng được thiết kế đúng. Môi trường tiếng ồn cao tồn tại, nhưng bị giới hạn ở các địa điểm được biết đến. Một bảng có thể không hoạt động 10 mét từ máy phát 10 kW, nhưng thậm chí có thể được thiết kế cho.

Vì vậy, câu trả lời về cơ bản là các tín hiệu số trên cùng một bảng, nếu được thiết kế hợp lý, có thể được coi là hoàn toàn đáng tin cậy cho hầu hết các mục đích sử dụng thông thường. Trong trường hợp đặc biệt khi chi phí thất bại rất cao, như không gian và một số ứng dụng quân sự, các chiến lược khác được sử dụng. Chúng thường bao gồm các hệ thống con dự phòng. Bạn vẫn xem xét các tín hiệu riêng lẻ trên một bảng đáng tin cậy, nhưng giả sử các bảng hoặc hệ thống con nói chung đôi khi có thể sai. Cũng lưu ý rằng các hệ thống này có giá cao hơn nhiều và gánh nặng chi phí như vậy sẽ khiến hầu hết các hệ thống thông thường, như máy tính cá nhân chẳng hạn, trở nên vô dụng vì quá đắt.

Tất cả đã nói, có những trường hợp ngay cả trong phát hiện và sửa lỗi điện tử tiêu dùng thông thường được sử dụng. Điều này thường là do bản thân quá trình có xác suất lỗi nhất định và vì các giới hạn đang được đẩy. Bộ nhớ chính tốc độ cao cho máy tính thường bao gồm các bit phụ để phát hiện lỗi và / hoặc sửa lỗi. Nó rẻ hơn để có được hiệu suất và tỷ lệ lỗi cuối cùng bằng cách đẩy các giới hạn và thêm tài nguyên vào sửa lỗi hơn là làm chậm mọi thứ và sử dụng nhiều silicon hơn để làm cho mọi thứ vốn đã đáng tin cậy hơn.


Cảm ơn bạn đã trả lời dài. Tôi đã không xem xét một trường hợp đặc biệt không nhận được bit chính xác thực sự. Suy nghĩ của tôi đơn giản hơn nhiều. Tôi đã sử dụng bộ điều khiển I / O I2C trong các ứng dụng của mình để điều khiển thứ gì đó và tôi không muốn mở rơle do lật một bit, giả sử. Tiếng ồn phụ gia có ở khắp mọi nơi (điện trở, bóng bán dẫn, v.v.), tại sao không gây ra một chút lộn xộn trong quá trình giao tiếp.?
Alper

6

Đặc biệt đối với các giao thức không được thiết kế để sử dụng qua cáp, bảng được thiết kế đúng sẽ không có lỗi và bảng được thiết kế kém sẽ không hoạt động tốt khi có hoặc không có kiểm tra lỗi. Ví dụ: trục trặc trên xe buýt I2C có nhiều nô lệ có thể khóa vĩnh viễn xe buýt (*) trừ khi chủ có trình điều khiển có thể kéo SDA lên cao ngay cả khi nô lệ đang cố gắng kéo thấp. Bảo vệ chống lại điều đó sẽ làm cho giao thức chậm hơn, nhưng nếu xe buýt không đủ trục trặc thì hành vi có thể đó không được coi là rủi ro, nói chung sẽ không cần logic kiểm tra lỗi.

(*) Nếu một nô lệ nghĩ rằng nó thấy một điều kiện bắt đầu ở giữa một byte dữ liệu được đọc từ một thiết bị khác và diễn giải dữ liệu được đọc là bắt đầu một lệnh nên đọc một chuỗi số 0, thì có thể cho mỗi thiết bị nô lệ xác nhận các byte dữ liệu được gửi cho nhau theo cách mà tại bất kỳ thời điểm nào, ít nhất một trong số các nô lệ sẽ giữ xe buýt.


Xem thêm: SMBus.
Photon

1
Nhận xét: nói chung, một bậc thầy không thể kéo SDA lên cao kể từ khi trình thu thập mở được điều khiển của nó. Ngay cả khi một bậc thầy tạm thời chuyển sang đầu ra đẩy và lái lên cao, bạn sẽ có một cuộc chiến xe buýt với một nô lệ lái xe thấp, kết thúc với một trạng thái không xác định và thiệt hại chip có thể. Cách chính xác để cố gắng xóa xe buýt là chuyển SCL cho đến khi nô lệ giải phóng SDA, sau đó gửi (tôi tin) khoảng 8 đồng hồ.
DoxyLover

1
@DoxyLover: Nếu có hai hoặc nhiều nô lệ và họ đã không đồng bộ, một người có thể gặp tình huống một nô lệ kéo SDA xuống thấp trong tám trên chín chu kỳ và một người khác kéo SDA xuống thấp trong tám trên chín chu kỳ khác nhau . Không có số lượng xung SCK sẽ khắc phục tình hình. Nếu chủ được kết nối độc lập với từng nô lệ thông qua điện trở 100ohm và có thể kéo SDA lên cao trong khi đạp SCK trong chín xung có thể sẽ khắc phục được sự cố. Không phải là một giải pháp tốt, nhưng quan điểm chính của tôi là người ta cần tránh để I2C gặp phải tình huống đó ngay từ đầu.
supercat

3

Tại sao bạn hỏi rằng chỉ liên quan đến kiểm tra lỗi?

Làm thế nào bạn có thể chắc chắn rằng điều kiện bắt đầu được giải thích chính xác? Trên truyền thông hữu tuyến hoặc không dây, bắt đầu khung là sự kết hợp các bit rất phức tạp, trong khi trên RS-232, nó là một thay đổi từ cao đến thấp đơn giản và trên I2C là một vi phạm giao thức đơn giản.

Quan điểm của tôi là không chỉ kiểm tra lỗi là khác nhau, mà tất cả các yếu tố của giao thức đều đơn giản hơn nhiều đối với các giao thức trên bảng so với các đối tác của chúng đối với truyền thông hữu tuyến và không dây. Và lý do là xác suất xảy ra lỗi thấp hơn một số đơn hàng so với liên lạc có dây / không dây.


Bit ACK xác minh việc nhận lệnh, phải không? (Điều gì sẽ xảy ra nếu ACK bị lật? Đi mãi mãi ...) Truyền lại là một điểm giao tiếp khác và được nhiều ứng dụng chấp nhận. Điều khiển ghim đến mức sai do lật bit và kiểm tra lỗi không đủ nghiêm trọng hơn nhiều sau đó truyền lại.
Alper

2

Câu trả lời ngắn gọn là nhiều thiết bị mà I2C và SPI nhắm đến là các thiết bị có công suất thấp với bộ hướng dẫn nhỏ và bộ nhớ chương trình hạn chế. Các thông số kỹ thuật cho phép họ thực hiện trong phần sụn với ít chi phí. Nếu bạn có mã lực, bạn có thể thêm bao nhiêu lớp tùy ý, nhưng các lớp này sẽ loại bỏ nhiều ứng dụng nhúng nhỏ.


Tuy nhiên, tôi không thể thay đổi hành vi của thiết bị mở rộng I / O I2C được đề cập ngay cả khi tôi kết nối với bộ xử lý lõi tứ (mã lực). Tôi không thể thêm một cơ chế sửa lỗi bổ sung trên đó.
Alper

0

Tôi không thể cung cấp một câu trả lời hợp pháp nhưng một số so sánh. Các giao thức mạng cần các lớp cơ chế, thực hiện tất cả các mục đích cùng một lúc không phải là ý tưởng hay, bạn không có gói crc trong PHY cho đến khi lớp MAC phát hiện ra lỗi RF trong 802.11.

SPI và i2c đều có xung nhịp đồng bộ nên tỷ lệ lỗi và xung đột truyền thông trong thời gian sẽ là tối thiểu và phần cứng để thực hiện chúng được coi là khan hiếm.

đó là tất cả những gì tôi có thể nghĩ ra.


0

Tìm một giải pháp cụ thể cho một vấn đề cụ thể.

Nếu bạn có 3 rơle yêu cầu độ tin cậy tuyệt đối: Sau đó đo đầu ra của chúng bằng 3 đầu vào kỹ thuật số, một hệ thống xác nhận dự phòng, được điều chỉnh cho ứng dụng của bạn.

Nếu bạn đã tắt và thiết kế một giao thức giao tiếp tùy chỉnh, để giải quyết tất cả các vấn đề về độ tin cậy một lần và mãi mãi, bạn sẽ mắc một lỗi thiết kế chung; Đi lạc từ các yêu cầu cụ thể để trở thành sidetracked nói chung.


0

Trước hết, điều quan trọng cần nhớ là I2C là viết tắt của truyền thông Mạch tích hợp đến Mạch tích hợp. Nó được thiết kế để chạy từ chip này sang chip khác trên bo mạch PC. Tuy nhiên, với các hệ thống như Raspberry Pi điều khiển kết nối I2C qua cáp, tiêu chuẩn này không được sử dụng cho mục đích của nó và việc suy giảm tín hiệu dẫn đến việc truyền dẫn sẽ dễ bị lỗi hơn nhiều. Tôi đang đọc chủ đề này bởi vì tôi đang tìm kiếm manh mối về cách giảm lỗi I2C trong thiết lập Raspberry Pi của tôi.

Điều đó nói rằng, mọi thiết bị tương thích I2C trên xe buýt của tôi đều xác nhận và tạo CRC để kiểm tra lỗi xe buýt. Điều không kiểm tra lỗi là trình điều khiển thiết bị I2C đến trong Linux, nhưng bạn có thể dễ dàng tìm thấy các thư viện trực tuyến cho C hoặc Python để kiểm tra CRC quay trở lại. Những gì tôi có thể nói với bạn là việc kiểm tra chúng là mở mắt vì một phần đáng báo động của dữ liệu quay trở lại là xấu. Bây giờ, tôi chỉ loại bỏ nó và thử đọc lại dữ liệu nhưng giải pháp dài hạn hơn là thiết kế lại hệ thống I2C của tôi để có ít khoảng cách / điện dung trong đó. Tôi đang xem xét một công tắc I2C để cách ly các thiết bị trên tín hiệu riêng của chúng. Hoặc chuyển sang Modebus hoặc CANbus mạnh hơn về điện (và đắt hơn một chút để sử dụng vì các thiết bị đắt hơn.)

Do các điểm yếu trong tiêu chuẩn được kích thích khi chạy tín hiệu dài, có một số lỗi như SDA bị giữ bởi một thiết bị nô lệ không thể phục hồi bằng trình điều khiển I2C linux điển hình và có thể yêu cầu chu kỳ nguồn. Để sửa lỗi khóa xe buýt trên Pi của bạn, bạn có thể thay đổi các chân I2C thành các chân I / O chung và sau đó đặt lại bus trong phần mềm với 9 đồng hồ cần thiết ở 400 KHz trước khi thay đổi chúng trở lại chức năng I2C, nhưng có rất nhiều vấn đề điều này bao gồm yêu cầu mã C để chuyển đổi pin CLK đủ nhanh để thiết lập lại. Mặc dù tôi đã thấy điều này được thảo luận trực tuyến, tôi vẫn chưa tìm thấy bất kỳ mã nào cho nó và tôi đang xem xét việc tự viết nó. Hoặc bảo lãnh trên I2C.

Nhân tiện, tôi nghĩ rằng sử dụng I2C gần với mục đích của nó, chẳng hạn như kết nối thẻ con gái với Pi, là khá an toàn. Tôi không gặp rắc rối với những thiết kế như vậy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.