Chúng ta có 4 lựa chọn chính khi xây dựng hệ thống nhúng. Đầu tiên, bạn có thể chọn bare metal, nghĩa là không dùng hệ điều hành (RTOS). Thứ hai, bạn có thể tự phát triển một hệ điều hành riêng ngay trong dự án, gọi là homebrewed RTOS. Thứ ba, bạn dùng một hệ điều hành mã nguồn mở (open source RTOS). Cuối cùng, bạn có thể chọn một RTOS thương mại (commercial RTOS).

1. Các trường hợp không cần dùng RTOS

Một ứng dụng sẽ không cần đến một hệ điều hành thời gian thực (RTOS) nếu nó khá đơn giản. Ứng dụng chỉ có vài tác vụ nhỏ và không cần lập lịch phức tạp. Các linh kiện có sẵn trên chip hoặc bo mạch như timer và interrupt đủ khả năng xử lý các yêu cầu thời gian thực. Ví dụ, chúng ta có thể dùng timer để nhấp nháy đèn LED. Hoặc dùng edge-triggered interrupt để phản hồi khi bạn nhấn nút.

Trong một số ứng dụng, chúng ta chỉ cần giám sát một vài tín hiệu bên ngoài. Số lượng hành động để đạt được kết quả mong muốn cũng rất ít. Nếu chúng ta dùng một scheduler phức tạp cho hệ thống này, mã nguồn sẽ trở nên khó đọc hơn. Ngoài ra, scheduler còn làm tăng kích thước tổng thể của code. Lúc này, việc chia nhỏ ứng dụng thành nhiều task riêng biệt sẽ không mang lại nhiều lợi ích. Nếu chúng ta muốn tái sử dụng code, tốt nhất nên thực hiện ở mức driver.

Khi chúng ta muốn triển khai một kịch bản phức tạp hơn, chúng ta có thể cần dùng đến biến toàn cục (global variables) để trao đổi dữ liệu. Chúng ta cũng có thể cần dùng máy trạng thái (state machines) và ngắt (interrupts). Việc linh hoạt trong xử lý các tác vụ sẽ giúp chúng ta tái sử dụng code dễ dàng hơn.

Tuy nhiên, khi xây dựng ứng dụng, chúng ta phải xem xét kỹ yêu cầu của từng tác vụ. Yêu cầu của một tác vụ có thể làm hạn chế tài nguyên mà tác vụ khác có thể dùng. Có rất nhiều ứng dụng có mức độ phức tạp trung bình, vì vậy chúng ta nên xác định rõ ràng và ổn định các yêu cầu. Khi đó, chúng ta sẽ biết cách tiếp cận này có phù hợp hay không. Việc này rất quan trọng với các kỹ sư để có thể làm việc hiệu quả hơn.

2. Các trường hợp cần dùng tới RTOS

Ở mức độ phức tạp tiếp theo, một ứng dụng có thể cần dùng nhiều thành phần phần cứng và giao thức phức tạp. Ví dụ như: USB, TCP/IP, embedded Ethernet, CAN bus, Wi-Fi và BLE. Thông thường, chúng ta phải kết hợp nhiều giao diện và giao thức này cùng lúc. Ví dụ, một nút (node) trong hệ thống ô tô có thể vừa dùng Ethernet có dây, vừa dùng CAN bus để giao tiếp với nhiều nút CAN khác.

Các lĩnh vực IoT (Internet of Things) và IIoT (Industrial Internet of Things) có rất nhiều ví dụ kiểu này. Ở đây, chúng ta cần hệ điều hành (OS) đủ mạnh, có nhiều thư viện phần mềm, hỗ trợ nhiều giao thức mạng, bảo mật và xử lý tín hiệu nâng cao. Nhờ vậy, bạn có thể phát triển ứng dụng mới nhanh hơn với phương pháp agile software development hiện đại.

Tuy nhiên, các hệ điều hành như Linux thường quá lớn, quá phức tạp và tiêu tốn nhiều tài nguyên cho những thiết bị nhúng. Vì vậy, các hệ điều hành nhẹ như AWS FreeRTOS, Azure RTOS ThreadX và Zephyr RTOS rất quan trọng. Trong số này, Zephyr RTOS là dự án open source thực sự. AWS FreeRTOS là FreeRTOS được Amazon mua lại và đổi tên. Azure RTOS ThreadX là ThreadX, sau khi Microsoft mua lại Express Logic – nhà phát triển ban đầu của ThreadX.

Bạn có thể xem mã nguồn của FreeRTOS và ThreadX miễn phí. Tuy nhiên, nếu muốn dùng thương mại thì vẫn có một số hạn chế nhất định.

3. Các công cụ cần thiết để học RTOS

Ở phần trước, chúng ta đã nói về lý do chọn Zephyr RTOS cho nhiều dự án thay vì AWS FreeRTOS hay Azure RTOS ThreadX. Chúng ta cũng đã tìm hiểu khi nào nên dùng RTOS để phát triển ứng dụng hệ thống nhúng và loại ứng dụng nào sẽ có lợi từ việc này.

Nhiều bộ vi xử lý ARM Cortex M0, M4, M7 và các bộ kit phát triển (development kit) do các hãng như STMicroelectronics, Microchip, Silabs, và NXP sản xuất. Hầu hết các bo mạch này đều được Zephyr OS framework hỗ trợ. Zephyr RTOS đã được chuyển sang các thiết bị ESP32 và RISC-V. Chúng ta có thể chạy các ví dụ trên nhiều loại bo mạch ESP32 và RISCV32 mà không cần thay đổi nhiều. Ngoài việc dùng môi trường phát triển tích hợp (IDE) như Microsoft VS Code, chúng ta hoàn toàn có thể phát triển và kiểm thử ứng dụng bằng các công cụ dòng lệnh (command-line interface - CLI) và trình soạn thảo văn bản để chỉnh sửa mã nguồn và file cấu hình.

Bộ công cụ phát triển phần mềm của Zephyr RTOS có một công cụ CLI hiệu quả tên là west. Bạn có thể dùng west để thực hiện quá trình build và nạp chương trình (code flashing). Khi xây dựng ứng dụng Zephyr, chúng ta sẽ sử dụng CMake. CMake rất mạnh, nhưng hơi khó học. Tuy nhiên, west sẽ giúp ẩn đi các chi tiết phức tạp của CMake. Trong VS Code IDE, bạn có thể chạy các lệnh west ngay trong cửa sổ terminal.

Các hệ điều hành thời gian thực (RTOS) khác nhau có thể dùng nhiều API (Application Programming Interface) khác nhau. Tuy nhiên, các thành phần cơ bản và cách hoạt động của chúng thường rất giống nhau. Khi bạn hiểu rõ các hành vi, mô hình, và cách sử dụng các đối tượng này, bạn sẽ dễ dàng xây dựng các ứng dụng nhúng đa nhiệm dùng RTOS. Kiến thức này cũng giúp chúng ta so sánh, đánh giá các hệ điều hành RTOS khác nhau và chuyển đổi ứng dụng từ RTOS này sang RTOS khác dễ dàng hơn.

Zephyr sử dụng OS abstraction layer (OSAL). OSAL là một lớp trung gian cung cấp các hàm wrapper API, giúp đóng gói nhiều chức năng hệ thống phổ biến mà hệ điều hành gốc cung cấp. Zephyr hỗ trợ hai OSAL chính là POSIX và CMSIS v2. Bạn có thể tìm thông tin chi tiết về các tính năng hỗ trợ và sự khác biệt giữa các API này trong tài liệu chính thức của Zephyr.