In my project, I will eventually need to store a couple of numbers that change *all the time*.
EEPROM or FLASH is unsuitable for this, as there is a write limit of about 10,000 writes to EEPROM (which will be exhausted in around 24 hours in our situation).
Flash is more robust, but there is not any provision for writing to flash, plus it is a Page based write, which means more than the number being changed is affected.
Many RTC devices have a few bytes of ram that is battery backed up. If this exists, any possibility of access to this ram through the code?
which MCU are you using with your project?
Nextion side RTC may not be guaranteed to be same RTC used from production run to production run. Therefore, any bytes that may have been available in a given available RTC could be non existent in another model. As such, the firmware would be limited to the common functionality of providing time functions with no extended RTC support.
Nextion side, Global scope variables use Nextion side MCU sram, accessible anytime, from all pages within the running HMI design.
But since you are speaking of a maximum of 56 bytes that may or may not have been inside an RTC device, you should be able to have 56 bytes available for use as a global scope variables and still have a functional HMI design
-- Atmel EEPROMs used in Nextion from what I can dig up have 1,000,000 write cycles
may not solve all, but may reduce maintenance to every 90 days =)
We are using a PSOC. No battery backed up ram. Has flash and eeprom. However, same limitations apply. But the users would throw the unit through our front window if every 90 days they were down. It could also (rarely) cause problems such as destroyed end customer equipment. (That event does require stupidity on top of carelessness on top of laziness, but those characteristics are in abundance in our field.)
There are several RTC devices out there, many with 64 bytes of battery backed up ram. I had not looked at yours, I see it has no ram, based on another forum post. Based on commercial single piece prices, looks like it adds a dime to the cost as compared to an RTC without ram.
We are looking at modifying our PCB to include NVRAM and/or RTC with 64 bytes of SRAM, 700na to back up with battery. That complicates our design and possibly moves us to 4 layer board.
No problem, we can handle. I was hoping! <grin>
One more thing. If you do the work for a "Stop" you may be able to fold that technology into the windows machine debugger and allow for single stepping through commands. It is a pain, but can be done. (ivbasic on iPad).
BTW, I understood your humor about the 90 day replacement. :)
Sometimes, that is a good thing!
I know the RTC on my Enhanced 3.5 "has" 56 bytes - but still not accessible via firmware
So other posts will most likely be "no bytes", as the result is the same.
Do your settings actually change ~ every 8 seconds?
Many times, life cycle is greatly extended by compare before write and only
consume a write cycle if the values have actually changed.
Would this extend things for you?
When you still have the possibility to change the PCB layout, why not just add a RAMTRON FM24C04 Ferrorelectric NVR I2C device ...
I dont think, that the addon of such a device will change the PCB layout from 2/3 layers to 4 ... for this the connection is too simple ...
Anyway, such Ferro NVR's are the most speedy and reliable you can momentary buy ...
Our device is a depth counter. It can change two or three times a second. If power goes out temporarily, we need to remember the last reading.
Perhaps the command processor can give yes/no for available ram in the RTC and be used in an if statement along with commands to read/write that ram.
We are going to experiment with both NVRam and RTC. Our PBC is used in various products, and has quite a few connections. an RTC will be useful in other indications. However, since it is easy to get an RTC with ram, and such a device is cheap, I was just hoping for a short cut.
I did see where a ferroelectric NVRAM was good for 100 trillion read/writes. hmm. could last a week or two. <grin>