/**
  \example eeprom4.cpp 

  The benefit of EEPROM is that it's \e persistent: It stores values
  indefinitely until they're changed.  But, that's also a problem: If
  EEPROM data 'lasts forever', how and when do you \e initialize
  EEPROM data values?  Notice, for example, how \ref eeprom2.cpp never
  actually set its button-press-count to zero, to get things started
  cleanly!  Bogus!

  But if you just initialize your EEPROM data in your #setup()
  function, when you initialize reflexes and alarms and so on, well
  then that initialization will happen on \e every reboot, and the
  'persistent' advantage of the EEPROM is lost.

  One strategy is to create a special 'reset' reflex of some kind,
  that initializes EEPROM when handled.  In a way, though, that
  doesn't \e solve the problem so much as just fob it off on somebody
  else: Now something external to the board must decide when EEPROM
  initialization should happen.

  Another strategy is to write some 'magic value' along with the other
  EEPROM data; then later, if the magic value is found to be there,
  the rest of the written EEPROM data is \e assumed to be valid.  A
  problem with that approach is that if the EEPROM data is only \e
  partially overwritten, then the magic value might still match even
  though the data is corrupt.

  A third strategy is to write two complete copies of the data, in
  different places in EEPROM.  If the two copies match, they are
  trusted, otherwise they are initialized.  This doubles your space
  requirements, which in the worst case is like cutting your EEPROM in
  half, but if you can afford the space the 'two copies' approach is
  indeed quite robust.

  This advanced sketch illustrates a fourth strategy for handling
  EEPROM initialization.  Instead of writing all the data twice, the
  idea is to compute an #SFBChecksum value from the EEPROM data, and
  write the checksum along with the data, at an overhead of only 8
  bytes, no matter how much data is stored.

  Then later, if that stored checksum matches a freshly-computed
  checksum of the EEPROM data, the data is taken as valid; if not, the
  data is initialized.

  Used this way, the #SFBChecksum acts like a magic value that \e
  depends on the stored data values -- so if any of the stored data is
  changed, it is \e likely (though \e not guaranteed) that the
  #SFBChecksum won't match.

 */
