ADR-008: ESP32 Dual-Core Gorev Dagilimi

Durum	Kabul Edildi
Tarih	2026-01
Karar Veren	Güçlü Ceyhan

Baglam

Zeus 2.0 ESP32 gateway'leri sahada iki kritik gorevi es zamanli yurutur:

• Modbus RTU polling: RS-485 uzerinden inverter, enerji analizoru, meteoroloji istasyonu gibi cihazlardan periyodik veri okuma (5 saniye aralik)
• Network iletisimi: WiFi baglantisi, MQTT publish/subscribe, OTA firmware guncelleme, NTP senkronizasyonu

Bu iki gorev birbirini bloklamamalidir:

• Modbus RTU zamanlama-kritik — timeout degerleri milisaniye hassasiyetinde
• WiFi/MQTT event-driven — paket gonderme/alma sureleri degisken
• OTA guncelleme sirasinda bile Modbus okuma devam etmeli (veya guvenli sekilde durmali)

ESP32, Xtensa LX6 dual-core islemciye sahiptir (Core 0 ve Core 1).

Karar

FreeRTOS xTaskCreatePinnedToCore() ile gorev dagilimi:

Core	Gorevler	Oncelik
Core 0	WiFi stack, MQTT client, OTA handler, NTP sync	Event-driven
Core 1	Modbus RTU polling, uygulama mantigi, sensor okuma	Zamanlama-kritik

Gorev Yapisi

Core 0 (PRO_CPU — Protocol):
  ├── WiFi event handler (sistem gorevi)
  ├── MQTT task (publish/subscribe)
  ├── OTA task (firmware indirme + flash)
  └── NTP sync task (periyodik)

Core 1 (APP_CPU — Application):
  ├── Modbus polling task (ana dongu)
  ├── Template parser task
  ├── LED status task
  └── Watchdog feed task

Alternatifler

Tek cekirdek — cooperative scheduling

• Artilari: Basit tasarim, mutex gerektirmez, debugging kolay
• Eksileri: Modbus timeout'u WiFi reconnect sirasinda asiliyor, OTA guncelleme tum sistemi durduruyor, bir gorev takildiginda diger gorevler de durur
• Red nedeni: Modbus zamanlama gereksinimleri ile network gecikmeleri catisiyor

FreeRTOS tek core (yazilimsal multitasking)

• Artilari: Iki core arasinda kaynak paylasimi sorunlari yok
• Eksileri: Context switching overhead, Modbus timing'i network interrupt'lari tarafindan bozulabilir
• Red nedeni: Hardware kaynaklarini tam kullanmamak — dual-core'un avantajlarindan vazgecmek gereksiz

Ayri islemci (ESP32 + STM32)

• Artilari: Tam izolasyon, her islemci kendi gorevine odaklanir
• Eksileri: Ek donanim maliyeti, islemciler arasi iletisim protokolu (SPI/UART), PCB karmasikligi
• Red nedeni: Maliyet ve karmasiklik — ESP32 dual-core yeterli

Gerekce

Secilen gorev dagilimi su avantajlari sundu:

1. Modbus RTU zamanlama-kritik: Core 1'de calisir, WiFi interrupt'larindan etkilenmez — timeout hassasiyeti korunur
2. WiFi/MQTT event-driven: Core 0'da calisir, ESP-IDF WiFi stack'i zaten Core 0'a pinlenmiistir — dogal uyum
3. Iki islem birbirini bloklamaz: Modbus polling devam ederken MQTT publish bekleyebilir, veya WiFi reconnect sirasinda Modbus verileri tamponlanir
4. FreeRTOS pinToCore ile deterministik: Gorevlerin hangi cekirdekte calisacagi garanti altinda — debugging ve profiling kolaylasir
5. Bellek verimi: Her gorev icin 21KB stack yeterli — toplam RAM kullanimi kontrol altinda (ESP32: 520KB SRAM)

Sonuclar

Olumlu

• Modbus polling zamanlama hassasiyeti korunuyor — timeout hatalari neredeyse sifir
• WiFi reconnect veya MQTT baglanti kopmalari Modbus okumalarini etkilemiyor
• OTA guncelleme sirasinda cihaz veri toplamaya devam edebiliyor (opsiyonel olarak durdurulabilir)
• Gorev oncelikleri ile kritik islemler garanti altinda
• Gercek zamanli performans profiling Core bazinda yapilabiliyor

Olumsuz

• Shared resource erisimi mutex gerektirir: UART (Modbus ve debug log ayni port'ta degilse sorun yok), paylasilan veri tamponlari, durum degiskenleri — xSemaphoreTake/Give ile korunmali
• Deadlock riski: Iki core'da da mutex kullanan gorevler yanlis siralamayla kilit alirsa deadlock olusur — kilit siralama kurallari belirlenmis
• Debug zorlugu: Dual-core hata ayiklama tek core'a gore daha karmasik — JTAG debugger oneriliyor ancak sahada sinirli
• Stack overflow riski: Her gorev icin ayri stack — boyut yetersizse sessiz cokme. Stack watermark monitoring eklenmis