Discuss use of EEPROM_VERSION

I wanted to start a discussion about how to use the reserved EEPROM_VERSION byte now that we’ve added UnitID and UnitName and other things… Obviously a sketch would still need to set the value initially - we could add that to the unit setting example sketch.

So what about (for now):

0x00 - Custom build, unknown.
0x01 - Dev Kit
0x02 - Production, reversed RGB
0x03 - Production, correct RGB
0xFF - Reserved / unset.

For starters, this would allow sketches to better make use of the RGB considering the many units in the wild with incorrect wiring. I know CircuitDude doesn’t properly light the LED on my 5 Kickstarter units. If it had a way to detect the hardware version it could light the blue LED when the level was complete, etc.

This could also be treated as a bitfield…

3 bits - VERSION (0-7)
5 bits - RESERVED for future use

Thoughts?

I don’t think you need a flag for DevKit. Conditional compiles testing AB_DEVKIT should suffice, with less code produced.

Perhaps not… I suppose DEVKIT is so different if we want to support it as a compiled type we’d have to do that everywhere, so I guess it would just fall under unknown/custom then?

I assumed EEPROM_VERSION was to indicate the format of the rest of system EEPROM, in case it changed in a non-backwards compatible format in the future. I don’t know whether this is necessary or would ever be useful, though. The extra code required to test for and handle multiple EEPROM formats would be a detriment.

However, since we’re currently not tight for EEPROM space, I think we should just leave it be and add a new flags byte. (As we’ve discussed privately, you know I’ve already done this, called EEPROM_SYS_FLAGS.)

Instead of hardware version numbers, use individual flags to indicate specific settings. In this case, you would only use one flag to indicate the orientation of the RGB LED.

Since EEPROM defaults to 0xFF, A bit set to 1 should indicate the default, desired or more common value. For the RGB LED, a 1 would mean correctly installed and 0 would mean reversed.

All flags would be abstracted by providing API function calls to test and set them.