Seluruh kebenaran tentang RTOS. Artikel # 8. Nucleus SE: Desain dan Penyebaran Internal

Artikel ini melanjutkan ulasan tentang Nucleus SE.

Layanan

Nucleus SE menyediakan satu set alat yang dapat diharapkan dari RTOS apa pun.
Pertama, Nucleus SE berisi penjadwal yang cukup sederhana, namun, berkat empat opsi yang tersedia, ia menyediakan fleksibilitas. Penjadwal mendukung algoritma Run to Completion, Round Robin, Carousel, Time Slice, dan Priority.

Nucleus SE API mencakup sekitar 50 panggilan utilitas yang memberikan pengembang akses ke manajemen tugas, bagian memori, sinyal, grup bendera acara, semaphore, kotak surat, antrian, saluran pipa, waktu sistem, pengatur waktu aplikasi, dan diagnostik.

Selain penjadwalan tugas sederhana, Nucleus SE (opsional) mendukung jeda tugas. Fungsi ini bisa "bersih" (misalnya, sebagai hasil dari panggilan API layanan penskorsan yang ditetapkan secara eksplisit), itu bisa berupa fungsi "tidur" (ketika tugas ditangguhkan untuk periode waktu tertentu), atau itu bisa merupakan hasil dari panggilan API lain di mana tugas diblokir (yang disebut suspensi "kondisional"), menunggu akses ke sumber kernel. Tidak seperti Nucleus RTOS, Nucleus SE tidak mendukung batas waktu saat memblokir panggilan API.

Berbagai mekanisme yang disajikan memungkinkan Anda untuk memilih dari hierarki sarana sinkronisasi dan komunikasi antar-tugas: dari semafor ke sinyal, bendera acara, kotak surat, dan antrian / jalur pipa.

Artikel sebelumnya dalam seri:
Artikel # 7. Nucleus SE: Pendahuluan
Artikel # 6. Layanan RTOS lainnya
Artikel # 5. Interaksi tugas dan sinkronisasi
Artikel # 4. Tugas, pengalihan konteks, dan interupsi
Artikel # 3. Tugas dan Perencanaan
Artikel # 2. RTOS: Struktur dan mode waktu-nyata
Artikel # 1. RTOS: pengantar.

Verifikasi parameter

Saat memilih konfigurasi NUSE_API_PARAMETER_CHECKING , kode untuk memverifikasi parameter disertakan dalam semua fungsi API: memeriksa null pointer, indeks objek, dll. Karena ini adalah kode tambahan yang memerlukan memori tambahan, akan lebih bijaksana untuk mengaktifkan fungsi ini selama debugging, tetapi matikan di rakitan rilis.

Konfigurasi

Nucleus SE memiliki struktur yang fleksibel, yang memberi kita dua poin positif. Di satu sisi, kernel dapat memiliki konfigurasi berbutir halus yang memenuhi tugas-tugas aplikasi tertentu karena konfigurasi sederhana dari fungsionalitas yang tersedia dan pengelolaan penggunaan memori yang sederhana. Di sisi lain, kode Nucleus SE mudah dibawa-bawa antara kedua alat dan di antara prosesor.

Konvensi penamaan

Karena kejelasan dan kemudahan pemahaman adalah penting ketika mengembangkan Nucleus SE, konvensi penamaan dipikirkan dengan cermat. Setiap karakter dalam kode diawali dengan NUSE_. Segala sesuatu yang mengikuti awalan ini mematuhi seperangkat aturan sederhana.

Panggilan API

Setiap fungsi panggilan API di Nucleus SE dimulai dengan NUSE_, yang hampir selalu diikuti oleh tipe objek, diikuti oleh operasi case campuran, dipisahkan oleh garis bawah. Contohnya adalah fungsi NUSE_Queue_Send () , yang mengantri pesan.

Fungsi dan variabel lainnya

Sisa fungsi dan variabel (global) dalam kode Nucleus SE juga menggunakan awalan NUSE_, tetapi sisa nama tidak selalu memiliki "struktur". Ini tidak penting untuk rata-rata pengguna kernel, karena ia akan memiliki cukup fungsi API.

Simbol konfigurasi

Karena Nucleus SE dikonfigurasikan dengan karakter #define, mereka juga mematuhi konvensi penamaan. Mereka hanya ditulis dalam huruf besar. Nama-nama aktivator panggilan API adalah sama dengan nama-nama fungsi dan juga ditulis dalam huruf besar, misalnya, NUSE_QUEUE_SEND.

Karakter #define lainnya

Karakter #define lainnya (misalnya, parameter panggilan API dan nilai status pengembalian) yang dapat digunakan oleh kode aplikasi mematuhi aturan yang sama, mereka mulai dengan NUSE_ dan ditulis dalam huruf besar. Misalnya, NUSE_SUCCESS.

Struktur data

Semua RTOS memiliki seperangkat struktur data yang menggambarkan objek kernel. Dalam sebagian besar implementasi, mereka adalah struktur data dalam C yang membentuk daftar tertaut, seringkali dengan komunikasi dua arah dan bahkan melingkar. Ini logis, karena data penting dirangkum dengan mudah, dan item daftar dapat ditambahkan atau dihapus ketika objek dibuat dan dihapus.

Dalam Nucleus SE, semua objek bersifat statis, jadi mengatur semua struktur data objek ini ke dalam daftar sederhana adalah solusi yang jelas. Ini mengurangi volume dan kompleksitas pointer maju dan mundur. Namun, saya memutuskan untuk memperkuat optimisasi sistem dan menolak menggunakan struktur sama sekali. Dalam Nucleus SE, semua data dari objek kernel diwakili oleh beberapa array sederhana (juga disebut tabel) dari berbagai jenis, satu atau lebih untuk setiap jenis objek. Ada beberapa argumen yang mendukung keputusan ini:

• Nucleus SE dirancang dengan kompatibilitas dengan struktur 8-bit. Sebagian besar CPU kecil tidak memiliki alat yang optimal untuk mengimplementasikan struktur data dalam kompiler C. Array sederhana jauh lebih efisien.
• Karena jumlah maksimum objek yang diperbolehkan dari setiap jenis adalah 16, dan mengakses elemen dari setiap array memerlukan empat bit, satu byte sering digunakan. Ini lebih efisien daripada alamat, yang biasanya membutuhkan 16 atau 32 bit.
• Data objek permanen harus disimpan dalam ROM dan tidak disalin ke RAM. Karena struktur tidak dapat dibagi antara ROM dan RAM (dalam C portabel portabel), setiap jenis objek dapat memiliki dua struktur, yang terlalu kompleks. Dalam Nucleus SE, tabel deskripsi objek dapat ditemukan di ROM dan RAM, seperti yang diperlukan.
• Karena tingginya konfigurasi Nucleus SE ("skalabilitas ultra-tinggi"), beberapa data uraian objek mungkin opsional, tergantung pada alat yang dipilih. Hal ini menyebabkan penggunaan kompilasi bersyarat yang meluas. Definisi struktural dengan arahan kompilasi bersyarat bawaan sangat sulit untuk dipahami. Mengontrol instantiasi array individual menggunakan metode ini, pada gilirannya, cukup mudah dimengerti.

Semua tabel data objek tunduk pada konvensi penamaan hirarkis yang disebutkan di atas. Dengan demikian, cukup mudah untuk memahami tabel mana yang terkait secara logis.

Perbedaan utama dari RTOS Inti

Meskipun Nucleus SE dirancang dengan tingkat kompatibilitas yang tinggi dengan Nucleus RTOS, beberapa perbedaan kecil dan lebih besar tidak dapat dihindari. Mereka akan dijelaskan secara rinci dalam artikel yang relevan, dan deskripsi singkat diberikan di bawah ini.

Data Objek

Dalam Nucleus RTOS, objek dibuat dan dihapus berdasarkan permintaan. Dalam Nucleus SE, semua objek dibuat secara statis dan ditentukan selama perakitan.

Jumlah objek

Nucleus RTOS mendukung jumlah objek yang tidak terbatas untuk setiap jenis. Nucleus SE mendukung maksimal enam belas objek dari setiap jenis.

Nama objek

Nucleus RTOS memungkinkan Anda untuk menetapkan jenis teks ke beberapa jenis objek yang dapat digunakan untuk debugging. Nucleus SE tidak memiliki fitur ini.

Mekanisme penguncian tugas

Mekanisme untuk memblokir tugas dengan panggilan API di Nucleus SE cukup sederhana. Ketika sumber daya dilepaskan, semua tugas yang tertunda dilanjutkan dan bersaing satu sama lain (menggunakan penjadwal tugas) untuk sumber daya. Tugas yang hilang ditangguhkan lagi (diblokir). Dalam Nucleus RTOS, mekanismenya lebih kompleks, hanya tugas-tugas penting yang berlanjut di dalamnya, yang lebih efektif.

Batas Waktu Panggilan API

Saat memanggil API pemblokiran, Nucleus RTOS memungkinkan pengembang untuk menentukan periode waktu habis setelah mana panggilan akan dilanjutkan bahkan jika sumber daya tidak dirilis. Nucleus SE tidak memiliki fitur ini.

Penjadwalan tugas

Penjadwal Nucleus RTOS fleksibel, efisien, dan terdefinisi dengan baik. Nucleus SE menawarkan serangkaian penjadwal, yang masing-masing sederhana dan cukup efektif untuk mengurangi jumlah tugas yang didukung: dari 1 menjadi 16.

Prioritas tugas

Suatu sistem yang menggunakan Nucleus RTOS dapat memiliki jumlah tugas yang arbitrer yang dapat ditetapkan salah satu dari 256 tingkat prioritas, sementara beberapa tugas dapat memiliki satu tingkat prioritas. Level prioritas tugas juga dapat berubah pada saat dijalankan. Dalam Nucleus SE, jika penjadwal prioritas dipilih, setiap tugas harus memiliki tingkat prioritas unik yang tidak dapat diubah secara dinamis. Hanya ada satu tingkat prioritas per tugas.

Penanganan interupsi

Nucleus RTOS mendukung arsitektur canggih penangan interupsi dua tingkat yang memungkinkan penangan interupsi yang efisien dan interoperabilitas layanan kernel. Nucleus SE menggunakan pendekatan serupa yang mendukung penangan interupsi non-kernel sederhana (interupsi tidak dikelola) dan penangan interupsi sadar konteks sepenuhnya yang dapat menggunakan panggilan API (interupsi terkelola).

Driver perangkat

Nucleus RTOS memiliki arsitektur driver perangkat yang dirancang dengan baik. Nucleus SE tidak memiliki arsitektur seperti itu, meninggalkan pengembang dengan tugas mendistribusikan kontrol perangkat antara tugas dan kode pengendali interupsi.

Distribusi Inti SE

Kode sumber Nucleus SE akan dipublikasikan saat seri artikel ini dikembangkan. File yang tersedia akan tersedia berdasarkan permintaan melalui email. Menjelang akhir seri artikel, repositori akan dibuat untuk mengunduh semua file yang diterbitkan.