Ways to configure and persist settings in Arduino-based hardware

Question

I'm currently building an Arduino-based LaserTag Game. After solving a lot of technical challenges I'm now at the point of programming and configuring my first prototype.

Next challenges:

• The "Taggers" should be customizable to the players needs (damage, bullets in mag..)
• Rules should be customizable before each game
• The Player shouldn't be able to reset health and ammo by just restarting the Tagger

Ideas:

1. My first Idea was to use the arduinos EEPROM but I read that it would only survive around 100k write/delete cycles. Which is not much when I write to it after every shot.

2. My second Idea was to use an external I2C EEPROM to persist settings and current game data. Atleast I wouldn't break my arduinos when I reach the point when it breaks. Also I can save a lot more data on it.

3. Another Idea is to customize the firmware for every player (I already have a tool for compiling and flashing firmware to the tagger) and also define the most common game rules in the firmware and just activate it over a serial connection. But then again, how can I persist the current tagger data like health and ammo.

Questions:

• Are there any best practices out there?
• Are there any technics I'm not aware of?
• What about SD Cards? They seem a bit overpowered for my use.

Answer 1

You may want to look into "EEPROM wear leveling". If you had a 32-bit (4 bytes) counter and 1024 bytes of EEPROM you could in theory extend the EEPROM's life time by a factor of 1024/4 = 256, which gives more than 25M write cycles. Even if you only use 50% of the EEPROM for the counter that'd be about 12M 'shots'.

See for example Wear leveling on a microcontroller's EEPROM or https://stackoverflow.com/questions/10667491/is-there-a-general-algorithm-for-microcontroller-eeprom-wear-leveling. I think there are also supporting libraries out there.

An SD card probably is overkill, but should work fine. The same principles apply to (SD-)flash memory as to EEPROMS. Flash has limited write cycles, too, but the integral controllers on SD cards automagically perform the wear leveling so you don't have to deal with that. If you have a 1GB card and write 1MB of new data per game, ideally the controller would have taken care so that after 1000 games played each sector of the card has only been written to once. Assuming only 10k guaranteed write cycles per sector, that should give about 10M guaranteed games.

Answer 2

FRAM combines the strengths of both SRAM and EEPROM. It's not cheap, but each chip will effectively last the lifetime of the equipment. It comes in SPI-enabled forms and so should be very easy to integrate with an Arduino.

Answer 3

Yes, EEPROM has a limited write life. One technique is to hold a buffer in RAM, which you write to. Then, every so often, that buffer is written to EEPROM. Or it's written in response to an event. In some cases, it's written as a response to an interrupt that's generated on power-down. Of course, you'd need some way to generate that interrupt and to keep the actual chip powered up long enough to write the EEPROM.

Another way is to spread out the writes over the entire EEPROM. Do check the datasheet, but in some cases the maximum write life is per-byte. So if you can find a way to locate the current data at any location in the EEPROM, you can keep moving it around to even out the wear.

Answer 4

One thing you could do is put a big capacitor across VCC and ground, then continuously check to make sure the input voltage is 5 volts (or whatever your using). If it drops below some level you could assume that power has been cut off, and you can write data to eeprom in the few ms before the capacitor runs out (eeprom writes take 3.3 ms). According to this the supply voltage can drop to 3.8 volts before 16 mhz clock speeds become an issue, so that should give you a fair amount of time to dump data.

I know that this isn't they type of solution your looking for, but it might work well since you won't have to write to eeprom every time a shot is fired.

Answer 5

There are certainly many ways in which one could keep count values stored in EEPROM; if you never fire more than 1000 shots within a single game, you could have a 1KB area of EEPROM which counts shots for the current game; on every shot, you reset an FF byte to 00. On startup, counting the non-FF bytes would indicate how many shots had been fired.

That having been said, I don't really see the necessity of that in this application. If a player was could reset his tagger whenever he wanted, the player could simply keep his tagger in reset except when he could zap an opponent from a position of safety. I would suggest instead that the taggers be robust enough that they will never reset except by consequence of deliberate player action, and that a tagger which gets reset mid-game should be out of commission and flash a distinctive light pattern until such time as a game official restores it to operation.

Additionally, while different tagging games use different communications approaches, I would suggest that wireless modules are sufficiently cheap that it should be possible to have taggers exchange real-time information about what is going on; even if player's gun does get reset, at most a few shots would be omitted from its reports.