NIM : 1911511010
I. Prinsip,
Sistem operasi waktu nyata ( RTOS ) adalah sistem operasi (OS) untuk aplikasi waktu nyata
yang memproses data dan peristiwa yang memiliki batasan waktu yang ditentukan secara kritis.
Sebuah RTOS berbeda dari sistem operasi berbagi waktu, seperti Unix, yang mengelola berbagi
sumber daya sistem dengan penjadwal, buffer data, atau prioritas tugas tetap dalam lingkungan
multitasking atau multiprogramming. Persyaratan waktu pemrosesan harus sepenuhnya dipahami
dan terikat daripada hanya disimpan seminimal mungkin. Semua pemrosesan harus terjadi dalam
batasan yang ditentukan. Sistem operasi real-time didorong oleh peristiwa dan preemptive,
artinya OS mampu memantau prioritas yang relevan dari tugas yang bersaing, dan membuat
perubahan pada prioritas tugas. Sistem yang digerakkan oleh peristiwa beralih di antara tugas
berdasarkan prioritasnya, sementara sistem pembagian waktu mengalihkan tugas berdasarkan
interupsi jam .
Karakteristik utama dari RTOS adalah tingkat konsistensinya mengenai jumlah waktu yang diperlukan
untuk menerima dan menyelesaikan tugas aplikasi ; variabilitasnya adalah ' jitter '. Sistem operasi waktu
nyata 'keras' (hard RTOS) memiliki lebih sedikit jitter daripada sistem operasi waktu nyata 'lunak' (RTOS
lunak). Jawaban yang terlambat adalah jawaban yang salah dalam RTOS keras sedangkan jawaban yang
terlambat dapat diterima dalam RTOS lunak. Tujuan desain utama bukanlah throughput yang tinggi ,
melainkan jaminan kategori kinerja lunak atau keras . RTOS yang biasanya atau umumnya dapat
memenuhi tenggat waktu adalah OS waktu nyata yang lunak, tetapi jika dapat memenuhi tenggat waktu
secara deterministik itu adalah OS waktu nyata yang keras.
Sebuah RTOS memiliki algoritma canggih untuk penjadwalan . Fleksibilitas penjadwal memungkinkan
orkestrasi prioritas proses sistem komputer yang lebih luas, tetapi OS waktu nyata lebih sering
didedikasikan untuk sekumpulan aplikasi yang sempit. Faktor kunci dalam OS waktu nyata adalah latensi
interupsi minimal dan latensi peralihan utas minimal ; OS real-time lebih dihargai karena seberapa cepat
atau seberapa dapat diprediksi responsnya daripada jumlah pekerjaan yang dapat dilakukan dalam periode
waktu tertentu.
Prinsip kerja dari scheduler RTOS adalah membagi slot waktu eksekusi (tick time) untuk tiap-tiap
program dari beberapa program yang dijalankan. Gambar 1 mendeskripsikan prinsip kerja sebuah
scheduler RTOS yang menjadwalkan eksekusi setiap program oleh CPU bergilir secara cepat.
Setiap program yang dijadwalkan oleh scheduler untuk dieksekusi diberikan prioritas dari HIGH ke
LOW, hal ini tersebut untuk menentukan pola penggiliran sesuai denga prioritassnya disapmping
menjalankan penjadwalan, RTOS juga menerima permintaan interupsi baik dari perangkat keras maupun
dari perangkat lunak yang meminta layanan. I. PRINSIP :
Teknik desain sistem tertanam yang sangat normal adalah membuat setiap tugas RTOS menghabiskan
sebagian besar waktu diblokir, menunggu rutinitas interupsi atau tugas lain untuk mengirim pesan atau
menyebabkan suatu peristiwa atau membebaskan semaphore untuk memberi tahu tugas bahwa ada
sesuatu untuk itu untuk dilakukan.
Ketika interupsi terjadi, rutin interupsi menggunakan layanan RTOS untuk memberi sinyal satu atau
lebih tugas, yang masing-masing kemudian melakukan pekerjaannya dan masing-masing kemudian dapat
memberi sinyal tugas lain. Dengan cara ini, setiap interupsi dapat membuat rangkaian sinyal dan aktivitas
tugas.
Gambar 1 berikut menunjukkan versi yang sangat disederhanakan dari beberapa hal yang terjadi di dalam
sistem telegraf. Dalam gambar itu panah melengkung menunjukkan pesan yang melewati RTOS.
Ketika sistem menerima bingkai jaringan, perangkat keras menyela. Rutinitas interupsi mengatur
ulang perangkat keras dan kemudian meneruskan pesan yang berisi bingkai yang diterima ke tugas
protokol DDP (protokol pengiriman datagram).
Tugas protokol DDP diblokir menunggu pesan. Ketika pesan ini tiba, tugas itu bangun dan di
antara banyak hal lainnya, menentukan apakah bingkai itu dimaksudkan untuk telegraf atau
diterima oleh telegraf karena kesalahan .
jika bingkai dimaksudkan untuk telegraf, tugas protokol DDP mengirim pesan yang berisi bingkai
yang diterima ke tugas protokol ADSP (Apple Talk data Stream Protocol).
Pesan ini membuka blokir tugas protokol ADSP, jika bingkai berisi data cetak; tugas protokol ADSP
mengirim pesan yang berisi data ke tugas port serial, yang mengirimkan data ke perangkat keras
port serial dan melaluinya ke printer.
Demikian pula, ketika sistem menerima data serial dari printer, rutin interupsi mengatur ulang
perangkat keras dan meneruskan data dalam pesan ke tugas port serial.
Jika data berisi status printer, tugas port serial meneruskan status ke ADSP, ADSP menggunakannya
saat menanggapi permintaan status nanti dari jaringan.
Gambar 1: Operasi Telegraf yang menunjukkan prinsip-prinsip desain RTOS
Prinsip terbaik dalam desain RTOS:
1. tulis rutinitas interupsi singkat
4. Enkapsulasi tugas
2. IR rentan terhadap kesalahan dan sulit untuk di-debug daripada kode tugas (karena
bagian perangkat lunak yang bergantung pada perangkat keras)
Misalkan kita menulis perangkat lunak untuk sistem dengan karakteristik berikut:
Sebuah sistem harus merespon perintah yang datang dari port serial
Perintah tiba satu per satu, perintah berikutnya tidak akan tiba sampai sistem merespons yang
sebelumnya.
Perangkat keras port serial hanya dapat menyimpan satu karakter yang diterima pada satu
waktu, dan karakter tiba dengan cepat.
Salah satu masalah pertama dalam desain sistem tertanam adalah membagi pekerjaan sistem Anda ke
dalam tugas-tugas RTOS. Ini akan membuat Anda memiliki banyak tugas. Ada beberapa keuntungan dan
kerugian menggunakan sejumlah besar tugas.
Keuntungan:
Lebih banyak tugas menawarkan kontrol yang lebih baik atas waktu respons secara keseluruhan.
Dengan lebih banyak tugas, sistem Anda bisa menjadi lebih modular.
Dengan lebih banyak tugas, terkadang Anda dapat merangkum data dengan lebih
efektif. Kekurangan:
Dengan lebih banyak tugas, Anda cenderung memiliki lebih banyak data yang dibagikan di
antara dua atau lebih tugas. Ini akan membuat sistem memiliki lebih banyak semaphore, dan
karenanya menjadi lebih banyak waktu mikroprosesor untuk menangani semaphore dan lebih
banyak bug terkait semaphore
Dengan lebih banyak tugas, Anda cenderung memiliki lebih banyak persyaratan untuk
komunikasi antartugas melalui pipa, antrian kotak surat, dan sebagainya. Ini juga akan
menerjemahkan lebih banyak waktu mikroprosesor dan lebih banyak peluang untuk
bug.
Setiap tugas membutuhkan tumpukan; oleh karena itu lebih banyak tugas mungkin
membutuhkan lebih banyak memori, setidaknya untuk ruang tumpukan.
Setiap kali RTOS beralih tugas. Dibutuhkan lebih banyak waktu mikroprosesor untuk
menyimpan konteks tugas yang berhenti dan memulihkan konteks tugas yang akan dijalankan.
3. TugasPrioritas:
Penguraian berdasarkan 'fungsi' dan 'kekritisan waktu,' memisahkan komponen ES menjadi tugas (secara
alami), prioritas tugas akan memberikan respons yang lebih cepat – prioritas tinggi untuk yang kritis
waktu, dan prioritas rendah untuk yang lain
Masuk akal untuk memiliki tugas terpisah untuk menangani perangkat keras yang digunakan bersama
oleh berbagai bagian sistem.
Satu tugas yang mengontrol tampilan perangkat keras dapat mengatasi masalah ini. Ketika tugas lain
dalam sistem memiliki informasi untuk ditampilkan, mereka mengirim pesan ke tugas tampilan. RTOS
akan memastikan bahwa pesan yang dikirim ke tugas tampilan diantrekan dengan benar. Logika
sederhana dalam tugas tampilan kemudian dapat memutuskan pesan mana yang harus ditempatkan pada
tampilan. Gambar di atas menunjukkan hal itu.
5. Struktur tugas:
Struktur tugas akan memberikan informasi keseluruhan tentang data pribadi dan waktu hidupnya.
Dan berapa kali itu akan dieksekusi, Dan dari tugas mana ia membaca data dan ke tugas mana ia
menulis.
Jika tidak ada yang harus dilakukan untuk tugas ini, antrian inputnya akan kosong, dan tugas
akan memblokir dan menghabiskan waktu mikroprosesor.
Tugas tidak memiliki data publik yang dapat dibagikan tugas lain, jadi tidak ada data yang
dibagikan, dan tidak ada masalah semaphore dan semaphore.
Setiap RTOS memungkinkan Anda untuk membuat tugas saat sistem dimulai dan sebagian besar
RTOS juga memungkinkan untuk membuat dan menghancurkan tugas saat sistem sedang berjalan. Ada
dua alasan bagus untuk menghindari ini.
Fungsi yang membuat dan menghancurkan tugas biasanya merupakan fungsi yang paling memakan
waktu di RTOS, daripada mendapatkan semaphore.
Membuat tugas adalah operasi yang relatif andal, sulit untuk menghancurkan tugas tanpa bug .
Memberikan mikroprosesor ke salah satu tugas untuk waktu yang singkat, kemudian
mengalihkan mikroprosesor ke tugas lain untuk jangka waktu yang kecil dan seterusnya.
Seseorang mungkin ingin mempertimbangkan apakah mereka ingin memiliki dua tugas dengan
prioritas atau apakah mereka bisa menjadi satu tugas saja. RTOS memungkinkan untuk mematikan opsi
ini.
• Enkapsulasi antrian
Setidaknya beberapa dari bug tersebut berasal dari penggunaan yang tidak disiplin. Anda dapat
menghancurkan bug ini sebelum mereka merangkak hanya dengan menyembunyikan semaphore dan data
yang dilindunginya di dalam modul.
GetSemaphore <SEMAPHORE_TIME_OF_DAY);
++l SecondsToday;
if (lSecondsToday == 60 * 60 * 24)
l SecondsToday = 0L;
GiveSemaphore (SEMAPHORE_TIME_OF_DAY);
long lReturnValue;
GetSemaphore (SEMAPHORE_TIME_OF_DAY);
lReturnValue =lSecondsToday;
GiveSemaphore (SEMAPHORE_TIME_OF_DAY);
return (lReturnValue);
}
long lTemp;
Dalam kode di atas , daripada membiarkan sembarang kode yang menginginkan nilai variabel
lSecondsToday membacanya secara langsung dan melompat ke yang terbaik, konstruksi ini memaksa
kode apa pun yang ingin mengetahui nilai lSecondsToday untuk memanggil 1second SinceMidnight
untuk mendapatkannya. 1second SinceMidnight menggunakan semaphore dengan benar. Semaphore ini
tidak akan menimbulkan bug lagi.
GetSemaphore (SEMAPHORE_TIME_OF_DAY);
++lSecondsToday;
if (lSecondsToday == 60 * 60 * 24)
lSecondsToday =OL;
GiveSemaphore (SEMAPHORE_TIME_OF_DAY);
/* (Here, too) */
Kode di atas mengundang bug semaphore atau bug data bersama setiap saat.
Enkapsulasi antrian:
Demikian pula, Anda harus mempertimbangkan untuk mengenkapsulasi antrean yang digunakan tugas
untuk menerima pesan dari tugas lain. Kita harus menulis kode untuk menangani memori flash bersama.
Kode itu berhubungan dengan benar dengan menyinkronkan permintaan untuk membaca dari dan menulis
ke memori flash. Namun, mungkin ide yang buruk untuk mengirimkan kode itu dalam sistem nyata.
Pertimbangkan daftar bug potensial ini.
Bahkan jika setiap orang menggunakan struktur yang benar, beberapa badan dapat
menetapkan nilai untuk berkedip selain salah satu dari dua nilai hukum.
Siapa pun secara tidak sengaja menulis pesan yang ditujukan untuk tugas flash ke antrian
yang salah.
Tugas apa pun dapat merusak antrean input tugas flash secara tidak sengaja.
Tugas flash mengirimkan data yang dibacanya dari flash kembali melalui antrian lain. Seseorang
mungkin mengirim ID antrian yang tidak valid.
AKU AKU AKU. PERTIMBANGAN PENJADWALAN WAKTU NYATA KERAS
• Berikut ini adalah model penjadwalan yang umum digunakan oleh scheduler:
– Penjadwalan kooperatif tugas siap dalam antrian. Hal ini berkaitan erat dengan fungsi
penjadwalan antrian.
– Penjadwalan preemtif
Beberapa kode penting dalam perakitan untuk memenuhi waktu nyata dengan cepat.
Saat tugas waktu nyata yang sulit sedang berjalan, semua interupsi lain dengan prioritas lebih
rendah dinonaktifkan.
Preemption tugas prioritas yang lebih tinggi dengan tugas prioritas yang lebih rendah.
Sistem waktu nyata yang sulit, tugas n memulai pemrosesannya secara berkala setiap Tn unit waktu, dan
harus diselesaikan sebelum waktunya untuk memulai lagi Tn unit waktu nanti.
Untuk setiap tugas ada kasus terburuk waktu eksekusi Cn satuan waktu dan batas waktu Dn satuan waktu
.
Asumsikan bahwa waktu pengalihan tugas adalah 0 dan tugas itu tidak saling memblokir untuk
semaphore, acara, dan sebagainya. Setiap tugas memiliki prioritas Pn. Kemudian pertanyaan yang harus
diselesaikan adalah apakah setiap tugas akan selesai sebelum tenggat waktu bahkan dalam kasus terburuk.
Berikut adalah beberapa cara untuk menghemat ruang kode. Beberapa teknik ini memiliki kelemahan.
Kita harus menerapkannya hanya jika diperlukan untuk memasukkan kode kita ke dalam ROM kita.
1. Ganti atau hilangkan fungsi besar, perhatikan panggilan berulang ke fungsi besar
2. Pastikan dua fungsi tidak menggunakan hal yang sama atau melakukan operasi
yang sama.
5. Kita harus selalu melihat daftar bahasa rakitan yang dibuat oleh kompiler silang kita
untuk melihat apakah pernyataan C tertentu diterjemahkan ke dalam sejumlah besar
instruksi.
8. Kita dapat menghemat banyak ruang dengan menulis kode kita dalam bahasa
assembly. Menghemat Daya:
Mode memiliki nama seperti:
Mode tidur
Modus ideal
Modus siaga.
i. Mode hemat daya yang sangat umum adalah mode di mana mikroprosesor berhenti mengeksekusi
instruksi, menghentikan periferal bawaan, dan menghentikan sirkuit jamnya. Ini menghemat
banyak daya, tetapi kekurangannya adalah bahwa satu-satunya cara untuk memulai mikroprosesor
adalah dengan menyalakannya kembali.
ii. Mode hemat daya tipikal lainnya adalah mode di mana mikroprosesor berhenti mengeksekusi
instruksi tetapi periferal terpasang terus beroperasi. Setiap interupsi memulai mikroprosesor lagi,
dan mikroprosesor akan menjalankan rutin interupsi yang sesuai dan kemudian melanjutkan
kode tugas dari instruksi yang mengikuti instruksi yang membuat mikroprosesor tertidur. Metode
ini menghemat lebih sedikit daya. Daripada cara di atas.
iii. Metode umum lainnya untuk menghemat daya adalah dengan mematikan seluruh sistem
dan pengguna menyalakannya kembali saat dibutuhkan.
iv. Jika kita ingin menempatkan mikroprosesor kita dalam mode hemat daya, kita harus
merencanakan untuk menulis perangkat lunak yang cepat. Semakin cepat perangkat lunak Anda
menyelesaikan
pekerjaannya, semakin cepat ia dapat mengembalikan mikroprosesor ke mode hemat daya dan
berhenti menggunakan baterai.
1. Tiang sinyal
2. Antrian dan
3. Kotak surat.
2. Bendera acara
3. Manajemen tugas
a) Buat tugas
b) Hapus tugas