Belajar Firmware Engineer - Real-Time Constraints

#Pendahuluan

Setelah di episode 15 kita menulis firmware Rust, pada episode ini kita kembali ke filosofi paling mendasar embedded: waktu. Bukan "secepat mungkin" — melainkan tepat waktu, selalu, dalam kondisi apa pun. Ini yang membedakan sistem real-time dari sekadar program.

Mengapa ini penting? Coba bayangkan airbag mobil: dari sensor tabrakan hingga airbag mengembang, tenggatnya milidetik, dan keterlambatan berarti nyawa. Motor, robot, telekomunikasi, medis — semua butuh jaminan waktu. Di episode ini kalian belajar memikirkan deadline, determinism, dan bagaimana menganalisisnya sebelum kode ditulis.

#Apa Itu Real-Time?

Sistem real-time bukan "sistem yang cepat" — melainkan sistem yang benar dari sisi waktu: hasil harus datang sebelum deadline. Ada dua kelas:

Perluasan lain: firm real-time (menengah). Prinsip penentu: seberapa mahal pelanggaran deadline.

Konsep terkait:

• Determinism — perilaku dapat diprediksi: input yang sama + kondisi sama → hasil yang sama dalam waktu yang sama.
• Jitter — variasi waktu respons. Rendah jitter = respons konsisten.
• Deadline — batas waktu absolut penyelesaian tugas.

Latency    : waktu dari event ke reaksi pertama
Throughput : jumlah pekerjaan per satuan waktu
Jitter     : deviasi latency antar eksekusi

#WCET: Worst-Case Execution Time

Anda tidak bisa menjamin deadline tanpa tahu berapa lama task bisa berjalan. WCET (Worst-Case Execution Time) adalah batas atas durasi eksekusi sebuah task — diukur atau dianalisis untuk input terburuk:

mulai = timer_now()
fungsi_tugas()
durasi = timer_now() - mulai
// ulangi ribuan kali + variasi input -> dapat distribusi
// WCET ≈ maksimum yang terukur + margin

Yang sering dilupakan: WCET bukan rata-rata. Loop dengan kondisi terburuk, cache miss, dan interrupt preempt menambah waktu. Estimasi yang terlalu optimis = deadline dilewati di lapangan.

#Analisis Penjadwalan

Untuk sistem multitasking (RTOS dari episode 7), kita perlu membuktikan semua task memenuhi deadline. Dua pendekatan klasik:

#Rate-Monotonic (RM)

Prioritas tetap: task dengan periode lebih pendek dapat prioritas lebih tinggi. Analisis utilisasi sederhana untuk n task periodik: jika utilisasi total U = Σ (C_i / T_i) kurang dari n(2^(1/n) - 1), semua task terjamin memenuhi deadline.

#Earliest Deadline First (EDF)

Task dengan deadline terdekat jalan duluan. Optimal secara teori, tapi kompleks di implementasi embedded.

Task A: periode 10 ms, WCET 2 ms  -> util 0.2
Task B: periode 20 ms, WCET 3 ms  -> util 0.15
Total util = 0.35 < 0.69 (batas 2 task) -> aman

Batas RM untuk 2 task adalah 2·(√2 − 1) ≈ 0.83 — aman di 0.35, dengan margin sehat. Formula ini bisa dihitung cepat di awal desain.

#Desain RT yang Benar

#Prioritaskan Latensi Interrupt

Interrupt (episode 6) adalah jalur respons tercepat — jaga tetap pendek:

1. Jaga ISR minimal (set flag / data siap)
2. Kerja berat di task berprioritas sesuai deadline
3. Hindari blocking pada jalur kritis
4. Ukur latency interrupt dan jitter secara berkala

#Hindari Blocking pada Jalur Kritis

Task dengan deadline ketat tidak boleh menunggu lama di mutex, queue kosong, atau I/O lambat. Gunakan timeout, bukan portMAX_DELAY tak terbatas:

if (xSemaphoreTake(mutex, pdMS_TO_TICKS(5)) == pdTRUE) {
    // aman: dapat mutex
} else {
    // timeout: jalankan jalur alternatif / laporkan
}

#Prediksi dan Stabilitas

Determinism dirusak oleh: alokasi dinamis (episode 8), cache policies yang tidak terkontrol, dan prioritas yang sering berubah. Desain yang baik menghapus variabilitas, bukan mengkompensasinya.

#Praktik: Desain RT Firmware

Analisis sebuah task yang sering ditemui — sampling ADC + kontrol PWM:

Periode     : 1 ms (1000 Hz)
WCET sampl  : 150 us  (ADC + filter)
WCET compute: 400 us  (PID + output)
Deadline    : 900 us  (margin 100 us)
 
Utilisasi = (150+400)/1000 = 0.55
Latency interrupt target: < 50 us
Jitter target            : < 100 us

Langkah verifikasi: ukur latency interrupt nyata (oscilloscope/GPIO toggle), ukur WCET task, konfirmasi utilisasi di bawah batas analisis, lalu jalankan stress test (interrupt banjir + workload maksimal).

#Kesalahan Umum Real-Time

1. Mengukur rata-rata, bukan worst-case — deadline terlewat justru di kasus terburuk.
2. ISR panjang — latensi seluruh sistem naik (episode 6).
3. Blocking tanpa timeout — task hang menunggu resource.
4. malloc di jalur kritis — variabilitas + risiko gagal.
5. Prioritas tidak dianalisis — "rasanya jalan", tanpa bukti utilisasi.
6. Cache/interrupt preemption tidak dihitung — WCET meleset.

#Penutup

Inti yang harus dibawa pulang:

• Real-time = memenuhi deadline, bukan "cepat"; hard vs soft deadline.
• Ukur latency, throughput, jitter; estimasi WCET bukan rata-rata.
• Rate-Monotonic untuk prioritas tetap; formula utilisasi membuktikan kelayakan.
• Desain RT: ISR pendek, blocking dengan timeout, tanpa alokasi dinamis di jalur kritis.
• Verifikasi dengan stress test + pengukuran nyata.

Di episode 17 selanjutnya kita menata penyimpanan: Storage & Filesystem — flash memory, LittleFS dan FAT, wear leveling, serta desain firmware yang menyimpan data dengan aman dan tahan terhadap putusnya listrik. Data kalian akan bertahan!