Belajar Firmware Engineer - Multi-Core & Heterogeneous
Menulis firmware untuk sistem multi-prosesor: mengapa chip multi-core muncul, mode AMP dan SMP, contoh RP2040, ESP32, dan STM32H7, komunikasi antar-core lewat mailbox dan shared memory, arsitektur heterogen MCU+AP, serta praktik mendesain firmware multi-core.
#Pendahuluan
Setelah di episode 23 firmware kita bicara lewat CAN, pada episode ini kita menjawab kebutuhan performa: berapa pun cepat satu inti, kadang tidak cukup. Chip multi-core — dua inti kecil yang berbagi satu chip — kini tersebar dari board murah (RP2040, ESP32) sampai MCU high-end (STM32H7) dan SoC heterogen (STM32MP1, i.MX). Firmware engineer modern harus tahu cara memanfaatkannya.
Mengapa penting? Karena single-core sudah mendekati batas fisik: menaikkan clock boros daya dan panas. Solusi 2026 adalah paralelisme di dalam chip. Tapi paralelisme mengubah cara berpikir — sekarang ada pertanyaan baru: siapa yang boleh menyentuh peripheral mana, dan bagaimana dua inti berbicara tanpa saling menabrak.
#Mengapa Multi-Core?
Tiga motivasi utama:
- Performa — dua inti = lebih banyak kerja per watt (dengan pengaturan yang tepat).
- Pemisahan beban — inti real-time untuk kontrol, inti lain untuk komunikasi/UI — salah satu macet, yang lain tetap jalan.
- Ekonomi — satu chip dengan dua inti sering lebih murah dan hemat daripada dua chip.
Contoh nyata: ESP32 memakai satu inti untuk WiFi/BLE stack dan satu lagi untuk aplikasi pengguna. STM32H7 memakai M7 untuk aplikasi berat dan M4 untuk low-power/assist.
#AMP vs SMP
Dua cara menjalankan sistem multi-core:
| Aspek | AMP (Asymmetric) | SMP (Symmetric) |
|---|---|---|
| OS per core | Bisa berbeda (RTOS + RTOS, atau RTOS + bare-metal) | Satu OS, semua core |
| Penjadwalan | Manual (core ditugaskan tugas) | OS menyeimbangkan |
| Komunikasi | Eksplisit (mailbox/shared memory) | Sinkronisasi via kernel |
| Contoh | ESP32 (pro+app), STM32H7 | Zephyr SMP, Linux SMP |
| Kapan | Beban asimetris, isolasi | Beban homogen, OS dewasa |
Di firmware, AMP lebih umum: inti real-time diisolasi dari inti yang menangani networking/UI. Kalian sebagai firmware engineer lebih sering menulis di satu inti sambil berkomunikasi eksplisit dengan inti lain.
#Komunikasi Antar-Core
Tanpa komunikasi, dua inti hanyalah dua program terpisah. Mekanismenya:
| Mekanisme | Fungsi |
|---|---|
| Mailbox | Mengirim "pesan pendek" (perintah/event) dengan interrupt antar-core |
| Shared memory | Data besar (buffer, frame) lewat region memori bersama |
| Semaphore/hardware lock | Melindungi akses bersama (hindari race) |
| IPC library | OpenAMP/RPMsg, atau library vendor (IPCC di STM32) |
1. Producer menulis data ke shared buffer
2. Tulis flag/sequence (bukan data!)
3. Ketuk mailbox -> interrupt ke core lain
4. Consumer membaca buffer + flag
5. Semaphore/hardware semaphore melindungi aksesIngat episode 6: aturan yang sama berlaku — tulis data dulu, lalu sinyal; kalau tidak, consumer membaca data separuh jadi.
#Heterogeneous: MCU + Application Processor
SoC heterogen menggabungkan inti aplikasi (ARM Cortex-A, Linux) dan inti MCU (Cortex-M, bare-metal/RTOS):
| Lapisan | Peran |
|---|---|
| Cortex-A (Linux) | UI, cloud, framework, jaringan |
| Cortex-M (RTOS/bare-metal) | Kontrol real-time, GPIO ketat, low-power |
| Komunikasi | RPMsg/IPCC, atau shared memory |
Pembagian beban yang sehat: semua yang butuh determinisme → M-core; semua yang butuh ekosistem → A-core. Contoh: smart thermostat — M-core membaca sensor & mengendalikan HVAC, A-core menjalankan aplikasi & cloud. Keuntungan besar: bug di layer Linux tidak menjatuhkan kontrol real-time.
Tip
Aturan emas multi-core: desain antarmuka dulu, baru implementasi. Tentukan dulu pesan antar-core, region memori bersama, dan protokol ack — sebelum menulis satu baris kode di kedua inti. Dua tim (atau dua hari kalian) yang mengimplementasi "send/recv" yang tidak pernah disepakati = debugging berminggu-minggu.
#Praktik: Desain Multi-Core
Skema desain untuk produk dua-inti:
Core 0 (real-time, prio tinggi) : ADC sampling, kontrol PID, safety logic
Core 1 (aplikasi) : MQTT, BLE, UI, penyimpanan log
Kontrak antar-core:
- Region memory : 0x3800_0000.. (4 KB shared)
- Pesan : command ID (1B) + length (1B) + payload (14B)
- Sinyal : mailbox IRQ core0 -> core1 (dan sebaliknya)
- Proteksi : hardware semaphore untuk region bersamaVerifikasi: ukur latency antar-core (dari kirim ke ack) dan pastikan kedua core tidak pernah menulis region yang sama tanpa kunci — lalu stress test dengan beban maksimal kedua inti.
#Kesalahan Umum Multi-Core
- Berbagi variabel tanpa sinkronisasi — race condition lintas core lebih sulit dideteksi.
- Menulis data + flag tanpa urutan — core lain baca data separuh.
- Interrupt core tidak di-handle — mailbox penuh, komunikasi mati.
- Satu core "kelaparan" — prioritas salah membuat inti lain idle.
- Region memory tumpang tindih — data satu inti menimpa yang lain.
- Menguji hanya satu inti — kedua inti harus diuji bersama di target.
#Penutup
Inti yang harus dibawa pulang:
- Multi-core hadir karena performa per watt dan isolasi beban.
- AMP (core dibagi manual, OS bisa beda) vs SMP (satu OS semua core).
- Komunikasi antar-core: mailbox + shared memory + semaphore + IPC library (RPMsg/IPCC).
- Heterogen A+M: A-core untuk ekosistem, M-core untuk determinisme.
- Desain kontrak antar-core dulu, uji kedua inti bersama di target.
Di episode 25 selanjutnya kita membawa firmware dari meja kerja ke pabrik: Production & Scalability — manufacturing support, yield, dan scale-up produksi. Kode kalian akan lahir di jalur produksi nyata!