Thử nghiệm Hệ điều hành thời gian thực cho độ cứng

Question

Tôi có một thiết bị nhúng (Technologic TS-7800) quảng cáo khả năng thời gian thực, nhưng không nói gì về 'cứng' hoặc 'mềm'. Trong khi chờ đợi phản hồi từ nhà sản xuất, tôi nhận thấy nó sẽ không làm hại bản thân để kiểm tra hệ thống.

Một số quy trình được thiết lập để xác định 'độ cứng' của một thiết bị cụ thể đối với hành vi thời gian thực/xác định (độ trễ và độ rung) là gì?

Đang ở trường đại học, tôi có quyền truy cập vào một số phần cứng khá gọn gàng (máy đo dao động và máy phát tín hiệu tốt), vì vậy tôi không nghĩ mình sẽ gặp phải bất kỳ vấn đề nào về thiết bị thử nghiệm.

Answer 1

Tôi có cùng một bảng ở đây tại nơi làm việc. Đó là một hạt nhân 2.6 được sửa đổi một chút, tôi tin rằng ... không phải là phiên bản thời gian thực.

Tôi không biết rằng tôi đã đọc bất kỳ nội dung nào trong tài liệu chưa cho biết rằng nó có nghĩa là cho công việc RTOS nghiêm ngặt.

Answer 2

Với loại thiết bị đó, phải tương đối dễ dàng để đồng bộ o-phạm vi với đồng hồ ổn định, tạo ra tăng đột biến mỗi lần hệ thống thời gian thực tạo ra đầu ra. . Càng ít biến thể, độ cứng càng lớn.

Answer 3

Để làm rõ câu trả lời của Bob có thể:

Sử dụng trình tạo tín hiệu để tạo xung ở một số tần số khác nhau. Phân phối ngẫu nhiên trên một số phạm vi sẽ là tốt nhất.

sử dụng trình tạo tín hiệu (tín hiệu kích hoạt) để bắt đầu phạm vi.

RTOS phải trả lời, làm điều đó và gửi xung đầu ra.

nạp đầu ra RTOS vào đầu vào 2 của phạm vi.

lấy phạm vi cho chế độ thu thập/lưu giữ. nhận phạm vi bắt đầu từ A, dừng lại B. nếu bạn có thể.

trong một workd lý tưởng, làm cho nó để đo phân phối cho bạn. Một LeCroy sẽ. Bắt đầu với một dấu vết chậm hơn nhiều so với bạn mong đợi. Bạn cần có khả năng nhìn thấy các ngoại lệ chậm. Bạn sẽ có thể xem bản phân phối.
Giả sử phân bố chuẩn SD của biến thể thời gian phản hồi là SOFTNESS. (Điều này sẽ không thực sự xảy ra trong thực tế, nhưng nếu bạn không nhận được ngoại lệ nó là hợp lý hữu ích.) Nếu có những ngoại lệ có độ trễ lớn, thì RTOS KHÔNG phải là rất khó. Không đáp ứng thời hạn tốt. Không phù hợp thì nó là dành cho công việc thời gian thực khó khăn. Nhiều thứ giống như RTOS có cạnh trái tốt với đường cong, dốc xuống như đường cong 1/f. Thats chỉ ra các jitters kết hợp. Điều cần xem xét là các phản ứng chậm ở đầu bên phải của phạm vi. Tiếp tục lặp lại thí nghiệm với các dấu vết nhanh hơn nếu không có ngoại lệ để có được hình ảnh tốt về độ dốc. Nên tốt cho một số kết luận đầu cơ trong bài báo của bạn.

Nếu cho ứng dụng của bạn, hãy nói rằng một đồng bằng của 1uS là ổn, và bạn đo 0,5us, tất cả đều mát mẻ.

Dù sao, bạn có thể công bố kết quả (và có lẽ trong xuất bản nghĩa nào đó, nhưng chắc chắn trên web.)

Liên kết từ Câu hỏi này để giấy khi bạn đã viết nó.

Answer 4

Tôi hiểu là đam mê, nhưng sử dụng dao động để kiểm tra máy tính với cổng ethernet/usb/kỹ thuật số khác và trạng thái bên trong HUGE (RAM) không hiệu quả và không đáng tin cậy.

Thay vì xem biểu mẫu sóng, bạn có thể kết nối bất kỳ PC nào với cổng đầu ra và chạy phân tích thống kê phù hợp.

Quy trình được thiết lập (nếu tín hiệu đầu vào tương tự theo bản chất) là kiểm tra hệ thống đối với một số đầu vào đặc trưng - gai truyền thống, chức năng bước và sóng sin có tần số khác nhau - và đo pha dịch chuyển và phương sai cho từng loại đầu vào. Trường hợp xấu nhất sau đó được sử dụng trong thông số kỹ thuật của hệ thống.

Một lần nữa, nếu bạn đang sử dụng các cổng tiêu chuẩn, bạn có thể dễ dàng tạo chúng trên PC. Nếu đầu vào là thực sự tương tự, một DAC riêng biệt hoặc chỉ đơn giản là một card âm thanh tốt sẽ là cần thiết.

Bây giờ, điều đó sẽ không nói bất cứ điều gì về hệ điều hành là thời gian thực - nó có thể chạy vanilla Linux hoặc thậm chí Win CE và vẫn tạo ra kết quả tốt và ổn định trong các bài kiểm tra đó nếu phần cứng đủ nhanh.

Vì vậy, bạn cần mô phỏng tải trọng nặng và khác nhau trên bộ vi xử lý, bộ nhớ và tất cả các cổng, để nhiệt và ăn bộ nhớ trong vài giờ và sau đó lặp lại kiểm tra. Nếu độ trễ vẫn không đổi, thì sẽ rất khó khăn trong thời gian thực. Nếu không, dưới bất kỳ loại tín hiệu tải và tín hiệu đầu vào nào, tăng trên giới hạn chấp nhận được, nó sẽ mềm. Nếu không, đó là quảng cáo.

P.S .: Ngụ ý là ngay cả đối với các hệ thống quan trọng bạn không thực sự cần thời gian thực cứng nếu bạn có phần cứng.

Answer 5

Thời gian thực cứng có nhiều việc phải làm với cách phần mềm của bạn hoạt động như thế nào so với phần cứng của chính nó. Khi yêu cầu nếu một cái gì đó là khó khăn thời gian thực nó phải được áp dụng cho hệ thống hoàn chỉnh (Phần cứng, RTOS và ứng dụng). Điều này có nghĩa là thời gian thực cứng hoặc mềm là vấn đề thiết kế hệ thống.

Khi tải vượt quá đặc điểm kỹ thuật, hệ thống thời gian thực cứng sẽ không thành công (hy vọng với chỉ báo lỗi đúng) trong khi hệ thống thời gian thực mềm với tải thấp sẽ cho kết quả thời gian thực khó. Quá trình xử lý phải diễn ra đúng lúc và mức độ xử lý trước/sau có thể thực hiện là khóa thực sự đối với thời gian thực cứng/mềm.

Trong một số ứng dụng thời gian thực, một số mất dữ liệu không phải là lỗi, nó chỉ ở dưới một mức nhất định, một lần nữa là tiêu chí hệ thống.

Bạn có thể tạo đầu vào cho bảng và có một ứng dụng nhỏ đếm chúng và kiểm tra dữ liệu ở mức nào sẽ bị mất. Nhưng điều đó mang lại cho bạn một đánh giá cụ thể cho hệ thống đang chạy ứng dụng đó. Ngay sau khi bạn bắt đầu thực hiện nhiều việc xử lý tải tính toán của bạn tăng lên và bây giờ bạn có một giới hạn thời gian thực cứng khác.

Bảng này sẽ chạy bộ lập lịch xương trần sẽ mang lại hiệu suất thời gian thực khó dự đoán lớn cho hầu hết các tác vụ. Chạy một RTOS đầy đủ với tải tính toán nặng, bạn có thể chỉ nhận được thời gian thực mềm.

Edit after comment
Cách hiệu quả nhất và dễ dàng nhất tôi đã sử dụng để đo lường hiệu suất phần mềm của tôi (giả sử bạn sử dụng một schedular) là bằng cách sử dụng một bộ đếm thời gian phần cứng chạy tự do trên bảng và thời gian đóng dấu bắt đầu và kết thúc của chu kỳ của tôi của tôi . Hoặc nếu bạn chạy một tem thời gian RTOS đầy đủ, bạn mua lại và chuyển đổi. Tiết kiệm thời gian Max của bạn và chạy trung bình trên các giá trị trong một giây. Nếu trung bình của bạn là khoảng 50% và bạn tối đa là trong vòng 20% ​​trung bình của bạn, bạn là OK. Nếu không, đó là thời gian để cấu trúc lại ứng dụng của bạn. Khi ứng dụng của bạn tăng thời gian chu kỳ sẽ tăng lên. Bạn có thể theo dõi hiệu quả của tất cả các thay đổi phần mềm trong thời gian chu kỳ của bạn.

Một cách khác là sử dụng bộ hẹn giờ phần cứng tạo ra gián đoạn theo chu kỳ. Nếu bạn đang trong thời gian thiết lập lại ngắt. Nếu bạn bỏ lỡ thời hạn bạn đã ngắt tín hiệu xử lý một thất bại.Tuy nhiên điều này sẽ chỉ cung cấp cho bạn một cảnh báo khi ứng dụng của bạn mất nhiều thời gian nhưng nó phụ thuộc vào phần cứng và ngắt nên bạn không thể bỏ lỡ.

Các giải pháp này cũng loại bỏ yêu cầu treo lên một phạm vi để giám sát đầu ra vì thông tin thời gian có thể được hiển thị trong bất kỳ loại thiết bị đầu cuối nào bằng tác vụ nền. Nếu dễ giám sát, bạn sẽ theo dõi nó thường xuyên tránh giải quyết các vấn đề về thời gian ở cuối nhưng ngay khi chúng được giới thiệu.

Hy vọng điều này sẽ giúp

Answer 6

Tôi nghĩ rằng đây không phải là một thiết bị thời gian thực cứng vì nó không chạy RTOS.