Kenapa halaman ini penting

Halaman ini menjelaskan bagaimana Kebutuhan 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 Kebutuhan 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

Setup berbasis repo

Pakai ini saat Anda ingin source of truth lokal yang bersih dan kontrol update yang eksplisit.

    git clone git@github.com:ZeroBitsTech/ZeroKernel.git
cd ZeroKernel
bash scripts/run_desktop_tests.sh

Boot runtime paling minimum

Mulai dari satu task bounded dan clock board yang jelas sebelum menambah queue atau modul network.

    ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Sample", sampleTask, 100, 0, true);
ZeroKernel.tick();

Kunci profile di PlatformIO

Pasang profile di build flags agar drift footprint terjadi dengan sengaja, bukan tanpa sadar.

    [env:esp32]
platform = espressif32
board = esp32dev
framework = arduino
build_flags =
  -DZEROKERNEL_PROFILE_LEAN_NET

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

Mulai dari jalur paling kecil yang valid

Boot runtime, daftar task minimum yang berguna, lalu buktikan baseline timing bersih sebelum menambah lapisan opsional.

Tambah satu lapisan, lalu ukur

Masukkan routing, diagnostics, atau transport satu lapisan demi satu agar biaya dan payoff-nya tetap jelas.

Publikasikan hanya hasil yang bisa diulang

Update docs, chart, atau klaim publik hanya setelah workload yang sama lolos jalur validasi yang sama lebih dari sekali.

Target yang didukung

Keluarga	Status	Use case umum
ESP8266	Tervalidasi	Node direct AP, gateway ringan
ESP32	Tervalidasi	Workload campuran, WiFi transport, telemetry lebih kaya
RP2040	Compile matrix	Control loop, node monitoring
STM32	Compile matrix	Firmware industrial dan kontrol deterministik

Aturan runtime

Task harus bounded. Kalau ada task blocking, runtime cooperative tetap bisa ikut ketahan.
Core memakai storage fixed-capacity; tidak ada active-path heap allocation di runtime.
Timing default berbasis clock millisecond kecuali nanti ditambah jalur high-resolution khusus workload tertentu.
Modul network opsional sudah cukup stabil di ESP32 untuk evaluasi deployment yang serius, tetapi masih tetap BETA di ESP8266 dan wajib divalidasi ulang di hardware target Anda.

Tooling

Node 20.x direkomendasikan untuk docs site dan tooling web pendukung.
Arduino CLI atau PlatformIO diperlukan untuk validasi board.
Pakai compare script sesuai dokumentasi supaya output tetap bisa dibandingkan antar-run.

FAQ kebutuhan

Apakah compile-matrix berarti board sudah field-tested penuh?

Tidak. Compile validation membuktikan jalur build. Validasi hardware tetap diperlukan untuk timing dan transport.

Apakah model cooperative selalu cukup?

Tidak. Model ini cocok saat task bounded masih realistis dan RTOS penuh akan jadi overhead yang tidak perlu.

Bagaimana cara paling aman memvalidasi halaman ini di board nyata?

Mulai dari profile paling lean yang masih relevan, jalankan compare script yang paling sempit untuk topik ini, lalu baru lanjut ke workload yang lebih berat. Jangan lompat langsung ke build penuh kalau timing dasarnya belum jelas.