Làm thế nào để bạn kiểm tra mô-đun xử lý ngắt của bạn?

Question

Tôi có một mô-đun xử lý ngắt điều khiển phần cứng bộ điều khiển ngắt trên bộ xử lý được nhúng. Bây giờ tôi muốn thêm nhiều thử nghiệm vào nó. Hiện tại, các bài kiểm tra chỉ kiểm tra xem việc lồng ghép các ngắt có hoạt động hay không bằng cách thực hiện hai ngắt phần mềm từ bên trong ISR, một phần có mức ưu tiên thấp và có mức ưu tiên cao. Làm thế nào tôi có thể kiểm tra mô-đun này hơn nữa?

Answer 1

Tôi khuyên bạn cũng nên thử tạo các kích thích khác.

Thông thường, cũng có thể kích hoạt ngắt phần cứng bằng phần mềm (kiểm tra tự động) hoặc trình gỡ lỗi bằng cách đặt cờ. Hoặc làm gián đoạn qua I/O. Hoặc một bộ đếm thời gian bị gián đoạn. Hoặc bạn chỉ có thể thiết lập bit ngắt trong bộ điều khiển ngắt thông qua trình gỡ lỗi trong khi bạn đang bước đơn.

Bạn có thể thêm một số kiểm tra thời gian chạy vào những thứ không được cho là xảy ra. Đôi khi tôi chọn đặt chân đầu ra để giám sát bên ngoài (tốt nếu bạn có một máy phân tích dao động hoặc logic ...)

low_prio_isr(void) 
{ 
    LOW_PRIO_ISR=1; 
    if (1 == HIGH_PRIO_ISR) 
    { this may never happen. dummy statement to allow breakpoint in debugger } 

} 

high_prio_isr(void) 
{ 
    HIGH_PRIO_ISR=1 
} 

Điểm bất lợi của phần mềm gián đoạn là thời điểm được sửa; luôn luôn hướng dẫn tương tự. Tôi tin rằng bạn muốn thấy bằng chứng rằng nó luôn hoạt động; bế tắc miễn phí.

Đối với các thói quen dịch vụ gián đoạn, tôi thấy đánh giá mã rất có giá trị. Cuối cùng, bạn chỉ có thể kiểm tra các tình huống mà bạn đã tưởng tượng và tại một số điểm nỗ lực thử nghiệm sẽ rất cao. ISRs nổi tiếng là khó gỡ lỗi.

Tôi nghĩ rằng nó rất hữu ích để cung cấp các xét nghiệm sau: - ISR không bị gián đoạn cho ưu tiên thấp hơn gián đoạn - ISR không bị gián đoạn cho cùng một ưu tiên ngắt - ISR bị gián đoạn cho ưu tiên cao hơn ngắt - count làm tổ tối đa trong giới hạn ngăn xếp.

Một số xét nghiệm của bạn có thể ở lại các mã như thiết bị đo đạc (để bạn có thể theo dõi ví dụ mức độ làm tổ tối đa

Oh, và một điều nữa:. Tôi thường đã quản lý để giữ ISRs quá ngắn mà tôi có thể kiềm chế không làm tổ .... nếu bạn có thể điều này sẽ được bạn đơn giản bổ sung và hiệu suất hơn.

[EDIT] Tất nhiên, ISRs cần phải được thử nghiệm trên phần cứng trong hệ thống quá. Ngoài các bằng bit -bit, cách tiếp cận từng bước bạn có thể muốn chứng minh: - sự ổn định của hệ thống tại tải ngắt lớn nhất (tốt nhất là nhiều lần e dự đoán tải tối đa; nếu trình điều khiển nối tiếp 115kbps của bạn cũng có thể xử lý 2MBps, bạn sẽ không sao!) - đúng thời điểm bật/tắt isr, đặc biệt nếu hệ thống cũng đi vào chế độ ngủ - # lần ngắt. Có thể gây ngạc nhiên nếu bạn thêm công tắc cơ khí, quay cơ học (hàng trăm khoảnh khắc ngắt quãng/tiếp xúc trước khi đạt được tình trạng ổn định)

Answer 2

Tôi không phải là nhà phát triển được nhúng, vì vậy tôi không biết điều này có khả thi hay không, nhưng làm cách nào để tách mã xử lý các ngắt từ cơ chế đăng ký gọi lại? Điều này sẽ cho phép bạn viết mã mô phỏng sự cố gián đoạn khi bạn thích ...

Answer 3

Tôi khuyên bạn nên thử nghiệm phần cứng thực. Xử lý ngắt vốn vốn dĩ ngẫu nhiên và không thể đoán trước được.

Sử dụng trình tạo tín hiệu và nạp một wave vuông vào chân ngắt thích hợp. Sử dụng nhiều máy phát (hoặc một với nhiều đầu ra) để kiểm tra nhiều dòng IRQ và xác minh xử lý ưu tiên.

Thử nghiệm quay số tần số & xuống trên bộ tạo tín hiệu (thay đổi tốc độ giữa chúng) và xem điều gì xảy ra. Có rất nhiều mã chẩn đoán để xác minh trạng thái của bộ điều khiển ngắt ở các trạng thái khác nhau.

Thay thế: Nếu nền tảng của bạn có bộ hẹn giờ có thể kích hoạt ngắt, bạn có thể sử dụng chúng thay vì phần cứng bên ngoài.

Answer 4

Đối với những nội dung như thế này, tôi đặc biệt khuyên bạn nên sử dụng những thứ như SPIN model checker. Bạn sẽ kiểm tra thuật toán chứ không phải mã, nhưng thử nghiệm là đầy đủ. Quay lại trong ngày, I found a bug in gdb bằng kỹ thuật này.