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. The system will use three state machines to :

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.

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.

Turn Signal State Machine

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

ADC Driver

Description

The STM32 has a 12-bit onboard analog-to-digital converter (ADC). The role of an ADC is to take an analog signal as an input and give as output a digital number proportional to the magnitude of the input signal. The ADC on the STM32 has 19 multiplexed channels, allowing it to read signals from 16 external sources and 3 internal sources. The pin mappings for the 16 external sources are included below:

The ADC does conversions in groups of selected channels. Each conversion can be performed in either single mode, in which the ADC converts all the channels in the group in one single sequence, and continuous mode, where the device automatically restarts the scan after finishing the sequence, resulting in a nonstop conversion of the input channels. The 12-bit value obtained from each conversion will be stored in the ADC read-only data register (ADC_DR). To obtain the desired value from ADC_DR reading, the following formula is used:

Additionally, the sequence of channels to convert is defined in the ADC's 32-bit Channel Selection register (ADC_CHSELR), which contains a series of selection bits corresponding to each analog input channel. By using this register, it is possible to select the set of channels to be converted by the ADC, making it useful for when you want to convert either a single channel or a specific set of them. 

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

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 (for the prototype, we will collect information on the gas pedal through polling).

Once the ISR initiates, the pin that triggered it is debounced so that a steady reading can be obtained. The ISR will then observe both the address and the current state of the pin and determine the proper event to process based on that information. For the prototype, this has been implemented through the use of switch statements. However, as more work is done on the system and the amount of input devices increases, there may be a need to add additional functions to delegate the different input requests to, since it would keep the code cleaner and modular as well as easier to debug.

After determining the proper event to process, the ISR will go through another switch statement to ensure the event is handled by the proper state machine, after which the status of the system will be displayed as a text output. We intend to later output this information to CAN.