Dokumentasi

Contoh

Setiap example sengaja dibuat untuk membuktikan klaim runtime tertentu: stabilitas timing, throughput transport, queue pressure, atau recovery.

Kenapa halaman ini penting

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

Urutan validasi penuh

Pakai ini saat Anda butuh regression pass yang kredibel sebelum mempublikasikan angka atau mengubah docs.

Shell
    bash scripts/run_desktop_tests.sh
bash scripts/run_desktop_benchmark.sh --enforce-performance
bash scripts/run_resource_matrix.sh --enforce-budget
  
Hardware compare pass

Jalankan compare hardware yang fokus, jangan menebak apakah perubahan membantu atau merugikan.

Shell
    bash scripts/run_esp32_modules_compare.sh /dev/ttyUSB1
bash scripts/run_esp32_real_project_demo.sh /dev/ttyUSB1
  
Guard build lean

Kunci build ke profile yang dimaksud sebelum menganggap benchmark atau compare sebagai angka resmi.

Text
    -DZEROKERNEL_PROFILE_LEAN_NET
-DZEROKERNEL_ENABLE_DIAGNOSTICS=0
-DZEROKERNEL_ENABLE_LEGACY_LABEL_API=0
  

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.

Matriks referensi

Nama Apa yang dibuktikan Fokus output
EnvMonitorNode Sampling + filtering + threshold alarm Lag, misses, alarm trips
TelemetryGatewayNode Queue-heavy HTTP and MQTT style transport flow Success rate, queue depth, reconnect cadence
IndustrialLoopNode Fast control loop + commands + diagnostics Lag, safe mode, recoveries
RealProjectNode Mixed network node under realistic cadence HTTP/MQTT rate, queue health, timing
8266_zerokernel project Sensor + buzzer + direct AP + queued HTTP Field timing and successful local delivery

Cara membaca example

  • Baseline bukan berarti “dibikin jelek”, tapi mewakili pattern manual atau loop blocking.
  • Compare ZeroKernel harus dilakukan di board yang sama, clock yang sama, dan window yang sama.
  • Transport example bisa bersifat synthetic. Pakai RealProjectNode saat Anda butuh gambaran mixed workload yang lebih realistis.

FAQ contoh

Contoh mana yang sebaiknya saya tiru dulu?

Pilih contoh yang paling dekat dengan bottleneck Anda: cadence sensor, throughput gateway, atau perilaku mixed control.

Kenapa baseline dan ZeroKernel sama-sama disimpan?

Supaya tradeoff tetap terukur dan klaimnya tetap berdasar compare yang adil.

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.