[GH-ISSUE #46] Feature request: Direct writing without buffering in flash #566

New Issue

sascha_hemi · 2026-03-20T18:10:34+01:00

sascha_hemi commented

2026-03-20 18:10:34 +01:00

Originally created by @seeers on GitHub (May 22, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/46

I am afraid that the flash memory of the ESP32 will not live long with frequent updates (e.g. SmartHome status display with an update every few minutes).

Maybe it would be possible to store the data in a ramdisk. Or to store temporarily on a external webserver?

Or retrieve an image directly as RAW from a webserver without caching it? Then you could create the raw files directly on the system where they are fetched.

It would be a pity if the gateway had to be replaced every few months because of defective flash cells.

Originally created by @seeers on GitHub (May 22, 2023). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/46 I am afraid that the flash memory of the ESP32 will not live long with frequent updates (e.g. SmartHome status display with an update every few minutes). Maybe it would be possible to store the data in a ramdisk. Or to store temporarily on a external webserver? Or retrieve an image directly as RAW from a webserver without caching it? Then you could create the raw files directly on the system where they are fetched. It would be a pity if the gateway had to be replaced every few months because of defective flash cells.

sascha_hemi added the enhancement good first issue labels 2026-03-20 18:10:34 +01:00

sascha_hemi closed this issue

2026-03-20 18:10:34 +01:00

sascha_hemi commented

2026-03-20 18:10:34 +01:00

@jjwbruijn commented on GitHub (May 22, 2023):

Hey there! Thank you for bringing this to our attention.

I am pretty sure this won't be an issue, this is my reasoning:

Wear levelling. LittleFS uses wear levelling in order to prolong device life

Lets do some easy math. Round-ish numbers and a few assumptions.
Lets assume:

20kbyte for an image. Might be more, might be less, depending on your screen sizes, compression, etc.
100k erase/write cycles. Taken from this (not the same thing, but still) datasheet
1MB LittleFS flash partition

1mbyte/20kbyte = 50 image updates for an entire wear-levelled device write
at least 100k write endurance = 5 million images updated

In short: In 5 million images updated, we'll begin to run into the risk that the flash might fail. Might be 10 million, for all we know. Lets assume that we'll accept a usable life of about 10 years. At 5 million updates, that translates to about 1400 images per day, or about 1 image every minute. Roughly. You can do the calculations yourself :)

For a 16mb ESP32-S3, this is an order of a magnitude better. Bottomline: I'm not worried. But I'm open to arguments!

@jjwbruijn commented on GitHub (May 22, 2023): Hey there! Thank you for bringing this to our attention. I am pretty sure this won't be an issue, this is my reasoning: Wear levelling. LittleFS uses wear levelling in order to prolong device life Lets do some easy math. Round-ish numbers and a few assumptions. Lets assume: * 20kbyte for an image. Might be more, might be less, depending on your screen sizes, compression, etc. * 100k erase/write cycles. Taken from this (not the same thing, but still) [datasheet](https://github.com/jjwbruijn/OpenEPaperLink/files/11535842/0900766b81704060.pdf) * 1MB LittleFS flash partition 1mbyte/20kbyte = 50 image updates for an entire wear-levelled device write at least 100k write endurance = 5 million images updated In short: In 5 million images updated, we'll _begin_ to run into the risk that the flash _might_ fail. Might be 10 million, for all we know. Lets assume that we'll accept a usable life of about 10 years. At 5 million updates, that translates to about 1400 images per day, or about 1 image every minute. Roughly. You can do the calculations yourself :) For a 16mb ESP32-S3, this is an order of a magnitude better. Bottomline: I'm not worried. But I'm open to arguments!

sascha_hemi commented

2026-03-20 18:10:35 +01:00

@seeers commented on GitHub (May 22, 2023):

Thanks for the clarification, that definitely sounds more reassuring. That is definitely acceptable.

@seeers commented on GitHub (May 22, 2023): Thanks for the clarification, that definitely sounds more reassuring. That is definitely acceptable.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#566