Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Overview

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.

...

Off

...

Idle

...

Driving

...

Image Removed

Directional State Machine

Governs the possible gear shifts made by the user.

...

Image Removed

Turn Signal State Machine

Governs the states of the turn signals made by the driver. Independent from the other FSMs.

...

ADC Driver

On the STM32 is a 12-bit 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 following formula can be used to determine the ADC reading:

Image Removed

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:

...

Analog-to-digital conversion of the different channels can be performed both single mode, in which the ADC converts all the channels at once in a single sequence of conversions, and continuous mode, where the device automatically restarts the scan after converting all of the different channels. The 12-bit value obtained from the conversion will be stored in the ADC read-only data register (ADC_DR).

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.

Handling input requests

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 interrupts (for the prototype, we will collect information on the gas pedal through polling). all set to be handled by interrupt service routine. objective for the driver controls firmware is to create a robust system capable of both properly keeping track of the state of the vehicle when responding to user inputs, as well as being able to send out the correct messages to other subsystems of the car.

The driver controls system works by waiting for the user to take an action such as a button press, which will then be used to construct an event to push to a global queue. When the event is ready to be raised from this queue, the system observes the current state of the car to determine whether the event is safe to be processed at the current time. If an event is raised at an unsafe time (i.e. flooring it while in neutral), then the event will be discarded.

To monitor the current state of the car, a series of Finite State Machines is used to monitor each input device. The different states of each FSM have a corresponding check function, which can be used to approve or decline an event according to it's current state. An event arbiter module is then used to run the check functions of all active FSMs, and the event is only processed if they all determine the event to be safe to run.

Once a given event is processed, the FSMs change state to reflect the event. A CAN message is then sent to the relevant subsystem based on the data held in the event.

Sequence Diagram

Image Added