Cách Thiết kế cho Kiểm tra trong Hệ thống Nhúng

Dù bạn đang thiết kế một PCB tốc độ cao hay một hệ thống nhúng phức tạp, nó sẽ cần một mức độ kiểm tra nào đó. Đối với các hệ thống tốc độ cao và RF tiên tiến, điều này thường có nghĩa là mô phỏng so với các phép đo VNA hoặc oscilloscope. Đối với phần mềm và firmware nhúng, các bước kiểm tra có thể khá khác biệt. Thực tế, có một số việc bạn có thể làm trong thiết kế nguyên mẫu của mình để giúp bạn tăng tốc quá trình kiểm tra và loại bỏ nhu cầu phải dùng đến đồng hồ đo đa năng.

Trong bài viết này, tôi sẽ chỉ cho bạn một số mẹo đơn giản có thể làm cho việc kiểm tra và gỡ lỗi nguyên mẫu trở nên dễ dàng hơn. Điều này có nghĩa là áp dụng cách tiếp cận thiết kế cho kiểm tra đối với cả phần mềm và phần cứng. Đây là một gợi ý: con đường tốt nhất cho việc kiểm tra hệ thống nhúng không chỉ đơn giản là đặt các điểm kiểm tra hoặc điểm thử nghiệm.

Thiết Kế Cho Kiểm Tra Trong Phần Cứng Nhúng

Chúng ta có rất nhiều từ ngữ chuyên môn trong ngành PCB, và “thiết kế cho kiểm tra” thường được nhóm cùng với gói DfX rộng lớn hơn. Nhiều nhà thiết kế sẽ tiếp cận thiết kế cho kiểm tra cho một bảng mạch chạy mã nhúng theo cách họ sẽ tiếp cận kiểm tra cho bất kỳ bảng mạch nào khác.

Điều này thường có nghĩa là các nhà thiết kế sẽ đặt rất nhiều điểm kiểm tra trên các tín hiệu quan trọng, nhưng có thể không nhiều hơn thế. Nhiều nguyên mẫu nhúng sẽ bắt đầu trông giống như một bảng phát triển Arduino, nơi mọi thứ bạn có thể nghĩ đến trên bộ xử lý chính được đưa ra ngoài qua các cổng pin và điểm kiểm tra.

Tôi không có gì chống lại cổng pin trên một bảng mạch hệ thống nhúng, hoặc trên bất kỳ bảng mạch nào khác. Nhưng, việc giám sát mọi tín hiệu và chân trong khi cố gắng kiểm tra và gỡ lỗi phần mềm hoặc firmware chạy trên bảng mạch là khó khăn. Trong một số trường hợp bạn phải thực sự viết một ứng dụng chỉ để kiểm tra ứng dụng của mình. Đôi khi, nếu bạn thấy một lỗi trong chức năng thiết kế của mình, nó có thể không luôn rõ ràng liệu nguyên nhân gốc rễ là do mã của bạn hay do PCBA của bạn.

Ở phía phần cứng, tập trung vào việc áp dụng cách tiếp cận đơn giản này cho thiết kế kiểm tra:

• Không phải mọi thứ đều cần một cổng pin. Chỉ đưa tín hiệu ra cổng nếu bạn thực sự dự định kết nối nó với thứ gì đó hoặc nếu bạn thực sự sẽ đo lường nó.
• Đặt các kết nối bạn có thể sử dụng thực sự. Như vậy bạn có thể kết nối với thẻ thu thập dữ liệu, máy phân tích logic, oscilloscope, v.v.
• Hãy để phần mềm thực hiện việc kiểm tra. Đừng quên rằng ứng dụng nhúng của bạn có thể đọc tín hiệu từ các thiết bị ngoại vi, điều này cho phép bạn xây dựng các trường hợp kiểm tra vào mã của mình.
• Bạn có thể nhìn vào dữ liệu trên màn hình, bạn chỉ cần một kết nối với PC của mình, chẳng hạn qua cổng nối tiếp, thẻ thu thập dữ liệu, hoặc phần mềm độc quyền.

Một số khái niệm này đã được Ari Mahpour thảo luận nhiều trong các cuộc thảo luận của ông về kiểm thử và tích hợp liên tục. Hãy xem bài viết này để tìm hiểu thêm về cách tiếp cận này. Nếu bạn muốn gửi dữ liệu trở lại máy tính của mình, phương pháp đơn giản nhất là thêm một giao diện USB-to-serial vào nguyên mẫu của bạn. Hãy xem dự án này từ Zach Peterson và lấy link tải các tệp thiết kế.

Các Trường Hợp Kiểm Thử trong Phần Mềm Nhúng

Tiếp theo, nếu bạn đang chạy một ứng dụng nhúng trên hệ thống của mình, thì bạn có thể bao gồm xử lý lỗi hoặc các trường hợp kiểm thử trong mã để giúp tăng tốc độ kiểm thử. Thêm các kết nối với giao diện có header, test pads, và một giao diện serial cơ bản đều là những bước quan trọng giúp bạn theo dõi bảng mạch nhúng của mình theo thời gian thực. Mục tiêu là xem ứng dụng phần mềm hoạt động như thế nào ngay cạnh phần cứng.

Vậy làm thế nào bạn có thể theo dõi tiến trình của ứng dụng và phần cứng cùng một lúc? Hãy lấy gợi ý từ các nhà phát triển phần mềm: thêm vào xử lý lỗi và thông báo để hiển thị trạng thái của từng chức năng trong ứng dụng của bạn. Điều này có thể đơn giản như hiển thị thông báo cho biết liệu các chức năng quan trọng đã được vượt qua hay thất bại trong ứng dụng. Việc viết ra tất cả những kiểm tra lỗi đó mất một chút thời gian, nhưng việc có một thông báo trên màn hình chỉ ra những gì hệ thống của bạn đang làm trong quá trình thực thi ứng dụng có thể loại bỏ một lượng lớn công việc gỡ lỗi.

Đây là một ví dụ cho thấy điều này sẽ được triển khai như thế nào trong C/C++ sử dụng một hàm đơn giản (gọi là myFunction()) và một thư viện GPIO giả định. Giả sử bạn đang làm việc với một nền tảng cung cấp một thư viện GPIO đơn giản với các hàm như gpio_init(), gpio_read(), v.v.:

Nếu ứng dụng của bạn đang theo dõi trực tiếp các tín hiệu, ứng dụng của bạn có thể in kết quả đó ra màn hình ở mỗi bước trong các hàm cốt lõi của nó. In những kết quả này trên màn hình cùng với các tín hiệu chỉ thị chính sẽ cho bạn biết chính xác điều gì đang xảy ra khi ứng dụng của bạn tiến triển, và bạn sẽ không cần phải đo lường thủ công mọi tín hiệu trên bo mạch của mình bằng một đơn vị bên ngoài. Chắc chắn, điều này đòi hỏi phải định tuyến thêm một vài đường dẫn tín hiệu extra đến GPIOs khi thiết kế bo mạch, nhưng bạn có thể phát hiện ra rằng một lỗi logic rõ ràng thực sự chỉ là một lỗi kết nối đơn giản trên PCB của bạn.

Đừng quên, bạn vẫn có thể chuyển bất kỳ tín hiệu nào khác cần đi đến một đầu dò qua một header. Như vậy, những tín hiệu đó vẫn có thể được đo lường bằng một oscilloscope, hoặc một thẻ thu thập dữ liệu. Trong khi đó, cổng nối tiếp sẽ làm rất nhiều công việc giúp bạn tương tác với logic ứng dụng của mình.

Dù bạn muốn thiết kế gì, bạn có thể triển khai các thực hành thiết kế cho kiểm tra sáng tạo sử dụng bộ tính năng thiết kế PCB đầy đủ trong Altium Designer®. Để triển khai sự hợp tác trong môi trường đa ngành nghề ngày nay, các công ty sáng tạo đang sử dụng nền tảng Altium 365™ để dễ dàng chia sẻ dữ liệu thiết kế và đưa dự án vào sản xuất.

Chúng ta mới chỉ khám phá bề mặt của những gì có thể làm được với Altium Designer trên Altium 365. Bắt đầu dùng thử miễn phí Altium Designer + Altium 365 ngay hôm nay.