mirror of
https://github.com/OpenEPaperLink/OpenEPaperLink.git
synced 2026-03-21 00:04:28 +01:00
[GH-ISSUE #150] Feature request: avoid writing to Tag EEPROM on every screen update #2280
Assignees
sascha_hemi
Clear assignees
sascha_hemi
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/OpenEPaperLink#2280
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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).
@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?
@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?
@jonasniesner commented on GitHub (Dec 31, 2023):
Closing as not possible for all tags / not planned.
@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 👍