Page Comparison

...

Since input commands are to be made by the user, the events will be handled through the ISRs. The idea is to use the triggering address to correctly identify the raised event, and then raise the event it in a global event queue. 

Once the program returns to an event is popped from the queue in the main loop, it must be processed with the correct FSM. Additionally, we must also ensure that a given event is not processed if any of the FSMs are in a state that disallow the event. However, this approach can create dependencies between FSMs, which can result in coupled implementations. To avoid this, an event is popped from the queue and is filtered through the event arbiter arbiter is used to see if an event can be processed at the current time. The event arbiter works by looking at the current state of each active state machine and determining whether the event can be processed. This can be thought of as similar to a Caesar Cipher, where the correct alignment of states is needed for the event to be passed.

Through this approach, we can filter out events while also eliminating dependencies between different state machines.

CAN Data Scheme

Until a sufficient protocol can be defined for sending driver input data over CAN, we will be using the following dummy scheme for the event data field:

...

Finite State Machine

The program will be controlled through the use of multiple Finite State Machines to ensure that inputs are only serviced at the appropriate periods. 

...