Seluruh kebenaran tentang RTOS. Artikel # 32. Migrasi Nucleus SE: Fitur dan Kompatibilitas yang Tidak Direalisasikan

Persyaratan utama untuk pengembangan Nucleus SE adalah tingkat kompatibilitas yang tinggi dengan produk Mentor RTOS utama - Nucleus RTOS. Nucleus SE mendukung bagian tertentu dari fungsi Nucleus RTOS, yang telah dibahas berulang kali dalam artikel sebelumnya, tetapi dalam artikel ini saya akan mencoba untuk mengumpulkan semua perbedaan utama di satu tempat. Artikel ini dimaksudkan sebagai referensi cepat untuk semua orang yang akan beralih dari satu inti ke inti lain, atau sedang dalam proses memilih kernel untuk proyek tertentu.



Selain fungsionalitas yang terbatas atau disederhanakan, dibandingkan dengan Nucleus RTOS, Nucleus SE juga telah dirancang dengan penekanan pada memaksimalkan pemanfaatan memori dengan opsi penyesuaian yang luas. Bagian penting dari pendekatan ini adalah skalabilitas. Banyak fitur dari fungsionalitas kernel dapat diaktifkan atau dinonaktifkan seperlunya. Jelas, menonaktifkan fungsi dalam implementasi tertentu meningkatkan ketidakcocokannya dengan Nucleus RTOS.

Dalam Nucleus RTOS, sebuah sistem dapat dibuat dengan jumlah objek kernel yang tidak ditentukan; satu-satunya batasan di sini adalah jumlah sumber daya yang tersedia (mis. Memori). Nucleus SE memiliki batas enam belas objek dari setiap jenis; sistem dapat memiliki dari satu hingga enam belas tugas dan dari nol hingga enam belas objek dari setiap jenis (kotak surat, antrian, dll.). Terlepas dari kenyataan bahwa batas ini dapat ditingkatkan, upaya yang besar akan diperlukan, karena Nucleus SE memanfaatkan secara luas kemampuan untuk menyimpan indeks suatu objek dalam sebuah nibble (empat bit). Selain itu, dengan lebih dari enam belas tugas, Penjadwal Prioritas cenderung menjadi sangat tidak efisien. Aplikasi yang fungsinya secara serius menderita keterbatasan ini tidak cocok untuk Nucleus SE, dalam hal ini Nucleus RTOS adalah pilihan yang jauh lebih cocok.

Perencana

Seperti semua inti real-time modern, Nucleus RTOS memiliki penjadwal yang sangat fleksibel yang menyediakan beberapa tingkat prioritas (dengan jumlah tugas yang tidak ditentukan pada setiap tingkat prioritas), serta kemampuan untuk memilih penjadwal Round Robin dan Time Slice. Nucleus SE jauh lebih sederhana dan menawarkan empat penjadwal yang harus dipilih pada waktu membangun: Lari ke Penyelesaian, Round Robin, Time Slice, dan Priority. Tidak mungkin untuk menggabungkan penjadwal yang berbeda (yaitu, tidak ada penjadwal komposit). Misalnya, Anda tidak dapat memilih kombinasi Time Slice dan Priority schedulers. Selain itu, Penjadwal prioritas memungkinkan Anda untuk menetapkan hanya satu tugas untuk setiap tingkat prioritas, yaitu, ada tingkat prioritas sebanyak tugas. Prioritas tugas diatur selama pembuatan dan tidak berubah lagi (seperti slot waktu jika penjadwal Time Slice dipilih).

Panggilan API

Application Programming Interface (API) - "wajah" yang terlihat dari sistem operasi. Tidak mengherankan, di sinilah perbedaan antara Nucleus RTOS dan Nucleus SE paling jelas.

Nucleus SE API berbeda dari Nucleus RTOS API. Namun, Nucleus SE API telah dirancang dengan cermat sehingga dapat ditransfer ke fragmen Nucleus RTOS API. Pemegang Nucleus RTOS berlisensi bisa mendapatkan "shell" (file header yang berisi makro #define ) yang akan melakukan transfer hampir secara langsung.

Dari fakta bahwa Nucleus SE API dapat disebut “subset” dari Nucleus RTOS API, maka beberapa panggilan API hilang. Ini benar dan itu adalah hasil yang tak terhindarkan dari kriteria pengembangan Nucleus SE. Beberapa panggilan API tidak masuk akal, karena dikaitkan dengan fungsionalitas yang tidak ada, panggilan lain dikecualikan untuk menyederhanakan implementasi beberapa objek kernel. Semua ini dijelaskan secara rinci di bagian berikut artikel ini.

Fungsi API Umum

Nucleus RTOS memiliki fungsi API yang umum untuk beberapa jenis objek kernel, atau bahkan semua jenis objek. Beberapa dari mereka juga diimplementasikan dalam Nucleus SE, contoh yang baik dari fungsi tersebut diatur ulang. Fungsi lain tidak berlaku untuk implementasi objek kernel di Nucleus SE.

Buat dan hapus

Dalam Nucleus RTOS, semua objek kernel bersifat dinamis, mereka dibuat dan dihapus sesuai kebutuhan. Karena itu, ada panggilan API untuk ini. Di Nucleus SE, semua objek statis (dibuat selama perakitan), jadi panggilan API ini tidak diperlukan.

Mengembalikan pointer ke objek

Identifier utama (deskriptor) dari objek kernel di Nucleus RTOS adalah pointer ke blok kontrol objek, yang ditugaskan ketika objek dibuat. Oleh karena itu, ada juga satu set panggilan API yang mengembalikan daftar pointer ke objek dari setiap jenis. Karena Nucleus SE menggunakan indeks sederhana untuk mengidentifikasi objek kernel, panggilan seperti itu tidak perlu. Suatu program dapat mensurvei kernel untuk mengetahui berapa banyak instance objek dari tipe tertentu yang dikonfigurasi (menggunakan panggilan seperti NUSE_Mailbox_Count () ); jika nilai ini adalah n , indeks objek jenis ini akan memiliki nilai dari nol hingga n-1 .

Streaming data

Untuk beberapa jenis objek kernel Nucleus RTOS (seperti kotak surat, antrian, dan pipa), overhead API disediakan untuk menerjemahkan data. Ini memungkinkan Anda untuk mengirim data ke setiap tugas yang mengharapkan data dari objek. Kemungkinan ini dikecualikan dari Nucleus SE untuk penyederhanaan, karena akses ke data objek tersebut selalu dilakukan dalam konteks tugas tertentu, yang kemudian membebaskan objek. Oleh karena itu, untuk menerapkan terjemahan, diperlukan mekanisme bendera tambahan.

Fitur Unik Objek API

Banyak objek kernel memiliki panggilan API yang unik untuk jenis objek tertentu dan berbeda dalam Nucleus RTOS dan Nucleus SE.

Tugasnya

Karena Penjadwal Nucleus RTOS secara signifikan lebih kompleks daripada Nucleus SE, beberapa fungsi API tidak diperlukan:

• Mengubah posisi interupsi tugas - tidak didukung di Nucleus SE.
• Ubah prioritas tugas - Dalam Nucleus SE, prioritas tugas ditetapkan selama konfigurasi dan tidak dapat diubah.
• Mengubah slot waktu tugas - dalam Nucleus SE, nilai slot waktu adalah umum untuk semua tugas dan diatur selama konfigurasi.
• Penyelesaian Tugas - Nucleus SE tidak mendukung status tugas "selesai".

Memori dinamis

Karena semuanya dibuat secara statis di Nucleus SE, memori dinamis tidak didukung (dan tidak diperlukan). Karena itu, fungsi API terkait juga tidak diperlukan.

Sinyal

Nucleus RTOS mendukung penangan sinyal, program yang berjalan (seperti penangan interupsi) ketika sinyal tugas berubah. Fitur ini dikecualikan dari Nucleus SE, oleh karena itu, panggilan API untuk mengelola sinyal dan membuat penangan sinyal tidak diperlukan.

Gangguan

Nucleus SE menggunakan pendekatan non-interupsi interupsi, hanya menyediakan kemampuan untuk melakukan beberapa panggilan API dari interrupt handler. Oleh karena itu, beberapa panggilan Nucleus RTOS API yang menentukan bagaimana kernel seharusnya menangani interupsi tidak didukung.

Diagnostik

Nucleus SE memiliki layanan diagnostik yang sangat sederhana, mengikuti gaya pengembangan "terkendali", membatasi dirinya pada (opsional) parameter, memeriksa dan mengeluarkan kode versi produk. Oleh karena itu, panggilan Nucleus RTOS API yang terkait dengan pencatatan riwayat dan konfirmasi kesalahan tidak didukung.

Driver

Nucleus RTOS memiliki struktur driver formal yang terdefinisi dengan baik dan beberapa fungsi API yang terkait dengan manajemen driver. Nucleus SE tidak memiliki struktur ini, oleh karena itu, panggilan API yang sesuai tidak diperlukan.

Fungsi Panggilan API

Beberapa aspek fungsi Nucleus SE, yang diimplementasikan dalam bentuk yang disederhanakan, menyebabkan perbedaan dari Nucleus RTOS. Beberapa di antaranya memengaruhi cara panggilan API digunakan dan layanan tersedia.

Batas waktu

Saat menggunakan Nucleus RTOS, sering ada situasi ketika panggilan API dapat menjeda tugas yang menunggu untuk mengakses sumber daya: tugas tersebut diblokir. Penangguhan tugas semacam itu dapat bersifat implisit (yaitu, hingga sumber daya tersedia), atau nilai batas waktu dapat ditentukan. Nucleus SE menyediakan pemblokiran dengan panggilan API sebagai opsi, namun, hanya penangguhan tersirat yang dapat digunakan (yaitu, panggilan hanya dapat menggunakan NUSE_SUSPEND atau NUSE_NO_SUSPEND , bukan nilai batas waktu). Fitur ini cukup sederhana untuk ditambahkan ke Nucleus SE.

Prosedur Penangguhan

Ketika beberapa jenis objek dibuat di Nucleus RTOS, perintah penskorsan dapat ditetapkan. Ini adalah urutan di mana beberapa tugas yang diblokir akan dilanjutkan saat sumber daya tersedia. Tersedia dua opsi: FIFO, first-in-first-out (pertama-masuk-keluar-pertama), di mana tugas-tugas dilanjutkan dalam urutan yang sama di mana mereka diblokir; atau berdasarkan prioritas, di mana tugas dengan prioritas tertinggi selalu dilanjutkan terlebih dahulu. Nucleus SE tidak menawarkan pilihan seperti itu. Ini hanya mengimplementasikan urutan prioritas. Bahkan, lebih tepat untuk mengatakan urutan berdasarkan indeks tugas, karena urutan penangguhan dapat diterapkan tidak hanya ketika menggunakan penjadwal Prioritas, tetapi juga saat menggunakan penjadwal Round Robin dan Time Slice.

Fungsionalitas fitur unik

Dalam beberapa kasus, perubahan fungsional yang terkait dengan jenis objek tertentu diperlukan.

Penangan sinyal
Seperti disebutkan di atas, implementasi sinyal dalam Nucleus SE tidak mendukung prosedur pemrosesan sinyal.

Pengaturan Pengatur Waktu Aplikasi
Timer memiliki durasi awal / durasi operasi awal dan durasi restart dan secara opsional dapat melakukan fungsi yang ditentukan pengguna saat selesai. Fungsi ini didukung di Nucleus RTOS dan Nucleus SE. Namun, Nucleus SE, tidak seperti Nucleus RTOS, tidak memungkinkan untuk mengubah parameter yang dijelaskan di atas saat memanggil fungsi API untuk reset. Selain itu, dalam Nucleus SE, semua dukungan untuk prosedur penyelesaian timer adalah opsional.

Bendera acara
Nucleus RTOS memiliki opsi untuk "menyerap" bendera acara. Ini berarti bahwa bendera yang cocok dengan kriteria yang ditetapkan oleh tugas diatur ulang. Fungsionalitas tersebut tidak didukung di Nucleus SE, karena kemampuan untuk mencari kriteria dari beberapa tugas secara signifikan meningkatkan kompleksitas sistem.

Ukuran data

Dua kriteria pengembangan untuk Nucleus SE: mempertahankan kesederhanaan dan meminimalkan penggunaan memori, telah menyebabkan perbedaan tertentu dalam ukuran elemen data dibandingkan dengan Nucleus RTOS. Perlu dicatat bahwa Nucleus RTOS biasanya menggunakan data yang tidak ditandatangani , yang kemungkinan besar 32-bit. sementara Nucleus SE menggunakan tipe data yang disederhanakan seperti U32 , U16 , U8 dan sebagainya. ( Catatan Penerjemah: Menurut pendapat saya, penulis tepat untuk sistem 8-bit. Dalam sistem modern, register masih 32-bit, jadi memotong bagian yang lebih lama menghabiskan memori untuk kode dan siklus jam untuk pelaksanaannya, dan data semuanya sama dengan 32 bit saat disimpan dalam memori, jika tidak kinerja sistem akan turun, sehingga pendekatan ini tidak memberikan keuntungan untuk sistem modern, dan kerugian karena instruksi yang ditambahkan oleh kompiler yang memotong bagian yang lebih tua bisa sangat baik. ).

Kotak surat

Dalam Nucleus RTOS, kotak pesan menyimpan pesan yang terdiri dari empat elemen data yang tidak ditandatangani. Di Nucleus SE, kotak surat menyimpan item data ADDR . Menurut pendapat saya, kotak surat sering digunakan untuk mentransfer alamat (menunjukkan data spesifik) dari satu tugas ke tugas lainnya.

Antrian

Dalam Nucleus RTOS, antrian memproses pesan dari satu atau lebih elemen data yang tidak ditandatangani . Antrian juga dapat dikonfigurasi untuk menangani pesan panjang variabel. Di Nucleus SE, antrian memproses pesan yang terdiri dari item data ADDR tunggal. Menurut pendapat saya, antrian digunakan dengan cara yang sama dengan kotak surat. Selain itu, dalam Nucleus RTOS, ukuran total antrian (yaitu jumlah total elemen yang tidak ditandatangani yang dapat ditempatkan dalam antrian) ditentukan sebagai nilai yang tidak ditandatangani. Dalam Nucleus SE, nilai ini adalah dari tipe U8 . Oleh karena itu, antrian dapat menampung lebih sedikit data.

Saluran data

Dalam Nucleus RTOS, saluran memproses pesan dari satu atau lebih byte; Saluran juga dapat dikonfigurasi untuk menangani pesan panjang variabel. Dalam Nucleus SE, saluran memproses pesan yang terdiri dari satu atau lebih elemen data tipe U8 . Ukuran pesan diatur selama pengaturan untuk setiap saluran. Selain itu, dalam Nucleus RTOS, ukuran saluran total (yaitu, jumlah total byte yang dapat ditempatkan di suatu saluran) ditetapkan sebagai nilai yang tidak ditandai . Di Nucleus SE, nilai ini bertipe U8 dan mewakili jumlah pesan (dalam NUSE_Pipe_Information () panggilan API). Akibatnya, saluran dapat menyimpan lebih sedikit data.

Grup Bendera Acara

Dalam Nucleus RTOS, grup bendera acara berisi 32 bendera; di Nucleus SE, jumlahnya berkurang menjadi delapan. Ukuran ini telah dipilih karena kemungkinan target prosesor Nucleus SE dapat memproses data 8-bit secara efisien. Pada saat yang sama, mengubah jumlah bendera dalam kelompok acara bendera yang diproses oleh Nucleus SE tidak akan sulit.

Sinyal

Dalam Nucleus RTOS, setiap tugas memiliki satu set 32 ​​tanda sinyal. Dalam Nucleus SE, sinyal bersifat opsional, dan setiap tugas memiliki 8 flag. Ukuran ini telah dipilih karena kemungkinan target prosesor Nucleus SE dapat secara efisien memproses data 8-bit. Pada saat yang sama, mengubah jumlah flag di set flag sinyal yang diproses oleh Nucleus SE tidak akan sulit.

Bagian dari memori

Dalam Nucleus RTOS, jumlah dan ukuran partisi tidak ditandai . Dalam Nucleus SE, jumlah partisi adalah parameter tipe U8 , dan ukuran partisi adalah U16 . Ini mengarah ke beberapa batasan ukuran partisi dan kolam.

Pengatur waktu

Di Nucleus RTOS, timer (timer aplikasi dan timer tidur tugas) bekerja dengan nilai yang tidak ditandatangani . Dalam Nucleus SE, mereka adalah tipe U16 . Jenis ini dipilih karena target kemungkinan prosesor Nucleus SE dapat memproses data 16-bit secara efisien (dan delapan bit jelas tidak cukup untuk menggunakan timer). Pada saat yang sama, mengubah ukuran pengatur waktu di Nucleus SE tidak akan sulit.

Artikel berikut akan memeriksa bagaimana Nucleus SE dapat digunakan dalam proyek perangkat lunak tertanam.

Tentang Pengarang: Colin Walls telah bekerja di industri elektronik selama lebih dari tiga puluh tahun, mencurahkan sebagian besar waktunya untuk firmware. Dia sekarang adalah seorang insinyur firmware di Mentor Embedded (sebuah divisi dari Mentor Graphics). Colin Walls sering berbicara di konferensi dan seminar, penulis berbagai artikel teknis dan dua buku tentang firmware. Tinggal di Inggris. Blog profesional Colin , email: colin_walls@mentor.com.