Driver Control Software

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.

Within the state machines used in this system, there exist transitions that depend on the current states of other state machines. However, since the current FSM API does not provide a way to view the current state outside of string comparisons, a wrapper struct will be used to hold both the FSMs as well as their current states. In addition, the code defining each FSM has been split up, which will make it easier to add new FSMs in the future if needed. As of now, the driver input system is controlled by four FSMs.

Power State Machine:

Keeps track of the car's functional state.

State	Description	Transition
Off	The vehicle is off	Receiver POWER signal while in brake and neutral.
On	The vehicle is on	Receiver POWER signal while in the off state.

Pedal State Machine:

This state machine governs the running state of the car and defines the conditions under which the driver can turn on and move the vehicle. Transitions for this FSM depend on the state of the directional state machine.

State	Description	Transition
Off	The vehicle is not receiving power	Receiver POWER_OFF signal while in brake and neutral.
Brake	The car is on, but braking is active	Receive POWER_ON signal while in the off state Receive GAS_BRAKE signal while in coast, drive, or cruise control
Coast	The gas pedal is pressed just enough to allow the car to coast.	Receive GAS_COAST signal while in the brake or drive state
Drive	The brakes are engaged and the car is not moving	Receive GAS_DRIVE while in the coast state or brake state (Direction state must be in either forward or reverse)
Cruise Control	The car is currently in cruise control mode	Receive CRUISE_CONTROL_ON while in coast or drive

Directional State Machine

This state machine governs the possible gear shifts made by the user. Transitions in the pedal state machine depend on the current state of this FSM.

State	Description	Transition
Neutral	The vehicle is in neutral gear	Receive DIRECTION_SELECTOR_NEUTRAL signal while the Pedal FSM is in the brake state
Forward	The vehicle is in forward gear	Receive DIRECTION_SELECTOR_FORWARD signal while the Pedal FSM is in the brake state
Reverse	The vehicle is in reverse	Receive DIRECTION_SELECTOR_REVERSE signal while the Pedal FSM is in the brake state

Turn Signal State Machine

This state machine governs the states of the turn signals made by the driver. Independent from the other FSMs.

State	Description	Transition
No signal	The car is currently not signalling	Receive TURN_SIGNAL_NONE signal while either signal is active
Left signal	The car has the left signal active	Receive TURN_SIGNAL_LEFT signal while the left signal is inactive
Right signal	The car has the left signal active	Receive TURN_SIGNAL_RIGHT signal while the right signal is inactive

Hazard Light State Machine

State	Description	Transition
Hazard Light On	Hazard lights are currently active	Receive HAZARD_LIGHT_ON signal while hazard lights are off
Hazard Light Off	Hazard lights are currently inactive	Receive HAZARD_LIGHT_OFF signal while hazard lights are on

Possible State Transition Solutions

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

Give each state a list of forbidden events

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.

Driver Inputs

SMT32F0 Interrupts

Interrupts on the SMT32 are managed by the extended interrupts and events controller (EXTI), which allows for the management of up to 32 different interrupt lines (23 external and 9 internal). Each line can have both its active edge and interrupt priority programmed independently.

In order to generate an interrupt for an external line, the line must be configured. To do this, the bit in the interrupt mask register (EXTI_IMR) corresponding to the interrupt line must be set to '1', along with the corresponding bits in the desired edge trigger registers (Should an interrupt be triggered on a high-to-low or low-to-high change?), which are EXTI_RTSR and EXTI_FTSR for rising and falling edges respectively. Once this is done, an interrupt request will be generated once the selected edge appears on the external interrupt line and the pending bit corresponding to said interrupt line will be set. The STM32 will clear this bit automatically once the ISR concludes.

The STM32 has the first 16 external interrupt lines set aside for the GPIOs, meaning that there are only 16 digital interrupts available for use on the STM32. The GPIOs are mapped to the external interrupt lines as follows:

This means that only one port can have have an interrupt enabled for a given pin number at a time. For instance, enabling interrupt on PA0 will preclude the enabling of interrupts for pin 0 of any other port.

Pin Assignments

Input Device	Pin
Power	PC0
Gas Pedal	PC1
Direction Selector	PC2 - PC3
Cruise Control	PC4
Cruise Control Increase	PC5
Cruise Control Decrease	PC6
Turn Signal	PC7 - PC8
Hazard Light Switch	PC9
Hazard Light	PC10

Handling Inputs

The driver control inputs will be connected to onboard GPIOs. As we are only concerned with handling each input as they are triggered, most of the inputs will be set to be handled through the use of a common ISR. The ISR will then look at the debounced state of the triggering input device and raise the proper event in the event queue. The event queue will then be used to send the necessary messages over CAN and I2C.