Manfaat RTOS vs Bare Metal untuk Pemrograman MCU?


11

Harap dicatat: Pertanyaan ini secara khusus menyebutkan dua RTOS tetapi lebih umum dan mungkin dapat dijawab oleh siapa saja yang telah menulis kode C untuk RTOS tertanam, dan menjalankan perangkat lunak mereka langsung di MCU.

Saya tertarik untuk mempelajari lebih lanjut tentang RTOS tertanam dan menulis aplikasi untuk mereka. Saat ini saya melihat Embox dan RIOT karena mereka open source, modern, aktif, dan sepertinya memiliki dokumentasi yang sangat baik. Tujuan saya memiliki dua fase: Fase 1 adalah untuk mengetahui cara mengkompilasi dan mem-flash OS ini ke MCU (mungkin AVR atau ARM). Fase 2 adalah untuk kemudian menulis program C sederhana (pada dasarnya daemon tanpa kepala), yang akan berkembang seiring waktu sebagai "aplikasi hobi". Saya kemudian akan mem-flash / menyebarkan program ini ke MCU yang sama, dengan demikian berhasil menyebarkan appstack yang terdiri dari Embox / RIOT dan aplikasi saya yang berada di atasnya.

Sebelum saya menyusuri jalan yang akhirnya mengarah ke jalan buntu, saya menemukan artikel yang cukup bagus menjelaskan mengapa aplikasi real-time, yang ditulis dalam C / assembler dan melintas ke MCU, tidak benar - benar membutuhkan RTOS di bawahnya. .

Jadi sekarang saya benar-benar bingung, dan mempertanyakan beberapa pemahaman mendasar saya tentang teori komputasi. Saya kira saya sedang mencoba membuat keputusan apakah akan menggunakan Embox / RIOT atau tidak, antara lain:

  • Ikuti kursus dan lanjutkan dengan "tumpukan aplikasi" pada MCU kedua aplikasi OS +; atau
  • Perhatikan peringatan artikel ini dan ikuti MCU yang menjalankan aplikasi "bare metal" saya

Jelas, yang pertama adalah lebih banyak pekerjaan, dan karena itu lebih baik ada alasan / hasil yang baik untuk menempuh rute itu. Jadi saya bertanya: apa manfaat nyata yang ditawarkan RTOS (dan serupa) yang ditanamkan ini kepada pengembang aplikasi MCU / C? Apa fitur spesifik yang dapat dimanfaatkan aplikasi C saya (mungkin dengan tidak menciptakan kembali roda?) Dengan menggunakan RTOS? Apa yang hilang dengan membuang RTOS dan menjadi bare metal?

Saya meminta contoh konkret di sini, bukan hype media yang Anda dapatkan ketika Anda masuk ke entri wikipedia untuk RTOS ;-)


3
Jika bahkan tidak jelas bagi Anda apa yang ditawarkan RTOS, lalu mengapa Anda tertarik untuk menulis aplikasi untuk mereka? Apakah RTOS akan menguntungkan Anda atau tidak, sepenuhnya tergantung pada apa yang Anda coba capai. Dengan itu, Anda harus belajar berjalan sebelum bisa berlari. Program untuk bare metal, dan ketika Anda mengalami masalah dan menyelesaikannya, Anda akan benar-benar belajar apa manfaat dan kelemahannya.
whatsisname

Terima kasih @whatsisname (+1) - itu adalah saran yang masuk akal dan saya akan membawa Anda ke situ. Saya tidak berpikir itu palsu Namun, masih tertarik pada apa yang ditawarkan RTOS, bahkan jika saya bulan / tahun keluar dari membutuhkannya. Saya kira saya ingin melihat seluruh gambar di depan, pada tampilan 30.000 kaki. Terima kasih lagi!
smeeb

Jawaban:


11

Program mikrokontroler terdiri dari sejumlah tugas . Katakanlah Anda ingin membuat mount teleskop yang dikendalikan komputer. Tugasnya adalah:

  • Ambil byte input baru dari buffer serial USB.
  • Periksa apakah kami telah menerima perintah lengkap.
  • Jika demikian, jalankan perintah itu.
  • Baca sensor untuk posisi teleskop saat ini.
  • Atur output yang tepat untuk mengendalikan langkah motor selanjutnya.

Ini adalah serangkaian tugas yang cukup tipikal untuk sesuatu yang Anda akan gunakan untuk mikrokontroler, dan cukup mudah untuk dikelola dengan infinite loop, seperti:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

Jika Anda terus menambahkan dan menambahkan fitur, Anda akhirnya mulai menemukan masalah umum yang ingin Anda buat abstraksi, seperti:

  • Buffer Anda meluap, jadi Anda ingin memastikan bahwa tugas dapat mengganggu tugas lain sebelum meluap.
  • Anda ingin menghemat baterai dengan tidur ketika tidak ada yang dibutuhkan.
  • Anda ingin memastikan semua tugas mendapatkan pukulan yang adil. Jika readSensorsterlalu lama, Anda ingin dapat menginterupsi dan kembali lagi nanti.
  • Anda ingin hanya dapat mereset satu tugas tanpa mempengaruhi yang lain.
  • Anda ingin kebocoran memori atau bug lain dalam satu tugas tidak menghilangkan tugas lainnya.
  • Anda ingin dapat memberikan tugas yang berbeda prioritas yang berbeda.
  • Anda ingin dapat mengamplas tugas yang tidak dipercaya.
  • Anda ingin dapat menjalankan tugas pada tingkat yang berbeda. Mungkin sensor Anda hanya dapat dibaca 10 kali per detik, tetapi Anda ingin menjalankan langkah motor 100 kali per detik.

Satu atau dua item ini dapat ditangani secara manual dengan relatif mudah. Jika Anda memiliki cukup banyak masalah seperti ini cukup sering sehingga Anda mulai menggeneralisasikannya ke perpustakaan, pada dasarnya Anda telah menemukan kembali RTOS. Jika manajemen tugas program Anda cukup kompleks, bahkan jika Anda tidak menggunakan RTOS, Anda pada akhirnya akan menemukan yang buruk.

Namun, dalam pengalaman saya, garis di mana Anda ingin RTOS sangat dekat dengan garis di mana Anda ingin mikroprosesor, bukan mikrokontroler. Jika Anda mengantisipasi firmware Anda mendapatkan kompleks itu, biasanya lebih baik untuk pergi rute mikroprosesor dari awal.


Ini adalah analisis yang sangat baik dan sangat jelas bagi saya. Saya setuju dengan apa yang Anda katakan, tetapi saya lebih setuju dengan jawaban dari @Atsby. Apalagi jika tujuannya adalah belajar / meningkatkan keterampilan saya sendiri. Dalam sistem produksi, mungkin lebih baik dengan produk COTS atau RTLinux, tetapi untuk dapat men-debug level rendah produk itu ketika terjadi kesalahan, saya pribadi perlu menulis beberapa kode yang sering kali dalam daftar itu sebanyak bisa jadi.
Sam Hammamy

7

Saya menulis perpustakaan multi-threading koperasi saya sendiri untuk ARM Cortex-M0.

Itu hanya beberapa halaman kode, dan versi pertama tidak butuh lebih dari sehari untuk menulis dan men-debug.

Keuntungan besar dari roll-your-own adalah Anda tahu kode dan Anda dapat port ke chip yang RTOS mungkin tidak mendukung. Selain itu, Anda menghabiskan lebih sedikit waktu untuk memikirkan pertanyaan seperti "akankah macet saya mencoba menggunakan fitur A dan B secara bersamaan?" Karena Anda menulis kode, Anda tahu jawabannya.

Threading adalah hal utama yang Anda dapatkan dari RTOS, dan ternyata itu bukan masalah besar untuk diterapkan sendiri. Jarang bahwa Anda memerlukan banyak fitur RTOS. Tetapi jika Anda memenuhi persyaratan Anda dan ternyata Anda melakukannya, maka gunakan RTOS.


Terima kasih @Atsby! Jawaban ini sangat membantu saya memutuskan apakah perlu investasi waktu untuk belajar lebih jauh ke Bare Metal. Saya telah menulis berapakah jumlah perpustakaan GPIO yang menggunakan logam kosong untuk Pi, dan saya pikir sekarang saatnya untuk mengambil satu atau dua langkah lebih jauh. Terima kasih!
Sam Hammamy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.