assigning multiple constants with non-zero base? (enum)?

I need a byte to store values from 0 to 240 to express time of day (yes, that has two midnights, with cause!), and use values greater than that for "hourly" and so fourth.

If I was starting names at zero, I could use enum, but I'm not (cannot, AFAIK). So for the moment I define

``````const byte SPR_HOURLY=241;
const byte SPR_TWO_HOURS=242;
const byte SPR_THREE_HOURS=243;
const byte SPR_FOUR_HOURS=244;
const byte SPR_SIX_HOURS=245;
const byte SPR_EIGHT_HOURS=246;
const byte SPR_TWELVE_HOURS=247;
const byte SPR_HALF_HOUR=246;
const byte SPR_FIFTH_HOUR=247;
``````

and, as to be expected, I've realized that that's not quite how I want it.

As I'll probably change my mind another couple of times in the next couple of days, is there a "sensible" way to start a serious of assignments at, say, 241?

[FWIW, this divides the day into 240 six minute segments for a sprinkler system. But for the early weeks when seeding, I need to keep the soil moist, so hourly or two hourly, depending on weather And some things just want to be watered every six hours, or whatever.]

dochawk: If I was starting names at zero, I could use enum, but I'm not (cannot, AFAIK).

Oh, yes, you can.

``````enum {
SPR_HOURLY = 241,
SPR_TWO_HOURS,
SPR_THREE_HOURS,
SPR_FOUR_HOURS,
SPR_SIX_HOURS,
SPR_EIGHT_HOURS,
SPR_TWELVE_HOURS,
SPR_HALF_HOUR,
SPR_FIFTH_HOUR
};
``````

You can give an explicit value as many times as you need.

Wow.

That's just plain*perfect!*

Note that an enum occupies 2 bytes of RAM on an AVR processor.

hmm, what did it do to my post?

2 bytes makes it less than perfect :)

But as I think of it, why would it take any RAM?

so

``````enum {three=3};

byte one=1;

byte four=three + one;
[/coe]

results in three being stored as an in in ROM, three using two bytes of ROM as an int, the addition evaluating as a two byte int, and then being stood in four?

What if I use

[code]
enum {three=3};

byte one=1;

byte four= ( byte) three + one;
``````

?

And as I code implementation, I may not even need all of those.

For a "time" from 241 to 246 it could mean (time -240) hours, 247 for eight, and 249 four twelve. Or . . .

Defining an enum consumes ZERO RAM. In c++ and enum is also, effectively, a typdef. So, if you define an enum, then define a variable of that enum type, that variable will occupy two bytes of RAM.

Regards,
Ray L.

For my projects, flash usage isn't that important, but my curiosity is up.

If I only ever use the enumerated values as constants, in byte expressions, such as

``````enum {someEnumeratedConst=7};
byte someVar=3+someEnumeratedConsxt
``````

would the stored value in the code/Flash of someEnumeratedConst for calculating someVar be a one byte byte, or a two byte int? And if the latter, I guess that would force the calculation to be an int, causing 3 to be cast to an int, and then the result cast back to a byte to store in someVar?

``````enum : uint8_t {...};
``````

The : type addition specifies the underlying type of the enum. In this case uint8_t is a standard typedef for an unsigned 8-bit integer, ie unsigned char.

``````const byte SPR_EIGHT_HOURS=246;
const byte SPR_TWELVE_HOURS=247;
const byte SPR_HALF_HOUR=246;
const byte SPR_FIFTH_HOUR=247;
``````

Mmmmm

Mark

holmes4: ``` const byte SPR_EIGHT_HOURS=246; const byte SPR_TWELVE_HOURS=247; const byte SPR_HALF_HOUR=246; const byte SPR_FIFTH_HOUR=247; ```

Mmmmm

Mark

Mmmmm?

What's wrong with those constants?

holmes4: Mmmmm

After using 0-240 for time (a second midnight for wrap-up), only 16 are lef for specifying intervals. However, only some of these are actually useful/realistidf.