arduino help - Page 1
Forum section: electronics / general

author: grifftech
author_rank: Frequent Contributor
timestamp: May 25, 2016, 02:05:09 am
content: So I want to use my arduino UNO R3 to count how many times it is given power. Could anyone write some code for me to do this?

author: botcrusher
author_rank: Regular Contributor
timestamp: May 25, 2016, 03:06:43 am
content: You are looking for theEEPROM librarySpecifically read() and write ()Take note you've only got 100k writes, so for a counter Its fine, but i wouldn't use it to log large amounts of data.Code:setup(){int powerOnCount;powerOnCount = EEPROM.read(address);powerOnCount ++;EEPROM.write(address,powerOnCount);}loop(){//do stuff}

author: grifftech
author_rank: Frequent Contributor
timestamp: May 25, 2016, 04:03:31 am
content: Quote from: botcrusher on May 25, 2016, 03:06:43 aman e-paper display would be nice one something like this

author: botcrusher
author_rank: Regular Contributor
timestamp: May 25, 2016, 04:08:05 am
content: Hmm. Thought i forgot something.I mightnhave forgotten to initialize address

author: bitseeker
author_rank: Super Contributor
timestamp: May 25, 2016, 06:55:27 am
content: Yep. Although I thought that it was intended as an exercise for the reader.

author: Ian.M
author_rank: Super Contributor
timestamp: May 25, 2016, 07:22:53 am
content: Due to the limited write endurance you can wear out the EEPROM in under a day if you write to it too frequently. See:http://tronixstuff.com/2011/05/11/discovering-arduinos-internal-eeprom-lifespan/If you need to write to the EEPROM on every powerup, insert the longest delay you can tolerate before the first write to it, to delay the write until you are reasonably certain the power is stable, otherwise a bad connection could chew through the EEPROM endurance in only a matter of hours.The other thing you need to do is store multiple copies of the counter, because if power is lost during a write the EEPROM location will be corrupted. One approach is two copies with checksums. As it is a simple counter you don't need to track which copy is the most recent as its the highest one with a valid checksum. Each time you increment the count, you update whichever one is either lower or has an invalid checksum. If the checksum is invalid, and the count is less than double the endurance (because the wear is spread over two copies), there has been a write failure which almost certainly indicates one or more attempts to increment the count were made but power was lost during the write, so to partially compensate for the powerup(s) that were lost, increment the count by two instead of the normal one.

author: tszaboo
author_rank: Super Contributor
timestamp: May 25, 2016, 11:10:19 am
content: Quote from: Ian.M on May 25, 2016, 07:22:53 amOr you can make a database server to store all the data. Or in case the earth gets destroyed, build a space ship and launch the information into space. So long for the ridiculous complicated solutions.

author: Ian.M
author_rank: Super Contributor
timestamp: May 25, 2016, 12:07:14 pm
content: Its only an Arduino, but that's no reason not to code defensively. There a 3.3ms window on every byte write where power loss *WILL* corrupt the value written.I've seen commercial products failthis waydue to EEPROM wearand in one case the manufacturer got the MCU supplier involved for failure analysis - there was nothing wrong with the MCUs except EEPROM wear, due to a poor choice of unconditional write on power failure detection even if the parameter was unchanged, and some factories with very poor power quality, that were triggering the power failure interrupt several times each minute. It was resolved with no hardware changes by switching to a delayed write on parameter change strategy, with the power failure interrupt only as a last resort if a parameter hadn't been saved.Of course, sometimes you don't have the code and/or EEPROM space needed for the defensive code, or its too much of a performance penalty. That's when you have to choose between lower reliability or increased hardware cost, but making the decision to accept lower reliability without even noticing you have done so is just piss poor engineering.Edit: I had removed a paragraph when composing this which left 'this way' rsther ambiguous.

author: dannyf
author_rank: Super Contributor
timestamp: May 25, 2016, 01:43:28 pm
content: I did a few tests in pic12f675 / 16f684 (1 million write endurance) and. Stm8s003 (100k write endurance).I wrote and then read back the whole eeprim and counts until error occurs.I did over 1mil writes and stopped as no error took place for both families.I suspect that's true for other devices as. Well, regardless of their endurance. Ratings.

author: stj
author_rank: Super Contributor
timestamp: May 26, 2016, 01:35:30 am
content: you can by FRAM based eeproms now with unlimited writes.

author: Ian.M
author_rank: Super Contributor
timestamp: May 26, 2016, 03:46:27 am
content: FRAM has its own set of problems. Although it doesn't wear out, the underlying technology uses a destructive read. Seehttps://www.eevblog.com/forum/projects/the-other-downside-to-fram/

author: stj
author_rank: Super Contributor
timestamp: May 26, 2016, 08:26:23 am
content: not really, the guy in that thread was running out-of-spec.Arduino has a 5v regulator, it's either 5v or nothing.

author: Ian.M
author_rank: Super Contributor
timestamp: May 26, 2016, 08:48:57 am
content: I think its important to be aware that FRAM will permanently loose data if the supply dips during a read operation. Also, you cant verify the memory contents without automatically rewriting it. This means the classic EEPROM strategy of verifying what you've written to check for write errors is at best useless and at worst actively harmful. Additionally, the Arduino linear 5V regulator is marginal at high input voltages and load currents due to its limited heatsinking, so the integrity of the 5V supply is far from being ensured.

author: stj
author_rank: Super Contributor
timestamp: June 01, 2016, 07:15:00 am
content: well you can get a power management chip that will lift /CE if the voltage starts to drop - they are intended for battery-backed cmos ram.engineers dont just complain about problems, they find workarounds.

author: Ian.M
author_rank: Super Contributor
timestamp: June 01, 2016, 10:52:08 am
content: Gating /CE with a power management chip's active high BOR output is great if you are using a parallel FRAM, and gating /CS may help with SPI FRAM, and should be done anyway so that any power-up/down I/O pin glitches from your MCU don't get the chance to trigger a memory access cycle, but the key to preventing FRAM data loss is never start an access cycle unless there is sufficient energy available to complete it while Vdd remains in spec. Extra hardware is likely to be needed so the MCU can be aware of loss of incoming power well before Vdd reaches its critical lower level.As you said. its engineering, but for FRAM it needs to be good engineering without cutting corners.

author: Rick Law
author_rank: Super Contributor
timestamp: June 13, 2016, 01:12:10 am
content: Quote from: botcrusher on May 25, 2016, 03:06:43 amAn approach to deal with the 100K write cycle life is to implement some form of wear leveling.Basically, it is to use block of memory to store a byte and each update you use a different spot - so you reduced the writes to the same spot of EEPROM. For example, if you use a 128byte block to store one byte, you have 128x100K writes - that is 12.8 million writes.Initialize with erase (erase only, no write) erasing the block so the whole 128 is now 0xFF. 0xFF implies no data stored/not-in-use. It also means 0xFF is not a valid value to store.When reading it in, you read the 128 byte into an array. First one that is not 0xFF (has data) is the current spot. When you update, you write to the next spot (wrapping back to zero if it exceeds array size). After update at next spot, erase (without write) the current spot and now the current spot becomes the old spot and it is 0xFF, and the next spot is now your current spot.If you need store bigger than 0 to 254 (0x00 to 0xFE), you can use 2 blocks. The first block for the higher order byte - since that will support searching for !=0xFF, so it can store 0x00 to 0xFE. The second block for the low order byte (0x00 to 0xFF). So you can store 0x0000 to 0xFEFF. During read, you search only the first block for high-byte which will max at 0xFE. The low-byte is in block 2 and requires no searching. The entry would be at the same offset from the start of block.Of course, if the whole EEProm is devoted to storing just that, you can use the whole 1K to store your two bytes in two 512byte blocks. Creating a 512 byte array will be difficult (lots of RAM), so you may need to loop the read/search. But 51 million writes is a good bit more writes than 100K writes.