Kích hoạt và bỏ kích hoạt tác vụ (Activation and Deactivation of Tasks)

Một phần của tài liệu Phân tích, thiết kế phần mềm nhúng (Trang 52)

Tasks)

Những tác vụ dưới RTOS có thể ở trạng thái sẵn sàng hoặc không sẵn sàng. RTOS nắm giữ một danh sách các tác vụ ở trạng thái sẵn sàng và quyền ưu tiên thực hiện của chúng. Một tác vụ sẵn sàng sẽ được thêm vào danh sách tác vụ và thực hiện chúng theo thứ tự. Khi một tác vụ ở trạng thái không sẵn sàng, nó sẽ được xoá khỏi danh sách. Một tác vụ sẵn sàng có thể bị ngăn chặn hoạt động bởi vì nó bị khoá hoạt động do một nguyên nhân nào đó. Một tác vụ khi được gán quyền điều khiển nó có thể thực hiện đến khi hoàn thành hoặc đến khi không thể thực hiện tiếp được nữa.

3.1.3 Lập lịch hƣớng sự kiện (Event-Driven Scheduling)

Vấn đề thêm và loại bỏ tác vụ từ danh sách tác vụ được dựa trên việc thay đổi các tình huống gọi là lập lịch hướng sự kiện. Trong hệ thống hướng sự kiện, ưu tiên, một sự kiện được xem như là một ngắt hoặc một tác vụ có thể xác định những tác vụ khác cần được kích hoạt. Ví dụ nó có thể thực hiện điều này bằng cách thiết lập một semaphore hoặc đặt dữ liệu vào trong một mailbox. Tác vụ mà được thiết lập kích hoạt từ trước bởi RTOS khi sự kiện này xảy ra, sẽ được kích hoạt nếu nó có mức ưu tiên cao hơn tác vụ hiện thời. RTOS có thể kích hoạt một tác vụ khi một semaphore được đặt hay một thông điệp được chuyển đến, chỉ khi nó được thiết lập từ trước. Trong một hệ thống dựa trên RTOS, những hàm dịch vụ ngắt (ISR) thường nhận điều khiển thông qua RTOS do đó một hàm dịch vụ ngắt có thể không cần đặt semaphore để bắt đầu một tác vụ. Thay vào đó, RTOS có thể lập lịch tác vụ dựa trên sự kích hoạt của ngay bản thân ISR.

Một lưu ý cuối cùng về lập lịch: Cả hai hệ thống lập lịch tuần tự và lập lịch ưu tiên đều cho phép một tác vụ thực thi cho đến khi kết thúc. Điểm khác biệt là trong hệ thống ưu tiên, một tác vụ thực hiện cho đến khi kết thúc hoặc bị chiếm quyền ưu tiên. Giữa hai tác vụ sẵn sàng có mức ưu tiên khác nhau, tác vụ có mức ưu tiên cao hơn luôn được ưu tiên so với tác vụ có mức ưu tiên thấp hơn và kết thúc trước. Nếu hai tác vụ có cùng mức ưu tiên và đều sẵn sàng tại một thời điểm thì một RTOS phức tạp thường kích hoạt tác vụ có thời gian thực hiện lâu hơn. RTOS chỉ biết được những tác vụ đã được tạo. Mã cho những tác vụ khác có thể nằm trong bộ nhớ nhưng RTOS không thấy chúng cho đến khi chúng được tạo.

3.2 Theo dõi các tác vụ

RTOS theo dõi dấu vết của các tác vụ bằng khối điều khiển tác vụ (TCB). Đây là nơi RTOS lưu các thông tin về tác vụ. Một mục TCB được tạo ra cho tất cả các tác vụ được quản lý bởi RTOS. TBC lưu trữ những thông tin như sau: số hiệu tác vụ (task ID), trạng thái của tác vụ (task state), mức ưu tiên (task priority), địa chỉ tác vụ (task address), con trỏ ngăn xếp tác vụ (task stack pointer).

Ngăn xếp tác vụ là ngăn xếp bộ vi xử lý. Khi một tác vụ có quyền điều khiển, con trỏ ngăn xếp bộ vi xử lý sẽ được sửa đổi để trỏ tới ngăn xếp cho tác vụ đó. Từng tác vụ phải được gán đủ bộ nhớ để lưu ngữ cảnh bộ xử lý, các biến và thông tin cần thiết. Khi một tác vụ dừng thực hiện vì một lý do nào đó, RTOS sẽ lưu con trỏ ngăn xếp tác vụ vào trong TCB. Và khi tác vụ đó sẵn sàng chạy lại, RTOS sẽ phải lấy con trỏ ngăn xếp đó ra từ TCB, bỏ những giá trị đó vào con trỏ ngăn xếp bộ xử lý và trả quyền điều khiển cho tác vụ.

Tuỳ thuộc vào từng RTOS, TCB có thể chứa thêm những thông tin như về môi trường cho tác vụ …Ngoài ngăn xếp cho tác vụ, RTOS cũng có những ngăn xếp cho chính bản thân RTOS sử dụng.

3.3 Truyền thông giữa các tác vụ

Trong hệ thống có sử dụng RTOS, dữ liệu thường được chuyển qua RTOS. Nó có thể hỗ trợ những dịch vụ semaphore, bộ đệm, hàng đợi và mailbox để truyền thông giữa các tác vụ.

Semaphore cung cấp cơ cấu chia sẻ dữ liệu được sử dụng trong hầu hết các nhân của hệ điều hành đa nhiệm. Những tác dụng của semaphore là: điều khiển việc truy cập tới tài nguyên chia sẻ, phát tín hiệu khi sự kiện xuất hiện và cho phép hai tác vụ đồng bộ hoạt động. Một semaphore đơn giản là một giá trị không âm. Khi một tác vụ sử dụng tài nguyên, nó cần semaphore như khoá để truy cập tài nguyên. Khi sử dụng tài nguyên, tác vụ đó làm cho giá trị của semaphore giảm đi 1. Khi không sử dụng nữa, semaphore lại được tăng lên 1. Các tác vụ khác nếu cố tình muốn giảm semaphore xuống giá trị nhỏ hơn 0 thì sẽ bị khoá lại và đặt vào hàng đợi semaphore. Semaphore được cài đặt ba toán tử trong hệ điều hành là: INITIALIZE, WAIT, và SIGNAL. Sự khác biệt trong hệ thống RTOS là tất cả truy cập tới semaphore đều được truyền thông qua RTOS.

Một bộ đệm RTOS giống như bộ đệm FIFO nhưng do RTOS quản lý. Khi một tác vụ A cần chuyển dữ liệu nó sẽ yêu cầu một bộ đệm từ RTOS, bỏ dữ liệu vào trong đó và thông báo với RTOS chuyển đến tác vụ B. Tác vụ B nhận được con trỏ trỏ tới bộ đệm, con trỏ này xác định vị trí bộ đệm trong bộ nhớ và dung lượng dữ liệu của nó.

Một hàng đợi là một chuỗi các bộ đệm. tác vụ A có thể đặt một thông điệp vào bộ đệm và chuyển bộ đệm đó cho tác vụ B. Tác vụ B có thể bận khi thông điệp gửi đi kế tiếp đã sẵn sàng, lúc đó tác vụ A sẽ đề nghị RTOS đặt thông điệp kế tiếp này vào hàng đợi, nơi mà tác vụ B sẽ xử lý lần lượt theo thứ tự.

Trong cấu trúc mailbox, thông thường một tác vụ nhận thông điệp từ vài tác vụ khác. RTOS quản lý mailbox, lưu giữ thông điệp cho một tác vụ cho đến khi tác vụ đó sẵn sàng đọc thông điệp. Giống như mailbox ngoài thực tế, khi một tác vụ đã gửi thông điệp thì nó không thể lấy lại được. Tuỳ thuộc vào RTOS, một tác vụ có thể kiểm tra mailbox và đợi mail khi không có. Hình 3.4 tóm tắt cơ chế truyền thông trong RTOS. Ở ví dụ đầu tiên (bộ đệm RTOS), Tiến trình A chuyển dữ liệu cho tiến trình B thông qua một bộ đệm. Ở ví dụ thứ 2 (hàng đợi RTOS), Tiến trình A đổ đầy dữ liệu vào các bộ đệm (hàng đợi) 1, 2 và đang đổ dữ liệu vào bộ đệm 3. Tiến trình B đang lấy dữ liệu từ bộ đệm 1. Ở ví dụ thứ 3 trong hình 3.4 là một RTOS mailbox. Các tiến trình A, B và C đang đưa dữ liệu vào một mailbox chung cho tiến trình D. Từng thông điệp của mỗi tiến trình sẽ được lưu một cách riêng biệt. RTOS thông thường cho phép tiến trình gửi gán các mức ưu tiên cho thông điệp gửi đi.

Một tác vụ có thể sẵn sàng thực thi sau khi có một sự kiện xảy ra hoặc có thể được lập lịch bắt đầu thực thi muộn hơn. Nó cũng có thể được lập lịch thực thi khi một semaphore được đặt, một khoảng thời gian nhất định đã trôi qua hoặc thực thi tác vụ vào một thời điểm xác định trong ngày.

3.4 Quản lý bộ nhớ

RTOS thường cấp phát bộ nhớ dưới dạng các khối, vùng nhớ liên tục có kích thước nhỏ nhất. Ví dụ nếu kích thước của khối là 1K, một tác vụ cần một bộ đệm 14 byte cũng phải yêu cầu một khối và nhận được khối 1K bộ nhớ gán cho nó. Việc xác định kích thước khối nhớ cũng rất quan trọng trong thiết kế hệ thống. Một tác vụ cần nhiều khối nhớ thường cần bộ nhớ liên tục, do đó RTOS có nhiệm vụ đi tìm những khối nhớ liên tục đủ dung lượng yêu cầu. Nếu khối nhớ quá nhỏ bộ nhớ có thể bị phân mảnh do khi giải phóng khối nhớ không thực hiện theo thứ tự liên tục, ngược lại nếu khối nhớ quá lớn sẽ gây ra lãng phí không cần thiết vì có ít khối nhớ đạt yêu cầu bộ nhớ của tất cả các tác vụ. Hình 3.5 sẽ minh hoạ cả hai vấn đề này. Trong nửa bên trái của hình, khi các khối bộ nhớ quá nhỏ, bộ nhớ sẽ bị phân mảnh. Tác vụ 1 được gán ba khối nhớ sau đó giải phóng hai khối, tác vụ 2 cũng như vậy, tác vụ 3 được gán bốn khối nhớ, tác vụ 4 có hai khối. Bây giờ nếu tác vụ thứ 5 cần 3 khối liên tiếp thì sẽ gặp vấn đề. Các khối 1,2,5,7,8,13 và 16 đều chưa cấp phát nhưng không thể tìm được ba khối nhớ trống liên tiếp. Nên tác vụ 5 không có đủ bộ nhớ để thực hiện. Phần còn lại của hình 3.5 thể hiện vấn đề ngược lại khi các khối nhớ quá lớn. Các tác vụ từ 1 tới 4 đều được gán một khối nhớ mặc dù những tác vụ này chỉ cần rất ít bộ nhớ trong phần được cấp phát và tác vụ 5 cũng không còn bộ nhớ để thực thi.

3.5 Quản lý tài nguyên

Tài nguyên là bất kỳ thực thể nào được sử dụng bởi các tác vụ. Tài nguyên có thể là thiết bị I/O như máy in, bàn phím, bộ nhớ,…Bộ định thời cũng là một loại tài nguyên, RTOS có thể cung cấp các bộ định thời hệ thống được thực hiện trong phần mềm và đếm tích tắc thời gian. Tài nguyên chia sẻ có thể được sử dụng bởi nhiều tác vụ, điều này đòi hỏi phải có kế hoạch chia sẻ tài nguyên sao cho đảm bảo vấn đề đồng bộ hoá dữ liệu giữa các tác vụ. RTOS có trách nhiệm quản lý các tài nguyên hiệu quả và tránh xung đột giữa các tác vụ khi sử dụng tài nguyên ví dụ như dùng semaphore, gán quyền thực hiện.

Hình 3.5 Các khối bộ nhớ được gán trong RTOS

3.6 RTOS và ngắt

Ngắt bắt đầu với các tín hiệu từ phần cứng, hầu hết các chip vào ra điều khiển cổng tuần tự hoặc giao tiếp mạng cần sự chú ý của CPU lúc có một sự kiện xảy ra. Khi một ngắt xuất hiện, bộ xử lý sẽ xử lý ngắt đó, lưu lại địa chỉ trả về và điều khiển hàm dịch vụ ngắt. Giả sử khi một tác vụ đang thực thi thì ngắt xuất hiện, địa chỉ trả về được lưu vào ngăn xếp của tác vụ. Một RTOS thường có những dịch vụ nhân đặc biệt cho ngắt. Khi hàm dịch vụ ngắt có quyền điều khiển nó có thể thực hiện những dịch vụ đặc biệt này. RTOS thường cung cấp ít nhất ba loại dịch vụ cho ISR. Dịch vụ đầu tiên, mục vào của ngắt cho phép hàm dịch vụ ngắt thông báo cho RTOS biết là ngắt đã xảy ra. Hàm mục vào ngắt có thể lưu lại ngữ cảnh của bộ xử lý hoặc những thông tin khác được cung cấp bởi các nhà sản xuất RTOS. Dịch vụ ISR thứ hai là để yêu cầu đặt một semaphore. Dịch vụ thứ ba là một lời gọi thoát khỏi dịch vụ, nó sẽ thông báo cho RTOS biết khi thủ tục ngắt hoàn thành nhiệm vụ.

phép sự trở lại. Ví dụ nếu một ngắt xảy ra trong khi RTOS đang thực hiện và ISR cố gắng sử dụng chức năng RTOS đang thực hiện thì sẽ sinh ra lỗi.

Khi ISR thoát (thông qua RTOS), RTOS có thể thực hiện việc chuyển tác vụ, dành quyền điều khiển cho tác vụ khác có mức ưu tiên cao hơn tác vụ mà đã bị ngắt.

3.7 Liên lạc trong RTOS thông dụng

Các RTOS thì khác nhau, nhưng trong phần này sẽ liệt kê danh sách các dịch vụ RTOS thông dụng cần thiết cho việc giao tiếp (với tên mang tính đặc tả):

 Define_Task: Xác định một tác vụ được thực hiện. Những tham số thông

thường được truyền cho RTOS có thể bao gồm số hiệu tác vụ, mức ưu tiên và địa chỉ mục vào của tác vụ

 Activate_Task: Yêu cầu kích hoạt một tác vụ. Những tham số được truyền cho

RTOS bao gồm cả số hiệu tác vụ.

 Deactivate_Task: Bỏ kích hoạt tác vụ. Tham số bao gồm số hiệu tác vụ.

 Yield: Thông báo cho RTOS biết tác vụ đã thực hiện xong và tác vụ khác trong

danh sách có thể được thực thi.

 Define_Timeslice: Xác định khoảng thời gian giữa các time-slice mà tác vụ

được phép thực thi.

 Allocate_Memory: Yêu cầu một một lượng khối nhớ xác định.

 Mailbox_In: Nhận được một thông điệp vào mailbox. Tham số bao gồm số hiệu

tác vụ và số hiệu mailbox.

 Send_Mail: Gửi mail tới một mailbox. Tham số có thể bao gồm số hiệu

mailbox, số hiệu tác vụ đích và mức ưu tiên của thông điệp.

 Wait_On: Đợi cho đến khi hàng đợi có thông điệp, semaphore được thiết lập,

hoặc mailbox nhận được thư.

3.8 Khả năng sử dụng RTOS

Một RTOS không phải phù hợp với mọi ứng dụng. RTOS có thể không là một giải pháp tốt nếu thiết bị phải thực hiện những ngắt ở tốc độ rất cao như trong hệ thống điều khiển động cơ mức thấp hoặc khi hệ thống đơn giản không cần đến các chức năng phức tạp của RTOS. Trong hệ thống mà bộ xử lý càng gần với việc điều khiển phần cứng mức bit thì càng ít nhu cầu sử dụng RTOS trong hệ thống.

Một RTOS thường được sử dụng khi hệ thống cần đến tài nguyên chia sẻ, cần phân bổ bộ nhớ. Nói chung trong những hệ thống phức tạp nhưng các tác vụ có thể được lập lịch trong khoảng thời gian của bộ định thời (tích tắc) thì dùng RTOS có thể có ý nghĩa. Thậm chí trong những hệ thống đơn giản, một RTOS có thể được sử dụng để cấu trúc sự hoạt động của mã. RTOS cũng hữu dụng khi chúng ta cần sử dụng những tài nguyên cơ bản (ổ đĩa, màn hình hiển thị, …).

RTOS thường được sử dụng khi các tác vụ được lập lịch tuần tự không thể đảm bảo được những công việc có mức ưu tiên cao nhất sẽ được thực hiện trước. Sử dụng

lập lịch ưu tiên, RTOS có thể đảm bảo những chức năng quan trọng sẽ được thực hiện đúng giờ.

Hầu hết RTOS đều có khả năng cấu hình được, chúng ta bắt đầu với hạt nhân cơ bản và thêm những đặc trưng cần thiết cho hệ thống của mình. Nếu hệ thống có sử dụng các ổ đĩa, giao tiếp mạng, chúng ta có thể thêm mô-đun bao gồm các driver và mô-đun TCP/IP của RTOS.

Khi cân nhắc sử dụng một RTOS, hãy xem xét cả đến chi phí của nó. Một số RTOS có phí mua một lần, trong khi những cái khác có cả phí cho mỗi sản phẩm sản xuất ra. Chúng ta có thể trả phí bản quyền theo cách: trả mức phí cơ bản cho nhân hệ điều hành và trả thêm phí cho mỗi mô-đun thêm vào.

Sự phân chia giữa một RTOS và nhân là không rõ ràng. Nói chung một nhân thì nhỏ hơn so với RTOS tương ứng và nó không cung cấp đầy đủ các đặc trưng của RTOS đầy đủ. Phần nhân có thể cung cấp các chức năng lập lịch và quản lý phù hợp với những hệ thống nhúng nhỏ.

Sử dụng RTOS cũng đồng nghĩa với tốn kém bộ nhớ hơn do từng tác vụ đều có ngăn xếp riêng của nó. Một số RTOS được liên kết vào mã chương trình, trong khi những cái khác lại hoạt động giống như hệ điều hành của PC. RTOS được nạp từ một thiết bị lưu trữ và chương trình của chúng ta thực thi như là một ứng dụng. Việc lựa chọn RTOS nào có thể ảnh hưởng lớn đến các thiết bị phần cứng vì cần phải có những tài nguyên cơ bản mà RTOS đó yêu cầu.

Các chuẩn truyền thông cũng rất quan trọng. Nhiều RTOS bây giờ hỗ trợ TCP/IP. Nếu sử dụng một chuẩn giao tiếp như vậy chúng ta có thể liên lạc với bất kỳ

Một phần của tài liệu Phân tích, thiết kế phần mềm nhúng (Trang 52)

Tải bản đầy đủ (PDF)

(84 trang)