Atlas Robotics
Đọc DatasheetTrung bình

Đọc bảng điện — timing diagram cơ bản

Atlasbot · 23/8/2026 · 11 phút đọc

Đọc bảng điện — timing diagram cơ bản
Timing diagram I2C: setup time và hold time giữa SCL và SDA

Bài Absolute Maximum Ratings đã bàn giới hạn giá trị. Cùng nằm trong phần Electrical Characteristics còn có một dạng thông tin khác — timing diagram, mô tả quan hệ giữa các tín hiệu theo thời gian, không phải chỉ giá trị đơn lẻ.

Khái niệm chính

Timing diagram vẽ dạng sóng của nhiều tín hiệu (clock, dữ liệu, chip-select...) theo cùng một trục thời gian, đánh dấu các khoảng thời gian tối thiểu/tối đa cần tuân thủ giữa chúng — hai loại phổ biến nhất là:

  • Setup time (t_SU) — thời gian dữ liệu phải ổn định trước khi một sự kiện tham chiếu (thường là cạnh clock) xảy ra
  • Hold time (t_HD) — thời gian dữ liệu phải giữ ổn định sau khi sự kiện tham chiếu đã xảy ra

Nguyên lý hoạt động

Vi phạm setup time hoặc hold time khiến bên nhận đọc sai bit dữ liệu — không phải vì tần số clock vượt giới hạn danh nghĩa, mà vì quan hệ thời gian tương đối giữa 2 tín hiệu bị sai. Đây là lý do lỗi vi phạm timing thường biểu hiện thành lỗi "ngẫu nhiên", khó tái hiện: dữ liệu đọc đúng phần lớn thời gian (khi jitter/nhiễu tình cờ không đẩy tín hiệu ra khỏi cửa sổ setup/hold), chỉ sai ở một số lần cụ thể khi điều kiện thời gian thực tế (dây dẫn dài hơn, tải điện dung khác, nhiệt độ khác) đẩy tín hiệu ra ngoài giới hạn.

Tóm lại: Timing diagram trả lời câu hỏi mà bảng Electrical Characteristics một mình không trả lời được — "tín hiệu A phải ổn định bao lâu trước/sau tín hiệu B" — không phải "giá trị điện áp/dòng bao nhiêu". Đọc thiếu phần này dễ dẫn tới thiết kế đúng về giá trị điện nhưng sai về quan hệ thời gian.

Kiến thức kỹ thuật

Công thức

Tần số clock tối đa khả dụng bị giới hạn bởi tổng thời gian cần cho setup + hold + thời gian xử lý tín hiệu, không chỉ bởi thông số "tần số tối đa" ghi riêng lẻ:

Chu_kỳ_tối_thiểu ≥ t_SU + t_HD + t_xử_lý_tín_hiệu (trễ truyền dây, bộ đệm...)

f_max_thực_tế = 1 / Chu_kỳ_tối_thiểu

VD: t_SU = 100ns, t_HD = 100ns, trễ truyền dây ước tính 50ns
Chu_kỳ_tối_thiểu ≥ 100 + 100 + 50 = 250ns
f_max_thực_tế ≤ 1/250ns = 4 MHz

Nếu datasheet ghi "hỗ trợ tới 400kHz (Fast Mode)" nhưng dây dẫn dài
làm tăng đáng kể t_xử_lý_tín_hiệu, tần số an toàn thực tế có thể thấp
hơn nhiều so với con số 400kHz danh nghĩa

Thông số

Loại timingVi phạm gây ra hiện tượng gì
Setup time (t_SU)Bên nhận đọc giá trị CŨ thay vì giá trị MỚI của dữ liệu
Hold time (t_HD)Bên nhận đọc giá trị KHÔNG ỔN ĐỊNH (đang chuyển tiếp)
Rise/Fall timeTín hiệu chuyển mức chậm hơn dự kiến, lệch pha với clock
Propagation delayTrễ giữa lúc kích hoạt và lúc tín hiệu thực sự phản hồi

Ứng dụng thực tế

Khi giao tiếp giữa MCU và cảm biến qua I2C với dây dẫn dài hơn bình thường (ví dụ cảm biến gắn xa bo mạch chính trên khung AMR), điện dung ký sinh của dây dẫn dài làm tăng thời gian chuyển mức tín hiệu (rise/fall time), có thể vi phạm timing dù tần số clock cấu hình trong phần mềm vẫn đúng thông số danh nghĩa của cảm biến — đây là lý do lỗi giao tiếp I2C "chập chờn" khi tăng khoảng cách dây dẫn thường không phải lỗi phần mềm, mà là vi phạm timing vật lý cần hạ tần số clock hoặc thêm điện trở pull-up phù hợp để khắc phục.

Ví dụ thực tế

Kịch bản debug: cảm biến I2C hoạt động tốt trên breadboard (dây ngắn ~10cm),
nhưng đọc sai dữ liệu ngẫu nhiên khi lắp thật trên robot (dây dài ~50cm)

Phân tích theo timing diagram:
- Dây dài hơn → điện dung ký sinh tăng → rise/fall time tăng
- Tần số I2C đang cấu hình 400kHz (Fast Mode, chu kỳ 2500ns)
- Với dây ngắn, rise/fall time đủ nhanh để không ảnh hưởng setup/hold
- Với dây dài, rise/fall time tăng đáng kể, "ăn" vào khoảng thời gian
  vốn dành cho setup/hold, thỉnh thoảng vi phạm khi có thêm nhiễu

Giải pháp: giảm tần số I2C xuống 100kHz (Standard Mode, chu kỳ 10000ns)
để chừa nhiều biên độ thời gian hơn cho rise/fall time dài hơn của dây dài,
hoặc giảm giá trị điện trở pull-up để tăng tốc độ chuyển mức

Lỗi thường gặp

  • Chỉ kiểm tra "tần số tối đa" mà bỏ qua timing diagram chi tiết — như tính ở mục Công thức, tần số an toàn thực tế phụ thuộc cả điều kiện lắp đặt (độ dài dây, tải điện dung), không chỉ thông số danh nghĩa của chip.
  • Đổ lỗi cho phần mềm khi gặp lỗi giao tiếp "ngẫu nhiên" — như ví dụ trên, phần lớn trường hợp là vi phạm timing vật lý, cần xem lại phần cứng (độ dài dây, giá trị pull-up) trước khi nghi ngờ code.
  • Không tính trễ truyền dây khi thiết kế bus tốc độ cao — với khoảng cách xa hoặc tần số cao, trễ truyền tín hiệu qua dây dẫn có thể chiếm tỉ trọng đáng kể trong ngân sách thời gian, cần tính vào công thức chu kỳ tối thiểu.
  • Nhầm setup time và hold time khi đọc sơ đồ — hai loại timing này áp dụng ở hai thời điểm khác nhau (trước/sau sự kiện tham chiếu), nhầm lẫn dẫn tới tính sai margin thời gian thực tế.

Kết luận

Timing diagram bổ sung chiều thông tin mà bảng giá trị Electrical Characteristics không thể hiện được — quan hệ thời gian tương đối giữa các tín hiệu. Lỗi vi phạm timing thường biểu hiện thành lỗi giao tiếp "ngẫu nhiên", khó tái hiện, và nguyên nhân gốc thường nằm ở điều kiện lắp đặt thực tế (độ dài dây, tải điện dung) chứ không phải lỗi logic phần mềm. Bài cuối cùng của chuyên mục Đọc Datasheet đi vào register map — cách đọc bảng thanh ghi để cấu hình đúng một ngoại vi phần cứng.

Đọc bảng điện — timing diagram cơ bản — Atlasbot