Kenapa halaman ini penting
Halaman ini menjelaskan bagaimana Dokumentasi, cara pakai, dan integrasi 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 Dokumentasi, cara pakai, dan integrasi 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
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
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();
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
Boot runtime, daftar task minimum yang berguna, lalu buktikan baseline timing bersih sebelum menambah lapisan opsional.
Masukkan routing, diagnostics, atau transport satu lapisan demi satu agar biaya dan payoff-nya tetap jelas.
Update docs, chart, atau klaim publik hanya setelah workload yang sama lolos jalur validasi yang sama lebih dari sekali.
Mulai dari sini
Halaman ini merangkum dokumentasi utama ZeroKernel menjadi panduan praktis: install, konfigurasi, wiring task, pilih profile, lalu validasi dengan compare suite bawaan.
Mulai dari jalur instalasi nyata untuk download GitHub, Arduino IDE, dan PlatformIO sebelum menulis kode.
QuickstartInstall library, hubungkan clock board, daftar task pertama, lalu jalankan compare script dengan urutan yang benar.
KebutuhanKeluarga board, asumsi clock, aturan zero-heap, dan apa yang runtime butuhkan dari setiap task.
ProfilePilih profile paling kecil yang masih cocok: POWER_SAVE, LEAN_NET, NETWORK_NODE, atau build diagnostic.
Core RuntimePahami perilaku scheduler, execution contract, kernel state, dan batas nyata dari model cooperative.
tick()Lihat apa yang terjadi dalam satu putaran scheduler, apa yang di-drain, dan kenapa bounded work per tick penting.
addTask()Baca detail registrasi task: cadence, first-run behavior, dan execution contract.
API ReferencePakai halaman referensi yang rapi untuk lifecycle, task control, routing, diagnostics, dan hook operasional runtime.
CommandPakai script yang benar-benar dipakai untuk validasi timing, gate performa, dan menjaga budget resource.
publishDeferredPahami routing deferred yang bounded, kapan lebih aman dari publish langsung, dan bagaimana menjaga biaya queue tetap kecil.
Topic KeyPindah dari string legacy ke key-first routing agar hot path tetap lean dan deterministik.
WatchdogLihat aturan heartbeat, failure budget, eskalasi panic, dan cara runtime mengungkap fault sebelum menjadi diam.
KonfigurasiAtur compile-time flags, pilih profile yang benar, dan hindari setting yang saling bertabrakan.
Modul NetworkLihat fungsi modul transport opsional, biayanya, lalu buka halaman terpisah untuk tiap modul.
ContohLihat dulu workload referensi dan apa yang sebenarnya sedang divalidasi sebelum dipakai ke project nyata.
ValidasiIkuti urutan validasi yang sama setiap saat agar angka yang dipublikasikan tetap kredibel dan repeatable.
FAQPahami trade-off: batas cooperative, klaim timing, modul transport, dan apa yang masih beta.
Quick start
#include <ZeroKernel.h>
unsigned long boardMillis() {
return millis();
}
void sampleTask() {
// bounded sensor work
}
void setup() {
ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Sample", sampleTask, 100, 0, true);
}
void loop() {
ZeroKernel.tick();
}
Status modul
Transport counters, queue depth, retry visibility
Cooperative HTTP step pump with bounded retries
Cooperative MQTT publish pump with queue control
Reconnect pacing, state topic, capability-aware link gating
Scheduler, watchdog, commands, events, safe mode, panic flow
Command validasi
bash scripts/run_desktop_tests.sh
bash scripts/run_desktop_benchmark.sh --enforce-performance
bash scripts/run_resource_matrix.sh --enforce-budget
bash scripts/run_workload_matrix.sh
bash scripts/run_esp32_env_monitor_compare.sh /dev/ttyUSB1
bash scripts/run_esp32_gateway_compare.sh /dev/ttyUSB1
bash scripts/run_esp32_industrial_compare.sh /dev/ttyUSB1
FAQ ringkasan
Harus mulai dari ringkasan atau langsung quickstart?
Baca halaman ini sekali untuk memahami mental model-nya, lalu lanjut ke quickstart untuk setup nyata.
Apakah ini sudah cukup untuk firmware produksi?
Jadikan halaman ini fondasi, lalu tetap validasi di board, jalur transport, dan workload Anda sendiri sebelum menganggap build siap produksi.
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.