Protocol module

The protocol module inserts an abstraction layer between the CAN bus driver and the top level board software. The incentive to do this was to achieve Don't repeat yourself (DRY) code and all the advantages that brings. Message reception is handled here and messages are inspected for certain content then passed on to the client only if they do not match one of the tags checked for.

Transitions between the states for client boards are performed by the protocol handler, the client board need only check what the current state is and act accordingly. The exception to this being the transitions to error state which can caused by hardware or software faults discovered by the client. Typically error transitions will be caused by a timeout which is detected by the protocol handler. The timeout counter, which is tracked by the protocol handler, must be refreshed by the client periodically to prevent the board, then system, falling into the error state.

The master board has a unique interface to the protocol module which allows it to use most of the features of the module but reject the message inspection (implemented as a hack on line 295 of protocol.c), which conflicts with the master board's purpose of controlling the global state. To be consistent with the design for the client boards this state handling code would have been implemented in protocol.c but for code readability it was left in comms.c.