Belajar Embedded Engineer - Storage & Filesystems

#Pendahuluan

Firmware kalian sekarang punya data yang perlu bertahan: konfigurasi pengguna, kalibrasi sensor, log kejadian, atau data telemetry. Menyimpannya terlihat mudah — tinggal tulis ke flash — tapi flash itu mudah rusak. Setiap blok flash hanya bisa ditulis sejumlah kali tertentu sebelum aus, dan menulis di tengah listrik mati bisa mengkorup seluruh sistem file.

Episode ini membangun pemahaman tentang cara kerja flash, memilih filesystem yang tepat (LittleFS vs FATFS), menerapkan wear leveling, dan merancang data yang selamat dari kehilangan daya — keterampilan yang menentukan apakah produk kalian bertahan di lapangan selama bertahun-tahun.

#Memahami Flash: NOR vs NAND, dan Batasannya

Flash memory datang dalam dua keluarga dengan karakteristik berbeda:

Fakta yang harus melekat di kepala: flash tidak bisa menulis ulang bit 0 menjadi 1 secara sembarang — hanya erase (per blok besar) yang bisa mengembalikan ke 1. Jadi menulis berarti: erase blok → tulis. Dan tiap erase "memakai" blok itu sekali. Datasheet endurance (misal 100.000 siklus) adalah batas per blok, bukan batas total — itulah mengapa distribusi tulis yang merata (wear leveling) begitu penting.

#Wear Leveling: Menyebar Aus Secara Merata

Jika firmware menulis log ke alamat yang sama berulang-ulang, satu blok akan aus dalam hitungan minggu sementara blok lain menganggur selamanya. Wear leveling menyebar penulisan ke seluruh flash sehingga umurnya dimaksimalkan:

Tanpa wear leveling:
[LOG][LOG][LOG][LOG][. ][. ][. ]  <- blok LOG aus cepat, sisanya kosong
 
Dengan wear leveling (LittleFS):
[LOG][. ][LOG][. ][LOG][. ][LOG]  <- tulis menyebar, umur memanjang

Cara sederhana menerapkan wear leveling tanpa filesystem: slot rotation — tulis ke beberapa slot secara bergantian. Cara modern: pakai LittleFS, yang wear-leveling dan power-loss-resilience-nya sudah tertanam di desain.

#Memilih Filesystem: LittleFS vs FATFS

Untuk data di MCU, dua filesystem yang paling umum:

Aturan praktis: data internal MCU → LittleFS; data yang harus dibuka di PC → FATFS (SD card). LittleFS menangani masalah yang paling sering membunuh produk (aus dan korupsi); FATFS menangani kompatibilitas.

Contoh menulis konfigurasi ke LittleFS (ESP-IDF):

#include "esp_littlefs.h"
#include <stdio.h>
 
void save_config(void) {
    esp_vfs_littlefs_conf_t conf = {
        .base_path = "/cfg",
        .partition_label = "storage",
        .format_if_mount_failed = true,
    };
    ESP_ERROR_CHECK(esp_vfs_littlefs_register(&conf));
 
    FILE *f = fopen("/cfg/config.txt", "w");
    if (f) {
        fprintf(f, "sensor_id=42\ncalibration=1.25\n");
        fclose(f);  /* pastikan flush + sync sebelum listrik mati */
        fsync(fileno(f));
    }
}

Perhatikan fsync — ia memaksa data ditulis ke flash sekarang, bukan nanti. Tanpa sync, "tulis berhasil" di log kalian bisa berarti "data hilang saat listrik mati".

#Desain Data Tahan Listrik Mati

Fakta menyakitkan di embedded: listrik bisa mati kapan saja, termasuk tepat di tengah penulisan flash. Tiga strategi standar agar data selamat:

1. Copy-on-write / double buffering — tulis data baru ke slot kosong, lalu tandai slot lama tidak dipakai; jika listrik mati di tengah, data lama masih utuh.
2. Checksum + header — tiap record diberi magic number dan CRC; saat boot, buang record yang korup.
3. Atomic rename — tulis file temp, fsync, baru rename (rename di sebagian besar filesystem atomic). LittleFS mendukung pola ini dengan baik.

1. tulis config.new (lengkap + CRC)
2. fsync config.new
3. rename config.new -> config   <- langkah ini atomic
4. baru hapus config lama

Kesalahan umum: menulis langsung ke file "config" tanpa pola di atas — satu kali listrik mati di momen yang salah dan konfigurasi hilang atau korup, tanpa jejak recovery.

#Praktik: Sistem Penyimpanan Nyata

1. Mount LittleFS di partisi flash board kalian (ESP32 mudah: konfigurasi partisi + esp_littlefs).
2. Simpan konfigurasi (id sensor + kalibrasi), reboot, dan baca kembali — verifikasi persistensi.
3. Tulis log 1.000 record dengan timestamp, lalu periksa wear dengan tooling partition.
4. Simulasi listrik mati: matikan power tepat setelah fclose sebelum fsync, boot ulang, dan lihat apakah data korup — lalu terapkan pola copy-on-write dan ulangi.

#Common Pitfalls

1. Menulis terlalu sering — memperpendek umur flash; kurangi frekuensi tulis.
2. Lupa fsync/flush — data "berhasil" tapi hilang saat listrik mati.
3. Tidak ada checksum — korupsi tak terdeteksi sampai data dibaca dan salah.
4. Menimpa file config tanpa atomic pattern — korupsi permanen.
5. Memakai FATFS di flash internal — tanpa wear leveling, flash aus cepat.

#Penutup

Inti yang harus dibawa pulang:

• Flash punya endurance per blok; NOR untuk kode, NAND untuk data besar.
• Wear leveling menyebar tulis dan memperpanjang umur — LittleFS memilikinya bawaan.
• LittleFS untuk data MCU, FATFS untuk SD card yang dibaca PC.
• Data tahan listrik mati dengan copy-on-write, checksum, dan atomic rename.
• Kurangi frekuensi tulis — itu penghematan flash paling efektif.

Di episode 16 selanjutnya kita memastikan semua yang dibangun tetap terjaga: embedded testing & CI — unit test, HIL (hardware-in-the-loop), dan pipeline CI untuk firmware. Firmware yang tidak dites akan menagih utangnya berlipat di lapangan. Sampai jumpa di episode 16!