C oding wizzards?

[Hamburger]

In eeprom.pde I want to change checkNewConf to

Code: Select all

 checkNewConf = 17 + EEBLOCK_SIZE 

This gives compiler error. How to satisfy compiler?

[kos]

your have circulare dep (1) in your define .. that can not work


EEBLOCK_SIZE require eep_entry require checkNewConf require EEBLOCK_SIZE

Code: Select all

#define EEBLOCK_SIZE sizeof(eep_entry)/sizeof(eep_entry_t)

static uint8_t checkNewConf = 17 + EEBLOCK_SIZE;
// ************************************************************************************************************
// EEPROM Layout definition
// ************************************************************************************************************
static eep_entry_t eep_entry[] = {
  {&checkNewConf, sizeof(checkNewConf)}
, {&P8, sizeof(P8)}
, {&I8, sizeof(I8)} 
, {&D8, sizeof(D8)} 
, {&rcRate8, sizeof(rcRate8)}
, {&rcExpo8, sizeof(rcExpo8)}
, {&rollPitchRate, sizeof(rollPitchRate)}
, {&yawRate, sizeof(yawRate)}
, {&dynThrPID, sizeof(dynThrPID)}
, {&accZero, sizeof(accZero)}
, {&magZero, sizeof(magZero)}
, {&accTrim, sizeof(accTrim)}
, {&activate1, sizeof(activate1)}
, {&activate2, sizeof(activate2)}
, {&powerTrigger1, sizeof(powerTrigger1)}
#ifdef FLYING_WING
, {&wing_left_mid,  sizeof(wing_left_mid)}
, {&wing_right_mid, sizeof(wing_right_mid)}
#endif
#ifdef TRI
, {&tri_yaw_middle,  sizeof(tri_yaw_middle)}
#endif

};  

1 : http://fr.wikipedia.org/wiki/R%C3%A9f%C ... circulaire

[timecop]

Im wondering why eep storage is organized in this way anyway.

I just ended up doing something like

Code: Select all

typedef struct config_t {
    uint8_t version;
    uint8_t mixerConfiguration;
    uint32_t enabledFeatures;

    uint8_t P8[8];
    uint8_t I8[8];
    uint8_t D8[8];

    uint8_t rcRate8;
    uint8_t rcExpo8;
    uint8_t rollPitchRate;
    uint8_t yawRate;
....

config_t cfg;

and then eeprom writing/reading is just


    eeprom_open();
    eeprom_write_block(&cfg, (void *)NULL, sizeof(cfg));
    eeprom_close();


    eeprom_open();
    eeprom_read_block(&cfg, (void *)NULL, sizeof(cfg));
    eeprom_close();

Not sure why this eeblocksize stuff is even needed?

[Hamburger]

your have circulare dep (1) in your define .. that can not work
EEBLOCK_SIZE require eep_entry require checkNewConf require EEBLOCK_SIZE

I understand the principles of circular dependencies in general. but the size of the struct would be independent from the value of checkNewConf; and the sizeof(checkNewConf) is fixed regardless of its value as well.

So it seems I still should be allowed to separate this in a declaration static uint8_t checkNewConf; and later assign the value checkNewConf = 17 + EEBLOCK_SIZE; right before calling the writeEeprom(), right?

Of course, the same argument holds for dongs' simplified variant?

[timecop]

Why do you even *care* about including EEBLOCK_SIZE into the stuff.
No, with my way, you can just do version = checknewconf + sizeof(config_t) since size of struct will be known.
If you're trying to protect against silly changes, youre gonna screw yourself over when the following occurs:

1) user adds one more value to config struct, bumping size by 1byte, not increasing chknewconf
2) next user increases chknewconf without changing any data in struct. now version # is same.

[kos]

your have circulare dep (1) in your define .. that can not work
EEBLOCK_SIZE require eep_entry require checkNewConf require EEBLOCK_SIZE

I understand the principles of circular dependencies in general. but the size of the struct would be independent from the value of checkNewConf; and the sizeof(checkNewConf) is fixed regardless of its value as well.

So it seems I still should be allowed to separate this in a declaration static uint8_t checkNewConf; and later assign the value checkNewConf = 17 + EEBLOCK_SIZE; right before calling the writeEeprom(), right?

preprocessor first .. then only you can think about assigning value.



http://gcc.gnu.org/onlinedocs/cpp/Macro ... o-Pitfalls

[Hamburger]

Why do you even *care* about including EEBLOCK_SIZE into the stuff.
No, with my way, you can just do version = checknewconf + sizeof(config_t) since size of struct will be known.
If you're trying to protect against silly changes, youre gonna screw yourself over when the following occurs:

1) user adds one more value to config struct, bumping size by 1byte, not increasing chknewconf
2) next user increases chknewconf without changing any data in struct. now version # is same.

yes, I understand.
Actually I was not thinking about this combination of neutralizing changes, but more of the developer adding another value but not changing the version number. In current implementation this has lead for users to reading some eeprom rubbish into the new variable. This happened with added servo midpoint value(s). In this case I'd rather have the automatic reset to defaults as a fallback to working defaults.

[ziss_dm]

Hi,
Just move magic number(checkNewConf) to the tail..

Regards,
Ziss_dm

[Hamburger]

Cool. Very pragmatic.
Will do.

[Tommie]

Why not create a simple XOR checksum over the eeprom content and attach it the struct? It's simple and would probably catch most errors, even corupted EEPROM content.

Code: Select all

uint8_t check_cfg_integrity(config_t *cfg) {
  uint8_t chk = 0;
  uint8_t i;
  for(i=0; i<sizeof(*cfg); i++) {
    chk ^= (uint8_t*)cfg[i];
  }
  return (chk == 0);
}

...

    eeprom_open();
    eeprom_read_block(&cfg, (void *)NULL, sizeof(cfg));
    eeprom_close();
    if (! chk_cfg_integrity(&cfg)) {
      /* config is broken, reset it */
      cfg_load_default_values(&cfg);
    }

Then we need just another field inside the struct to hold the checksum byte.

[Alexinparis]

There is now a reset button in the GUI to set back all params to their default values