Writing to EEPROM vs. SD

My application counts pulses received from a digital pin. Those pulses accumulate for a month at a time. If the unit reboots or otherwise loses power it loses count of how many pulses have registered MTD. I'm not buying a battery backup, seems silly, so instead I was considering writing to the EEPROM or SD card once every hour. On boot I would read it once and pick up from there. This calculates out to about 11 years of read/write cycles using EEPROM and undetermined if going the SD route. Either way would suffer from losing the current hours pulses since only the count up to the current hour is stored away, and I can live with that.

So, EEPROM or SD card?
If EEPROM, how would I store an integer ~600,000? As I understand the EEPROM storage unit is bytes.
If SD, I imagine the r/w cycles are lower. SanDisk did not list it (odd) for my card.,

Thanks

I think the eepromWriteAnything library will split up your number into bytes to write it to eeprom.

600,000 = 0x09 0x27 0xC0, so three bytes.
Store your count as unsigned long, 4 bytes.

Or split it up yourself, is not hard to do.

Then writing to EEPROM is pretty simple
eepromWrite(address, data);
something along those lines.

Or just keep track of the pulses as bytes:

if (pulseOccurred ==1){
if (pulseCount[0] <=255){
pusleCount[0] = pulseCount[0] +1;
}
else {
pulseCount[0] = 0;
 if (pulseCount[1] <=255){
 pusleCount[1] = pulseCount[1] +1;
 }
else {
pulseCount[1] = 0;
if (pulseCount[2] <=255){
pusleCount[2] = pulseCount[2] +1;
}
else {
pulseCount[2] = 0;
if (pulseCount[3] <=255){
pusleCount[3] = pulseCount[3] +1;
}
else {
pulseCount[3] = 0;
}
//then write the 4 bytes to EEPROM.

and work out the { } so this increments and rolls over correctly

Lithium cell.

RTC (Real Time Clocks) use a lithium battery and almost always have a RAM area backed up by the same battery.

They are not expensive, and you get the time for your records as well.

If you use SDcard and open a file in append mode and write to it, you are never going to
wear it out writing a short string once an hour, since each block is only rewritten a few
hundred times at worst. Well you might have to create a new file every so often to avoid
too many writes to the file length and file-update timestamp fields.

A data-logging shield seems a natural fit for your application, since you get a historical
record, not just a final count.

Note, most if not all modern flash memory cards (CF, SD, MS, etc.) uses a hidden mapping from the logical block number that the software specifies to the physical block number used in the memory card. The software might think it is writing block 0 over and over again, but each write actually writes to a different block each time. http://en.wikipedia.org/wiki/Wear_leveling

I have an SD card on the Ethernet shield and after some trials I was able to get it to do what I wanted. I still think the EEPROM is a good way to go long-term but I couldn't be bothered to get the EEPROM_writeAnything library to work, and after a while I convinced myself to move on. So for now, SD Card it is, and while it may not be a true data logger, that's OK. I don't need timestamps as I write all of my important metrics to SQL. Some of my gauges use real-time data that is not cached and to to save some SQL queries I just use "live" data. The webpage JS handles the calculations and while a reboot would be a bummer, at least I would seed the vars with the last known values and begin incrementing from there. Time will tell how well the SD card holds up.

Thanks for the responses.

MichaelMeissner:
Note, most if not all modern flash memory cards (CF, SD, MS, etc.) uses a hidden mapping from the logical block number that the software specifies to the physical block number used in the memory card. The software might think it is writing block 0 over and over again, but each write actually writes to a different block each time. http://en.wikipedia.org/wiki/Wear_leveling

I really doubt if cheap SDcards bother with wear-levelling, its not trivial to implement
without reducing throughput. I’ve certainly had many failures in SDcard and microSD cards
that suggest no bad block management other than static… Most SDcards have VFAT32
and go in cameras which don’t overwrite sectors very much if at all…

USB memory sticks on the other hand are more likely to have it as standard to support
real world use and I’ve hardly ever seen a data integrity failure in a USB stick.

Rather than both with the EEPROM writeAnything library, just write the bytes out?
Something like this untested code

#include <EEPROM.h>
long value ;

#define addr ??   // whatever EEPROM address you want

void store_value ()
{
  for (byte i = 0 ; i < 4 ; i++)
    EEPROM.write (addr+i, (byte) (value >> (i<<3))) ;  // extract little endian byte order
}

long read_value ()
{
  long result = 0 ;
  for (byte i = 0 ; i < 4 ; i++)
  {
    long part = 0xFF & EEPROM.read (addr+i) ;
    result |= part << (i << 3) ;  // reconstruct, need long shift hence the part variable
  } 
  return result ;
}