Seluruh kebenaran tentang RTOS dari Colin Walls

Seluruh kebenaran tentang RTOS. Artikel # 1.

Sistem Operasi Real-Time: Pendahuluan

Seri artikel ini dikhususkan untuk studi menyeluruh tentang semua aspek sistem operasi waktu nyata (RTOS). Artikel ini ditujukan untuk pengembang yang ingin mengetahui cara kerja RTOS dan cara menggunakannya. Titik awal akan menjadi diskusi tentang sistem real-time secara umum, dan kemudian kita akan berbicara tentang bagaimana RTOS dapat menyederhanakan implementasi mereka dan membuat kode yang dihasilkan lebih dapat diandalkan.

Melihat ke dalam RTOS, kita akan melihat cara kerja penjadwal tugas. Berkat multithreading, tampaknya CPU melakukan beberapa operasi pada saat bersamaan. Ini bukan sihir, pemahaman tentang prinsip-prinsip penjadwal tugas tersedia bahkan untuk insinyur perangkat lunak yang tidak berpengalaman. Kita akan berbicara tentang objek lain dari RTOS: tentang interaksi antara tugas dan sinkronisasi, tentang mode waktu nyata, tentang manajemen memori, dll., Semuanya akan dijelaskan secara akurat dan didukung oleh contoh kode.

Untuk pengembang, aspek kunci RTOS adalah API, serangkaian panggilan prosedur yang menyediakan akses ke fungsionalitas RTOS. Seri ini akan menampilkan artikel tentang bagaimana API bekerja, standar apa yang tersedia, dan bagaimana cara berpindah dari satu API ke yang lain.

Di bawah ini adalah daftar topik yang akan kami pertimbangkan dalam waktu dekat:

• Struktur program dan waktu nyata
• Sistem operasi waktu-nyata
• Tugas dan Perencanaan
• Interaksi tugas dan sinkronisasi
• Layanan sistem operasi lain
• Nucleus SE
• Perencana
• Tugasnya
• Bagian dari memori
• Sinyal
• Grup Bendera Acara
• Semafor
• Kotak surat
• Antrian
• Saluran
• Waktu sistem
• Pengatur waktu perangkat lunak
• Gangguan
• Diagnostik dan pengecekan kesalahan
• Inisialisasi dan Peluncuran

Rangkaian artikel tidak terikat dengan sistem operasi waktu nyata tertentu, sebagian besar materi berlaku untuk opsi yang tersedia untuk menerapkan RTOS. Menurut penulis, penggunaan OS komersial siap pakai dengan dukungan yang ada adalah cara kerja yang paling dapat diandalkan dan paling produktif. Salah satu artikel akan dikhususkan untuk diskusi terperinci tentang topik "make vs buy" dan metodologi lain untuk memilih RTOS.

Namun, untuk menjelaskan desain internal RTOS, contoh kode produk nyata, Nucleus SE, digunakan.

Sumber: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed

Seluruh kebenaran tentang RTOS. Artikel # 2

RTOS: Struktur dan mode waktu-nyata
Struktur program dan waktu nyata

Seri artikel ini adalah tentang embedded system dan, khususnya, tentang perangkat lunak yang berjalan pada embedded system. Mari kita mulai dengan definisi. Apa itu sistem tertanam? Pada tahun 1986, ketika saya menulis buku pertama tentang hal ini, istilah seperti itu tidak ada. Konsep "sistem khusus" atau "sistem mikro" digunakan, tetapi mereka, tentu saja, tidak mencerminkan keseluruhan esensi. Beberapa tahun kemudian, kata "built-in" mulai digunakan, dan semua spesialis mulai menggunakannya secara aktif.

Kembali ke definisi sistem tertanam. Dalam upaya menjelaskan kepada teman dan keluarga tentang apa yang sedang saya kerjakan, saya datang dengan penjelasan berikut: sistem tertanam adalah setiap perangkat elektronik yang memiliki prosesor, tetapi yang biasanya tidak diterima sebagai komputer.

Sistem operasi (OS) selalu ada di komputer; dalam sistem embedded modern, hanya beberapa jenis OS yang digunakan. Terlepas dari kenyataan bahwa penggunaan kernel berlaku dalam sistem berperforma tinggi (32- dan 64-bit), dimungkinkan untuk mengambil manfaat dari penggunaannya pada perangkat berdaya rendah. Fokus artikel ini adalah pada sistem operasi, baik secara umum maupun dengan implementasi spesifik.

Mengapa menggunakan sistem operasi sama sekali?

Mari kita lihat mengapa sistem operasi pada prinsipnya digunakan. Ada banyak penjelasan, beberapa di antaranya tergantung pada faktor manusia dan karakteristik teknis. Saya ingat ceritanya. Di salah satu kantor kami ada sudut dapur di mana Anda bisa membuat kopi. Di pintu ada tulisan dengan tulisan: "Tolong jangan tutup pintu." Di bawahnya, seseorang menulis: "Mengapa tidak?", Yang orang lain menjawab: "Karena." Versi yang sangat singkat dari frasa "karena kami memberitahu Anda untuk melakukan hal itu." Untuk alasan yang sama, sistem operasi digunakan pada beberapa sistem, hanya karena itu perlu dilakukan.

Penjelasan lain adalah penggunaan aplikasi desktop. Di mana Anda memulai jika Anda menulis perangkat lunak untuk PC atau Mac? Anda menyalakan komputer, mulai Windows / Linux atau macOS dan mulai pemrograman. Memiliki sistem operasi adalah kondisi yang diberikan, dan menyediakan sejumlah layanan yang bermanfaat. Tidak mungkin Anda akan memutuskan untuk memulai dari awal ketika memprogram bare metal. Oleh karena itu, tidak mengherankan jika seorang insinyur yang memiliki pengalaman menulis perangkat lunak, tetapi untuk siapa firmware baru, akan bergantung pada keberadaan sistem operasi dalam sistem yang ia kembangkan.

Perlu dicatat aspek kunci dari OS desktop yang diketahui pengguna adalah antarmuka pengguna (UI). Tanyakan kepada seseorang apa itu Windows dan mereka akan menjawab bahwa itu adalah windows, menu, kotak dialog, ikon, tetapi sistem file, komunikasi antar-program dan kemampuan untuk berinteraksi dengan sistem lain hampir tidak disebutkan. Ini adalah perbedaan utama antara desktop dan sistem tertanam: yang terakhir mungkin tidak memiliki antarmuka pengguna, dan jika ya, itu cukup mudah. Ini adalah yang pertama dari banyak perbedaan utama:

• Sistem tertanam biasanya menjalankan aplikasi perangkat lunak tunggal dari daya hidup ke daya mati.
• Sistem tertanam memiliki sumber daya terbatas. Jumlah memori bisa sangat besar, tetapi bukan fakta bahwa itu dapat diperluas; Prosesor memiliki daya terbatas.
• Banyak aplikasi tertanam bekerja secara real time. Lebih lanjut tentang ini di artikel di bawah ini.
• Alat pengembangan firmware khusus dan berjalan di komputer host (seperti PC), dan bukan pada sistem target.
• Memperbarui firmware adalah proses yang rumit. Meskipun ada peluang yang muncul karena perangkat yang terhubung, pembaruan firmware selama operasi masih bukan norma (tidak seperti pembaruan dan tambalan biasa (tambalan) yang digunakan untuk perangkat lunak desktop).

Sebelum kita mempertimbangkan bagaimana membuat struktur aplikasi yang tertanam, kita akan memahami konsep yang digunakan pada komputer untuk menjalankan program menggunakan sistem operasi.

Pertama, ada eksekusi program bergaya DOS, ketika program dijalankan secara bergantian.



Setiap program diluncurkan, diimplementasikan, dan diakhiri. Kami menggunakan, katakanlah, program 1, lalu program 2, lalu mungkin istirahat, beralih ke program 3, dan kemudian kembali ke program 2. Penggunaan kedua program 2 dimulai lagi: peluncuran tidak dimulai dari tempat kami tinggalkan ini (kecuali dalam kasus di mana aplikasi itu sendiri tidak memberikan kesempatan seperti itu).

Setelah DOS, segalanya menjadi sedikit rumit, karena Windows sudah menjadi hal yang biasa. Menjalankan program bergaya Windows berarti menjalankan banyak program dalam mode multithreaded.



Dalam mode ini, tampaknya program sedang berjalan pada saat yang bersamaan, dan Windows mengendalikan ilusi ini. Pertama, program 1 dimulai, kemudian pada saat yang sama program 2 dimulai, lalu program 3. Program 2 berakhir, program 1 dan 3 masih berjalan. Program 3 berakhir, hanya sisa program 1. Nanti, program 2 melanjutkan, dan program 1 berakhir, hanya sisa program 2. Ini adalah program yang realistis ketika Windows digunakan oleh pengguna biasa. Sistem operasi mengalokasikan sumber daya sehingga semua program menggunakan prosesor dengan benar. Ini juga menyediakan komunikasi yang mudah antar program (mis. Clipboard) dan mengontrol antarmuka pengguna.

Beberapa perangkat portabel memerlukan lebih banyak fleksibilitas daripada yang dapat ditawarkan DOS, tetapi mengingat sumber daya yang terbatas, biaya overhead yang lebih rendah diperlukan daripada Windows. Akibatnya, kami memiliki eksekusi program dengan gaya iOS, yaitu:



Program diluncurkan satu per satu, tetapi statusnya disimpan secara otomatis sehingga Anda dapat melanjutkan dari tempat yang sama saat menutup. Misalnya, program 1 dimulai, kemudian berhenti untuk menggunakan program 2, lalu, misalnya, perangkat mati untuk sementara waktu. Ketika melanjutkan, program 3 dimuat (keadaan program 2 disimpan secara otomatis), dan kemudian pengguna kembali ke program 2, terus bekerja di dalamnya. Saya mengerti bahwa model pelaksanaan aplikasi iOS jauh lebih rumit daripada yang dijelaskan di atas, namun, deskripsi ini hanya ringkasan singkat dari persepsi awal pengguna.

Sebagian besar aplikasi bawaan tidak cocok dengan model di atas. Sebagai aturan, perangkat memulai program ketika daya dihidupkan dan terus bekerja hanya dengan perangkat lunak ini untuk waktu yang tidak terbatas. Struktur kode semacam itu harus dipikirkan dengan cermat.

Model Firmware

Sistem desktop hampir semuanya sama. Dari sudut pandang program aplikasi, semua komputer pribadi dengan Windows identik. Sistem tertanam adalah unik: masing-masing berbeda dari yang lain. Perbedaan dapat bersifat teknis: jenis prosesor, ukuran memori, jumlah perangkat periferal. Aspek prioritas aplikasi juga dapat berbeda dalam kecepatan, konsumsi energi, keamanan dan keandalan. Mungkin ada perbedaan komersial yang mempengaruhi harga: volume produksi dan pilihan antara perangkat keras khusus atau standar.

Perbedaan-perbedaan ini penting untuk pengembang tertanam. Misalnya, pilihan alat pengembangan (compiler, debuggers, dll.) Tergantung pada jenis prosesor. Banyak faktor yang mempengaruhi pilihan sistem operasi atau bahkan keputusan untuk menerapkannya secara prinsip. Struktur perangkat lunak (model perangkat lunak) harus dipilih dengan cermat untuk setiap aplikasi yang disematkan masing-masing.

Tergantung pada persyaratan aplikasi, perangkat lunak yang disematkan mungkin memiliki berbagai struktur dengan tingkat kompleksitas yang berbeda, misalnya:



Bentuk paling sederhana adalah struktur tertutup di mana urutan tindakan yang sama diulang. Jika aplikasi ini cukup sederhana sehingga dapat diimplementasikan dengan cara ini, ini sangat ideal: kode sederhana dapat diandalkan dan dimengerti. Namun, struktur seperti itu sangat sensitif terhadap bagian kode yang dapat memakan waktu prosesor terlalu banyak, yaitu, beberapa perintah dijalankan begitu lama sehingga mereka menunda pelaksanaan tugas aplikasi lainnya. Selain itu, model ini tidak memiliki skala yang baik: meningkatkan kode dapat menjadi masalah, karena add-on dapat memengaruhi kinerja kode lama.

Jika sesuatu yang lebih rumit diperlukan, Anda dapat mencoba untuk menempatkan bagian yang tidak penting dari kode dalam loop utama, dan bagian yang sensitif terhadap waktu dalam interrupt handler (Interrupt Service Routines, ISR). Tindakan interrupt handler pada dasarnya cukup singkat, hanya melakukan tugas-tugas penting dan menandai bagian-bagian dari loop utama untuk menyelesaikan pekerjaan sesegera mungkin. Kesulitan dapat muncul ketika perlu untuk mendistribusikan pekerjaan antara loop utama dan pengendali interupsi (serta antara beberapa pengembang).

Untuk fleksibilitas aplikasi maksimum, Anda perlu membaginya menjadi beberapa program yang terpisah dan relatif independen (sebut saja tugas atau utas), yang akan dieksekusi dalam mode multi-utas. Penangan interupsi kecil juga dapat dimasukkan dalam sistem, tetapi mereka terutama akan memberi tahu tugas atau memicu tindakan. Untuk mencapai ini, Anda memerlukan sistem operasi, atau setidaknya sebuah kernel. Penggunaan multithreading tidak hanya menyediakan distribusi fungsionalitas yang fleksibel dalam perangkat lunak, tetapi juga memfasilitasi distribusi pekerjaan antar pengembang.

Apa itu waktu nyata?

Sebelumnya, saya menulis bahwa banyak aplikasi tertanam bekerja secara real time. Dalam konteks ini, biasanya berbicara tentang sistem operasi waktu-nyata, dan bukan tentang OS sederhana. Mari kita definisikan terminologinya.

“Sistem operasi real-time adalah sistem di mana kebenaran perhitungan tidak hanya bergantung pada kebenaran logis dari perhitungan, tetapi juga pada waktu di mana hasil akan dicapai.

Jika batasan waktu sistem tidak terpenuhi, diyakini bahwa kegagalan sistem telah terjadi. "

Ciri penting dari sistem semacam itu adalah sifatnya yang dapat diprediksi atau, seperti yang sering mereka katakan, determinisme.

Sistem operasi waktu nyata tidak selalu sangat cepat; "waktu nyata" tidak selalu berarti "waktu sangat cepat." Ini berarti bahwa setiap tindakan yang diperlukan akan diselesaikan pada waktu yang tepat. Yaitu, cukup cepat, tetapi pada saat yang sama tidak terlalu cepat (yaitu, cukup lambat).

RTOS (bila digunakan dengan benar) memberikan kontrol yang sangat tepat atas distribusi waktu prosesor untuk tugas dan, karenanya, membuat aplikasi sepenuhnya deterministik. Satu-satunya hal yang dapat merusak gambar ini adalah interupsi. Ada RTOS yang sepenuhnya mengendalikan interupsi. Tugas mereka adalah mengelola layanan interupsi sebagai bagian dari penjadwal tugas. Terlepas dari kenyataan bahwa ini harus mengarah pada perilaku yang dapat diprediksi, mekanisme ini cukup rumit dan mengandung biaya overhead yang tinggi.

Sebagian besar RTOS memungkinkan pengendali interupsi untuk "mencuri" waktu dari tugas yang sedang dijalankan pada saat interupsi. Ini, pada gilirannya, memaksa programmer untuk menulis kode interrupt handler sesingkat mungkin. Akibatnya, kami memiliki kesalahan yang diizinkan secara waktu nyata. Satu-satunya kesulitan adalah membuat panggilan ke layanan RTOS sebagai bagian dari tugas penangan. Beberapa panggilan bisa sangat tidak berbahaya, sementara yang lain akan menyebabkan perubahan konteks ketika kembali dari interupsi. Situasi ini harus ditangani secara khusus, yang dimungkinkan dengan bantuan berbagai RTOS.

Sumber: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time

Ketika kami mengerjakan sistem operasi OSRV MAX real-time kami sendiri (artikel yang sebelumnya diterbitkan tentang hal itu) , tim kami “menemukan” blog Colin Walls, seorang ahli mikroelektronika dan firmware di Mentor Graphics. Artikel-artikel tampak menarik, menerjemahkannya untuk diri mereka sendiri, tetapi agar tidak "menulis ke meja" mereka memutuskan untuk menerbitkan. Saya harap mereka juga bermanfaat bagi Anda. Jika demikian, maka kami berencana untuk menerbitkan semua artikel yang diterjemahkan dalam seri.

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: http://blogs.mentor.com/colinwalls , email: colin_walls@mentor.com

Pasal 3 diterbitkan di sini.