🌱 RTOS 01. Giới thiệu về hệ điều hành RTOS - Real-time Operating System
Khác với các ứng dụng trên di động, máy tính, hay trên Server, các ứng dụng phát triển trên các thiết bị điện tử - nhúng có các yêu cầu khắt khe hơn về mặt hiệu suất và tài nguyên.
- Về tài nguyên, các ứng dụng nhúng thường có kích thước nhỏ gọn, sử dụng ít tài nguyên hơn (Chip ít core hơn, bộ nhớ nhỏ hơn, thiết bị hỗ trợ ít hơn, ...)
- Về hiệu suất, các ứng dụng nhúng thường nhỏ và nhẹ hơn, nhưng đổi lại, yêu cầu đáp ứng nhanh hơn với các sự kiện quan trọng (Ví dụ các ứng dụng chơi game trên máy tính có thể đôi lúc giật lag, nhưng một phần mềm phát hiện va chạm trên xe để mở túi khí thì không được phép có độ trễ lớn).
Chính vì vậy, nếu trên máy tính sử dụng các hệ điều hành lớn như Windows, thì trên vi điều khiển cần một hệ điều hành nhỏ gọn và chuyên dụng hơn để quản lý tài nguyên và đảm bảo hai yêu cầu trên về mặt tài nguyên và hiệu suất! Trong bài viết này chúng ta sẽ cùng tìm hiểu về khái niệm RTOS và tại sao cần sử dụng nó?
👉 Các nội dung chính
- Đặt vấn đề
- Vậy RTOS là gì?
- Một số RTOS phổ biến
- So sánh với hệ điều hành thông thường
- Phân loại RTOS
👉 Đặt vấn đề
Với những ứng dụng vi điều khiển thông thường, chúng ta đã quen với việc dùng kỹ thuật polling (tức là chạy liên tục trong vòng while(1). Nếu có một sự kiện quan trọng cần thực thi, ta sẽ dùng Interrupt để thực hiện ngay lập tức. Nhưng với những hệ thống có số lượng sự kiện quá nhiều, có quá nhiều tác vụ cần xử lý, thì chúng ta cần xem xét lại với cách xử lý polling + ngắt.
➥ Đọc thêm bài viết: Các kỹ thuật thiết kế luồng xử lý trong chương trình nhúng
Mình lấy một ví dụ đơn giản như sau. Một vi điều khiển cần làm những công việc sau:
- Blink LED với chu kỳ 1s.
- Đọc cảm biến khí gas để cảnh báo nguy hiểm khi cần.
- Đọc nút bấm để điều chỉnh chu kỳ nháy led.
➤ Vậy mình sẽ viết chương trình theo thứ tự như sau:
Nhìn vào cách làm trên thì việc đọc cảm biến và cảnh báo có thể bị lỡ, do việc đọc diễn ra 1 lần / 1s. Có thể dẫn đến nguy hiểm. Ở đây mình mới chỉ sử dụng 3 task. Trong các hệ thống lớn số lượng task sẽ lớn hơn rất nhiều, và lượng task cần đảm bảo hoạt động đúng thời gian cho phép (ảnh hưởng đến an toàn người dùng) là rất nhiều.
Lập trình vi điều khiển theo cách polling + interrupt thông thường đang không đáp ứng được những yêu cầu đề ra, dẫn đến cần một cơ chế để giúp nó thực hiện cách task đúng thời gian người dùng quy định.
Mặt khác, khi cần mở rộng bài toán, chẳng hạn cần thêm một con cảm biến, thêm một giao thức truyền thông, nếu sử dụng ngắt, thì số lượng ngắt sẽ lớn, có thể ảnh hưởng đến hoạt động của các tác vụ cũ.
➤ Từ đó, người ta bắt đầu thiết kế sử dụng OS để quản lý tài nguyên của hệ thống hiệu quả hơn, cũng như dễ dàng mở rộng các ứng dụng. Và đó là lý do RTOS ra đời.
👉 Vậy RTOS là gì?
RTOS - viết tắt của Real-time Operating System hay hệ điều hành thời gian thực, sử dụng trong những ứng dụng yêu cầu thời gian đáp ứng nhanh, chính xác về thời gian. Hai chữ "Real-time" hay "thời gian thực" mang ý nghĩa là thời gian đáp ứng nhanh, đúng như người dùng mong muốn (khác với từ "ngay lập tức").
➥ Ví dụ người dùng muốn hệ thống thực hiện nếu đo được khí gas bị rò thì sẽ gửi cảnh báo sau không quá 0,5s. Thì việc hệ thống đáp ứng sau 0,1s hay 0,4s đều là real-time cả.
 |
| RTOS Concepts |
Trong khi ngay cả nếu người dùng muốn cảnh báo sau không quá 10s, thì việc hệ thống đáp ứng sau 9s, mặc dù con số này khá lớn (coi như là khá chậm) thì vẫn là đáp ứng thời gian thực real-time 😅
👉 Một số RTOS phổ biến
Thực tế thì RTOS chỉ nói về ý tưởng xây dựng các mô hình OS real-time cho các ứng dụng nhúng, các hãng / công ty / nhà phát triển đã xây dựng nhiều mô hình RTOS khác nhau. Dưới đây là một số RTOS phổ biến và mình đã tìm hiểu được:
➤ freeRTOS
Một RTOS quá quen thuộc với các lập trình viên nhúng và vi điều khiển STM32, freeRTOS là một RTOS mã nguồn mở, hiện đang tiếp tục được phát triển bởi AWS. Ưu điểm của freeRTOS là kích thước khá nhỏ gọn (vài KB), hỗ trợ nhiều thuật toán lập lịch, và dễ dàng porting sang các dòng vi điều khiển lõi ARM, AVR, RISC-V.
➥ Trang chủ freeRTOS: https://www.freertos.org/
➤ RTX (Keil RTX/MDK-RTOS)
RTX là RTOS được ARM phát triển và tích hợp vào MDK-ARM (Keil). RTX là mã nguồn đóng của ARM nên chủ yếu phát triển để tương thích với vi điều khiển lõi ARM, phần mềm Keil và bộ thư viện CMSIS.
Ưu điểm của RTX là hỗ trợ thread-safe cho các thư viện tiêu chuẩn của C, và các tính năng nâng cao dành cho các ứng dụng công nghiệp đặc thù.
➥ RTX Keil
➤ ThreadX (Azure RTOS)
ThreadX là một RTOS được phát triển bởi Express Logic, hiện thuộc Microsoft.
Điểm nổi bật của ThreadX là hiệu suất cao, thời gian chuyển đổi ngữ cảnh rất nhanh (dưới 1 micro giây), hỗ trợ tốt cho giao thức IoT, tích hợp Microsoft Azure IoT.
➤ VxWorks
VxWorks được phát triển bởi Wind River, VxWorks là RTOS thương mại lâu đời nhất. Ưu điểm nổi bật của VxWorks là độ bảo mật cao, thích hợp cho các ứng dụng quân sự và hàng không, Tương thích với nhiều kiến trúc CPU (x86, ARM, PowerPC, MIPS, RISC-V).
➥ VxWorks WindRiver➤ Zephyr RTOS
Zephyr RTOS được phát triển bởi Linux Foundation, là một RTOS mã nguồn mở tập trung vào các ứng dụng IoT. Một số đặc điểm nổi bật của Zephyr:
- Hỗ trợ nhiều kiến trúc (x86, ARM, RISC-V, ARC, Nios II...).
- Cung cấp giao thức mạng tích hợp như MQTT, CoAP.
- Hệ thống cấu hình linh hoạt với Kconfig và công cụ Device Tree.
- Tích hợp bảo mật mạnh mẽ, sử dụng các thư viện mã hóa như TinyCrypt.
Chính vì vậy, Zephyr được hỗ trợ bởi cộng đồng lớn và nhiều công ty lớn (Intel, Nordic, NXP).
➤ TinyOS
TinyOS được phát triển bởi UC Berkeley, tập trung vào các hệ thống mạng cảm biến (sensor network).
TinyOS thiết kế theo dạng component-based, dễ dàng tùy chỉnh, sử dụng ngôn ngữ lập trình riêng (NesC) và hỗ trợ tốt các hệ thống cảm biến năng lượng thấp.
➥ TinyOS
➤ OSEK (Autosar OS)
OSEK (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug - Open Systems and their Interfaces for the Electronics in Motor Vehicles) là một tiêu chuẩn dành cho hệ điều hành RTOS trong ngành công nghiệp ô tô, Autosar OS là một RTOS follow theo chuẩn OSEK. Mục tiêu của OSEK là giảm chi phí phát triển, tăng khả năng tái sử dụng mã nguồn và đảm bảo khả năng tương thích giữa các thành phần phần mềm từ các OEM khác nhau.
Một số đặc điểm của OSEK:
- Statically configured (Cấu hình tĩnh): Tất cả các task, tài nguyên và cơ chế đồng bộ được cấu hình tĩnh trước khi chương trình chạy, giảm chi phí xử lý động.
- Kiến trúc nhỏ gọn: Phù hợp với các hệ thống tài nguyên hạn chế như vi điều khiển trên xe hơi.
- Không phụ thuộc vào phần cứng: Có thể hoạt động trên nhiều nền tảng CPU.
➥ OSEK
Tổng kết lại chút:
👉 So sánh với hệ điều hành thông thường
RTOS khác với các hệ điều hành thông thường trong máy tính như window hay linux. Với hệ điều hành thông thường, khi bạn mở ứng dụng lên thì sẽ có nhiều lúc bạn phải chờ khá lâu, hoặc đôi khi ứng dụng lỗi thì chúng ta chỉ cần đóng process rồi chạy lại. Việc chờ đợi như vậy hầu như không ảnh hưởng gì nhiều lắm, chỉ làm người dùng hơi khó chịu thôi.
Trong khi đó, RTOS được thiết kế ra cho các nhiệm vụ đặc biệt. Các ứng dụng cần được thực thi với thời gian thật chính xác đặt trước, các lỗi phát sinh cần được cô lập và xử lý nhanh chóng. Mọi sự chậm trễ, lỗi phát sinh không lường trước có thể gây lỗi hệ thống, nặng hơn là gây hậu quả nghiêm trọng.
Với bộ tài nguyên khá nhỏ của mình, các hệ nhúng (vi điều khiển) sẽ cố gắng thực hiện một số chức năng chính: tối ưu tối đa số luồng, bộ lập lịch và các tác vụ (task). Với việc chỉ có một core, nên việc chạy song song các task là không thể. RTOS sẽ có tính năng lập lịch, để việc thực thi các task gần như là song song, và các task sẽ không cần phải đợi quá lâu để được thực thi.
👉 Phân loại RTOS
Có thể chia RTOS làm 2 loại dựa vào độ trễ:
- Hard Real-time: Hệ thống phải thực hiện task trong khoảng thời gian quy định một cách chính xác, việc không tuân thủ thời gian quy định có thể dẫn đến hậu quả nghiêm trọng.
Ví dụ: Túi khí trên ô tô cần bật lên trong khoảng thời gian nhỏ hơn 0,1s từ khi cảm biến phát hiện xe xảy ra va chạm nguy hiểm. Thì việc hệ thống không đáp ứng thời gian này có thể gây tai nạn nghiêm trọng cho người trên xe. Do đó, task đọc cảm biến và điều khiển túi khí phải yêu cầu là Hard Real-time. - Soft Real-Time: Có thể không cần đáp ứng gắt gao về mặt thời gian như Hard Real-time, việc đôi khi vị trễ thời gian với các task này có thể không gây ra hậu quả nghiêm trọng.
Chẳng hạn, việc bấm nút thì đèn sáng sau không quá 0,5s. Thì việc bị trễ 1 chút cũng sẽ không ảnh hưởng quá nhiều. - Có thể nhiều cách phân loại sẽ thêm Firm Real-time nằm giữa 2 loại trên.
Với hai đặc điểm trên, có thể thấy Hard Real-time yêu cầu gắt gao về mặt thời gian hơn, nên giá thành (về mặt phần cứng và phần mềm) để thực hiện nó cũng sẽ đắt đỏ hơn.
hay anh ơi
Trả lờiXóaThank e đã ủng hộ
XóaKhông có QNX hả anh
Trả lờiXóaĐể anh bổ sung nha :D
Xóa