Kapan kita membutuhkan Sistem Operasi dalam Desain Sistem Tertanam?

22

Saya telah menulis banyak kode logam kosong untuk prosesor PIC dan x86. Dapatkah seseorang memberi tahu saya bagaimana dan kapan saya perlu sistem operasi? Sebaliknya, aplikasi atau situasi apa yang dapat ditangani atau tanpa sistem operasi juga?

quantum231
sumber
2
Karena tidak semua yang perlu Anda ketahui diajarkan di sekolah. Jika Anda merasa perlu mempelajari RTOS, pilih platform dan pelajari.
Scott Seidman
3
Pertanyaan tentang penggunaan OS dalam embedded adalah valid. Namun, EE.SE tidak dapat membantu Anda dengan "mengapa mereka tidak mengajari saya ini di sekolah?" bagian. Saya mengambil kebebasan untuk mengeditnya.
Nick Alexeev
kemungkinan duplikat dari Apakah saya memerlukan OS di perangkat saya?
Kaz
Yah satu-satunya alasan saya bertanya tentang mengapa itu tidak diajarkan di universitas saya adalah karena saya belum pernah menemukan siswa EE mana pun yang pernah melakukannya di Universitas. Jadi bagi saya sepertinya itu tidak dilakukan di universitas mana pun.
quantum231
@ quantum231 Ini dilakukan di universitas saya, NTNU - Norwegia.
CK

Jawaban:

23

Aturan praktis saya adalah bahwa Anda harus mempertimbangkan sistem operasi jika produk memerlukan satu atau lebih dari yang berikut: tumpukan TCP / IP (atau tumpukan jaringan kompleks lainnya), GUI kompleks (mungkin yang dengan objek GUI seperti jendela dan acara) ), atau sistem file.

Jika Anda telah melakukan beberapa pengkodean bare metal maka Anda mungkin akrab dengan arsitektur program super-loop . Jika persyaratan firmware produk cukup sederhana untuk diimplementasikan dengan super-loop yang dapat dipertahankan (dan mudah-mudahan agak dapat diperpanjang) maka Anda mungkin tidak memerlukan sistem operasi.

Dengan meningkatnya persyaratan perangkat lunak, super-loop menjadi lebih kompleks. Ketika persyaratan perangkat lunak sangat banyak sehingga super-loop menjadi terlalu kompleks atau tidak dapat memenuhi persyaratan real-time dari sistem maka sekarang saatnya untuk mempertimbangkan arsitektur lain.

Arsitektur RTOS memungkinkan Anda membagi persyaratan perangkat lunak menjadi tugas. Jika dilakukan dengan benar, ini menyederhanakan implementasi setiap tugas. Dan dengan memprioritaskan tugas, RTOS dapat membuatnya lebih mudah untuk memenuhi persyaratan waktu-nyata. Namun, RTOS bukanlah obat mujarab. RTOS meningkatkan kompleksitas sistem secara keseluruhan dan membuka Anda hingga jenis bug baru (seperti deadlock). Sebagai alternatif untuk RTOS, Anda mungkin mempertimbangkan dan arsitektur mesin keadaan berbasis peristiwa (seperti QP ).

Jika produk Anda memiliki jaringan, GUI yang kompleks, dan sistem file maka Anda mungkin berada pada titik di mana Anda harus mempertimbangkan sistem operasi berfitur lengkap seperti VxWorks, Windows, atau Linux. Sistem operasi berfitur lengkap akan menyertakan driver untuk detail tingkat rendah dan memungkinkan Anda untuk fokus pada aplikasi Anda.

krambo
sumber
8

Ini benar-benar tergantung pada definisi Anda tentang 'sistem tertanam'. Mungkin ada beberapa yang akan mengklaim bahwa jika itu bukan pemrograman bare-metal, itu tidak tertanam (yang menghalangi pertanyaan Anda), tetapi saya akan tidak setuju dengan itu - saya berpendapat bahwa sistem apa pun yang dirancang untuk melakukan hanya satu fungsi, yaitu, hanya menjalankan satu 'aplikasi' tertentu, dapat disebut sistem tertanam.

Yang mengatakan, itu harus cukup mudah untuk membayangkan situasi yang akan mendapat manfaat dari layanan OS penuh sesak nafas. Sebagai contoh, di mana saya bekerja, sangat umum untuk menemukan orang membangun alat uji di atas suite desain instrumentasi yang berjalan di atas jendela. Sistem-sistem ini dikonfigurasikan untuk mem-boot ke konfigurasi stasiun pengujian dan mengunci penggunaan umum (untuk mencegah kerusakan stasiun) dan karena itu dapat dikatakan sebagai sistem tertanam.

Namun, hanya membeli modul I / O yang tidak tersedia, menghubungkannya ke PC mount rack, dan menyiapkan konfigurasi dalam GUI mungkin gagal memenuhi syarat sebagai desain sistem tertanam untuk beberapa orang. Untuk situasi yang tidak terlalu mencolok, pertimbangkan pengontrol proses khusus dengan FPGA, yang ingin Anda lakukan pencatatan data mewah. Anda mungkin menanamkan sistem prosesor soft-core (dengan BSP yang ada) dan menjalankan linux realtime untuk menjalankan tumpukan jaringan (untuk logging dan NTP Anda dll) dan melakukan semua hal lain dalam logika.

JustJeff
sumber
7

Aturan praktis saya (sangat kabur) adalah jika Anda memerlukan lebih dari satu utas kontrol (katakan setidaknya satu perangkat yang melibatkan protokol atau mesin negara plus sesuatu yang harus dilakukan) maka beberapa perangkat lunak OSish akan membuat hidup Anda lebih mudah

Taniwha
sumber
Menyiapkan RTOS membutuhkan sejumlah pekerjaan. Kecuali jika upaya menggunakan switchmesin-mesin berbasis negara melebihi itu, switchmesin-mesin berbasis cenderung menjadi lebih baik. Lebih lanjut, pada platform 8x51 dan TMS2000, saya telah mengimplementasikan sebuah tugas-switcher kooperatif sederhana berbasis stack. Tidak ada logika OS untuk memutuskan kapan harus beralih - kapan saja satu "utas" merasa itu bisa istirahat, itu akan beralih ke yang lain. Jika utas lainnya melihat bahwa sesuatu yang ditunggu belum terjadi, itu dapat beralih kembali ke yang pertama dalam waktu yang lebih singkat daripada yang biasa dihabiskan OS untuk memutuskan apakah akan beralih.
supercat
Mungkin perlu membuat perbedaan antara "utas" multi-perangkat lunak yang benar (yang sangat mengarah ke OS) vs. interupsi yang lebih sederhana menanggapi kondisi perangkat keras.
Chris Stratton
1

Sebuah pertanyaan lama tapi saya akan berkomentar.

Bahkan jika Anda tidak memiliki tumpukan jaringan atau yang serupa, pada titik di mana Anda memerlukan penjadwal tugas karena Anda memiliki cukup proses dalam aplikasi tertanam Anda, Anda mungkin mempertimbangkan RTOS. Menulis penjadwal multitasking kooperatif berbasis waktu yang sederhana tidaklah sulit, tetapi memastikan proses yang macet tidak akan memblokir aplikasi yang tersisa dan hal itu membutuhkan waktu untuk memperbaikinya. Anda perlu menerapkan sistem prioritas dengan semacam ketentuan untuk membuat proses turun dalam antrian jika belum selesai.

RTOS juga memberi Anda hal-hal seperti perlindungan memori dan sejenisnya yang membuatnya lebih mudah untuk melacak beberapa kesalahan umum dalam kode C tetapi mikrokontroler sederhana mungkin tidak mampu menangani perlindungan memori yang kompleks. Misalnya MSP430 memungkinkan Anda untuk memisahkan kode dan data dalam tingkat tinggi tetapi tidak ada kontrol akses memori yang bagus.

Barleyman
sumber
0

Sistem operasi sebenarnya menjembatani kesenjangan antara perangkat keras dan perangkat lunak aplikasi (melalui driver perangkat). Dengan kata lain, ini menyediakan platform tingkat tinggi untuk programmer yang pada akhirnya mengurangi kompleksitas kode. Dan selanjutnya, sistem operasi menyediakan platform yang kuat dan fleksibel untuk pelaksanaan aplikasi.

seolah-olah
sumber