Belajar Embedded Engineer - Real-Time Constraints

#Pendahuluan

Sejauh ini kalian sudah membangun firmware yang "bekerja": task jalan, interrupt menanggapi, data terkirim. Episode ini mengubah pertanyaannya dari "apakah bekerja?" menjadi "apakah selesai tepat waktu?" — dan itu adalah pertanyaan yang membedakan embedded dari software biasa.

Bayangkan airbag mobil: data sensor tabrakan harus diproses dalam hitungan milidetik, selalu, tanpa pengecualian. Terlambat 2 ms berarti keputusan salah — dan itu soal hidup-mati. Inilah dunia real-time systems: bukan soal kecepatan, tapi soal kepastian. Episode ini membangun kemampuan menganalisis dan menjamin perilaku waktu firmware kalian.

#Deadline, Jitter, dan Determinisme

Tiga konsep yang membentuk bahasa real-time:

Determinisme berarti perilaku waktu bisa diprediksi: diberi input yang sama dan kondisi yang sama, waktu eksekusi selalu konsisten. Sistem real-time yang baik bukan yang tercepat — tapi yang jitter-nya terkecil dan deadline-nya terjamin.

#Soft vs Hard Real-Time

Penting membedakan seberapa ketat kebutuhan waktunya:

Imbasnya pada desain: sistem hard real-time butuh analisis matematis dan RTOS dengan scheduling yang terbukti deterministik; sistem soft real-time cukup dengan prioritas dan observasi yang baik. Jangan mendesain hard real-time untuk kebutuhan soft — itu boros dan menyiksa.

#Scheduler & Prioritas yang Benar

RTOS di episode 7 menawarkan scheduling; episode ini membahas pemilihannya. Model paling umum untuk hard real-time: fixed-priority preemptive scheduling — setiap task punya prioritas tetap, dan task berprioritas tinggi selalu mendahului. Di sinilah aturan desain prioritas dibahas tuntas:

1. Task dengan deadline lebih dekat dapat prioritas lebih tinggi (Rate-Monotonic Scheduling).
2. Task periodik dengan periode pendek → prioritas lebih tinggi.
3. Jangan memberi prioritas berdasarkan "pentingnya bisnis" — tapi berdasarkan timing.

Analisis standar untuk memvalidasi: Rate-Monotonic Analysis (RMA) — periksa apakah total "utilisasi" semua task masih di bawah batas yang dapat dijamin schedulable. Untuk 3 task atau lebih, uji sederhananya: jumlahkan rasio (waktu eksekusi / periode) semua task; jika di bawah n(2^(1/n) - 1), scheduling terbukti aman. Detail penuhnya ada di buku real-time; yang harus kalian ingat adalah polanya: deadline ketat → prioritas tinggi → buktikan dengan analisis, bukan keberanian.

#Perangkap Jitter di Firmware

Jitter di firmware nyata tidak datang dari kemalasan — datang dari kebiasaan yang tampak tidak berbahaya:

1. vTaskDelay yang meleset — delay "relatif" menggeser fasa setiap siklus; pakai vTaskDelayUntil untuk periode presisi:

const TickType_t period = pdMS_TO_TICKS(10);
TickType_t last_wake = xTaskGetTickCount();
 
for (;;) {
    vTaskDelayUntil(&last_wake, period);  /* tunggu sampai deadline periodik */
    sample_sensor();
}

2. ISR panjang — tiap milidetik ISR memblokir task lain (episode 8); geser pekerjaan berat ke task.
3. Debug via UART blocking — print 100 byte di UART bisa memakan ratusan mikrodetik; pakai buffer/non-blocking.
4. Heap/malloc — durasi tak terduga (episode 3); hindari di path real-time.
5. Cache/Flash wait states — akses flash lebih lambat dari RAM; hot loop bisa ditaruh di RAM (__attribute__((section(".ramfunc")))).
6. Interrupt priority inversion — ISR berprioritas rendah diblokir task, membuat deadline terlewat; gunakan mutex priority inheritance.

Jitter bukan anomali — ia produk dari semua kebiasaan di atas. Mengukur dan menghilangkannya adalah pekerjaan nyata real-time engineer.

#Praktik: Mengukur Jitter

1. Ambil task periodik dengan vTaskDelayUntil periode 10 ms.
2. Toggle GPIO di awal dan akhir task.
3. Hubungkan logic analyzer (episode 9) ke pin itu dan ukur periode aktual antar toggle.
4. Variasikan beban: tambah task berat, UART print, dan heap allocation — amati jitter membesar.
5. Hilangkan satu per satu, ukur lagi, dan kuantifikasi perbaikannya dalam mikrodetik.

#Common Pitfalls

1. Prioritas berdasarkan "kesan penting" bukan timing — deadline terlewat tak terduga.
2. vTaskDelay relatif — jitter periodik yang menumpuk; ganti vTaskDelayUntil.
3. ISR melakukan banyak hal — waktu eksekusi tak terkendali.
4. Blocking I/O di path real-time — UART, print, malloc.
5. Tidak pernah mengukur — real-time tanpa angka = harapan kosong.

#Penutup

Inti yang harus dibawa pulang:

• Deadline, response time, dan jitter adalah tiga ukuran utama sistem real-time.
• Hard real-time butuh analisis dan RTOS deterministik; soft real-time cukup observasi.
• Prioritas task ditentukan oleh timing (rate-monotonic), bukan kesan penting.
• Jitter dibunuh dengan: vTaskDelayUntil, ISR singkat, non-blocking I/O, tanpa malloc.
• Ukur jitter dengan logic analyzer — bukti lebih berharga dari dugaan.

Di episode 15 selanjutnya kita menyimpan data dengan benar: storage & filesystems — flash, LittleFS/FAT, dan wear leveling, dengan praktik membangun sistem penyimpanan di perangkat. Data yang kalian kumpulkan tidak akan berharga jika perangkatnya rusak setelah flash ditulis berulang kali. Sampai jumpa di episode 15!