Mã thử nghiệm cho ứng dụng được nhúng

Question

Nền:

Tôi đang phát triển một dự án lớn bằng cách sử dụng Atmel AVR atmega2560. Dự án này chứa rất nhiều chức năng dựa trên phần cứng (7 thiết bị SPI, 2 I2C, 2 cổng RS485 MODBUS, rất nhiều I/O tương tự và kỹ thuật số). Tôi đã phát triển "trình điều khiển" cho tất cả các thiết bị này cung cấp vòng lặp ứng dụng chính với một giao diện để truy cập dữ liệu cần thiết.

Câu hỏi:

Dự án tôi đang phát triển cuối cùng sẽ phải đáp ứng các tiêu chuẩn SIL.

Tôi muốn có thể kiểm tra mã và cung cấp mức độ bao phủ mã tốt. Tuy nhiên tôi không thể tìm thấy bất kỳ thông tin nào để tôi bắt đầu về cách thiết lập một khung kiểm thử như vậy.

Ý tưởng là tôi có thể có một bộ kiểm tra tự động cho phép sửa lỗi trong tương lai và bổ sung tính năng để kiểm tra xem chúng có vi phạm mã hay không. Điều này là tôi không hiểu làm thế nào mã có thể được thử nghiệm trên chip.

Tôi có cần phần cứng để giám sát I/O trên thiết bị và mô phỏng các thiết bị được kết nối bên ngoài không? Bất kỳ con trỏ nào có thể được cung cấp sẽ được đánh giá cao.

--Steve

Answer 1

Đây là một câu hỏi rất hay - một mối quan tâm chung cho các nhà phát triển được nhúng. Thật không may, hầu hết các nhà phát triển nhúng không quan tâm như bạn và chỉ kiểm tra mã trên phần cứng thực. Nhưng như một câu trả lời khác chỉ ra, điều này về cơ bản có thể kiểm tra chức năng danh nghĩa của mã và không phải là trường hợp góc/lỗi.

Không có giải pháp đơn lẻ và đơn giản nào cho vấn đề này. Tuy nhiên, một số hướng dẫn và kỹ thuật tồn tại để thực hiện một công việc tương đối tốt.

Trước tiên, hãy tách mã của bạn thành các lớp. Một lớp phải là "thuyết bất khả tri phần cứng" - tức là các cuộc gọi hàm. Không yêu cầu người dùng ghi trực tiếp vào sổ đăng ký HW. Lớp khác (thấp hơn) giao dịch với HW. Lớp này có thể được "chế giễu" để kiểm tra mức cao hơn. Mức độ thấp hơn không thể thực sự được thử nghiệm mà không có HW, nhưng nó sẽ không thay đổi thường xuyên và cần tích hợp HW sâu, vì vậy nó không phải là một vấn đề.

"Khai thác thử nghiệm" sẽ là tất cả mã độc lập HW cấp cao của bạn với cấp thấp hơn "giả" cụ thể để thử nghiệm.Điều này có thể mô phỏng các thiết bị HW cho chức năng chính xác và không chính xác và do đó cho phép bạn chạy thử nghiệm tự động trên PC.

Answer 2

Không bao giờ chạy thử nghiệm đơn vị trên hoặc so với phần cứng thực. Luôn giả lập các giao diện I/O của bạn. Nếu không, bạn không thể mô phỏng các điều kiện lỗi và, quan trọng hơn, bạn không thể dựa vào thử nghiệm để thành công.

Vì vậy, những gì bạn cần là chia ứng dụng thành các phần khác nhau mà bạn có thể kiểm tra độc lập. Giả lập (hoặc giả lập) tất cả phần cứng mà bạn cần cho những thử nghiệm đó và chạy chúng trên PC phát triển của bạn.

Điều đó sẽ bao gồm hầu hết mã của bạn và để bạn với trình điều khiển. Cố gắng thực hiện càng nhiều mã trình điều khiển càng tốt mà không cần phần cứng. Đối với phần còn lại, bạn sẽ phải tìm cách để làm cho mã chạy trên phần cứng. Điều này thường có nghĩa là bạn phải tạo một giường thử nghiệm với các thiết bị bên ngoài đáp ứng các tín hiệu, vv Vì điều này là dễ vỡ (như trong "các xét nghiệm của bạn không thể thực hiện công việc này tự động"), bạn phải chạy các xét nghiệm này một cách thủ công sau khi chuẩn bị phần cứng.

Answer 3

Vectorcast là công cụ thương mại để chạy các kiểm tra đơn vị trên phần cứng có phạm vi mã.

Answer 4

Bạn có đầu nối JTAG không? Bạn có thể sử dụng JTAG để mô phỏng các điều kiện lỗi trên chip.

Answer 5

Tôi muốn tách các tác vụ. Ví dụ, khi tôi thực hiện một bộ đệm tròn cho Atmel AVR của tôi, tôi đã viết tất cả trong Code :: Blocks và biên dịch nó với trình biên dịch GCC thông thường thay vì trình biên dịch AVR GCC, sau đó tôi tạo một bài kiểm tra đơn vị cho nó. Tôi đã sử dụng một tệp tiêu đề đặc biệt để cung cấp các kiểu dữ liệu thích hợp mà tôi muốn làm việc (ví dụ uint8_t). Tôi tìm thấy lỗi với các bài kiểm tra đơn vị, cố định chúng, sau đó lấy mã cố định qua AVR Studio và tích hợp nó. Sau đó, tôi sử dụng chức năng hỗ trợ viết và ISR để phù hợp với bộ đệm thành mã hữu ích (ví dụ, bật một byte ra khỏi bộ đệm, đẩy nó vào thanh ghi đầu ra dữ liệu UART, nối thêm một chuỗi vào bộ đệm cho hàm printf, v.v.). Sau đó, tôi đã sử dụng bộ mô phỏng AVR để đảm bảo rằng các ISR và chức năng của tôi đã được gọi và dữ liệu phù hợp xuất hiện trong thanh ghi. Sau đó tôi lập trình nó trên chip và nó hoạt động hoàn hảo.

Tôi rất thích khả năng gỡ lỗi của Code :: Blocks so với AVR Studio vì vậy tôi sử dụng phương pháp trên bất cứ khi nào có thể. Khi tôi không thể, tôi thường chỉ xử lý phần cứng. Ví dụ tôi có một bộ đếm thời gian tự động tạo ra một làn sóng vuông. Điều tốt nhất tôi có thể làm là thấy rằng pin bit đã được twiddled trong giả lập. Sau đó tôi chỉ phải móc một phạm vi và chắc chắn.

Tôi thích sử dụng phương pháp tiếp cận đa cấp khi gỡ lỗi. Ví dụ với đồng hồ lớp đầu tiên là 'Đặt một thăm dò trên pin đồng hồ và xem nếu có một tín hiệu có'. Nếu không, hãy kiểm tra chốt trên uC và tìm tín hiệu. Sau đó, tôi mã hóa một giao diện gỡ lỗi trong một trong các UART của tôi, nơi tôi có thể xem xét các giá trị đăng ký cụ thể và đảm bảo chúng là những gì chúng được cho là. Vì vậy, nếu nó không làm việc bước tiếp theo là 'gọi lên giá trị đăng ký và đảm bảo nó là chính xác.'

Hãy thử suy nghĩ trước bốn bước hoặc hơn bất cứ khi nào bạn đang lập kế hoạch gỡ lỗi. Nên có + 5V ở đây, nhưng nếu không có thì sao? Viết vào giao diện gỡ lỗi một cách để chuyển đổi ghim và xem liệu nó có thay đổi hay không. Nếu điều đó không hiệu quả thì sao? Làm điều gì đó khác, v.v. v.v. Bạn đến một điểm mà bạn chạy vào 'TÔI KHÔNG CÓ Ý TƯỞNG TẠI ĐÂU NÀY NÀY KHÔNG LÀM VIỆC !!!!' nhưng hy vọng bạn sẽ tìm ra lý do trước.