W urządzeniach IoT rzadko psuje się najpierw procesor czy radio — zwykle pierwsza odchodzi pamięć flash. Zużycie rośnie po cichu przez lata, aż rejestrator zdarzeń przestaje się montować, a urządzenie wraca z serwisu z opisem „nie startuje po zaniku zasilania”.
W skrócie: pamięć flash w IoT wytrzymuje od ok. 1 000 (NAND TLC) do 100 000 (NOR SPI) cykli kasowania na blok, więc o żywotności decyduje nie kość, lecz architektura zapisów — wear leveling rozkłada kasowania po całym nośniku, a system plików LittleFS dokłada odporność na zanik zasilania.
Czym jest pamięć flash w IoT i dlaczego się zużywa?
Pamięć flash to nieulotny nośnik, w którym bity zapisuje się pojedynczo (1→0), ale kasować można wyłącznie całymi blokami, do stanu 0xFF. To kasowanie — przepychanie ładunku przez tlenek bramki pływającej — degraduje komórkę.
Każde kasowanie nieznacznie uszkadza izolację. Po przekroczeniu deklarowanej wytrzymałości komórka przestaje trzymać ładunek i blok trzeba wycofać. Producent podaje ten limit w cyklach P/E (program/erase) na blok, nie na całą kość.
Drugi, często pomijany parametr to retencja danych: typowo 10–20 lat w 25 °C, ale przy 85 °C i po wyczerpaniu połowy cykli — pojedyncze lata.
NOR czy NAND — którą pamięć flash wybrać do urządzenia IoT?
NOR flash to pamięć o adresowaniu losowym, wolnym zapisie i wysokiej wytrzymałości, przeznaczona do kodu i małych wolumenów danych. NAND daje wielokrotnie niższy koszt na gigabajt, ale wymaga ECC i obsługi bloków wadliwych od pierwszego dnia.
- NOR SPI/QSPI (1–64 MB) — ok. 100 000 cykli P/E, sektory 4 KB, odczyt XIP. Domyślny wybór dla czujników i bram IoT.
- SLC NAND (128 MB – 1 GB) — 60 000–100 000 cykli, bloki 128–256 KB, wymaga ECC i tablicy bad blocków.
- MLC/TLC NAND i eMMC (4 GB+) — 1 000–3 000 cykli, ale kontroler eMMC sam robi wear leveling. Sensowne przy wideo lub Embedded Linux.
- Flash wewnętrzna MCU — 10 000–100 000 cykli, sektory 2–128 KB. Wygodna, ale kasowanie blokuje magistralę na dziesiątki milisekund.
Przy wyborze między ESP32 a STM32 sprawdź, czy kontroler pozwala czytać z jednego banku flash podczas kasowania drugiego — bez tego aktualizacja w tle bywa niemożliwa.
Jak działa wear leveling?
Wear leveling to technika rozkładania kasowań równomiernie po wszystkich blokach nośnika, tak aby żaden blok nie zużył się szybciej niż pozostałe. Bez niego licznik zapisywany wciąż pod tym samym adresem zużyje jeden sektor w kilka miesięcy, a reszta kości zostanie nietknięta.
Dynamiczny i statyczny wear leveling
Wear leveling dynamiczny obraca wyłącznie blokami z danymi zmiennymi — jest prosty i tani obliczeniowo. Statyczny przenosi także dane rzadko zmieniane (np. konfigurację fabryczną), żeby uwolnić „zamrożone” bloki o niskim zużyciu: wydłuża życie nośnika nawet kilkukrotnie kosztem dodatkowych zapisów.
Rachunek: kość NOR 8 MB, 2 048 sektorów po 4 KB i 100 000 cykli to ok. 204 mln kasowań budżetu. Rejestrator zapisujący 50 rekordów po 64 B na minutę wyczerpie go po kilkudziesięciu latach — ale tylko przy rozłożonych zapisach. Bez wear levelingu awaria przychodzi po ok. 3 miesiącach.
LittleFS, SPIFFS czy własny format — który system plików do IoT?
LittleFS to system plików dla mikrokontrolerów, który łączy dynamiczny wear leveling z zapisem copy-on-write i odpornością na nagłą utratę zasilania. Zajmuje kilkanaście kilobajtów kodu i kilka kilobajtów RAM — stąd jego pozycja domyślnego wyboru w nowoczesnym firmware.
Alternatywy mają coraz węższe zastosowania:
- LittleFS — katalogi, power-loss resilience, wear leveling; wymaga ok. 20% wolnej przestrzeni.
- SPIFFS — brak katalogów, degradacja wydajności powyżej 75% zapełnienia, ryzyko utraty wolumenu przy zaniku zasilania. Tylko dla starszych projektów ESP.
- FATFS — potrzebny tylko wtedy, gdy nośnik ma czytać komputer (karta SD). Sam z siebie nie robi wear levelingu.
- Circular log — najlepszy do telemetrii: bufor pierścieniowy z rekordami stałej długości i CRC.
Jeśli dane i tak trafiają do chmury, ogranicz pamięć lokalną do bufora offline, a historię przenieś do bazy danych szeregów czasowych.
Jak projektować zapisy, żeby flash przeżył 10 lat?
Żywotność nośnika wyznacza współczynnik wzmocnienia zapisu (write amplification) — stosunek bajtów faktycznie skasowanych do zapisanych. W źle zaprojektowanym firmware przekracza 100.
- Buforuj w RAM i zapisuj paczkami — 60 zapisów po 32 B zastąp jednym zapisem 2 KB.
- Nie zapisuj konfiguracji przy każdej zmianie — zapisuj po debounce (np. 30 s) i przy kontrolowanym wyłączeniu.
- Stosuj rekordy o rozmiarze będącym wielokrotnością strony (256 B), wyrównane do granicy sektora.
- Nie loguj do flash na poziomie DEBUG w produkcji.
- Zostaw 20–25% wolumenu jako zapas dla wear levelingu i bloków wadliwych.
- Monitoruj liczbę kasowań i raportuj ją w telemetrii diagnostycznej.
Pamięć flash a aktualizacje OTA i bezpieczeństwo
Układ partycji flash przesądza o tym, czy urządzenie da się bezpiecznie aktualizować zdalnie. Schemat A/B wymaga dwóch pełnych slotów obrazu plus metadanych — przy firmware 1 MB realnie 4 MB kości.
Każda kampania aktualizacji OTA w skali floty to pełne kasowanie slotu nieaktywnego. Przy 12 aktualizacjach rocznie przez 10 lat to 120 cykli — pomijalne dla NOR, istotne dla NAND TLC. Dodatkowo secure boot weryfikuje podpis obrazu przy każdym starcie, więc pojedynczy uszkodzony bit w kodzie oznacza twardą odmowę uruchomienia.
Najczęściej zadawane pytania (FAQ)
Ile cykli zapisu wytrzyma pamięć flash w urządzeniu IoT?
Typowa kość NOR SPI deklaruje 100 000 cykli kasowania na sektor, a wewnętrzna flash mikrokontrolera zwykle 10 000–100 000. Pamięć NAND TLC bywa ograniczona do 1 000–3 000 cykli. Realną żywotność wyznacza nie sama kość, lecz liczba kasowań bloku na dobę — dlatego wear leveling i buforowanie zapisów są ważniejsze niż sam dobór układu.
Czym różni się LittleFS od SPIFFS?
LittleFS to system plików z wbudowanym dynamicznym wear levelingiem, strukturą kopiowania przy zapisie i odpornością na zanik zasilania — po nagłym restarcie wraca do ostatniego spójnego stanu. SPIFFS nie ma katalogów, drastycznie zwalnia przy zapełnieniu powyżej ok. 75% i potrafi utracić wolumen po utracie zasilania. W nowych projektach standardem jest LittleFS.
Czy wear leveling wystarczy, żeby zabezpieczyć dane w urządzeniu IoT?
Nie. Wear leveling rozkłada zużycie równomiernie, ale nie chroni przed przerwaniem zapisu w połowie operacji ani przed błędami bitów. Potrzebne są dodatkowo: transakcyjny zapis (A/B lub journal), sumy kontrolne CRC na rekordach, monitoring liczby błędów ECC oraz margines wolnej przestrzeni rzędu 20–25% wolumenu.
Podsumowanie — najważniejsze wnioski
Pamięć flash w IoT jest elementem zużywalnym i trzeba ją traktować jak budżet: policzyć zapisy na dobę, podzielić przez liczbę bloków, porównać z wytrzymałością kości. Wear leveling i LittleFS rozwiązują większość problemów, ale nie zastąpią dyscypliny w tym, co i jak często firmware zapisuje.
W FSS Technology projektujemy urządzenia IoT od schematu i płytki PCB, przez firmware i warstwę pamięci, po chmurę. Planujesz urządzenie, które ma pracować w terenie przez dekadę? Sprawdź ofertę projektowania urządzeń podłączonych do sieci — dobierzemy kość, układ partycji i strategię zapisów, zanim staną się problemem serwisowym.