Switching gears... from mechanical back to software.

I started a branch called multiple-timers to work on the "multiple-timers features". 

This is how I am thinking of it: 

• The state machine has an array of timers instead of just one. 
• Since each timer needs to run in parallel, the "state" of the timer is recorded in the timer struct and not on the state machine. The state machine keeps track of which timer is the "current timer". 
• The timer being displayed is always the current timer since the display can/should display only one timer at any given time.
• When a timer is displayed, there could be other timers running in the background. That means that at any point, one of the timers in the background can start RINGING. At that point, the RINGING timer becomes the current timer so it is displayed. For this, a variable in the state machine records the index of the last RINGING timer so it can be made the current timer on the "state-machine service" function
• I reorganized the state machine by event first, as opposed to when it was organized by state first. I am doing this cause, since each timer has its state, each event can have an impact in one or more timers.