...
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 an input event, and then raise it in a global event queue.
Once 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 disallows the event (To prevent situations such as powering off while the car is moving). However, this approach can create dependencies between FSMs, which can result in coupled implementations. To avoid this, an event 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.
...
| Input Device | Pin | Type |
|---|---|---|
| Power | PC0 | Digital |
| Gas Pedal | PA1 | Analog |
| Mechanical Brake | PA2 | Analog |
| Direction Selector Forward | PB2 | Digital |
| Direction Selector Reverse | PB3 | Digital |
| Cruise Control | PC4 | Digital |
| Cruise Control Increase | PC5 | Digital |
| Cruise Control Decrease | PC6 | Digital |
| Turn Signal Right | PC7 | Digital |
| Turn Signal Left | PC8 | Digital |
| Hazard Light Switch | PC9 | Digital |
| I2C Serial Data Line | PB4PB9 | I2C |
| I2C Serial Clock Line | PB5PB8 | I2C |
Finite State Machine
The program system will be controlled through the use a series of multiple Finite State Machines to both monitor the current state of the vehicle and ensure that inputs the proper input events are only serviced at the appropriate periodscorrect times. Within the state machines used in this system, there exist transitions that depend on the current states of other state machines. As a result, an event must be ok'd by all active FSMs before a transition can be made. This way, dependencies between different FSMs can be supported while keeping
For a given FSM, each of its states be assigned a filter function to determine if an event can be passed. When an event is raised, all active FSMs will have the filter functions of their respective current states called, with the event passing if all functions return true. This allows us to control eeping separate the implementations of each state machine.
...
| State | Description | Transition |
|---|---|---|
| Hazard Light On | Hazard lights are currently active |
|
| Hazard Light Off | Hazard lights are currently inactive |
|
Horn State Machine
...
| State |
|---|
...
Combine pedal state and direction state into one FSM
...
This option will eliminate the FSM interdependence as well as allow for the elimination of the state IDs. However, the resulting FSMs would become much more complex, and there may exist better solutions.
...
Use boolean array to record active states
...
Would eliminate FSM dependencies and state IDs and allow us to refer to the array to observe the needed states. However, it would make changes could become difficult to make. Also, the boolean would need to be globally exposed for modification by the FSMs
...
Each state's output function will take an event ID as an input and return true if the event ID does not appear in a given list of forbidden IDs. Once an event has been popped from the event queue, all FSMs will run this function. All results must be true for the event to be processed.
This solution would eliminate the dependencies between FSMs, as well as the need for state IDs. Additionally, this list of forbidden id would be private to each state, meaning that changing this list would be very easy to do without alterations to any other part of the program.
...
| Description | Transition | |
|---|---|---|
| Horn Off | ||
| Horn On |
Push-to-Talk State Machine
| State | Description | Transition |
|---|---|---|
| Push-to-Talk Active | ||
| Push-to-Talk Inactive |
