RTOS'ta preemptive priority-based scheduling nasıl çalışır? Bare-metal super loop yerine ne zaman RTOS tercih edilir?

Preemptive priority scheduling

Scheduler her zaman Ready durumundaki en yüksek öncelikli task'ı çalıştırır. Daha yüksek öncelikli bir task hazır hâle geldiğinde (ör. bir semaphore verildi, ISR'dan bildirim geldi, delay süresi doldu) çalışan task hemen kesilir (preemption).

• Aynı öncelikteki task'lar time slicing ile (her tick'te) round-robin paylaşır (FreeRTOS'ta configUSE_TIME_SLICING).
• Hiçbir task hazır değilse idle task çalışır; burada düşük güç moduna geçilebilir (tickless idle).

Task durumları

void sensor_task(void *arg) {
    TickType_t last = xTaskGetTickCount();
    for (;;) {
        read_sensor();
        vTaskDelayUntil(&last, pdMS_TO_TICKS(10));   /* sabit periyot, drift yok */
    }
}

xTaskCreate(sensor_task, "sensor", 256, NULL, 3, NULL);
vTaskStartScheduler();

vTaskDelay "şimdiden itibaren bekle", vTaskDelayUntil "sabit periyotla uyan" demektir; periyodik kontrol döngülerinde ikincisi kullanılır.

Öncelik atama

Klasik yaklaşım Rate Monotonic: periyodu kısa olan task'a yüksek öncelik. En yüksek öncelikler deadline'ı sıkı işlere (motor kontrol, haberleşme), düşük öncelikler loglama ve UI'a verilir.

Starvation riski: Yüksek öncelikli task hiç bloklanmazsa düşük öncelikli task'lar hiç çalışmaz. Her task'ın döngüsünde mutlaka bloklayan bir çağrı olmalıdır.

Super loop mu, RTOS mu?

• Super loop yeterli: Az sayıda iş, basit zamanlama, çok kısıtlı RAM/Flash, kolay doğrulama gereken sistemler.
• RTOS tercih edilir: Farklı periyot ve deadline'lara sahip çok sayıda bağımsız iş; bloklayan sürücüler (TCP/IP, USB, dosya sistemi); yanıt süresinin en uzun döngü süresine bağlı olmaması gerektiğinde.

RTOS'un maliyeti: her task için ayrı stack (RAM), context switch süresi ve senkronizasyon hatası riski (deadlock, race condition).