By | March 11, 2022

Bài viết này là bài đầu tiên trong loạt bài mô tả các khía cạnh ‘tinh tế’ hơn của Giao thức I2C, ban đầu được phát triển bởi Philips.

Vì bạn đang đọc loạt bài này, tôi cho rằng bạn đã biết bus I2C là gì và bạn đang muốn tránh một số vấn đề khi cần sử dụng nó trong một dự án. Nếu vậy, bạn đã đến đúng nơi. Nếu không, tôi sẽ sớm thêm một số thông tin giới thiệu về I2C trên trang web của mình.

Vì vậy, chúng tôi đã rõ, loạt bài này sẽ không bao gồm phạm vi bảo hiểm của Chế độ tốc độ cao, vì điều này về cơ bản khác với thiết kế và hoạt động của việc triển khai xe buýt chia sẻ 2 dây thông thường và cũng không được sử dụng phổ biến. Có rất nhiều tài liệu tham khảo tuyệt vời có sẵn trên Web về chế độ này.

Dưới đây là danh sách nhanh những gì sẽ được đề cập trong phần còn lại của loạt bài:

  • thiếu START
  • thiếu DỪNG
  • BẮT ĐẦU Lặp lại
  • thiếu bit dữ liệu
  • thiếu ACK / NAK
  • dữ liệu sau NAK
  • lỗi quay lại
  • điện trở pullup
  • bộ lặp xe buýt
  • triển khai bằng cách sử dụng thiết bị ngoại vi TWI hoặc I2C đầy đủ phần cứng
  • triển khai sử dụng thiết bị ngoại vi USI
  • triển khai sử dụng thiết bị ngoại vi USART
  • Sự khác biệt của SMBus so với I2C

Bây giờ, đến những thứ tốt!

Đối với bài viết này, chúng tôi sẽ tập trung vào 3 loại triển khai mà bạn sẽ tìm thấy trong các thiết kế ngày nay: phần cứng đầy đủ, kết hợp phần cứng / phần mềm và phần mềm đầy đủ (hoặc ‘bit-bang’ như đôi khi nó được gọi).

Nhiều bộ vi điều khiển ngày nay, ngay cả một số thiết bị cấp thấp, bao gồm một thiết bị ngoại vi I2C hoàn toàn phần cứng. Atmel gọi chúng là TWI, Microchip gọi chúng là I2C; các nhà cung cấp khác sử dụng cách đặt tên tương tự. Khi sử dụng cách tiếp cận toàn phần cứng, thực sự rất khó tạo ra bất kỳ loại lỗi bus nào trừ khi bạn hiểu sai cách hoạt động của thiết bị ngoại vi hoặc trình tự bus I2C chính xác sẽ như thế nào. Mặc dù vậy, nói chung, cách tiếp cận này đòi hỏi ít hiểu biết sâu sắc nhất về bản thân giao thức.

Thiết bị ngoại vi USI được tìm thấy trong một số thiết bị Atmel là một thiết kế phần cứng tối thiểu phụ thuộc vào tương tác phần mềm để làm cho nó trở thành một triển khai hoàn chỉnh. Thiết bị ngoại vi đa năng này thực sự có thể được sử dụng cho các cấu hình I2C, SPI và UART, và thích hợp cho các thiết bị cấp thấp, nơi việc thêm cả ba thiết bị ngoại vi sẽ rất tốn kém. Mặc dù nó yêu cầu nhiều mã hóa hơn một thiết bị ngoại vi TWI hoặc I2C toàn phần cứng, nhưng theo một số cách thì nó linh hoạt hơn. Cách tiếp cận này đòi hỏi sự hiểu biết sâu sắc hơn về giao thức, vì bạn chịu trách nhiệm chuyển từ trạng thái này sang trạng thái tiếp theo và có thể đi sai hướng.

Cuối cùng, việc triển khai phương pháp tiếp cận phần mềm 100% đòi hỏi sự hiểu biết đầy đủ về giao thức I2C. Hầu như mọi nhà cung cấp vi điều khiển đều cung cấp các ghi chú ứng dụng và ví dụ mã để tạo thiết bị I2C Master bằng giải pháp phần mềm thuần túy. Không giống như UART, I2C là một giao thức có xung nhịp (chứ không phải theo thời gian), do đó, các gián đoạn trong quá trình thực thi giao thức được dung nạp tốt, cho phép các ngắt được phục vụ mà không lo mất dữ liệu. Tốc độ tối đa của giải pháp dựa trên phần mềm cuối cùng được xác định bởi tốc độ xung nhịp của CPU và thông thường việc triển khai Master có thể dễ dàng đạt đến tốc độ 400KHz.

Việc triển khai dựa trên phần mềm của một thiết bị Slave là một thách thức lớn hơn nhiều. Không có hỗ trợ phần cứng, phần mềm phải giám sát đồng thời cả đường SDA và đường SCL để phát hiện các cạnh xung nhịp và biết tích cực trạng thái của đường SDA trước khi SCL tăng hoặc giảm. Việc phát hiện điều kiện START hoặc STOP thường sẽ yêu cầu sử dụng các ngắt, nếu không phần mềm sẽ cần được sử dụng 100% với việc giám sát SCL và SDA. Việc triển khai Slave dựa trên phần mềm có xu hướng bị ràng buộc bởi CPU, yêu cầu một số MIPS để đạt được hoạt động thậm chí 100KHz. Do đó, các triển khai Slave chỉ có phần mềm thực sự thậm chí có thể không tồn tại đối với một số họ vi điều khiển và những họ khác có thể không có khả năng đạt đến tốc độ bus 100KHz đầy đủ.

Với nền tảng phần cứng và phần mềm này đã được xây dựng, chúng tôi sẽ đi sâu hơn vào chính giao thức trong bài viết tiếp theo của chúng tôi. Cảm ơn vì đã đọc!

(Bản quyền 2010 Robert G. Fries)