Situasi spesifik saya, ketika saya menggunakan bahasa scripting yang ditafsirkan dalam aplikasi utama:
Ada perangkat eksternal yang melakukan beberapa fungsi. Pengukuran, kontrol, pembacaan. Itu cukup "bodoh" itu sendiri dan membutuhkan kontrol yang tepat, langkah-demi-langkah, termasuk banyak status tunggu dan pengambilan keputusan ad-hoc di sisi mekanisme kontrol.
Berbagai fungsi perangkat diperlukan di berbagai titik aplikasi utama, pada waktu yang berbeda, seringkali sesuai permintaan. Aplikasi utama tidak memungkinkan untuk menunggu negara seperti itu, semuanya harus dilakukan dengan mesin negara yang terbatas.
Sekarang siapa pun yang menulis mesin keadaan terbatas tahu menerapkan keadaan tunggu secara efektif setidaknya dua, sering tiga atau empat keadaan internal mesin. Menerapkan dua puluh negara tunggu untuk berbagai fungsi (dan menunggu tanggapan mereka dan bereaksi sesuai) dari perangkat eksternal akan menjadi pengalaman yang sangat, sangat membuat frustrasi.
Jadi, alih-alih ada keadaan "jalankan fungsi tanpa menunggu", "jalankan fungsi pemblokiran", "jalankan fungsi percabangan / kondisional / lompati" dalam mesin keadaan terbatas, mungkin total enam negara. Dan ada skrip kontrol yang dijadwalkan untuk dieksekusi, kemudian dieksekusi oleh penerjemah yang mengendalikan perangkat eksternal, dan hasilnya ditempatkan di tempat yang diperlukan.
Kesimpulannya, aplikasi: dalam RTOS, menggunakan bahasa skrip yang diinterpretasikan secara internal dapat sangat mengurangi kerumitan dalam melakukan tugas-tugas yang berlimpah di keadaan menunggu (fungsi pemblokiran).