Với sự phát triển của công nghệ bán dẫn, các bộ vi xử lý ngày càng mạnh hơn và hỗ trợ phát triển phần mềm trên những ngôn ngữ cấp cao như C/C++, việc tạo ra một khung chương trình nền so
TỔNG THUẬT CÁC CÔNG TRÌNH LIÊN QUAN
CƠ SỞ LÝ THUYẾT
Hệ điều hành thời gian thực
3.1.1 Khái niệm hệ thống thời gian thực
Một hệ thống thời gian thực là một hệ thống thỏa mãn ràng buộc về thời gian đáp ứng hay nói cách khác hệ thống thời gian thực phải đảm bảo tính đúng đắn cả về luận lý (logic) và thời gian đáp ứng
Một hệ thống thời gian thực mềm (soft real-time) là một hệ thống trong đó việc không đáp ứng các ràng buộc thời gian đáp ứng sẽ làm giảm hiệu suất hệ thống nhưng không phá hủy hệ thống
Một hệ thống thời gian thực cứng (hard real-time) là một hệ thống mà trong đó việc không đáp ứng một ràng buộc thời gian đáp ứng có thể dẫn đến sự phá hủy một phần hoặc toàn bộ hệ thống
Một hệ thống thời gian thực dẻo (firm real-time) là một hệ thống trong đó việc không đáp ứng một vài ràng buộc thời gian đáp ứng không phá hủy hệ thống nhưng nếu không đáp ứng nhiều hơn một vài ràng buộc thời gian đáp ứng có thể dẫn đến sự phá hủy một phần hoặc toàn bộ hệ thống
3.1.2 Lịch sử phát triển hệ điều hành
Trong những ngày đầu của ngành khoa học máy tính, các nhà phát triển tạo ra các ứng dụng phần mềm bao gồm mã máy cấp thấp để khởi tạo và tương tác trực tiếp với phần cứng của hệ thống Sự liên kết chặt chẽ giữa phần mềm và phần cứng dẫn đến các ứng dụng không thể di chuyển từ hệ thống này sang hệ thống khác một trừu tượng các phần cứng cơ bản từ các mã ứng dụng Ngoài ra, sự ra đời của hệ điều hành đã giúp thay đổi thiết kế các ứng dụng phần mềm từ ứng dụng lớn, nguyên khối đến các ứng dụng phân cấp theo module, kết nối với nhau mà có thể chạy trên môi trường hệ điều hành
Trong thập niên 60 và 70, khi quy mô máy tính vừa và lớn chiếm ưu thế, UNIX được phát triển để tạo thuận lợi cho nhiều người sử dụng truy cập vào hệ thống máy tính giới hạn sẵn có đắt tiền UNIX cho phép nhiều người sử dụng thực hiện một loạt các tác vụ để chia sẻ các máy tính lớn và tốn kém Việc truy cập đa người dùng là rất hiệu quả: một người sử dụng có thể in các tập tin, trong khi viết các chương trình khác Do đó, UNIX đã được sử dụng rất rộng rãi từ máy vi tính cho đến các siêu máy tính
Trong những năm 80, Microsoft giới thiệu hệ điều hành Windows, trong đó nhấn mạnh đến môi trường máy tính cá nhân Mục tiêu cho người sử dụng tương tác với máy tính thông qua một giao diện người dùng đồ họa, các hệ điều hành Microsoft Windows đã dẫn đến kỷ nguyên máy tính cá nhân
Trong những thập niên gần đây, việc xây dựng cho thế hệ kế tiếp của máy tính bắt đầu chuyển hướng sang các thiết bị di động sử dụng pin: máy tính bảng, máy tính nhúng, hệ thống nhúng Để đáp ứng nhu cầu của máy tính nhúng, các hệ điều hành thời gian thực (RTOS) thương mại, chẳng hạn như VxWorks, được phát triển Mặc dù một số chức năng tương tự tồn tại giữa RTOS và hệ điều hành đa dụng (GPOS), có nhiều sự khác biệt quan trọng giữa chúng Những khác biệt này giúp giải thích tại sao RTOS phù hợp hơn với các hệ thống nhúngthời gian thực
Một số chức năng cốt lõi giống nhau giữa một RTOS điển hình và các GPOS bao gồm:
• Một số mức độ đa nhiệm
• Phần mềm và quản lý tài nguyên phần cứng
• Cung cấp các dịch vụ cơ bản của hệ điều hành cho các ứng dụng
• Trừu tượng hóa các phần cứng từ các ứng dụng phần mềm
Mặt khác, một số khác biệt chức năng quan trọng làm cho RTOS khác biệt với GPOS bao gồm:
• Độ tin cậy tốt hơn trong các ngữ cảnh ứng dụng nhúng
• Khả năng thay đổi quy mô lên hoặc xuống để đáp ứng nhu cầu ứng dụng
• Giảm dung lượng bộ nhớ cần thiết
• Chính sách lập lịch phù hợp cho các hệ thống nhúngthời gian thực
• Hỗ trợ cho các hệ thống nhúng không có đĩa cứng bằng cách cho phép khởi động và thực thi chương trình từ ROM hoặc RAM
• Tính di động tốt hơn với các nền tảng phần cứng khác nhau
Ngày nay, GPOS hướng đến máy tính đa dụng và chạy chủ yếu trên các hệ thống như máy tính cá nhân, máy trạm, và máy tính lớn Trong một số trường hợp, GPOS chạy trên các thiết bị nhúng có bộ nhớ phong phú và yêu cầu thời gian thực rất mềm GPOS thường yêu cầu nhiều bộ nhớ hơn, tuy nhiên nó không phù hợp với các thiết bị nhúng thời gian thực với bộ nhớ hạn chế và yêu cầu hiệu suất cao
RTOS có thể đáp ứng các yêu cầu này một cách tốt hơn Chúng đáng tin cậy, nhỏ gọn, có khả năng mở rộng tốt và chúng thực hiện tốt trong các hệ thống nhúng thời gian thực Ngoài ra, RTOS có thể dễ dàng thiết kế, chỉnh sửa để sử dụng chỉ những thành phần cần thiết cho một ứng dụng cụ thể một RTOS có thể khá đa dạng, từ một ứng dụng đơn giản cho một đồng hồ bấm giờ kỹ thuật số đến một ứng dụng phức tạp hơn nhiều cho hệ thống định vị trên máy bay Những RTOS tốt luôn có khả năng mở rộng để đáp ứng các yêu cầu đặt ra khác nhau cho các ứng dụng khác nhau
Trong một số ứng dụng, một RTOS chỉ gồm một nhân (kernel), cung cấp luận lý tối thiểu, lịch trình, và các thuật toán quản lý tài nguyên Các RTOS đều có một kernel Mặt khác, một RTOS có thể là một sự kết hợp của các khối chức năng khác nhau; bao gồm kernel, một hệ thống quản lý tập tin, giao thức mạng và các thành phần khác cần thiết cho một ứng dụng cụ thể, như minh họa ở mức cao trong hình 3.1
Hình 3.1 - Góc nhìn cấp cao của một RTOS bao gồm kernel, và các thành phần khác trong các hệ thống nhúng (nguồn [20])
Mặc dù nhiều RTOS có thể mở rộng lên hoặc xuống để đáp ứng yêu cầu ứng dụng Hầu hết kernel của RTOS chứa các thành phần sau:
• Scheduler: được chứa trong từng kernel và chứa một tập các thuật toán để xác định tác vụ thực hiện khi nào Một số ví dụ phổ biến của thuật toán lập lịch bao gồm round-robin và lập lịch dựa trên độ ưu tiên của các tác vụ
• Các đối tượng: được giúp các nhà phát triển tạo ra các ứng dụng cho các hệ thống nhúng thời gian thực Đối tượng của kernel thông thường bao gồm các tác vụ, semaphore và message-queue, …
• Dịch vụ: là hoạt động mà kernel thực hiện trên một đối tượng hay nói chung là các hoạt động như định thời, quản lý ngắt và quản lý tài nguyên
Hình 3.2 - Các thành phần chính trong kernel của một RTOS (nguồn [20]) 3.1.3.2 Scheduler
Scheduler là trái tim của kernel trong một RTOS Scheduler cung cấp các thuật toán cần thiết để xác định tác vụ nào sẽ thực thi và khi nào thì thực thi chúng Để hiểu được cách thức hoạt động của lập lịch, chúng ta tìm hiểu qua các vấn đề sau: cung cấp một dạng khác của một đối tượng có thể lập lịch được gọi là một quá trình Các quá trình này được tương tự như tác vụ ở chỗ chúng có thể độc lập cạnh tranh thời gian thực hiện CPU Các quá trình khác với các tác vụ ở chỗ chúng cung cấp tính năng bảo vệ bộ nhớ tốt hơn khi tính đến chi phí về hiệu suất và chi phí bộ nhớ Đa nhiệm (multitasking): đa nhiệm là khả năng của hệ điều hành để xử lý các hoạt động trong thời hạn quy định Một kernel thời gian thực có thể có nhiều tác vụ thực thi cùng lúc mà vẫn đảm bảo các tác vụ hoàn thành trong thời gian quy định Một trong những kịch bản đa nhiệm được minh họa trong hình 3.3
Hình 3.3 - Đa nhiệm sử dụng chuyển đổi ngữ cảnh (nguồn [20])
Vi xử lý S1C17704
3.2.1 Giới thiệu họ vi xử lý S1C17 của Seiko Epson
Lõi S1C17 là loại lõi xử lý cấu trúc RISC 16 bit của Seiko Epson, dùng công nghệ CMOS cụng suất thấp 0.35 – 0.15àm Tần số hoạt động: tối đa 90MHz (tựy thuộc vào chủng loại bộ xử lý và công nghệ xử lý)
• Số lượng: 111 lệnh cơ bản (184 lệnh bao gồm các biến thể)
• Chu kỳ thực hiện: các lệnh chính thực thi trong một chu kỳ
• Lệnh mở rộng: có thể dài 24 bit
• Truyền dữ liệu: 8 bit, 16 bit, 24 bit, 32 bit, có dấu, không dấu
• Phép tính số nguyên: cộng trừ, so sánh
• Toán tử logic: and or xor not
• Dịch (shift) và chuyển đổi (swap)
• Lệnh điều khiển hệ thống
• Lệnh mở rộng câu lệnh
• 1 thanh ghi chuyên dụng 8 bit
Không gian bộ nhớ và bus:
• Có thể lên đến 16M byte không gian bộ nhớ (địa chỉ 24 bit)
• Kiến trúc Harvard dùng bus lệnh riêng 16 bit, và bus dữ liệu 32 bit
Các cách định vị địa chỉ:
• Định vị địa chỉ tức thời
• Định vị địa chỉ thanh ghi trực tiếp
• Định vị địa chỉ thanh ghi gián tiếp
• Định vị địa chỉ thanh ghi gián tiếp có tăng dần, giảm dần
• Định vị địa chỉ thanh ghi chuyển vị
• Định vị địa chỉ liên quan thanh ghi PC có dấu
• Định vị địa chỉ độc lập thanh ghi PC
• Reset, NMI (Non-Markable Interrupt), và hỗ trợ 32 nguồn ngắt ngoài
• Ngắt khi truy cập vào vùng địa chỉ không hợp lệ
• Ngắt cho việc kiểm lỗi chương trình
• Rẽ nhánh trực tiếp từ bảng vector ngắt đến hàm xử lý ngắt (interrupt handler routine)
• Ngắt bằng phần mềm với các vector ngắt cho trước
Các lệnh hỗ trợ tiết kiệm năng lượng:
S1C17704 là CPU lõi RISC 16 bit thuộc dòng S1C17 do Seiko Epson sản xuất
Bộ dao động chính (OSC3): sử dụng dao động thạch anh/ceramic tối đa 8.2 MHz, hay bộ dao động CR tối đa 2.2 MHz
Bộ dao động phụ (OSC1): thường sử dụng bộ dao động thạch anh 32.786 kHz
Bộ nhớ Flash trên chip: 64k byte (dùng chứa dữ liệu và lệnh), có thể lập trình/xóa; hay bảo vệ chỉ đọc Tích hợp công cụ kiểm lỗi như IDC Mini (S5U1C17704H) và tự lập trình
RAM trên chip có 4k byte
Vùng RAM cho hiển thị trên chip có 576 byte
Có đến 28 cổng xuất nhập đa dụng
• Bộ điều khiển từ xa (REMC) 1 kênh
• Timer 8 bit cho OSC1 1 kênh
Mạch lái (driver) LCD 56 SEG x 32 COM hay 72 SEG x 16 COM (1/5 bias), tích hợp bộ tăng áp
Bộ kiểm tra mức điện áp cung cấp: 13 mức có thể lập trình được (1.8 V đến 2.7 V)
Ngắt: reset, NMI, 16 ngắt có thể lập trình được (8 mức) Điện áp nguồn: 1.8 V đến 3.6 V (bình thường ở điện áp là 1.8 V (công suất thấp), 2.7 V đến 3.6 V (dùng khi lập trình/ xóa Flash))
Nhiệt độ hoạt động từ -20 o C đến 70 o C
• Trạng thỏi SLEEP tiờu biểu 1 àA
• Trạng thỏi HALT tiờu biểu 2.6 àA (bộ dao động thạch anh OSC1 32768
• Trạng thỏi chạy: tiờu biểu 17àA (bộ dao động thạch anh OSC1 32768 Hz, LCD tắt) 1950 àA (bộ dao động ceramic OSC3 8 MHz, LCD tắt)
Hình 3.6 - Sơ đồ khối của S1C17704 (nguồn Seiko Epson)
Vi xử lý S1C17704 được thiết kế đặc biệt cho ứng dụng đồng hồ với các chức năng hỗ trợ đồng hồ được tích hợp như stopwatch, mạch lái LCD …
GIẢI PHÁP, KIẾN TRÚC VÀ HIỆN THỰC HỆ THỐNG
Giải pháp
Mục tiêu của đề tài là xây dựng hệ điều hành thời gian thực cho ứng dụng đồng hồ trên vi xử lý S1C17704 của Seiko Epson với tiêu chí tiêu thụ năng lượng thấp Bên cạnh việc xây dựng các khối chức năng của hệ điều hành thời gian thực, bài toán đặt ra là tạo một cơ chế hoạt động cho các tác vụ sao cho tối ưu đối với ứng dụng đồng hồ và tiêu thụ năng lượng thấp Giải pháp cho việc tiêu thụ năng lượng thấp sẽ dựa trên việc quản lý năng lượng động với quá trình lập lịch phân cấp sử dụng xung đồng hồ hệ thống động (dynamic system tick)
Việc giảm năng lượng tiêu thụ của hệ thống được thực hiện qua các giải pháp sau:
• Hệ thống sẽ hoạt động ở chế độ tiêu thụ năng lượng thấp (low power mode) khi không còn tác vụ nào cần thực thi
• Giảm thời gian chạy của kernel bằng cách quản lý các tác vụ một cách hiệu quả: o Giảm thời gian quản lý tác vụ của Scheduler o Sử dụng xung đồng hồ hệ thống động (dynamic system tick) để kéo dài thời gian của CPU trong chế độ tiêu thụ năng lượng thấp (low power mode)
Do việc hiện thực việc đưa hệ thống vào hoạt động ở chế độ tiêu thụ năng lượng thấp tương đối đơn giản Phần này sẽ tập trung mô tả giải pháp để giảm thời gian chạy của kernel bằng cách quản lý các tác vụ tuần hoàn một cách hiệu quả
Hình 4.1 - Sự thực thi của CPU trong hệ thống thời gian thực
Việc quản lý các tác vụ sẽ do kernel đảm nhận hay chính xác hơn là Scheduler đảm nhận Qua quan sát tôi thấy có một số điểm sau:
• Nếu Scheduler quản lý tất cả các tác vụ tuần hoàn trong cùng một cấp thì Scheduler phải tốn thời gian duyệt qua tất cả các tác vụ đang chờ đến lần thực thi kế tiếp để quyết định xem tác vụ nào đã đến thời điểm thực thi kế tiếp và chuyển trạng thái của tác vụ để sẵn sàng cho việc thực thi Việc này làm tiêu tốn thời gian của CPU, đặc biệt khi số tác vụ này càng lớn thì thời gian quản lý tác vụ càng nhiều
• Khi xung đồng hồ hệ thống là cố định và thời gian lặp lại nhỏ hơn so với thời gian lặp lại nhỏ nhất của tác vụ, hệ thống phải liên tục thực thi mỗi khi có xung đồng hồ và kiểm tra xem có tác vụ nào sẵn sàng để thực thi hay không Điều này gây lãng phí và làm tăng năng lượng tiêu thụ của hệ thống
• Trong quá trình một hệ thống thời gian thực hoạt động, tập các tác vụ tại các thời điểm khác nhau có thể khác nhau Nhiều tác vụ chỉ tích cực (active) trong một khoảng thời gian hoạt động và sau đó sẽ bị khóa (inactive) cho đến khi chúng được kích hoạt lại bằng một sự kiện bên System tick Kernel time Task execution Low power mode time ngoài (ví dụ như tác vụ cập nhật màn hình của điện thoại di động sẽ bị khóa khi điện thoại ở chế độ chờ) Do đó nếu xung đồng hồ hệ thống là cố định sẽ làm tăng năng lượng tiêu thụ của hệ thống một cách không cần thiết
Dựa trên quan sát ở trên, một Scheduler phân cấp với xung đồng hồ hệ thống động được đề xuất Ý tưởng chính ở đây là việc sắp xếp các tác vụ tuần hoàn có cùng thời gian lặp vào cùng một mức tương ứng với thời gian lặp của một xung đồng hồ hệ thống và Scheduler sẽ chỉ làm việc với tất cả các tác vụ trong cùng một mức tại xung đồng hồ hệ thống tương ứng
Giải pháp cho Scheduler phân cấp được đề xuất ở trên bao gồm một hàng đợi phân cấp, một giải thuật cho việc quản lý các tác vụ trong hàng đợi phân cấp và một bộ điều khiển xung đồng hồ hệ thống
Hàng đợi tác vụ phân cấp sẽ lưu trữ các tác vụ ở trạng thái tích cực (active tasks) Các tác vụ có thời gian lặp lại giống nhau sẽ được lưu trữ trong cùng một mức Các tác vụ có thời gian lặp lại ngắn hơn sẽ ở trong mức có độ ưu tiên cao hơn
Hình 4.2 - Hàng đợi tác vụ phân cấp
Giải thuật cho việc quản lý các tác vụ trong hàng đợi phân cấp được thể hiện bằng đoạn mã giả sau:
// Li : ready task list level i
// Lm : main ready task list
Go to low power mode
If (T*i is blocked and Ti is empty) then disable system_ tick_ level_i
Việc chuyển chế độ hoạt động của CPU và bộ điều khiển xung đồng hồ hệ thống cũng được thể hiện trong đoạn mã giả trên Khi không còn bất kỳ tác vụ tích cực nào trong một mức, xung đồng hồ hệ thống tương ứng với mức này sẽ được tắt Để làm rõ hơn giải pháp này chúng ta hãy xét qua ví dụ sau: một hệ thống thời gian thực có 3 nhóm tác vụ T1, T2 và T3 với thời gian lặp tương ứng lần lượt là p, 2p và 4p Việc thực thi của hệ thống khi cả 3 nhóm tác vụ đều tích cực được mô tả trong hình 4.3
Hình 4.3 - Sự thực thi tác vụ của hệ thống khi T1, T2 và T3 đều tích cực
Nếu tất cả các tác vụ trong T1, T2 và T3 đều được quản lý trong cùng một hàng đợi chúng ta dễ dàng thấy rằng tại các thời điểm t = 3p và t = 7p chỉ có các tác vụ trong T1 sẵn sàng thực thi trong khi Scheduler phải duyệt qua các tác vụ trong T2 và T3 xem chúng đã sẵn sàng thực thi hay chưa Điều này gây lãng phí thời gian của CPU, làm giảm hiệu suất của hệ thống và tiêu tốn năng lượng Mặt khác khi T1 và T2 bị ngắt, sự thực thi của hệ thống sẽ như hình 4.4
Hình 4.4 - Sự thực thi tác vụ của hệ thống khi chỉ có T3 tích cực
Chúng ta thấy rằng tại các thời điểm t = p, 2p, 3p, 5p, 6p, 7p … hệ thống sẽ chạy trong chế độ kernel và không có tác vụ nào thực thi cả
Giả sử mỗi nhóm tác vụ T1, T2 và T3 có 3 tác vụ, áp dụng việc lưu trữ ba nhóm tác vụ trên vào hàng đợi phân cấp như hình 4.5
Hình 4.5 - Hàng đợi phân cấp cho 3 nhóm tác vụ T1, T2 và T3
Tại thời điểm t = 4mp (m=0,1,…), tất cả các tác vụ trong 3 mức đều được thực thi Tại thời điểm t = 2mp (m=1,2,…) Scheduler chỉ xem xét đến các tác vụ ở mức 1 và 2 Tại các thời điểm t khác, chỉ có các tác vụ trong mức 1 được xem xét Hình 4.6 cho ta thấy sự thực thi tác vụ của hệ thống khi mức 1 không tích cực (toàn bộ các tác vụ của T1 không tích cực)
Hình 4.6 - Sự thực thi tác vụ của hệ thống khi mức 1 không tích cực
Hình 4.7 cho thấy sự thực thi của tác vụ khi mức 1 và mức 2 không tích cực
Ví dụ trên cho ta thấy nếu chúng ta quản lý các tác vụ tuần hoàn theo giải pháp được đề nghị, hệ thống sẽ giảm thời gian chạy trong kernel và thời gian hệ thống hoạt động trong chế độ tiêu thụ năng lượng thấp sẽ dài hơn Điều này có nghĩa rằng năng lượng tiêu thụ của hệ thống sẽ được giảm xuống.
Kiến trúc hệ thống
Kiến trúc của hệ điều hành được mô tả trong hình 4.8
Hình 4.8 - Kiến trúc của hệ điều hành đề nghị
Lớp trên cùng trong kiến trúc là lớp ứng dụng, các ứng dụng sẽ giao tiếp với kernel thông qua các hàm API (Application Programming Interface) Nhân của hệ
Driver Hardware Access Layer điều hành gồm có Scheduler phân cấp (Hierarchical Scheduler), Hàng đợi tác vụ phân cấp (Hierarchical Task Queue), Hàng đợi tin nhắn (Messages Queue) dùng cho việc liên lạc giữ các tác vụ, Semaphore dùng để quản lý việc truy cập đến các tài nguyên, trình phục vụ ngắt (ISR) dùng để quản lý các ngắt và trình điều khiển thiết bị (Device driver) cho phép gắn các thiết bị ngoại vi vào hệ thống tài nguyên Lớp dưới cùng của kiến trúc là lớp giao tiếp phần cứng
Giao diện lập trình ứng dụng API (Application Programming Interface) cung cấp giao diện cho phép ứng dụng truy cập các dịch vụ trong kernel Trong hệ điều hành thời gian thực các hàm API thường cung cấp các dịch vụ sau:
• Các hàm API cho tác vụ
• Các hàm API cho các sự kiện (event)
• Các hàm API cho việc điều khiển hệ thống
• Các hàm API cho việc quản lý và sử dụng tài nguyên chia sẻ
• Các hàm API cho việc liên lạc giữa các tác vụ
4.2.2 Hàng đợi tác vụ phân cấp (Hierarchical Task Queue)
Hàng đợi tác vụ phân cấp sẽ lưu trữ các tác vụ ở trạng thái tích cực (active tasks) Các tác vụ có thời gian lặp lại giống nhau sẽ được lưu trữ trong cùng một mức Các tác vụ có thời gian lặp lại ngắn hơn sẽ ở trong mức có độ ưu tiên cao hơn
4.2.3 Scheduler phân cấp (Hierarchical Scheduler)
Scheduler phân cấp hoạt động dựa trên xung đồng hồ hệ thống động (dynamic system tick) và hàng đợi tác vụ phân cấp Mỗi cấp của hàng đợi tác vụ sẽ tương ứng với một xung đồng hồ hệ thống khác nhau Scheduler sẽ chỉ xem xét đến các tác vụ trong cùng một cấp khi có xung đồng hồ hệ thống tương ứng diễn ra Khi không còn tác vụ tích cực nào trong mức, xung đồng hồ hệ thống tương ứng với mức sẽ bị tắt ngắt xảy ra trong hệ thống ISR kết hợp với các module điều khiển tốc độ của CPU để tạo ra các xung đồng hồ hệ thống và tham gia một phần vào quá trình lập lịch của Scheduler
4.2.5 Lớp giao tiếp phần cứng (Hardware Access Layer)
Lớp giao tiếp phần cứng bao gồm các hàm giao tiếp phần cứng ở mức thấp có nhiệm vụ làm trung gian giao tiếp giữa phần cứng của CPU và các hàm API.
THỰC NGHIỆM VÀ ĐÁNH GIÁ
Phần mềm thử nghiệm
Hệ thống được thử nghiệm trên hệ điều hành thời gian thực với các tác vụ tiêu biểu cho phần mềm đồng hồ Bảng 5.1 mô tả chức năng và thời gian lặp của các tác vụ được sử dụng trong thử nghiệm:
Bảng 5.1 - Bảng mô tả các tác vụ thử nghiệm STT Tên tác vụ Chức năng của tác vụ Thời gian lặp
1 hello Hiển thị thông báo “Hello” sau khi hệ thống được bật 1s
3 menuMain Chọn lựa chế độ hoạt động 1s
4 clockMain Hiển thị thời gian 1s
5 clockSettingMain Điều chỉnh thời gian 1s
6 goOnclockData Cập nhật thời gian và kiểm tra giờ báo thức 1s
7 goOntimerData Cập nhật đồng hồ đếm ngược 1s
8 alarmMain Hiển thị và điều khiển đồng hồ báo thức 1s
9 alarmSettingMain Điều chỉnh thời gian báo thức 1s
10 alarmFlash Hiển thị biểu tượng khi đến giờ báo thức 0.5s
11 swtMain Điều khiển đồng hồ bấm giờ 1s
12 swt1HzData Cập nhật phần dữ liệu giây/phút/giờ của đồng hồ bấm giờ 1s
13 swtDisplay Hiển thị dữ liệu đồng hồ bấm giờ 31.25ms Các tác vụ được nêu trong bảng 5.1 đa phần được chỉnh sửa từ mã nguồn của ví dụ cho bo mạch SVT17701 từ nguồn của Seiko Epson
Phần mềm thử nghiệm được nạp vào bo mạch CPU SVT17704 thông qua bo mạch ICD Sau đó bo mạch CPU SVT17704 được cấp nguồn 3.3V (sử dụng 2 pin AA) và việc đo dòng tiêu thụ được thông qua một đồng hồ đo dòng Hình 5.1 mô tả việc đo dòng tiêu thụ của bo mạch khi thử nghiệm
Hình 5.1 – Đo dòng tiêu thụ của CPU trong thử nghiệm
Do bo mạch CPU SVT17704 có khá nhiều thiết bị ngoại vi đi kèm, việc đo dòng của CPU được thực hiện bằng cách đo dòng hoạt động của bo mạch khi CPU ở các chế độ hoạt động khác nhau và sau đó tính toán ra dòng tiêu thụ của CPU
Bảng 5.2 mô tả các chế độ thử nghiệm và số tác vụ tích cực trong mỗi chế độ hoạt động:
Bảng 5.2 - Bảng mô tả các chế độ thử nghiệm
KeyScan goOnclockData clockMain goOntimerData swt1HzData
KeyScan goOnclockData alarmMain goOntimerData swt1HzData
KeyScan goOnclockData timerMain goOntimerData swt1HzData
KeyScan goOnclockData swtMain goOntimerData swt1HzData swtDisplay
Hình 5.2 - Dòng tiêu thụ của CPU khi sử dụng hàng đợi phân cấp và xung đồng hồ hệ thống động 5.4.2 Kết quả trên hàng đợi một cấp và xung đồng hồ hệ thống cố định
Xung đồng hồ hệ thống cố định trong thử nghiệm này là 32.25 ms tương ứng với thời gian lặp nhỏ nhất của các tác vụ
Khi stopwatch chạy, để đảm bảo đáp ứng thời gian thực thì CPU chuyển sang xung clock 8 MHz và dòng tiêu thụ tăng lên khá nhiều so với thử nghiệm ở phần 5.4.1
Hình 5.3 - Dòng tiêu thụ của CPU khi sử dụng hàng đợi một cấp và xung đồng hồ hệ thống cố định 5.5 Đánh giá kết quả thử nghiệm
Kết quả thử nghiệm cho thấy hệ điều hành đáp ứng tốt về thời gian thực đối với ứng dụng đồng hồ Đồng thời dòng tiêu thụ của CPU là chấp nhận được đối với ứng dụng đồng hồ
So sánh kết quả khi hệ thống sử dụng hàng đợi phân cấp và xung đồng hồ hệ thống động, dòng tiêu thụ của CPU thấp hơn từ 17 ~66 % so với hàng đợi một cấp và xung đồng hồ hệ thống cố định khi hệ thống chạy ở xung clock 32768 Hz và cùng chế độ thử nghiệm Kết quả thử nghiệm này phù hợp với lý thuyết về việc sử dụng hàng đợi phân cấp và xung đồng hồ hệ thống động vì thời gian CPU chạy trong chế độ kernel sẽ giảm so với việc sử dụng hàng đợi một cấp và xung đồng hồ hệ thống cố định cải thiện đáng kể năng lượng tiêu thụ so với việc chỉ sử dụng hàng đợi không phân cấp và xung đồng hồ hệ thống cố định Kết quả thử nghiệm cho thấy dòng tiêu thụ giảm 17 ~ 66% khi sử dụng hàng đợi phân cấp và xung đồng hồ hệ thống động so với khi sử dụng hàng đợi một cấp và xung đồng hồ hệ thống cố định
Bên cạnh đó việc tạo ra một software platform cho các phần mềm đồng hồ cũng tạo ra những thuận lợi cho việc phát triển các phần mềm này
Tuy nhiên với kiến thức còn hạn chế và thời gian thực hiện đề tài còn hạn hẹp, có một số vấn đề cần phải được cải tiến để nâng cao hiệu suất của vi xử lý và tối ưu thời gian hệ thống (kernel time)
Với việc thử nghiệm thành công Scheduler sử dụng hàng đợi phân cấp và xung đồng hồ hệ thống động trên các tác vụ tuần hoàn, công việc kế tiếp là việc mở rộng hệ thống cho cả các tác vụ không tuần hoàn và mở rộng khung chương trình cho các ứng dụng nhúng khác bên cạnh ứng dụng phần mềm cho đồng hồ
Bên cạnh việc mở rộng hệ thống cho các tác vụ không tuần hoàn, việc nghiên cứu để tối ưu hóa việc sử dụng bộ nhớ on-chip cũng là một vấn đề cần phải giải quyết
PHỤ LỤC: BÀI BÁO KHOA HỌC
Một phần kết quả nghiên cứu của đề tài đã được đúc kết trong bài báo
“Dynamic Power Management for Periodic Tasks in Real-time Embedded Systems” được trình bày tại hội nghị “International Conference on Advanced Computing and Applications Ho Chi Minh City, October 19-21, 2011(ACOMP 2011)” Sau đó bài báo được chỉnh sửa và được đăng ở tạp chí KHOA HỌC VÀ CÔNG NGHỆ Vol 49, N o 4A, 2011.
Hướng phát triển
Với việc thử nghiệm thành công Scheduler sử dụng hàng đợi phân cấp và xung đồng hồ hệ thống động trên các tác vụ tuần hoàn, công việc kế tiếp là việc mở rộng hệ thống cho cả các tác vụ không tuần hoàn và mở rộng khung chương trình cho các ứng dụng nhúng khác bên cạnh ứng dụng phần mềm cho đồng hồ
Bên cạnh việc mở rộng hệ thống cho các tác vụ không tuần hoàn, việc nghiên cứu để tối ưu hóa việc sử dụng bộ nhớ on-chip cũng là một vấn đề cần phải giải quyết
PHỤ LỤC: BÀI BÁO KHOA HỌC
Một phần kết quả nghiên cứu của đề tài đã được đúc kết trong bài báo
“Dynamic Power Management for Periodic Tasks in Real-time Embedded Systems” được trình bày tại hội nghị “International Conference on Advanced Computing and Applications Ho Chi Minh City, October 19-21, 2011(ACOMP 2011)” Sau đó bài báo được chỉnh sửa và được đăng ở tạp chí KHOA HỌC VÀ CÔNG NGHỆ Vol 49, N o 4A, 2011.