Esp32

DEV-HTL-01 mendefinisikan implementasi final firmware Node berbasis ESP-family yang mampu beroperasi secara otonom dan dapat diakses langsung melalui smartphone (HTTP direct mode). Dokumen ini mengunci pemilihan hardware (MCU, sensor, actuator, power design), integrasi elektrikal, serta arsitektur software 3-layer OOP (app*, srv*, drv*, sys*). Node bertanggung jawab atas kontrol lokal, interlock safety, watchdog, brownout handling, dan manual override dengan TTL enforcement. Endpoint HTTP minimal disediakan untuk commissioning, diagnostics, dan maintenance tanpa ketergantungan gateway atau server. Dokumen ini memastikan bahwa kontrol kritikal tetap berada di Node, sesuai prinsip local-first pada HTL-00, serta menyediakan definisi selesai (Definition of Done) dan hook pengujian HTL-09 untuk validasi produksi.

Banyak engineer menggunakan ESP32 dengan Arduino core seolah-olah sistem berjalan secara single-thread melalui `setup()` dan `loop()`. Kenyataannya, ESP32 berjalan di atas FreeRTOS dengan beberapa task internal seperti WiFi, TCP/IP stack, dan idle task. Tanpa memahami execution model ini, firmware mudah menjadi blocking, race-prone, dan tidak deterministik. Artikel ini membongkar bagaimana `loop()` sebenarnya adalah task FreeRTOS, bagaimana ISR mem-preempt eksekusi, dan bagaimana aktivitas jaringan memengaruhi kontrol hardware. Tujuannya membentuk mental model eksekusi sistem sebelum masuk ke disiplin arsitektur produksi.

Concurrency pada ESP32 bukan fitur tambahan, tetapi kondisi default karena Arduino core berjalan di atas FreeRTOS. Banyak engineer memahami task dan interrupt secara terpisah, namun belum memiliki mental model utuh tentang scheduler, preemption, race condition, dan shared state. Artikel ini membangun pemahaman dari dasar - apa itu task, bagaimana scheduler bekerja, bagaimana ISR memengaruhi task aktif, serta bagaimana queue dan mutex berperan dalam menjaga integritas data. Fokusnya bukan pada API detail, tetapi pada model eksekusi yang memengaruhi desain firmware sensor–relay yang deterministik dan stabil.

ESP32 menjalankan Arduino core di atas FreeRTOS, tetapi banyak engineer belum memahami bagaimana scheduler, task stack, dual-core mapping, dan watchdog berinteraksi dalam praktik. Artikel ini membahas execution model secara spesifik untuk ESP32 - bagaimana `loopTask` dibuat, bagaimana core 0 dan core 1 berbagi beban, bagaimana stack dialokasikan per task, serta bagaimana blocking network atau operasi berat dapat memicu watchdog reset. Fokusnya bukan pada API detail, tetapi pada pemahaman mekanisme internal yang memengaruhi stabilitas firmware sensor–relay saat fitur komunikasi dan logging ditambahkan.

Memory pada ESP32 bukan sekadar “heap vs stack”. Setiap task FreeRTOS memiliki stack sendiri, sementara heap bersifat global dan digunakan oleh WiFi, TLS, dan library internal. Banyak kegagalan firmware produksi bukan karena logika salah, tetapi karena fragmentasi heap, stack overflow, atau lifetime object yang tidak selaras dengan lifecycle sistem. Artikel ini membedah struktur memori ESP32, perbedaan stack task dan heap global, risiko hidden allocation pada C++, serta konsekuensi destructor dan dynamic allocation terhadap stabilitas jangka panjang firmware sensor–relay.

OOP pada embedded bukan tentang membuat kode “modern”, tetapi tentang mengontrol ownership, lifetime, dan dependency secara eksplisit. Banyak engineer yang memahami class, constructor, dan inheritance, namun belum memetakan konsep tersebut ke realitas firmware - stack terbatas, heap global, ISR preemption, dan sistem yang tidak pernah exit. Artikel ini membahas OOP dari perspektif embedded - encapsulation sebagai boundary hardware, constructor sebagai lifecycle binding, composition sebagai struktur aman, serta risiko inheritance, virtual table, dan hidden allocation. Tujuannya membentuk pola pikir struktural sebelum masuk ke disiplin dependency freeze pada tahap produksi.

Layering dalam firmware embedded bukan sekadar pemisahan file, tetapi cara mengendalikan dependency dan kompleksitas sistem. Tanpa struktur yang jelas, callback komunikasi, ISR, dan logic kontrol dapat saling terhubung secara liar sehingga firmware sulit dipelihara. Artikel ini membangun model 3-layer yang digunakan dalam seluruh seri - Application, Service, dan Driver, dengan dukungan modul System. Kita membahas arah dependency, alasan pemisahan domain, serta bagaimana struktur ini diterapkan dalam project flat-folder Arduino ESP32. Tujuannya adalah membentuk mental model arsitektur sebelum masuk ke disiplin freeze pada tahap produksi.

Komunikasi (WiFi, MQTT, OTA) sering menjadi sumber coupling dan ketidakstabilan pada firmware ESP32. Callback yang langsung mengubah relay, reconnect logic yang tersebar, serta state implisit yang tidak terdokumentasi membuat sistem sulit diprediksi. Artikel ini membahas komunikasi sebagai domain terpisah yang memiliki state machine eksplisit. Kita membangun mental model event-driven, memisahkan transport dari business logic, dan memahami bagaimana reconnect serta network latency dapat memengaruhi kontrol sensor–relay. Tujuannya adalah membentuk pola pikir stateful sebelum masuk ke disiplin komunikasi yang lebih ketat pada tahap produksi.

Firmware yang berjalan dengan benar di meja uji belum tentu andal di lapangan. Reliability bukan hanya tentang tidak crash, tetapi tentang bagaimana sistem merespons error, bagaimana state dipertahankan saat gangguan terjadi, serta bagaimana kegagalan dapat diamati dan dianalisis. Artikel ini menyatukan seluruh mental model Foundation—execution, memory, OOP, layering, dan communication—ke dalam perspektif reliability sistem. Kita membahas fail-safe thinking, observability, error visibility, serta batas antara pemahaman konseptual dan disiplin produksi. Artikel ini menjadi transisi resmi menuju seri Production yang mengunci aturan dan boundary secara eksplisit.

Foundation Track membangun mental model sistemik sebelum masuk disiplin firmware produksi pada ESP32 berbasis Arduino. Seri ini tidak mengajarkan sintaks C++, tetapi membedah realitas eksekusi FreeRTOS, stack per task, heap global, object lifetime, layering 3-level, state machine komunikasi, serta reliability thinking. Tujuannya adalah membentuk pola pikir engineer agar memahami interaksi concurrency, memory, dan komunikasi sebelum aturan produksi dikunci. Foundation menjawab “mengapa” di balik setiap keputusan arsitektur. Dengan pemahaman ini, transisi ke seri Production menjadi logis, terstruktur, dan tidak terasa sebagai pembatasan tanpa alasan teknis.

Artikel ini membedah kenapa firmware ESP32 berbasis Arduino yang awalnya sederhana sering berubah menjadi spaghetti setelah 6 bulan deployment. Masalah bukan pada bahasa C atau library, melainkan pada pertumbuhan fitur tanpa boundary arsitektur. Global mutable tanpa owner, callback komunikasi yang langsung mengontrol hardware, ISR yang memanggil logic berat, serta reconnect logic tersebar menjadi sumber coupling tak terlihat. Dampaknya bukan hanya kompleksitas kode, tetapi juga fragmentasi heap, jitter control, relay chatter, hingga kegagalan OTA. Artikel ini mengunci diagnosis bahwa firmware adalah sistem multi-domain internal yang membutuhkan struktur sadar sebelum kompleksitas meningkat secara eksponensial.

Artikel ini mengunci fondasi pengendalian dependency dalam firmware ESP32 berbasis Arduino. Masalah utama spaghetti firmware bukan pada bahasa, melainkan global mutable state tanpa owner dan dependency implicit lintas domain. OOP digunakan bukan untuk gaya, tetapi untuk mengenkapsulasi state, menetapkan ownership yang jelas, dan memaksa dependency eksplisit melalui constructor injection. Setiap peripheral dan domain logic harus dibungkus dalam class dengan state private. Singleton dan inheritance berlebihan dilarang; composition menjadi pendekatan default. Dengan struktur ini, dependency menjadi terarah, blast radius perubahan mengecil, dan race condition lebih mudah dianalisis sebelum sistem berkembang semakin kompleks.

Artikel ini mengunci disiplin lifecycle object dan kebijakan alokasi memori untuk firmware ESP32 berbasis Arduino. Masalah jangka panjang pada sistem produksi sering berasal dari dynamic allocation tersembunyi, fragmentasi heap, object yang dibuat di dalam loop, serta penggunaan `String` dan container growable tanpa kontrol. Embedded system membutuhkan determinism dan prediktabilitas, bukan fleksibilitas runtime berlebihan. Artikel ini menetapkan prinsip static-first allocation, pembatasan ketat penggunaan heap, larangan alokasi di ISR dan control loop, serta destructor yang harus trivial. Dengan lifecycle eksplisit dan memori terkendali, firmware dapat bertahan bertahun-tahun tanpa degradasi stabilitas atau reset misterius.

Artikel ini mengunci struktur arsitektur firmware berbasis class yang layered dan deterministik untuk ESP32 Arduino. Setelah dependency dan memory discipline dikontrol, risiko terbesar berikutnya adalah coupling lintas domain akibat tidak adanya direction rule yang tegas. Artikel ini menetapkan model 3 layer - Driver, Service, dan Application, dengan aturan dependency satu arah (DAG) dan larangan circular include. Prefix file (`drv_`, `svc_`, `app_`, `sys_`) menjadi boundary enforcement pada struktur flat Arduino. Dengan layering eksplisit dan composition root di `IndustrialNode.ino`, firmware memiliki bentuk tetap yang stabil, mudah diaudit, dan tidak berubah meski fitur bertambah.

Artikel ini mengunci batas concurrency dalam firmware ESP32 berbasis Arduino yang berjalan di atas FreeRTOS internal. Setelah layering dan memory discipline dikendalikan, risiko berikutnya adalah eksekusi paralel tanpa boundary yang jelas. ISR, WiFi stack, MQTT callback, dan control loop berjalan dalam konteks berbeda yang dapat memicu race condition dan jitter. Artikel ini menetapkan aturan - task-per-domain, ISR hanya sebagai notifier, komunikasi antar task menggunakan queue fixed-size, serta larangan blocking di ControlTask. Dengan batas eksekusi eksplisit dan alur satu arah, firmware tetap deterministik meskipun berjalan pada sistem multitasking.

Artikel ini mengunci arsitektur komunikasi firmware ESP32 berbasis Arduino agar terisolasi dan deterministik. Tanpa boundary yang jelas, WiFi event, MQTT callback, dan OTA handler sering langsung memengaruhi logic aplikasi dan hardware, menciptakan coupling baru setelah layering dan concurrency sudah rapi. Artikel ini menetapkan CommManager sebagai satu-satunya gateway komunikasi, memisahkan transport dari business logic, serta mewajibkan state machine eksplisit untuk koneksi dan reconnect. Telemetry harus offline-safe dengan buffer terbatas, dan credential tidak boleh tersebar. Dengan freeze ini, komunikasi tidak lagi menjadi pusat coupling atau sumber jitter pada control loop.

Artikel ini mengunci model reliability dan error handling untuk firmware ESP32 produksi. Setelah dependency, memory, layering, concurrency, dan communication dibekukan, sistem masih bisa gagal jika tidak memiliki model propagasi error yang eksplisit dan fail-safe state yang jelas. Silent failure, printf liar, watchdog tanpa owner, serta relay fail-open adalah penyebab utama bug lapangan yang sulit diaudit. Artikel ini menetapkan error enum eksplisit, larangan exception, encapsulation watchdog dalam HealthService, logging via interface non-blocking, serta kewajiban health telemetry minimal. Dengan reliability model formal, firmware tidak hanya rapi, tetapi juga dapat diaudit dan dipertahankan bertahun-tahun.

ARCHITECTURE_RULES adalah dokumen normatif yang merangkum seluruh freeze arsitektur dari Artikel 2 hingga 7 menjadi 27 aturan eksplisit yang wajib dipatuhi. Dokumen ini mengunci disiplin dependency (tanpa global mutable dan singleton), memory (static-first, tanpa alokasi di control path), layering (3-layer DAG dengan composition root tunggal), concurrency (ISR hanya notify, queue bounded), communication (CommManager + state machine eksplisit), serta reliability (error enum, fail-safe, watchdog encapsulated, logging non-blocking). Tujuannya bukan edukasi, tetapi enforcement. Dokumen ini berfungsi sebagai guardrail produksi agar firmware ESP32 berbasis Arduino tetap deterministik, audit-able, dan stabil dalam jangka panjang.

README memposisikan seri C++ for Production Firmware on ESP32 sebagai panduan arsitektur firmware produksi, bukan kursus sintaks atau teori OOP umum. Dokumen ini menjelaskan filosofi inti (determinism, memory discipline, boundary control), struktur waterfall 8 artikel, serta model arsitektur yang dikunci - no global mutable, static-first allocation, 3-layer DAG, CommManager sebagai gateway komunikasi, dan fail-safe reliability model. README juga menegaskan constraint Arduino (flat structure, IndustrialNode.ino sebagai entry point) serta success criteria produksi jangka panjang. Tujuannya adalah menyatukan visi tim dan memastikan disiplin arsitektur sebelum firmware berkembang menjadi kompleks.