Seluruh kebenaran tentang RTOS. Artikel # 6. Layanan RTOS lainnya

Pada artikel sebelumnya, kami membahas fungsionalitas kernel dalam hal tugas yang dilakukan dan interaksi di antaranya. Pada artikel ini, kita melihat apa lagi yang dapat dilakukan kernel, yang sebagian besar dimanifestasikan dalam sejumlah panggilan API lain yang tersedia. Kami juga akan menjawab pertanyaan, apa yang mengubah kernel menjadi sistem operasi?

Artikel sebelumnya dalam seri:
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.

Manajemen tugas

Selain penjadwalan tugas dan interaksi di antara mereka, RTOS akan mencakup fungsionalitas (panggilan API) untuk mengelola tugas dengan berbagai cara. Mari kita pertimbangkan beberapa kemungkinan.

Buat dan hapus tugas

Dalam RTOS "dinamis" ada panggilan fungsi yang memungkinkan Anda untuk membuat tugas (dan objek RTOS lainnya) saat diperlukan. Panggilan semacam itu mencakup berbagai parameter yang menentukan tugas, misalnya, titik masuk, ukuran tumpukan, dan prioritas. Panggilan API penghapusan tugas terkait memungkinkan Anda membebaskan sumber daya setelah tugas selesai.

Dalam RTOS "statis", parameter yang menentukan tugas dikonfigurasikan dalam semacam file konfigurasi selama perakitan.

Jeda dan lanjutkan tugas

Seperti yang kita lihat, sebagian besar RTOS memiliki konsep tugas yang "ditangguhkan". Ini dapat dicapai dengan berbagai cara. Salah satunya adalah panggilan eksplisit ke fungsi Suspend Task API. Itu bisa disebabkan oleh dirinya sendiri atau tugas lain. Panggilan "Lanjutkan tugas" yang sesuai memungkinkan tugas untuk mengantri lagi untuk perencanaan.

Status tidur tugas

Untuk sistem waktu-nyata, kontrol waktu adalah persyaratan penting dan dapat mengambil berbagai bentuk. Pandangan sederhana adalah kemampuan tugas untuk "tertidur", yaitu tugas ditangguhkan untuk periode waktu tertentu. Ketika waktu habis, tugas "bangun" dan lagi-lagi mengantri untuk perencanaan. Panggilan API biasanya akan tersedia untuk tujuan ini. Tentu saja, fungsi ini tergantung pada ketersediaan pengatur waktu.

Pembebasan

Saat menggunakan penjadwal Round Robin ("carousel"), sebuah tugas dapat menolak untuk mengontrol prosesor untuk tugas selanjutnya dalam rantai. Untuk melakukan ini, fungsi API "Tugas rilis" akan tersedia. Tugas ini tidak ditangguhkan, itu akan tersedia untuk perencanaan ketika gilirannya tiba. Saat menggunakan penjadwal Time slice, ada kemungkinan bahwa suatu tugas dapat membebaskan sebagian dari interval waktunya jika tidak ada pekerjaan penting yang harus dilakukan segera. Melepaskan tugas tidak memiliki arti logis saat menjalankan Jalankan ke penyelesaian atau Penjadwal prioritas.

Penyelesaian tugas

Dalam artikel sebelumnya, kami menemukan bahwa selain status "Siap" atau "Ditangguhkan", RTOS dapat mendukung status tugas lainnya. Tugas dapat "Selesai", yang berarti bahwa fungsi utamanya baru saja tersisa: tidak ada panggilan API khusus yang diperlukan. Suatu tugas dapat "Dihentikan", yang berarti tidak tersedia untuk perencanaan dan harus diatur ulang agar tersedia untuk diluncurkan lagi, lihat "Mengatur ulang tugas" di bawah ini. Ini membutuhkan panggilan API khusus. Ketersediaan status tugas tambahan ini, terminologi yang digunakan, dan definisi pastinya akan berbeda tergantung pada RTOS.

Atur ulang tugas

Banyak RTOS menawarkan panggilan ke fungsi "Reset Task" API, yang memungkinkan Anda mengembalikan tugas ke kondisi semula. Dia mungkin dalam keadaan ditangguhkan dan membutuhkan fungsi "Lanjutkan tugas" untuk dieksekusi untuk mengantri untuk perencanaan.

Tugas Prioritas, dll.

Dalam RTOS "dinamis", panggilan API mungkin tersedia untuk mengonfigurasi beberapa parameter tugas pada saat dijalankan. Contohnya termasuk prioritas dan durasi interval waktu.

Informasi Sistem

Dalam RTOS, akan ada sejumlah panggilan API untuk memberikan sistem informasi tentang tugas tersebut, termasuk:
Informasi tentang tugas . Berapa banyak tugas dalam sistem, konfigurasi dan status saat ini.
Informasi tentang objek kernel lainnya. Berapa banyak objek dari masing-masing jenis dalam sistem, konfigurasi dan informasi tentang keadaan saat ini. Sebagai contoh:

• Berapa kapasitas antrian saat ini? Dapatkah saya menambahkan lebih banyak pesan?
• berapa banyak tugas yang ditangguhkan pada kotak surat tertentu?

Informasi tentang versi RTOS . Panggilan API dapat memberikan data serupa.

Alokasi memori

Dalam banyak aplikasi, penting bahwa program dapat secara dinamis menangkap beberapa memori ketika dibutuhkan, dan membebaskannya ketika tidak lagi diperlukan. Hal yang sama terjadi pada firmware. Namun, pendekatan konvensional rentan terhadap masalah yang tidak mungkin atau tidak nyaman dalam aplikasi desktop, tetapi mereka dapat menjadi bencana bagi sistem tertanam. Namun demikian, ada cara untuk mengimplementasikan layanan tersebut, bahkan dalam RTOS statis.

Masalah dengan fungsi malloc () dan gratis ()

Dalam program C desktop, suatu fungsi dapat memanggil malloc () , menunjukkan berapa banyak memori yang dibutuhkan, dan mendapatkan kembali sebuah pointer ke area penyimpanan. Menggunakan memori, itu dapat dibebaskan dengan menelepon gratis () . Memori dialokasikan dari area yang disebut heap. Masalah dengan pendekatan ini adalah bahwa dengan urutan panggilan yang tidak terkoordinasi untuk fungsi-fungsi ini, area tumpukan dapat dengan mudah menjadi terfragmentasi, dan kemudian alokasi memori akan gagal bahkan jika tersedia cukup memori, karena daerah yang berdekatan tidak cukup besar. Beberapa sistem (seperti Java dan Visual Basic) menggunakan skema pengumpulan sampah canggih untuk defragment. Masalahnya adalah bahwa skema ini dapat menyebabkan keterlambatan signifikan yang tidak dapat diprediksi dalam runtime dan kebutuhan untuk menggunakan pointer tidak langsung (yang tidak bekerja di C).

Jika malloc () dan free () diimplementasikan dengan cara reentrant (biasanya tidak) dan digunakan oleh tugas-tugas RTOS, fragmentasi akan terjadi dengan sangat cepat, dan kegagalan sistem hampir tidak terhindarkan. Di C ++, ada operator baru dan hapus yang umumnya melakukan fungsi yang sama seperti malloc () dan free (). Mereka tunduk pada batasan dan masalah yang sama.

Bagian dari memori

Untuk menyediakan sistem real-time dengan memori yang dapat diakses secara dinamis, pendekatan blok untuk manajemen memori dapat digunakan. Blok seperti itu biasa disebut "partisi"; partisi dapat dialokasikan dari "pool partisi".

Kolam partisi berisi sejumlah blok tertentu, yang masing-masing memiliki ukuran yang sama. Jumlah dan ukuran blok dalam partisi ditentukan ketika kumpulan partisi dibuat. Ini bisa dinamis jika sistem itu sendiri memungkinkannya, atau secara statis selama perakitan. Biasanya, aplikasi dapat menyertakan beberapa kumpulan partisi yang menawarkan blok dengan ukuran berbeda.

Jika tugas membutuhkan memori, ia memanggil API yang meminta blok dari kumpulan tertentu. Jika panggilan ini berhasil, tugas akan menerima pointer ke blok yang dipilih. Jika panggilan gagal karena tidak ada partisi yang tersedia di kumpulan yang ditunjukkan, tugas mungkin menerima respons kesalahan. Atau, tugas mungkin diblokir (ditangguhkan) sampai tugas lain melepaskan blokir di bagian.

Biasanya, tugas hanya melewati pointer ke blok memori dalam kode apa pun yang menggunakan blok tersebut. Ini mengarah ke masalah ketika blok tidak lagi diperlukan. Jika kode hanya memiliki pointer ke blok, bagaimana bisa memberitahu RTOS melalui panggilan API, dari kumpulan partisi mana yang ingin membebaskan memori? Jawabannya adalah bahwa sebagian besar RTOS mendukung data tambahan dalam blok khusus (biasanya offset negatif dari pointer) yang menyediakan informasi yang diperlukan. Jadi, untuk memanggil API untuk membebaskan blok, hanya alamatnya yang diperlukan.

Artikel berikut akan memiliki informasi lebih lanjut tentang partisi memori.

Waktu

Fungsionalitas yang terkait dengan penggunaan dan kontrol waktu kemungkinan akan tersedia di OS waktu nyata. Peluang akan bervariasi tergantung pada RTOS, tetapi kami akan mempertimbangkan yang tersedia untuk umum. Bagaimanapun, penghitung waktu-nyata adalah elemen yang sangat diperlukan untuk berfungsinya salah satu dari layanan ini.

Waktu sistem

Waktu sistem yang sederhana, atau "penghitung waktu jam", hampir selalu tersedia. Ini hanya penghitung (biasanya 32 bit), yang ditambahkan menggunakan rutin layanan interupsi waktu nyata dan dapat diatur dan dibaca melalui panggilan API.

Timeout Panggilan Layanan

Biasanya, RTOS memungkinkan pemblokiran panggilan API, yaitu, tugas panggilan ditunda (diblokir) sampai layanan yang diminta disediakan. Biasanya kunci ini tidak jelas, tetapi beberapa RTOS menawarkan batas waktu selama panggilan kembali ketika batas waktu berakhir jika layanan terus tidak tersedia. Waktu tunggu panggilan API tidak didukung oleh semua RTOS.

Status tidur tugas

Biasanya, tugas memiliki kemampuan untuk menjeda diri mereka sendiri untuk jangka waktu tertentu. Ini telah dibahas sebelumnya di bagian Manajemen Tugas.

Pengatur waktu perangkat lunak

Agar tugas-tugas program melakukan fungsi penghitungan waktu, sebagian besar RTOS menawarkan objek penghitung waktu. Ini adalah timer independen yang diperbarui oleh penangan interupsi timer waktu nyata, yang dapat dikontrol oleh panggilan API. Panggilan semacam itu mengonfigurasikan, memantau, dan memantau pengoperasian timer. Sebagai aturan, mereka dapat diatur untuk aktuasi tunggal atau restart otomatis. Rutin kedaluwarsa juga biasanya didukung, fungsi yang berjalan setiap kali timer menyelesaikan siklus. Artikel selanjutnya akan memberikan informasi lebih lanjut tentang penghitung waktu perangkat lunak dan deskripsi penerapannya.

Interupsi, Driver, dan I / O

Sejauh mana RTOS dikaitkan dengan interupsi dan I / O sangat berbeda. Demikian juga, beberapa RTOS memiliki struktur yang sangat jelas untuk driver perangkat, yang dapat menambah masalah ketika memilih produk tertentu.

Gangguan

Interupsi menghadirkan masalah bagi RTOS karena dua alasan.

• Tanpa tindakan pencegahan, interrupt handler (ISR) akan "mencuri" waktu prosesor, sehingga mengganggu perilaku RTOS real-time.
• Jika ISR membuat panggilan API yang memengaruhi penjadwalan tugas, ini harus dipantau, dan RTOS harus dapat menjalankan algoritme penjadwalannya.

Contoh panggilan API tersebut adalah prosedur untuk membangunkan tugas dengan prioritas lebih tinggi daripada yang diluncurkan saat interupsi terjadi.

Beberapa RTOS sepenuhnya mengontrol semua interupsi. Serangkaian panggilan API tersedia untuk "mendaftar" program ISR. Pendekatan ini memungkinkan penjadwal untuk menentukan kapan interupsi diaktifkan, dan memfasilitasi penggunaan sebagian besar panggilan API dari ISR.

Sebagai contoh, Nucleus RTOS mengimplementasikan konsep interrupt handler “prioritas rendah” dan “prioritas tinggi”, yang menyediakan manajemen interupsi yang andal tanpa overhead yang tidak perlu (yaitu, peningkatan penundaan interupsi).

RTOS lain dapat menggunakan mode “hands off” otomatis untuk interupsi, yang memberikan pengembang lebih banyak opsi untuk memastikan bahwa interrupt handler bekerja dengan benar. Sebagai aturan, awalan ISR tambahan (prolog) dan sufiks (epilog) disediakan untuk melindungi panggilan API yang dibuat di dalamnya.
Nucleus SE menggunakan rutin interupsi ringan, yang akan dijelaskan dalam artikel mendatang.

Driver

Sebagian besar RTOS menentukan struktur driver perangkat. Detail dapat bervariasi tergantung pada RTOS, tetapi driver biasanya terdiri dari dua komponen yang saling berinteraksi: kode tertanam (panggilan API) dan ISR. Biasanya, panggilan API lain akan tersedia untuk mengelola dan mendaftarkan driver.

Input / output

Saat ini, sebagian besar RTOS di pasaran tidak peduli dengan level input / output yang lebih tinggi, tetapi beberapa dari mereka mendefinisikan aliran input / output, yang pada dasarnya membangun koneksi antara driver perangkat yang sesuai dan fungsi bahasa C standar, seperti printf ().
Secara historis, RTOS sering mendukung "konsol", antarmuka pengguna ke RTOS melalui saluran serial. Ini terutama digunakan untuk diagnostik dan debugging. Menggunakan debugger modern yang mendukung aplikasi debugging dengan RTOS menghilangkan kebutuhan untuk objek tersebut.

Diagnostik

Biasanya, RTOS membutuhkan kinerja maksimum dengan jejak memori minimal. Karena itu, pemeriksaan integritas bukan prioritas tinggi. Dengan bantuan teknologi debugging modern yang memperhitungkan fitur-fitur RTOS, sebagian besar pemeriksaan dapat dilakukan di luar RTOS itu sendiri.

Memeriksa Parameter Panggilan API

Panggilan API dapat memiliki banyak parameter kompleks. Ini dapat menyebabkan kesalahan. Banyak RTOS menyediakan pemeriksaan parameter runtime dengan mengembalikan kode kesalahan jika parameter yang salah. Karena ini memerlukan kode tambahan, dan pemeriksaan itu sendiri mempengaruhi kinerja, lebih baik untuk memeriksa parameter selama perakitan atau konfigurasi.

Pemeriksaan tumpukan

Untuk sebagian besar jenis penjadwal (kecuali Jalankan ke Penyelesaian) setiap tugas memiliki tumpukan sendiri, yang ukurannya ditentukan secara individual. Dalam beberapa RTOS, kernel memiliki tumpukan yang terpisah, di yang lain, tumpukan tugas "dipinjam" selama panggilan API. Jelas, integritas tumpukan penting untuk keandalan sistem secara keseluruhan. Oleh karena itu, RTOS sering menawarkan alat untuk memeriksa integritas tumpukan saat runtime. Ada beberapa opsi:

• Panggilan API yang mengembalikan jumlah ruang stack untuk tugas saat ini atau yang ditentukan.
• Parameter pembatas tumpukan. Mereka diberi nilai unik (biasanya ganjil dan tidak nol), yang secara berkala diperiksa untuk penulisan ulang.

Diagnosis aplikasi

Terlepas dari kenyataan bahwa fungsi ini tidak secara langsung didukung dalam RTOS, tugas aplikasi dapat dialokasikan untuk memeriksa integritas seluruh sistem. Tugas semacam itu mungkin bertanggung jawab untuk mengatur ulang pengawas waktu. Suatu tugas dapat menerima data input berkala (misalnya, parameter sinyal) dari setiap tugas penting. Menyetel ulang pengawas waktu (yang akan mencegah sistem dari reboot) akan dilakukan hanya setelah data dari semua tugas telah tiba.

Layanan Non Kernel

RTOS lebih dari sekadar inti yang sejauh ini kami fokuskan. Sistem operasi desktop ini sangat berbeda dari RTOS yang disematkan. Biasanya, dalam OS desktop, semua komponen tambahan dibundel atau dapat diinstal (semua PC desktop memiliki antarmuka pengguna grafis, dan hanya beberapa dari mereka yang tidak memiliki akses jaringan). PC desktop tidak memiliki batas sumber daya nyata: selalu ada memori bebas, ruang hard disk, dan sumber daya CPU yang tidak digunakan. Dalam dunia sistem tertanam dengan sumber daya terbatas, komponen tambahan seperti kartu video, komponen jaringan, dan sistem file mungkin diperlukan, tetapi mereka harus diputuskan dan dapat diskalakan untuk meminimalkan jejak memori.

Fitur jaringan

Sebagian besar sistem embedded entah bagaimana terkait dengan jaringan. Dengan demikian, diharapkan ada minat yang signifikan dalam solusi jaringan untuk sistem embedded, karena ada sejumlah besar produk di pasar.

TCP / IP adalah protokol standar yang banyak digunakan dan merupakan pilihan yang jelas untuk banyak aplikasi. Biasanya, TCP / IP digunakan untuk protokol Ethernet (IEEE802.3), yang menyediakan kecepatan rata-rata 10 Mb / s. Saat ini, 100 Mb / s sangat umum, dan pada pendekatan 1 Gb / s. Selain itu, TCP / IP dapat digunakan untuk protokol lain. Misalnya, PPP (Point-to-Point Protocol) adalah implementasi TCP / IP untuk transfer data serial yang telah diadaptasi untuk koneksi internet broadband.

Sampai saat ini, versi v4 protokol IP (IPv4) digunakan. Namun, itu menjadi usang karena alamat gratis habis. Solusinya adalah IPv6, secara signifikan meningkatkan jumlah alamat yang mungkin dan menyediakan alat yang lebih efisien untuk pemeliharaan dan keamanan. IPv6 tersedia secara luas dan digunakan dalam peralatan di banyak negara, serta sistem militer di seluruh dunia.
Alternatif adalah User Datagram Protocol (UDP). Protokol ini digunakan untuk kinerja maksimum. UDP tidak memberikan keandalan dan konsistensi yang sama dengan TCP, tetapi ringan dan sangat efisien.

USB adalah Universal Serial Bus, banyak digunakan dalam perangkat untuk menghubungkan ke komputer desktop. Ini menyediakan antarmuka plug-and-play yang sangat mudah digunakan yang menyembunyikan perangkat lunak yang cukup canggih.Perangkat tertanam yang harus terhubung ke PC harus diimplementasikan sebagai fungsi USB, yang memerlukan komponen perangkat lunak tertentu. Jika perangkat harus mengelola perangkat lain yang terhubung melalui USB (seperti PC biasa), perangkat ini memerlukan perangkat lunak jenis host.

IEEE1394 adalah standar antarmuka serial lain yang digunakan untuk dengan cepat mentransfer sejumlah besar data antar perangkat (misalnya, untuk mentransmisikan data video), juga dikenal sebagai FireWire dan i.Link.

Protokol nirkabel - kenyamanan dan prevalensi berbagai teknologi nirkabel di antara konsumen telah menyebabkan permintaan tinggi untuk kemampuan nirkabel pada perangkat yang disematkan. Wi-Fi (standar IEEE802.11) menyediakan serangkaian kemampuan jaringan yang lengkap, memungkinkan Anda untuk mengimplementasikan topologi rekan dan infrastruktur pada jarak yang cukup. Ketertarikan terhadap keamanan data di jaringan tersebut semakin meningkat, yang berarti bahwa ini akan mempengaruhi perangkat lunak. Teknologi radio lainnya, terutama Bluetooth dan ZigBee, menyediakan komunikasi nirkabel point-to-point jarak pendek.

Verifikasi protokol

Karena peluang jaringan sangat diminati, ada banyak pemasok yang menawarkan solusi mereka. Pelanggan menghadapi tantangan untuk memeriksa kualitas produk yang tersedia. Berbeda dengan kernel RTOS, pemeriksaan lengkap fungsi dan kinerja stack protokol bukanlah tugas yang mudah. Untungnya, toolkit tersedia untuk memeriksa protokol (meskipun dengan harga yang signifikan), dan pembeli potensial dapat mencari tahu dari pemasok yang ditetapkan mereka periksa.

Grafik

Antarmuka grafis menjadi lebih umum di antara perangkat yang tertanam. Ini bisa berupa LCD monokromatik kecil yang sangat sederhana (seperti pada ponsel lama, pemutar MP3, alarm, dll.). Di sisi lain, penerima televisi digital dapat memiliki layar HDTV resolusi tinggi sendiri. Layar seperti itu membutuhkan dukungan perangkat lunak yang sepenuhnya terintegrasi ke dalam kernel RTOS.
Karena layar biasanya memiliki beberapa jenis perangkat input, dukungan untuk perangkat tersebut sering termasuk dalam paket grafis. Paket semacam itu dapat mendukung perangkat penunjuk (misalnya, mouse), layar sentuh, keypad, dan keyboard lengkap.
Grafik dapat digunakan dengan berbagai cara. Itu hanya dapat memberikan output informasi (misalnya, seperti papan skor elektronik). Atau tampilan dapat menjadi bagian dari antarmuka pengguna grafis bersama dengan menu, jendela, ikon, dan elemen serupa. Dalam kasus apa pun, perangkat lunak yang agak spesifik diperlukan, dan paket grafis yang disertakan dengan RTOS harus memberikan fleksibilitas yang diperlukan tanpa secara signifikan meningkatkan jumlah memori yang digunakan.

Sistem file

Ketika aplikasi yang disematkan perlu menyimpan dan memproses sejumlah besar data, jelas bahwa masuk akal untuk mengatur data ini menjadi semacam sistem file. Data dapat dalam RAM, dalam memori flash bawaan, pada USB flash drive, pada hard disk biasa, atau pada disk optik (CD-ROM atau DVD-ROM). Sekali lagi, kesempatan seperti itu harus memiliki dukungan perangkat lunak yang sepenuhnya terintegrasi ke dalam RTOS. Sistem file harus dirancang dengan hati-hati untuk memenuhi persyaratan reentrant dari sistem multi-tasking.

Kepatuhan sangat penting untuk sistem file. Sebagai contoh, penggunaan format disk yang kompatibel dengan MS-DOS memungkinkan pengembang untuk menggunakan arsitektur yang sudah mapan dan menawarkan pertukaran data lengkap dengan sistem desktop.