Gömülü sistemlerde RTOS mu, bare-metal mi? Doğru seçim nasıl yapılır

Mikrodenetleyici projelerinde RTOS ile bare-metal arasındaki seçim bir moda meselesi değildir. Kararı aynı anda yürüyen iş sayısı, zamanlama gereksinimleri, bellek ve güç bütçesi ve ekibin deneyimi verir. Bu yazıda iki yaklaşımı karşılaştırıyor, sık yapılan hataları ve sade bir karar tablosunu paylaşıyoruz.

Projeye başlarken iki uç tavır sık görülür: "Basit bir cihaz, döngü yeter" ya da "Profesyonel ürün, RTOS şart". İkisi de bazen doğru, bazen pahalı bir hatadır. Doğru soru, firmware'in ilerleyen sürümlerde ne kadar karmaşıklaşacağıdır.

Bare-metal: süper döngü ve kesmeler

Bare-metal yaklaşımda işletim sistemi yoktur. Tipik yapı:

• Sonsuz bir ana döngü sırayla görevleri çağırır: sensörü oku, hesapla, haberleş, ekranı güncelle.
• Zamana kritik olaylar kesmelerle (interrupt) yakalanır; kesme kısa tutulur, asıl iş döngüye bırakılır.
• Zamanlama genelde bir zamanlayıcıyla üretilen "tick" ve durum makineleriyle yönetilir.

Güçlü yanları: Az bellek kullanır, davranışı öngörülebilirdir, hata ayıklaması kolaydır, en düşük güç modlarına geçiş doğrudan kontrol edilir.

Zayıf yanları: Görev sayısı arttıkça döngü karmaşıklaşır. Uzun süren bir iş (örneğin flash'a yazma veya yavaş bir haberleşme) diğer her şeyi geciktirir. Bunu önlemek için her işi küçük parçalara bölmek gerekir, bu da kodu okunmaz hale getirebilir.

RTOS: görevler, öncelikler ve zamanlayıcı

Gerçek zamanlı işletim sistemi (RTOS), işi bağımsız görevlere (task/thread) böler ve bir zamanlayıcı ile hangisinin çalışacağına önceliğe göre karar verir. FreeRTOS, Zephyr ve benzerleri yaygın örneklerdir.

Güçlü yanları:

• Her görev kendi döngüsünü yazar; kod modüler ve okunur kalır.
• Yüksek öncelikli bir iş, düşük öncelikli uzun bir işi bekletmeden çalışır.
• Kuyruk, semafor ve olay bayrakları ile görevler arası haberleşme standarttır.
• Ağ yığını, dosya sistemi ve TLS gibi hazır bileşenler genelde RTOS ile gelir.

Bedeli:

• Her görevin kendi yığını (stack) vardır; RAM ihtiyacı artar.
• Yarış durumu (race condition), kilitlenme (deadlock) ve öncelik terslemesi gibi yeni hata sınıfları ortaya çıkar.
• Ekibin bu kavramlara hâkim olması gerekir; aksi halde hata ayıklama zorlaşır.

Karar tablosu

Durum	Öneri
Tek amaçlı cihaz, 3–4 basit iş, çok kısıtlı RAM	Bare-metal
Pille yıllarca çalışacak, çoğu zaman uyuyan sensör	Genelde bare-metal
Ağ bağlantısı (Wi-Fi, hücresel, Ethernet) + TLS	RTOS
Birbirinden bağımsız çok sayıda iş, farklı zaman gereksinimleri	RTOS
Ekran, dosya sistemi, USB gibi zengin çevre birimleri	RTOS
Ürün yol haritası belirsiz, özellikler eklenecek	RTOS'a hazır mimari

Ara yol da vardır: Bare-metal başlayıp sürücüleri ve iş mantığını donanımdan ve zamanlayıcıdan bağımsız yazmak, gerekirse sonra RTOS'a geçişi kolaylaştırır.

Güç tüketimi açısından

Bare-metal, uyku modlarını doğrudan kontrol ettiği için düşük güç tasarımında avantajlıdır. Ancak modern RTOS'ların çoğu tickless modu destekler: Yapılacak iş yoksa zamanlayıcı kesmesi durdurulur ve çekirdek derin uykuya girer. Doğru yapılandırılmış bir RTOS ile bare-metal arasındaki fark çoğu üründe küçüktür. Güç bütçesinin nasıl çıkarılacağını düşük güç tasarımı yazımızda anlattık.

Sık yapılan hatalar

• Kesmede uzun iş yapmak: Hangi yaklaşımı seçerseniz seçin, kesme içinde bekleme, yazdırma ya da uzun hesap yapılmaz.
• Yığın boyutunu tahminle vermek: RTOS'ta görev yığınları ölçülmeli; taşma tespiti açık tutulmalı.
• Her şeyi ayrı görev yapmak: Gereksiz görev sayısı RAM'i ve karmaşıklığı artırır. Birbirine sıkı bağlı işler aynı görevde kalabilir.
• Paylaşılan veriyi korumamak: İki görevin aynı değişkene yazdığı yerde kuyruk ya da mutex kullanılmalıdır.
• Takılan görevi fark etmemek: Her kritik görevin "yaşıyorum" sinyali vermesi ve bunun watchdog ile denetlenmesi gerekir.

Test edilebilirlik

İki yaklaşımda da iş mantığını donanımdan ayırmak test edilebilirliği artırır. RTOS projelerinde görevler arası zamanlama hataları masada zor yakalanır; bu yüzden HIL testi ile gerçek donanım üzerinde uzun süreli testler özellikle değerlidir.

SSS

RTOS kullanmak ürünü yavaşlatır mı?
Bağlam değiştirme maliyeti mikrosaniyeler mertebesindedir. Çoğu uygulamada fark edilmez; öncelikli görevler sayesinde tepki süresi çoğu zaman bare-metal'den daha öngörülebilir olur.

Küçük bir MCU'da RTOS çalışır mı?
Birçok RTOS birkaç KB RAM ile çalışabilir. Ancak her görevin yığını eklendiğinde toplam ihtiyaç hızla artar; RAM'i çok kısıtlı çiplerde bare-metal daha rahattır.

Sonradan RTOS'a geçmek zor mu?
Kod donanıma ve döngüye sıkı bağlıysa zordur. Sürücüler, iş mantığı ve zamanlama ayrı katmanlarda tutulduysa geçiş yönetilebilir.

TW Bilişim bu konuda ne yapıyor?
Ürünün yol haritasına göre bare-metal ya da RTOS tabanlı firmware mimarisi tasarlıyor; sürücü katmanı, görev yapısı, güç yönetimi ve test altyapısını birlikte kuruyoruz.

Sonuç

Basit ve uzun süre pille çalışan cihazlarda bare-metal hâlâ güçlü bir seçenektir. Ağ bağlantısı, çok sayıda bağımsız iş ve büyüyen bir özellik listesi varsa RTOS, kodun yönetilebilir kalmasını sağlar. Hangisini seçerseniz seçin, katmanlı bir mimari ve iyi bir test altyapısı sonradan yön değiştirmeyi mümkün kılar.

Firmware mimarinizi birlikte planlamak isterseniz: iletişim veya [email protected].