Manfaat RTOS vs Bare Metal untuk Pemrograman MCU?

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 ;-)

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.

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.