RTOS / Benchmark

Gerçek Zamanlı Sisteminiz Neden Deadline Kaçırıyor?

IRQ Gecikmesi Derinlemesine: 38.7µs'den 4.2µs'ye Ölçülen Sonuçlar

Spikedge Mühendislik1 Nisan 20268 dk okuma
Gerçek Zamanlı Sisteminiz Neden Deadline Kaçırıyor?
oscilloscope-verified

Bu Kanıtta Ne Çözüldü

Gerçek zamanlı sistemler sessizce bozulur — çökmez, sadece deadline'ları kaçırır. STM32H7 üzerinde TI-RTOS HWI direct dispatch ile worst-case IRQ gecikmesini 38.7µs'den 4.2µs'ye indirdik. Her adım osiloskop doğrulamalı.

Bu yazı, Spikedge mühendislik ekibinin saha deneyimleri ve teknik değerlendirmeleri temel alınarak hazırlanmıştır.

Gerçek Zamanlı Sisteminiz Neden Deadline Kaçırıyor?

IRQ Gecikmesi Derinlemesine: 38.7µs → 4.2µs

Kanıt Metrikleri

Metrik Önce Sonra Delta
IRQ Gecikmesi (worst-case) 38.7µs 4.2µs −89%
Jitter (σ) 4.8µs 0.3µs −94%
Kaçırılan deadline Sürekli 0 Tamamen giderildi
CPU yükü %71 %34 −52%

Giriş

Gerçek zamanlı sistemler yüksek sesle bozulmaz — sessizce bozulur. Gömülü sistemde kaçırılan bir deadline nadiren exception fırlatır. Bunun yerine: kararsız kontrol döngüleri, tutarsız sensör füzyonu veya sahada tekrarlanamayan arızalar olarak kendini gösterir.

Çoğu durumda kök neden "yavaş kod" değildir. Sorun kesme gecikmesi ve jitter'dır.

Kök Neden: IRQ Gecikmesi

IRQ gecikmesi = kesme tetiklenme anı → ISR başlangıç anı arasındaki süre.

Bu süreyi etkileyen faktörler:

  • Kesme öncelik yapılandırması (NVIC)
  • O anki çalışma bağlamı
  • Bellek/önbellek durumu
  • Bus çekişmesi
  • ISR iç içe geçmesi

Temel Sorunlar

1. NVIC Öncelik Yanlış Yapılandırması

FreeRTOS tick interrupt (IRQ öncelik 5), motor kontrol ISR ile aynı preemption seviyesini paylaşıyordu. Worst-case'de tick, motor ISR'ını preempt ediyordu: +12–18µs ekstra gecikme.

2. Scheduler Context Switch Yükü

Her görev geçişinde tam 256B stack frame kopyalanıyordu. Kritik yol üzerinde ~6µs overhead her geçişte.

3. Timer Coalescing

İlgisiz interrupt'lar gruplandırılıyor, 3–5µs arasında değişen gecikme dalgalanması üretiyordu. Jitter birikiminin ana kaynağı.

4. ISR'da Non-Critical İş

ISR işleyicisi loglama (UART DMA) ve shared state güncellemesi yapıyordu. Kritik yol üzerinde ~4µs non-critical harcama.

Ne Değiştirdik

  1. FreeRTOS → TI-RTOS HWI Direct Dispatch — Scheduler overhead kritik ISR yolundan tamamen kaldırıldı. Worst-case gecikme %62 azaldı
  2. Motor ISR önceliği en üst NVIC seviyesine (priority = 31) — Tick interrupt preemption riski sıfıra indi
  3. Tickless mode aktif, timer coalescing devre dışı — Jitter σ 4.1µs'den 0.3µs'ye düştü
  4. Non-critical iş SWI deferred handler'a taşındı — ISR execution süresi %40 kısaldı
  5. Zero-copy mailbox ile task-ISR haberleşmesi — Context switch 8.2µs → 1.1µs
  6. Kritik görevler R5F core 0'a, ertelenmiş görevler core 1'e — L1 cache thrashing giderildi
  7. Tüm paylaşılan mutex'lere öncelik tavanı protokolü — Priority inversion riski sıfır

Üretim Doğrulaması

72 saat kesintisiz çalışma. %100 sürekli yük. 10.000 örnek/ölçüm. Kaçırılan deadline: sıfır.

IEC 62443 uyumluluk kanıtı için CPU headroom'dan runtime izleme ve hata kayıt kanalları kuruldu.

İlgili Kaynaklar

Keşfetmeye Devam Et

BenchmarkRTOSSTM32H7IRQDeterminizm

Spikedge Mühendislik Ekibi

Bu teknolojiyi kendi sisteminizde kullanıyor musunuz?

Spikedge mühendisleriyle birebir teknik analiz planlayın. Platformunuzu, darboğazınızı ve hedeflerinizi konuşalım.

Mimari Denetim Talebi