Alur Validasi

Kenapa halaman ini penting

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

    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_esp32_modules_compare.sh /dev/ttyUSB1
bash scripts/run_esp32_real_project_demo.sh /dev/ttyUSB1
  

    -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

Kenapa alur validasi harus ketat

ZeroKernel membawa klaim tentang timing yang deterministik, queue yang bounded, dan tradeoff yang bisa dijelaskan. Klaim seperti itu hanya tetap kuat kalau jalur validasinya bisa diulang. Karena itu, alur validasi di sini bukan saran longgar, tetapi proses kerja yang dirancang agar hasilnya masih masuk akal saat dibaca dan diulang lagi nanti.

Urutannya sengaja: logic lokal dulu, footprint kedua, lalu board. Dengan urutan ini, waktu board yang lebih mahal dipakai hanya untuk hal yang memang tidak bisa dilihat di desktop. Ini juga mencegah situasi di mana board terlihat stabil padahal benchmark lokal atau budget compile-time sebenarnya sudah mundur.

Ada alasan komunikasi juga. Tabel benchmark hanya berguna kalau orang lain bisa mengulang jalur yang sama dan mendapatkan hasil yang sebanding. Karena itu, sequence di bawah ini adalah cara resmi untuk membuat angka yang layak dimasukkan ke docs, changelog, atau positioning produk.

Urutan yang direkomendasikan

1. Jalankan desktop tests dan benchmark gates.
2. Jalankan resource matrix dan pastikan budget tetap lolos.
3. Jalankan satu atau lebih hardware compare script di board target.
4. Update docs atau klaim publik hanya setelah hasilnya bisa diulang.

    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_esp32_real_project_demo.sh /dev/ttyUSB1
  

Apa yang harus selalu dicatat

• Fast miss dan lag untuk klaim deterministik.
• Queue depth dan success rate untuk klaim transport.
• Build profile dan target board untuk setiap angka yang dipublikasikan.

Hasil yang baik bukan hanya yang terlihat bagus, tetapi yang tercatat dengan baik. Kalau catatannya hanya "terasa lebih cepat", hasil itu sulit dipakai lagi. Kalau catatannya memuat board, profile, timing, queue depth, dan success rate, hasil tersebut bisa dibandingkan kembali terhadap versi berikutnya.

Apa yang jangan dipublikasikan terlalu cepat

• Output synthetic satu kali tanpa label workload yang jelas.
• Hasil modul network yang masih BETA tetapi ditulis seolah-olah final.
• Biaya resource tanpa payoff runtime yang jelas.

Data yang sedikit tetapi jujur lebih baik daripada angka yang terlihat mengesankan tetapi misleading. Tidak masalah menyebut hasil masih synthetic atau BETA. Yang tidak sehat adalah menyajikannya seolah-olah itu sudah setara dengan hasil lapangan yang benar-benar stabil.

Tiga pola validasi yang praktis

    Pola 1: ubah core runtime
Mulai dari desktop tests dan benchmark.
Pakai hardware hanya kalau efeknya terlihat di board.
  

    Pola 2: release yang sensitif size
Jalankan resource matrix lalu bandingkan overhead baru dengan payoff sebelum update docs.
  

    Pola 3: hasil yang mau dipublikasikan
Ulangi run hardware yang sama, catat board, profile, dan workload dengan jelas.
  

FAQ validasi