Kenapa halaman ini penting
Halaman ini menjelaskan bagaimana Registrasi Task dengan addTask 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 Registrasi Task dengan addTask 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 satu task bounded untuk hot path, lalu biarkan scheduler menjaga phase alignment seiring waktu.
ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Fast", fastTask, 10, 0, true);
ZeroKernel.tick();
Pindahkan routing dan transport non-kritikal dari body task utama agar fast path tetap terprediksi.
const auto key = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(key, sampleValue);
ZeroKernel.flushEvents();
Baca timing report dan stats bersamaan agar Anda bisa membuktikan biaya tiap lapisan abstraksi.
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
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.
Apa yang sebenarnya didefinisikan addTask
addTask() bukan sekadar fungsi untuk menyimpan callback. Ini adalah titik saat Anda mendeklarasikan niat eksekusi: seberapa sering pekerjaan boleh jalan, apakah ia langsung aktif saat boot, apakah ia perlu terlihat di diagnostics, dan bagaimana ia ikut dalam model pemilihan task due.
Semakin rapi deklarasi ini, semakin mudah firmware dirawat. Saat project terasa punya “terlalu banyak task”, biasanya masalahnya bukan jumlah task, tetapi registrasi task dilakukan tanpa batas cadence yang jelas, tanpa ownership, dan tanpa follow-up supervision yang tepat.
Bentuk dasar
void sampleTask() {
// bounded work
}
void setup() {
ZeroKernel.begin(millis);
ZeroKernel.addTask("Sample", sampleTask, 100, 0, true);
}
Ini bentuk minimum yang paling berguna: nama stabil, body task bounded, interval tetap, tanpa startup delay, dan langsung aktif.
Arti tiap argumen
| Argumen | Arti |
|---|---|
name | Identifier yang terbaca manusia dan disalin ke storage runtime untuk diagnostics, snapshot, dan signal. |
callback | Body task cooperative yang bounded dan harus selesai cepat. |
interval | Cadence di domain clock scheduler aktif; inilah kontrak kapan task boleh due. |
startDelay | Offset awal opsional sebelum task pertama kali eligible. |
enabled | Menentukan apakah task langsung ikut scheduler atau tetap terdaftar tetapi paused. |
Tiga pola registrasi yang paling sering dipakai
ZeroKernel.addTask("Sample", sampleTask, 100, 0, true);
Pakai ini saat task aman berjalan langsung saat boot dan tidak punya dependency pada subsistem lain.
ZeroKernel.addTask("WiFiFlush", flushTask, 250, 1000, false);
ZeroKernel.resumeTask("WiFiFlush");
Pakai ini saat task perlu terdaftar dari awal, tetapi baru boleh jalan setelah tahap setup tertentu selesai.
ZeroKernel.addTask("FastLoop", fastTask, 10, 0, true);
ZeroKernel.setTaskPriority("FastLoop", zerokernel::kPriorityCritical);
ZeroKernel.setTaskHeartbeatTimeout("FastLoop", 50);
Pakai ini untuk task bernilai tinggi yang butuh priority dan supervision eksplisit, bukan cuma cadence biasa.
Follow-up yang umum setelah registrasi
ZeroKernel.setTaskPriority("Sample", zerokernel::kPriorityHigh);
ZeroKernel.setTaskHeartbeatTimeout("Sample", 250);
ZeroKernel.setTaskExecutionContract("Sample", contract);
Kebanyakan task nyata belum “selesai” hanya dengan didaftarkan. Biasanya masih perlu paling tidak satu panggilan tambahan agar runtime paham seberapa penting task itu saat terjadi fault.
Cara menghindari task yang terlalu banyak
Tidak semua helper function layak menjadi task. Gunakan task untuk batas cadence, bukan untuk meniru struktur object atau batas file source. Jika dua langkah selalu berjalan di cadence yang sama dan gagal bersama, sering kali keduanya lebih cocok tetap berada di task yang sama.
Buat task terpisah hanya bila salah satu ini benar: cadence berbeda, arti failure berbeda, atau pekerjaan memang harus disupervisi secara mandiri.
FAQ addTask
Apakah semua function harus dijadikan task?
Tidak. Gunakan task untuk batas cadence. Helper internal bisa tetap berada di dalam body task yang sama jika jadwalnya memang sama.
Apakah nama task boleh berasal dari String sementara?
Runtime sekarang menyalin nama ke storage internal, tetapi string literal tetap pilihan paling aman dan paling bersih.
Apa kesalahan registrasi task yang paling umum?
Mendaftarkan task tanpa memutuskan apakah ia benar-benar sensitif waktu, lalu mengompensasi di belakang dengan terlalu banyak priority dan setting watchdog. Putuskan cadence dulu, baru tambahkan supervision.