[GH-ISSUE #150] Feature request: avoid writing to Tag EEPROM on every screen update #2832

New Issue

sascha_hemi · 2026-03-20T22:05:00+01:00

sascha_hemi commented

2026-03-20 22:05:00 +01:00

Originally created by @morfeus2 on GitHub (Oct 25, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/150

From the protocol description I read:

After a full block has been received, the tag will do a simple checksum over all received data. If the checksum matches, the 4K of data is stored in EEPROM storage for later use

so if I understand correctly every time I submit a new image to be displayed, it gets written to the Tag EEPROM. I don't really understand the reason..maybe to overcome some technical issue, but I really can't imagine why.
Would it be possible to avoid writing to EEPROM during normal usage?
I already read this page:

https://github.com/jjwbruijn/OpenEPaperLink/issues/46

but if I understand correctly it applies to the AP EEPROM not the Tag one.
I plan to use a Tag with very fast refresh (of the order of 5-10 seconds, since I am on rechargable AAA batteries the power consumption is not an issue at all).

Originally created by @morfeus2 on GitHub (Oct 25, 2023). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/150 From the protocol description I read: _After a full block has been received, the tag will do a simple checksum over all received data. If the checksum matches, the 4K of data is stored in EEPROM storage for later use_ so if I understand correctly every time I submit a new image to be displayed, it gets written to the Tag EEPROM. I don't really understand the reason..maybe to overcome some technical issue, but I really can't imagine why. Would it be possible to avoid writing to EEPROM during normal usage? I already read this page: https://github.com/jjwbruijn/OpenEPaperLink/issues/46 but if I understand correctly it applies to the AP EEPROM not the Tag one. I plan to use a Tag with very fast refresh (of the order of 5-10 seconds, since I am on rechargable AAA batteries the power consumption is not an issue at all).

sascha_hemi added the enhancement label 2026-03-20 22:05:00 +01:00

sascha_hemi closed this issue

2026-03-20 22:05:00 +01:00

sascha_hemi commented

2026-03-20 22:05:01 +01:00

@jonasniesner commented on GitHub (Dec 12, 2023):

This is more of a technical limitation that might only be able to be overcome for low res tags. The eeprom is used because an image can not be sent in one transmission most of the time but gets decided up into 4k block that have to be stored temporarily somewhere. And because the ram is not big enough for a full image on bigger Tags, the eeprom gets used. Some ePaper displays might also have enough ram to store 1 frame directly. But as far as I know, nothing is planned in this direction at the moment. Did you have time to test out the fast updates with the current firmware?

@jonasniesner commented on GitHub (Dec 12, 2023): This is more of a technical limitation that might only be able to be overcome for low res tags. The eeprom is used because an image can not be sent in one transmission most of the time but gets decided up into 4k block that have to be stored temporarily somewhere. And because the ram is not big enough for a full image on bigger Tags, the eeprom gets used. Some ePaper displays might also have enough ram to store 1 frame directly. But as far as I know, nothing is planned in this direction at the moment. Did you have time to test out the fast updates with the current firmware?

sascha_hemi commented

2026-03-20 22:05:01 +01:00

@morfeus2 commented on GitHub (Dec 12, 2023):

Ok, now I start to understand. I did not image the RAM could be so small. In my case the PNG image I upload is 296x128 (10522 bytes, but this is less important since there is the PNG compression algorithm in the middle) for a 2.9" tag. It's been some time that I did not look to this project so I am still running quite old firmware and PC client. I can update to the present version: is there something specific I should test?

@morfeus2 commented on GitHub (Dec 12, 2023): Ok, now I start to understand. I did not image the RAM could be so small. In my case the PNG image I upload is 296x128 (10522 bytes, but this is less important since there is the PNG compression algorithm in the middle) for a 2.9" tag. It's been some time that I did not look to this project so I am still running quite old firmware and PC client. I can update to the present version: is there something specific I should test?

sascha_hemi commented

2026-03-20 22:05:01 +01:00

@jonasniesner commented on GitHub (Dec 31, 2023):

Closing as not possible for all tags / not planned.

@jonasniesner commented on GitHub (Dec 31, 2023): Closing as not possible for all tags / not planned.

sascha_hemi commented

2026-03-20 22:05:02 +01:00

@atc1441 commented on GitHub (Dec 31, 2023):

By the time the eeprom will fail the E-Paper Display will be broken most likely already so it would not improve anything anyway 👍

@atc1441 commented on GitHub (Dec 31, 2023): By the time the eeprom will fail the E-Paper Display will be broken most likely already so it would not improve anything anyway 👍

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#2832