Routing Topic Key

Kenapa halaman ini penting

Halaman ini menjelaskan bagaimana Routing Topic Key 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 Routing Topic Key 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

    ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Fast", fastTask, 10, 0, true);
ZeroKernel.tick();
  

    const auto key = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(key, sampleValue);
ZeroKernel.flushEvents();
  

    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

Kenapa routing berbasis key itu ada

Topic key ada karena perbandingan string berulang adalah salah satu biaya paling mudah tertinggal di firmware embedded. Satu route string memang terasa ringan. Tetapi route yang dipanggil terus-menerus di node telemetry, queue command, atau jalur transport akan menjadi biaya kecil yang dibayar berkali-kali. Topic key memindahkan biaya itu ke langkah awal yang dilakukan sekali.

Efek praktisnya sederhana: routing menjadi lebih mudah dijaga tetap predictable. Queue, callback, dan diagnostics tetap punya biaya, tetapi Anda berhenti membayar kerja label berulang pada publish dan subscribe yang paling sering berjalan. Karena itu, ZeroKernel menganggap jalur key-first sebagai arah utama, sedangkan label legacy dipertahankan sebagai jembatan migrasi.

Semakin sering route dipakai, semakin penting hal ini. Route yang berjalan sekali per menit tidak sama dengan route yang berjalan setiap 10 milidetik. Topic key paling berharga pada route yang menjadi ritme utama node.

Pola yang direkomendasikan

    const auto sensorKey = ZeroKernel.makeTopicKey("sensor.reading");

ZeroKernel.subscribeFast(sensorKey, onSensorReading);
ZeroKernel.publishFast(sensorKey, 17);
  

Buat key sekali, simpan di scope yang stabil, lalu pakai ulang. Kesalahan umum adalah membuat key yang sama di dalam task panas berulang kali. Itu mengurangi sebagian manfaat yang seharusnya didapat.

Apa yang membaik saat memakai key

• Lebih sedikit kerja string di dispatch runtime yang berulang.
• Hot path yang lebih kecil dan lebih jelas untuk board yang ketat.
• Routing lebih mudah dijaga konsisten di modul dan contoh.

Topic key tidak menghilangkan seluruh biaya routing. Yang dihilangkan adalah satu kelas kerja berulang yang tidak perlu tetap berada di jalur paling aktif. Sisanya masih ada, tetapi jalur runtime menjadi lebih mudah diskalakan.

Cara migrasi dari label legacy

Cara migrasi yang paling aman adalah bertahap. Buat key, pindahkan subscriber dulu, lalu publisher, lalu baru matikan jalur label legacy di build lean. Pola ini membuat kode tetap terbaca sambil berpindah ke jalur yang lebih efisien.

    // Langkah 1: buat key stabil
const auto telemetryKey = ZeroKernel.makeTopicKey("telemetry.temperature");

// Langkah 2: pindahkan subscriber
ZeroKernel.subscribeFast(telemetryKey, onTemperature);

// Langkah 3: pindahkan publisher
ZeroKernel.publishDeferredFast(telemetryKey, currentTemperature);
  

    # Langkah 4: matikan jalur legacy di build lean
-DZEROKERNEL_ENABLE_LEGACY_LABEL_API=0
-DZEROKERNEL_ENABLE_TOPIC_KEY_ONLY=1
  

Tiga contoh routing yang berguna

    // Contoh 1: publish state langsung
const auto stateKey = ZeroKernel.makeTopicKey("node.state");
ZeroKernel.publishFast(stateKey, 1);
  

    // Contoh 2: telemetry deferred
const auto telemetryKey = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(telemetryKey, readSensor());
  

    // Contoh 3: kerja command yang diantre
const auto commandKey = ZeroKernel.makeTopicKey("pump.flush");
ZeroKernel.enqueueCommandFast(commandKey, 0);
  

FAQ topic key