RTOS untuk Sistem Tertanam

Saya telah melihat banyak artikel yang mengatakan bahwa saya harus menggunakan RTOS untuk manajemen waktu dan manajemen sumber daya. Waktu saya belum mengizinkan penelitian saya sendiri, jadi saya datang ke chiphacker untuk meminta nasihat.

Saya menggunakan mikrokontroler sumber daya rendah (MSP430, PIC) dan sedang mencari RTOS yang bisa saya gunakan.

Ke titik:

1. Biaya sumber daya sistem
2. Keuntungan sistem
3. Kekurangan sistem
4. Trik Implementasi
5. Situasi dimana RTOS seharusnya / tidak boleh digunakan.

Saya tidak menggunakan sistem seperti Arduino, proyek yang saya kerjakan tidak dapat mendukung biaya sistem seperti itu.

Saya belum memiliki banyak pengalaman pribadi dengan RTOS selain QNX (yang bagus secara keseluruhan tetapi tidak murah dan saya memiliki pengalaman yang sangat buruk dengan vendor papan tertentu dan sikap tidak peduli QNX untuk sistem lain daripada yang paling umum) yang terlalu besar untuk PIC dan MSP430.

Di mana Anda akan mendapat manfaat dari RTOS adalah di berbagai bidang seperti

• manajemen / penjadwalan thread
• komunikasi antar thread + sinkronisasi
• I / O pada sistem dengan stdin / stdout / stderr atau port serial atau dukungan ethernet atau sistem file (bukan MSP430 atau PIC untuk sebagian besar, kecuali untuk port serial)

Untuk peripheral PIC atau MSP430: untuk port serial saya akan menggunakan buffer cincin + interupsi ... sesuatu yang saya tulis sekali per sistem dan hanya digunakan kembali; perangkat lain yang saya rasa Anda tidak akan menemukan banyak dukungan dari RTOS, karena sangat spesifik untuk vendor.

Jika Anda memerlukan pengaturan waktu yang tepat untuk mikrodetik, RTOS mungkin tidak akan membantu - RTOS membatasi waktu, tetapi biasanya memiliki pengaturan waktu jitter dalam penjadwalan mereka karena penundaan pengalihan konteks ... QNX yang berjalan pada PXA270 memiliki jitter dalam puluhan mikrodetik khas, 100-200us maksimum, jadi saya tidak akan menggunakannya untuk hal-hal yang harus berjalan lebih cepat dari sekitar 100Hz atau yang membutuhkan waktu jauh lebih akurat daripada sekitar 500us. Untuk hal-hal semacam itu Anda mungkin harus menerapkan penanganan interupsi Anda sendiri. Beberapa RTOS akan bermain bagus dengan itu, dan yang lain akan membuatnya sakit kerajaan: waktu Anda dan waktu mereka mungkin tidak dapat hidup berdampingan dengan baik.

Jika pengaturan waktu / penjadwalan tidak terlalu rumit, Anda mungkin lebih baik menggunakan mesin keadaan yang dirancang dengan baik. Saya sangat merekomendasikan membaca Praktis Statecharts di C / C ++ jika Anda belum melakukannya. Kami telah menggunakan pendekatan ini di beberapa proyek kami di mana saya bekerja, dan itu punya beberapa keuntungan nyata daripada mesin negara tradisional untuk mengelola kompleksitas .... yang merupakan satu-satunya alasan Anda memerlukan RTOS.

Sudahkah Anda mencoba FreeRTOS ? Ini gratis (tunduk pada T&C), dan telah dipindahkan ke MSP430, dan beberapa rasa PIC.

Ini kecil dibandingkan dengan yang lain, tetapi ini juga membuatnya mudah dipelajari, terutama jika Anda belum pernah menggunakan RTOS sebelumnya.

Lisensi komersial (tidak bebas) tersedia, serta versi IEC 61508 / SIL 3.

Saya baru tahu tentang NuttX RTOS, yang bahkan dapat bekerja pada sistem 8052 (8-bit). Tidak memiliki banyak port, tetapi terlihat menarik. POSIX bisa menjadi nilai tambah, karena mungkin membuat beberapa kode Anda sedikit lebih portabel jika Anda naik ke prosesor yang lebih tangguh dan Anda ingin menjalankan linux atau QNX waktu nyata.

Saya sendiri tidak memiliki pengalaman dengan RTOS komersial, tetapi saya telah menggunakan yang buatan sendiri selama bertahun-tahun! Mereka hebat dalam membantu Anda membagi pengembangan kode Anda di antara banyak programmer, karena mereka masing-masing pada dasarnya bisa mendapatkan "tugas" atau "utas" untuk mengerjakan bagian mereka. Anda masih harus berkoordinasi dan seseorang harus mengawasi seluruh proyek untuk memastikan setiap tugas dapat memenuhi tenggat waktu.

Saya juga merekomendasikan Anda untuk melakukan riset Rate Monotonic Analysis atau RMA saat menggunakan RTOS. Ini akan membantu Anda menjamin bahwa tugas penting Anda akan memenuhi tenggat waktu mereka.

Saya juga akan melihat kerangka kerja pemrograman berbasis -QP-nano Miro Samek yang dapat bekerja dengan atau tanpa RTOS dan masih memberi Anda kemampuan waktu-nyata. Dengannya, Anda membagi desain menjadi mesin status hierarkis alih-alih tugas tradisional. Jason S menyebut buku Miro di posnya. Bacaan yang sangat bagus!

Satu hal yang saya temukan berguna pada sejumlah mesin adalah stack switcher sederhana. Saya belum benar-benar menulis satu untuk PIC, tapi saya akan mengharapkan pendekatan akan berfungsi dengan baik pada PIC18 jika kedua / semua thread menggunakan total 31 atau lebih sedikit level stack. Pada 8051, rutinitas utamanya adalah:

_taskswitch:
  xch a, SP
  xch a, _altSP
  xch a, SP
  membasahi

Pada PIC, saya lupa nama stack pointer, tetapi rutinitasnya akan seperti:

_taskswitch:
  movlb _altSP >> 8
  movf _altSP, w, b
  movff _STKPTR, altSP 
  movwf _STKPTR, c
  kembali

Pada awal program Anda, panggil rutin task2 () yang memuat altSP dengan alamat stack alternatif (16 mungkin akan bekerja dengan baik untuk PIC18Fxx) dan menjalankan loop task2; rutinitas ini tidak boleh kembali atau hal-hal lain akan mati dengan kematian yang menyakitkan. Sebagai gantinya, ia harus memanggil _taskswitch kapan pun ia ingin memberikan kontrol ke tugas utama; tugas utama kemudian harus memanggil _taskswitch setiap kali ia ingin menyerah pada tugas sekunder. Seringkali, seseorang akan memiliki rutin kecil yang lucu seperti:

membatalkan delay_t1 (val pendek yang tidak ditandatangani)
{
  melakukan
    taskswitch ();
  while ((unsigned short) (millisecond_clock - val)> 0xFF00);  
}

Perhatikan bahwa pengalih tugas tidak memiliki sarana untuk melakukan 'menunggu kondisi' apa pun; semua yang didukungnya adalah spinwait. Di sisi lain, pengalih tugas sangat cepat sehingga percobaan pengalihan tugas () saat tugas lainnya menunggu pengakhir waktu akan beralih ke tugas lain, memeriksa pengatur waktu, dan beralih kembali lebih cepat daripada pengalih tugas pada umumnya. akan menentukan bahwa itu tidak perlu taskswitch.

Perhatikan bahwa multitasking kooperatif memiliki beberapa keterbatasan, tetapi menghindari kebutuhan untuk banyak penguncian dan kode terkait mutex lainnya dalam kasus di mana invarian yang sementara terganggu dapat dibangun kembali dengan cepat.

(Sunting): Beberapa peringatan tentang variabel otomatis dan semacamnya:

1. jika sebuah rutin yang menggunakan pengalihan tugas dipanggil dari kedua utas, umumnya akan diperlukan untuk mengkompilasi dua salinan rutin (mungkin dengan # memasukkan file sumber yang sama dua kali, dengan pernyataan # definisi yang berbeda). File sumber apa pun yang diberikan akan berisi kode hanya untuk satu utas, atau yang lain akan berisi kode yang akan dikompilasi dua kali - sekali untuk setiap utas - jadi saya dapat menggunakan makro seperti "#define delay (x) delay_t1 (x)" atau #define delay (x) delay_tx (x) "tergantung pada utas mana yang saya gunakan.
2. Saya percaya bahwa kompiler PIC yang tidak dapat "melihat" suatu fungsi yang dipanggil akan menganggap bahwa fungsi seperti itu dapat merusak setiap dan semua register CPU, sehingga menghindari kebutuhan untuk menyimpan register dalam rutinitas pengalihan tugas [manfaat bagus dibandingkan dengan preemptive multitasking]. Siapa pun yang mempertimbangkan pengalih tugas serupa untuk CPU lain harus mengetahui konvensi register yang digunakan. Mendorong register sebelum beralih tugas dan memunculkannya setelahnya adalah cara mudah untuk mengurus berbagai hal, dengan asumsi ruang stack yang memadai ada.

Multitasking yang kooperatif tidak memungkinkan seseorang untuk sepenuhnya keluar dari masalah penguncian dan semacamnya, tetapi hal itu benar-benar menyederhanakan banyak hal. Dalam RTOS preemptive dengan pemulung sampah, misalnya, perlu untuk memungkinkan objek untuk disematkan. Saat menggunakan switcher kooperatif, ini tidak perlu asalkan kode menganggap objek GC dapat memindahkan taskswitch kapan saja () dipanggil. Kolektor pemadatan yang tidak perlu khawatir tentang benda yang disematkan bisa jauh lebih sederhana daripada yang tidak.

Saya telah menggunakan Salvo di MSP430. Ini sangat ringan pada sumber daya prosesor dan, asalkan Anda mematuhi aturan implementasi, sangat mudah digunakan dan dapat diandalkan. Ini adalah OS kooperatif dan mensyaratkan bahwa sakelar tugas dilakukan pada level panggilan fungsi luar dari fungsi tugas. Kendala ini memungkinkan OS untuk bekerja di perangkat memori yang sangat kecil tanpa menggunakan sejumlah besar ruang stack yang mempertahankan konteks tugas.

Pada AVR32 saya menggunakan FreeRTOS. Sekali lagi sangat dapat diandalkan sejauh ini tetapi saya telah memiliki beberapa perbedaan konfigurasi / versi antara versi yang diterbitkan FreeRTOS dan versi yang disertakan dengan kerangka kerja Atmel. Namun ini memiliki keuntungan bahwa itu gratis!

Edisi Desember Everyday Practical Electronics memiliki bagian 3 dari seri Sistem Operasi Waktu Nyata untuk PIC (di Kolom PIC n 'Mix) dan memiliki detail pengaturan FreeRTOS dengan MPLAB dan PICKit 2. Dua artikel sebelumnya (yang saya belum melihat) tampaknya telah membahas manfaat dari berbagai RTOS dan diselesaikan di FreeRTOS. Setelah artikel saat ini telah mengatur lingkungan pengembangan mereka melanjutkan untuk mulai merancang jam digital biner. Tampaknya ada setidaknya satu bagian lagi untuk topik ini.

Saya tidak yakin seberapa tersedia EPE di AS, tetapi tampaknya ada Toko AS yang ditautkan dari situs mereka dan mungkin ada salinan elektronik yang tersedia.

Kompilator CCS untuk PIC hadir dengan RTOS sederhana. Saya belum mencobanya, tetapi jika Anda memiliki kompiler ini, akan mudah untuk bereksperimen.

Pertanyaan yang terkait erat: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

Anda belum banyak bicara tentang aplikasi Anda. Apakah Anda menggunakan RTOS sangat tergantung pada apa yang perlu Anda lakukan dalam PIC. Kecuali jika Anda melakukan beberapa hal asinkron yang berbeda, yang membutuhkan batasan waktu yang ketat, atau menjalankan beberapa utas, maka RTOS mungkin berlebihan.

Ada banyak cara untuk mengatur waktu pada mikrokontroler tergantung pada apa yang paling penting:

1. Frame rate konstan: Untuk PIC yang menjalankan pengontrol servo yang harus dijalankan pada 1000Hz misalnya. Jika algoritma PID membutuhkan waktu kurang dari 1 ms untuk dieksekusi, maka Anda dapat menggunakan sisa milidetik untuk melakukan tugas lain, seperti memeriksa bus CAN, membaca sensor, dll.

2. Semua interupsi: Segala sesuatu yang terjadi dalam PIC dipicu oleh interupsi. Interupsi dapat diprioritaskan sesuai dengan pentingnya acara.

3. Tempelkan dalam satu lingkaran dan lakukan segalanya secepat mungkin. Anda mungkin menemukan ini memberikan batas waktu yang sesuai.