Belajar Embedded Engineer - Interrupts & Concurrency

#Pendahuluan

Di episode 7 kalian belajar task, semaphore, dan queue di FreeRTOS. Tapi ada satu "penduduk" lain di MCU yang tidak tunduk pada scheduler: interrupt. Interrupt adalah penyela yang bisa memotong task apa pun — termasuk task berprioritas tertinggi — kapan pun hardware mengirim sinyal. Karena sifatnya yang tak terduga, interrupt adalah sumber race condition dan bug paling licin di firmware.

Episode ini membangun aturan mainnya: bagaimana merancang ISR (Interrupt Service Routine) yang singkat, bagaimana memilih prioritas interrupt yang deterministik, dan bagaimana berkomunikasi dengan task RTOS secara aman dari dalam ISR. Kuasai ini, dan firmware kalian akan responsif sekaligus stabil.

#Interrupt: Penyela yang Tak Tunduk pada Scheduler

Bayangkan kalian sedang menulis laporan (task) di kantor — lalu telepon berdering (interrupt). Kalian berhenti, mencatat pesan singkat, lalu kembali menulis. Itu analogi interrupt: hardware memanggil, CPU menyimpan konteks pekerjaan saat ini, menjalankan ISR, lalu kembali ke pekerjaan semula.

Konteks ini disimpan otomatis oleh hardware (stack diisi register CPU). Setelah ISR selesai, eksekusi kembali ke titik semula — seolah tidak terjadi apa-apa. Karena itu ISR harus sesingkat mungkin: selama ISR berjalan, pekerjaan lain (termasuk task real-time) terhenti.

#Anatomi ISR yang Baik

ISR yang baik hanya melakukan tiga hal, dan tidak lebih:

1. Membaca sumber — tentukan penyebab interrupt (register status).
2. Menyimpan data mentah — misalnya byte UART ke ring buffer atau queue.
3. Membersihkan flag — beri tahu hardware bahwa interrupt sudah ditangani (lupa ini = interrupt berulang selamanya / CPU hang).

Semua pemrosesan berat (parsing, format, log, update state machine) didelegasikan ke task biasa. Pola ini disebut deferred work atau "ISR menyelesaikan urusan di konteks task":

void UART2_IRQHandler(void) {
    BaseType_t higher = pdFALSE;
    if (UART2->SR & (1U << 5)) {            /* RXNE: ada byte baru */
        uint8_t b = UART2->DR;
        xQueueSendFromISR(rx_queue, &b, &higher);
        UART2->SR &= ~(1U << 5);            /* bersihkan flag RXNE */
    }
    portYIELD_FROM_ISR(higher);             /* jika ada task menunggu, beri jalan */
}

Perhatikan tiga konvensi khusus ISR di FreeRTOS:

• xQueueSendFromISR — bukan xQueueSend biasa; versi ini aman dipanggil dari interrupt dan tidak pernah memblokir.
• higher — jika ISR "membangunkan" task, kernel menandai bahwa task itu mungkin lebih layak jalan daripada task yang sedang dipotong; portYIELD_FROM_ISR lalu menyerahkan CPU.
• Tanpa vTaskDelay dan tanpa mutex di ISR — keduanya memblokir, dan ISR tidak boleh memblokir.

Aturan umumnya: di ISR, hanya fungsi berakhiran FromISR yang boleh dipanggil.

#Prioritas: NVIC vs Prioritas Task

Jangan bingung dua "prioritas" yang berbeda ini:

Prioritas NVIC menentukan: jika dua interrupt datang bersamaan, mana yang jalan dulu, dan apakah sebuah ISR bisa disela ISR lain. Aturan desainnya:

1. Prioritas tertinggi hanya untuk ISR paling kritis waktu — misalnya timing engine, notifikasi sensor yang menentukan sample rate.
2. Jangan semuanya tinggi — ISR prioritas tinggi yang terlalu sering memblokir ISR lain = jitter dan bug timing.
3. Kelompokkan berdasarkan tenggat — deadline ketat dapat prioritas lebih tinggi (topik penuh di episode 14).

#Race Condition dan Cara Membunuhnya

Race condition terjadi saat ISR dan task (atau dua ISR) mengakses data yang sama tanpa sinkronisasi. Contoh klasik:

static uint16_t latest_sample;
 
void ADC_IRQHandler(void) {
    latest_sample = ADC1->DR;        /* ISR menulis */
}
 
void vTaskDisplay(void *pv) {
    for (;;) {
        printf("%u", latest_sample); /* task membaca — bisa kena data robek */
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

Jika latest_sample bertipe uint32_t atau lebih besar, ISR bisa menimpa data di tengah pembacaan task (pada bus yang tidak atomic). Tiga solusi, dari paling ringan ke paling kokoh:

1. Interrupt disable — taskENTER_CRITICAL() / taskEXIT_CRITICAL() untuk mengunci akses singkat; berhenti sejenak, tapi deterministik dan ringan.
2. Queue — ISR menyimpan ke queue, task membaca — ini solusi terbaik untuk data streaming (pola di atas).
3. Mutu berbasis volatile — hanya aman jika variabelnya atomic (ukuran ≤ lebar bus dan sesuai alignment); gunakan untuk flag sederhana.

#Praktik: ISR Handler yang Benar

Praktik untuk board kalian:

1. Hubungkan satu push button ke pin EXTI (interrupt eksternal).
2. Tulis ISR yang hanya memasukkan "1" ke queue tombol.
3. Buat task yang menunggu queue dan mencetak pesan setiap kali tombol ditekan.
4. Uji: tambahkan delay 5 detik di task utama. Ketika tombol ditekan, pesan harus tetap muncul cepat — bukti bahwa ISR membangunkan task lewat FromISR.

Latihan lanjutan: aktifkan stack overflow check dan jalankan dengan prioritas task yang berbeda-beda; amati urutan eksekusi berubah sesuai prioritas.

#Common Pitfalls

1. ISR panjang — parsing dan format di ISR adalah resep jitter (episode 14).
2. Lupa membersihkan flag interrupt — MCU hang dengan interrupt tak berujung.
3. Memakai API non-FromISR di ISR — crash tak tentu.
4. Berbagi data dengan ISR tanpa volatile + sinkronisasi — race condition.
5. Prioritas NVIC semua maksimum — ISR saling memblokir, sistem tidak responsif.

#Penutup

Inti yang harus dibawa pulang:

• ISR harus singkat: baca sumber, simpan data, bersihkan flag; sisanya di task.
• Pakai FromISR API dan portYIELD_FROM_ISR saat berkomunikasi dengan task dari ISR.
• Prioritas NVIC (hardware) dan prioritas task (scheduler) adalah dua hal berbeda.
• Race condition dibunuh dengan: critical section, queue, atau flag volatile atomic.

Di episode 9 selanjutnya kita menyiapkan senjata debugging: debugging & toolchain — GDB, OpenOCD, trace, dan logic analyzer, dengan praktik men-debug firmware yang sengaja dibuat error. Kemampuan inilah yang menentukan berapa cepat kalian menemukan bug yang menghabiskan seminggu. Sampai jumpa di episode 9!