Có phương pháp kiểm tra tiêu chuẩn nào cho mã kim loại trần không


8

Tôi muốn biết liệu mã kim loại trần, đặc biệt là những thứ như mã khởi tạo thiết bị / ngoại vi có bất kỳ phương pháp thử nghiệm nào không vì có rất ít lỗi có thể xảy ra khi ghi vào thanh ghi (một khi bạn biết rằng tất cả các địa chỉ được ánh xạ chính xác). Ngoài ra loại mã này thường có rất ít nhánh / đường dẫn khi thiết bị chỉ được cấu hình cho một chức năng duy nhất, vậy loại thử nghiệm nào sẽ cần thiết hoặc áp dụng ở đây?

Câu trả lời:


11

Điều đầu tiên tôi xác minh trên một bảng mới, cho dù đó là sử dụng bộ tạo dao động bên trong hay tinh thể bên ngoài, là tôi có tần số xung nhịp được thiết lập chính xác. Điều này rất quan trọng vì nhiều thiết bị ngoại vi, như UART, SPI, I2C và bộ hẹn giờ phụ thuộc vào nó.

Cách tôi xác minh là viết chương trình với một vòng lặp ngắn, bằng ngôn ngữ lắp ráp nơi tôi có thể đếm chu kỳ bằng tay hoặc C miễn là bạn có thể nhận được danh sách tháo gỡ và thực hiện tương tự - và bật đèn LED và tắt. Tôi thiết lập một vòng lặp để nó thực thi mỗi giây một lần. Tôi chạy mã và kiểm tra xem đèn LED nhấp nháy 60 lần trong một phút.

Theo như các thiết bị ngoại vi, cách tốt nhất để kiểm tra chúng là sử dụng máy hiện sóng nếu bạn có và xem dòng RX cho UART, CLK, MOSI và chọn dòng chip cho SPI và dòng SDA và SCL cho I2C, và kiểm tra xem các dòng đang chuyển đổi và thời gian có vẻ chính xác.

Nếu bạn không có máy hiện sóng, bạn có thể đặt đèn LED trên các đường này và sau đó bật hoặc tắt các thiết bị ngoại vi, Khi bị tắt, hầu hết các dòng sẽ ở mức thấp (đèn LED tắt), nhưng một số sẽ cao, như dây dẫn RX của UART (bật LED). Khi thiết bị ngoại vi được bật, hầu hết các đèn LED sẽ mờ đi, vì các dòng sẽ được bật. Bằng cách chạy trong một vòng lặp (bị vô hiệu hóa / kích hoạt), sẽ dễ dàng thấy sự khác biệt giữa bật hoặc mờ.

Đối với UART, bạn có thể kết nối đường TX với đường RX dưới dạng vòng lặp. Sau đó, bạn cũng có thể kết nối với cáp UART với USB và trên PC thực sự là một thiết bị đầu cuối như một chương trình như RealTerm . Bên cạnh việc thử nghiệm giao diện, điều này sẽ có ích cho việc gỡ lỗi khác sau này.

Đối với các đoạn mã khác, tôi sử dụng nhiều đèn LED khi cần thiết để hiển thị rằng các đường dẫn khác nhau trong mã đang được thực thi. Nếu bạn có UART hoạt động và được kết nối với PC, bạn có thể rắc mã của mình bằng các cuộc gọi đến chương trình con để xuất thông báo để hiển thị những điểm mà chương trình đã đạt tới (hoặc sử dụng printf nếu bạn có sẵn thư viện C tiêu chuẩn). Nhưng như Vladimir Cravero chỉ ra trong một bình luận bên dưới, điều này có thể làm chậm mã của bạn xuống một số (ở mức 115.200 baud, không quá nhiều, vì thời gian một ký tự là <10 trận). Nhưng trong ISR và mã quan trọng thời gian khác, chỉ cần sử dụng đèn LED.

Như Al Bundy chỉ ra trong một bình luận bên dưới, trình gỡ lỗi trong mạch cũng có thể hữu ích, đặc biệt nếu một người có thể đặt nhiều điểm dừng và thậm chí hữu ích hơn nếu bạn có thể thay đổi vị trí bộ nhớ trên một vị trí bộ nhớ. Không phải tất cả các trình sửa lỗi có tính năng đó.

Tuy nhiên, tôi không sử dụng trình gỡ lỗi rất nhiều trừ khi tôi phải xem xét các bit trong thanh ghi ngoại vi; hoặc để theo dõi một lỗi mà tôi không thể tìm thấy bằng cách kiểm tra; hoặc để phân tích bảo hiểm mã thô sơ. Nhưng nói chung, tôi thích chạy các chương trình ở tốc độ "bình thường" của chúng vì rất nhiều vấn đề thường sẽ xuất hiện, điều này có thể không xảy ra khi chương trình chỉ có một bước. Hầu hết các chương trình của tôi sử dụng ngắt rất nhiều, điều này cản trở việc sử dụng trình gỡ lỗi.


Bạn đã nói khá nhiều thứ, tôi chỉ nói thêm rằng việc thường xuyên rắc mã của bạn bằng fprintf sẽ làm chậm nó đi rất nhiều, đó là thứ bạn nên sử dụng nếu cần thiết và nếu bạn biết bạn đang làm gì. Tôi đã thấy một số câu hỏi (và có một số vấn đề) về một fprintf trong ISR hoặc như vậy.
Vladimir Cravero

@VladimirCravero Đồng ý - đó là lý do tại sao thích sử dụng đèn LED.
tcrosley

Cảm ơn câu trả lời. Bất kỳ con trỏ nào về công cụ / thiết lập nào bạn sẽ sử dụng để bảo hiểm mã trong trường hợp bạn chỉ có một trình giả lập nhưng không phải là phần cứng thực tế?
thượng cổ

Còn trình gỡ lỗi thì sao? Nó không đáng để đề cập?
Al Bundy

2
@AlBundy Tôi không sử dụng trình gỡ lỗi rất nhiều trừ khi tôi phải, ví dụ để xem các bit trong thanh ghi ngoại vi; hoặc để theo dõi một lỗi mà tôi không thể tìm thấy bằng cách kiểm tra; hoặc để thực hiện phân tích bảo hiểm mã thô sơ như tôi đã đề cập trong nhận xét của mình với OP. Nhưng nói chung, tôi thích chạy các chương trình ở tốc độ "bình thường" của chúng vì rất nhiều vấn đề thường sẽ xuất hiện, điều này sẽ không xảy ra khi chương trình chỉ có một bước. Hầu hết các chương trình của tôi sử dụng ngắt rất nhiều, điều này cản trở việc sử dụng trình gỡ lỗi. Tôi sẽ thêm một số ý kiến ​​vào câu trả lời của tôi.
tcrosley
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.