Reduce fsm mem

[ShiCheng-Lu]

• remove the need for transition list definition by defining the resulting transition table directly.
• remove redundant information:
  • id in FsmState, since the index into the FsmState list is the id of the state
  • curr_state change from a state pointer to a StateId (integer), store the state list in fsm to allow this.
  • num_transitions from FsmSetting

main:
   text    data     bss     dec     hex filename
  28368    1408   13808   43584    aa40 build/arm/bin/projects/centre_console

reduce_fsm_mem:
   text    data     bss     dec     hex filename
  28296    1452   12952   42700    a6cc build/arm/bin/projects/centre_console

[mitchellostler]

Hey, I'm happy with these changes. Also like that we don't have a num_transitions to worry about anymore.

I'm a bit worried about invalid accesses in the truth table if the size isn't properly initialized to NUM_STATESxNUM_STATES.

if we took the name of the transition array as a parameter in fsm_init, instead of making it part of the settings arg, I think we could do

#define fsm_init(fsm, transitions, settings, context)
static_assert(sizeof(transitions) == (settings.num_states * settings.num_states))
...

since fsm_init will be called in the same file as the 2d array is declared.
Will leave this up to you.

Would also be nice to verify transitions are correct, but I can't think of a way to do this other than adding back the num_transitions value and doing a check for redundancy, but this overcomplicates things

[ShiCheng-Lu]

I think if we take transition out, might as well take states and initial state out as well, kinda weird storing only two values in the setting.
fsm_init(fsm, states, transitions, initial_state, context) (maybe a bit too long)
but I think adding an assert for transition and state length is definitely good to have.

(even jankier can be that we just not have an initial_state parameter, and just make sure that the first state is the one the fsm starts on. As of rn, all fsm starts with state 0)

as for redundancy for num_transitions, while I was making changes, I found the power had multiple duplicate transitions, so I don't think the num_transitions count is very indicative, best to just keep the transitions organized.