Skip to main content

Hafıza Kullanımı ve Haritalama

Bu sayfa, B107AA R6 ana işlemcisinde hafıza kullanımını (Flash/RAM/EEPROM) ve harici hafıza katmanlarını (SD vb.) mühendislik bakışıyla ele alır. Bu platformda asıl kısıt, genellikle Flash değil SRAM tarafıdır. Özellikle GSM üzerinden gönderilen telemetri paketlerinin JSON formatında hazırlanması, tek bir “buffer” içinde tutulduğunda RAM’i hızlıca tüketebilir.

Flash / SRAM / EEPROM bütçesi (ATmega2560)​

ATmega2560’ın hafıza kaynakları özetle:

  • Flash: 256 KB (bootloader alanı düşülebilir)
  • SRAM: 8 KB
  • Dahili EEPROM: 4 KB

Bu kartta ayrıca kalıcı parametreler için RTC üzerinde non‑volatile hafıza kullanımı vardır (aşağıda açıklanır).

Pratik not: Flash genelde “kütüphaneler ve feature set” ile dolar; RAM ise çoğunlukla çalışma anındaki buffer’lar (JSON/AT komutları, seri RX/TX ring buffer’ları, ölçüm snapshot’ları) ile dolar. Sahada kilitlenmelerin büyük kısmı RAM taşması / fragmentation kaynaklı olur.

RAM’de JSON paket buffer’ı sorunu​

Problem​

Mevcut yaklaşımda cihazın gönderilecek paketi (JSON) tek bir değişkende/string buffer’da tutması, RAM’i hızla tüketir. SRAM’in 8 KB olduğu düşünülürse:

  • JSON string büyüdükçe RAM daralır,
  • String birleştirme/formatlama (özellikle dinamik String kullanımı) heap parçalanmasına yol açabilir,
  • heap/stack çarpışması “random reset”, “modem komutu cevaplamıyor” gibi sahada zor teşhis edilen hatalara dönüşür.

Harici EEPROM ile çözmeye çalışmak doğru mu?​

Genel cevap: Hayır, JSON paketini RAM yerine harici EEPROM’a yazmak çoğu senaryoda iyi bir çözüm değildir.

Neden?

  1. Performans: EEPROM (I2C) yazma hızı düşüktür; sayfa yazımı beklemeleri vardır. Paket oluşturma süresini uzatır.
  2. Ömür (wear): EEPROM yazma ömrü sınırlıdır (tipik 10^5–10^6 yazım). Telemetri sık ise çok hızlı tüketilir.
  3. Asıl sorun RAM davranışı: Eğer amaç RAM’i rahatlatmaksa, JSON’u EEPROM’a yazıp sonra tekrar okumak çoğu zaman aynı problem sınıfını farklı yere taşır.

Harici EEPROM ancak “seyrek güncellenen kalıcı parametreler” için mantıklıdır. Telemetri paket buffer’ı gibi yüksek frekanslı ve değişken veri için EEPROM iyi aday değildir.

Daha doğru çözümler (R6 için öneriler)​

Öneri‑1: JSON’u RAM’de “stream” ederek üret (tek parça tutma)​

  • JSON’u parça parça üretip doğrudan GSM modem tarafına yaz (UART üzerinden “stream”).
  • Böylece RAM’de sadece küçük bir chunk buffer (örn. 128–256 byte) tutulur.
  • Bu yaklaşımın yan faydası: String birleştirme kaynaklı heap parçalanması büyük ölçüde ortadan kalkar.

Öneri‑2: Statik buffer ve deterministik bellek​

  • Dinamik String yerine sabit char tx_buf[N] kullan.
  • En kötü senaryoda paket boyutunu ölç ve üst sınır tanımla.
  • Paket sınırı aşılıyorsa “field azaltma / kırpma” gibi deterministik bir fallback uygula.

Öneri‑3: Harici FRAM (yalnız gerçekten spool gerekiyorsa)​

  • “Mutlaka RAM dışına yazacağım” denilecek bir senaryo varsa, EEPROM yerine FRAM daha uygundur.
  • FRAM; yazma ömrü açısından çok daha dayanıklıdır ve yazma gecikmesi daha düşüktür.
  • Yine de öncelik stream üretim olmalıdır; FRAM spool yalnız “beklenmeyen reset/power loss durumunda paketi kaybetme” gibi bir gereksinim varsa değerlendirilmelidir.

Öneri‑4: SD’ye spool (yalnız log/queue için)​

  • SD; telemetri buffer’ı için değil, “offline log / queue” için daha mantıklıdır.
  • Şebeke yokken birikimi SD’ye atıp, şebeke gelince batch gönderim yapılabilir.
  • SD’de dosya sistemi ve power‑loss senaryoları iyi tasarlanmalıdır (aşağıda).

EEPROM kullanımı (kalıcı parametreler)​

RTC üzerindeki EEPROM/NVM (mevcut yaklaşım)​

Bu projede kritik parametrelerin bir kısmı RTC üzerindeki EEPROM/NVM alanında saklanmaktadır. Bu, ana MCU resetlense bile ayarların korunması için doğru bir yaklaşımdır.

Bu alanda saklanmaya uygun örnek parametreler:

  • cihaz konfigürasyonu (küçük flag’ler)
  • son bilinen durumlar (örn. power state)
  • üretim kalibrasyon sabitleri
  • sayaçlar (seyrek güncelleniyorsa)

Mühendislik önerileri​

  • Versiyonlu yapı: EEPROM’a yazılan struct’ın başına magic + version + length koy.
  • CRC: veri bütünlüğü için CRC16/CRC32 ekle.
  • Atomic update: iki slot (A/B) kullan; yaz → CRC doğrula → “aktif slot” işaretini güncelle.
  • Yazma sıklığı: sayaç/parametre güncellemelerini “her olayda yazma” yerine biriktirerek azalt.

RTC EEPROM’u doğru kullanılırsa çok değerli; yanlış kullanılırsa (sık yazım + atomic yok) sahada “bozuk config” sorunları üretir.

MCU dahili EEPROM​

MCU’nun dahili EEPROM’u da benzer parametreler için kullanılabilir; ancak sistemde zaten RTC NVM kullanımı varken “iki farklı kalıcı alan” yönetimi karmaşıklık yaratabilir. Bu nedenle kalıcı parametreleri tek kaynağa toplamak (RTC NVM) daha temizdir.

Harici hafıza: SD (log/queue) tasarımı​

SD kart varsa, onu iki farklı amaç için düşünmek gerekir:

  1. FOTA / firmware staging
  2. Offline log / kuyruk (şebeke yokken veriyi kaybetmemek)

Format / dosya sistemi​

  • Yaygın yaklaşım: FAT32 (geliştirme kolaylığı)
  • Alternatif: ham (raw) ring buffer bölümü (daha deterministik)

Power‑loss ve veri bütünlüğü​

SD yazımında en riskli konu, enerji kesintisidir.

  • Yazma işlemlerini “append + kontrollü flush” disiplinle yap.
  • Dosya boyutunu sınırlı tut.
  • Ring buffer yaklaşımıyla en kötü senaryoda yalnız son blok kaybını garanti altına al.

Wear / ömür​

SD’de wear leveling kart tarafından yapılır; ancak gereksiz sık yazımdan kaçınmak gerekir:

  • log’ları toplu yaz,
  • küçük bloklarda sürekli yazma yerine daha büyük bloklarla yaz.

Güvenlik​

  • Telemetri/log içinde hassas veri varsa, en azından CRC/imza ile bütünlük doğrulaması yapılmalı.
  • Tam şifreleme gerekiyorsa, maliyet/CPU yükü ve anahtar yönetimi ayrıca tasarlanmalıdır.

Özet karar (R6 için)​

  • JSON paketini rahatlatmak için harici EEPROM eklemek doğru yön değil.
  • İlk tercih: stream üretim + statik buffer (RAM deterministikleşsin).
  • Kalıcı parametreler için mevcut RTC EEPROM/NVM yaklaşımı doğru; yalnız CRC + A/B slot gibi disiplinlerle sağlamlaştırılmalı.
  • SD, telemetri buffer yerine “offline log/queue” veya FOTA staging için kullanılmalı.