Konfigurasi Build dan Flag

Kenapa halaman ini penting

Halaman ini menjelaskan bagaimana Konfigurasi Build dan Flag masuk ke model eksekusi ZeroKernel yang lebih besar, masalah apa yang sebenarnya diselesaikan, dan trade-off apa yang benar-benar Anda bayar saat fitur ini dipakai di firmware produksi. Tujuannya bukan melihat Konfigurasi Build dan Flag sebagai satu API terpisah, tetapi memahami posisinya di dalam bounded scheduling, disiplin queue, visibilitas fault, dan pemilihan profile.

Baca topik ini sebagai kontrak operasional. Mulai dari jalur paling kecil yang benar-benar jalan, pasang dulu di profile lean, lalu baru naik ke routing, diagnostics, atau state transport yang lebih kaya setelah Anda bisa membuktikan hasil timing-nya tetap layak dibanding tambahan flash dan RAM. Pola pikir ini yang menjaga ZeroKernel tetap berguna di board kecil dan tidak berubah jadi abstraksi yang gemuk.

Pola paling aman selalu sama: tentukan batas runtime-nya, jaga hot path tetap pendek, ukur efeknya dengan compare script, lalu baru naikkan kompleksitas. Contoh di bawah bukan pemanis; itu adalah pola minimum yang bisa Anda ambil ke firmware nyata saat Anda butuh integrasi yang rapi, bukan loop manual yang sulit dipertahankan.

Tiga pola yang langsung bisa dipakai

    ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Fast", fastTask, 10, 0, true);
ZeroKernel.tick();
  

    const auto key = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(key, sampleValue);
ZeroKernel.flushEvents();
  

    const auto stats = ZeroKernel.getStats();
const auto timing = ZeroKernel.getTimingReport();
Serial.println(timing.maxTickMs);
  

Apa yang perlu Anda cek saat memakainya

• Validasi timing lebih dulu, baru bentuk API. API yang terlihat rapi bukan kemenangan kalau fast miss justru naik.
• Pilih profile paling kecil yang masih cocok, lalu aktifkan modul opsional hanya saat payoff terukurnya benar-benar jelas.
• Jaga callback dan langkah transport tetap bounded supaya watchdog, panic flow, dan batas queue tetap punya arti.

Kesalahan umum yang membuat hasil jadi menyesatkan

• Jangan menyalin pola demo ke firmware produksi tanpa mengukurnya di board dan profile build yang benar-benar akan dipakai.
• Jangan membaca angka sukses tanpa membaca queue depth, timing, dan label workload di sampingnya.
• Jangan menyalakan diagnostics atau kompatibilitas berat di target lean hanya karena default-nya terasa nyaman.

Urutan kerja yang disarankan

Filosofi konfigurasi

ZeroKernel dibentuk kuat oleh konfigurasi compile-time. Kapasitas queue, kedalaman metrics, kompatibilitas legacy, dan modul opsional semuanya mengubah binary sebelum firmware pernah masuk ke board. Artinya, konfigurasi bukan catatan pinggir. Ia bagian dari kontrak runtime. Kalau flag diubah sembarangan, timing, footprint, dan perilaku runtime bisa berubah walau kode aplikasi terlihat hampir sama.

Cara paling aman adalah mulai dari profile, lalu baru turun ke flag satu per satu jika memang ada tradeoff spesifik yang ingin dicapai. Profile ada karena mayoritas firmware jatuh ke beberapa bentuk umum: node lean, node network, build diagnostic, atau firmware kecil yang harus sangat hemat.

Flag granular tetap penting, tetapi posisinya sebagai alat tuning. Gunakan saat Anda bisa menjelaskan tujuan pastinya: memangkas size, mematikan lapisan kompatibilitas, atau mengunci build ke jalur key-first. Kalau tujuannya tidak jelas, biasanya flag itu belum perlu diubah.

Profile flag umum

    -DZEROKERNEL_PROFILE_POWER_SAVE
-DZEROKERNEL_PROFILE_LEAN_NET
-DZEROKERNEL_PROFILE_NETWORK_NODE
-DZEROKERNEL_PROFILE_DIAGNOSTIC
  

Pilih profile berdasarkan bentuk firmware, bukan sekadar nama yang terdengar paling aman. POWER_SAVE cocok untuk board kecil dan jalur panas yang ketat. LEAN_NET untuk node network yang ingin tetap disiplin soal budget. NETWORK_NODE untuk node yang lebih kaya fitur. DIAGNOSTIC untuk bring-up, lab, dan pembuktian perilaku.

Flag level rendah yang paling berguna

    -DZEROKERNEL_ENABLE_CAPABILITIES=0
-DZEROKERNEL_ENABLE_EXTENDED_TASK_METRICS=0
-DZEROKERNEL_ENABLE_LEGACY_LABEL_API=0
-DZEROKERNEL_ENABLE_TOPIC_KEY_ONLY=1
  

Flag ini paling berguna saat Anda sudah tahu cost center yang ingin diubah. Misalnya, kalau ingin memangkas overhead routing lama, matikan legacy labels dan kunci jalur key-first. Kalau ingin mengurangi bookkeeping di target kecil, matikan extended task metrics. Gunakan perubahan kecil yang punya alasan jelas.

    ; Contoh PlatformIO
build_flags =
  -DZEROKERNEL_PROFILE_LEAN_NET
  -DZEROKERNEL_ENABLE_LEGACY_LABEL_API=0
  -DZEROKERNEL_ENABLE_TOPIC_KEY_ONLY=1
  

Aturan yang dipaksa konfigurasi

• Batas kapasitas dijaga dengan static_assert agar overflow uint8_t tidak lolos diam-diam.
• TOPIC_KEY_ONLY dan LEGACY_LABEL_API tidak boleh aktif secara kontradiktif.
• Profile lean mematikan fitur berat secara default agar build baru tidak langsung membengkak.

Aturan ini penting karena kesalahan konfigurasi embedded sering gagal secara diam-diam. Kapasitas yang overflow atau mode routing yang bertabrakan bisa tetap compile, lalu baru terasa aneh setelah firmware di-flash. Lebih baik build gagal cepat dengan pesan jelas daripada mencari gejala yang samar di board.

Tiga pola konfigurasi yang praktis

    Pola 1: board kecil
Profile: POWER_SAVE
Tujuan: menjaga hot path tetap lean dan tidak membayar diagnostics berat
  

    Pola 2: node network
Profile: LEAN_NET
Tujuan: tetap dapat helper transport tanpa footprint tumbuh terlalu jauh
  

    Pola 3: build validasi lab
Profile: DIAGNOSTIC
Tujuan: memaksimalkan visibilitas untuk membedah perilaku runtime
  

FAQ konfigurasi