Programming

If I'm understanding you correctly, INA_SAVE_APP_STATE(STATE) should clear state1, state2, and state3 from appState and then or in all bits present in the operand. So, states 4 through 8 can be set at any time and once set cannot be cleared. And whatever is set in the low order three bits of the operand will replace whatever was in those three bits before. If this is what you want, try:

Code:

#define INA_SAVE_APP_STATE(STATE)  appState = ((appState & !(state1 | state2 | state3)) | STATE);

To be on the safe side, you might want to AND the STATE operand with 0xF8 as well, and check that in STATE only one bit is set...

Agreed. I'm just not sure that we have a true specification of what this macro is supposed to do yet. I've worked on a lot of finite state machines, but the state changes described for this project still seem unusual to me. There seems to be a state0, but instead of having a bit identifying state0; it is identified by being not in state1, state2, or state3.

I was expecting to hear that my suggested change is a step in the right direction, but still isn't doing some things right. Should INA_SAVE_APP_STATE(state4) really clear state1, state2, and state3 from appState? Shouldn't there be some way to clear state4 through state8? Shouldn't there be a macro to initialize the state? (Maybe the header always defines appState to be an extern int (or char); but we haven't seen any evidence of that yet, and these macros won't behave as desired if appState is an uninitialized variable allocated on the stack.) There is no defined error mechanism. (What should happen if one calls INA_SAVE_APP_STATE(state1 | state2)?) Et cetera.

I'm still hoping for an actual set of specifications of the allowed state transitions, what happens when an illegal state is passed in, etc.