Page Comparison

...

The objective of the driver input system is to wait on the actions taken events generated by the user attached input devices and use those events to broadcast the relevant message to the correct subsystem. Since the events will, for the most part, be user-initiated, using interrupts is the ideal way to handle incoming events. A series of finite state machines will be used to monitor the current state of the vehicle based on the actions generated by each event. 

Driver Inputs

IO Initialization

IO initialization has been split into two separate modules for both digital and analog devices.

Input Handling

Once an event has been generated, it will be stored inside a global event queue until it is time to process the event. The system will use FSM arbitration to events will be stored inside a global event queue until 

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. 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.

The prototype of the system used a switch statement to determine the correct event to raise. However, given the amount of inputs that the system will need to serve in the future, using individual callbacks may  

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. 

...

Additionally, it may be useful to have the FSMs stored in an array rather than in the fsm_group struct. This will allow us to iterate through the active fsms and make it easier to do operations on multiple ones at once.

...

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:

Image Removed

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. 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.

The prototype of the system used a switch statement to determine the correct event to raise. However, given the amount of inputs that the system will need to serve in the future, using individual callbacks may