CEG3136 – Lab3 Complex State machine
Complex State machine
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
CEG3136 – Lab3
Complex State machine (C)
Objectives
To implement a state machine for an alarm system monitoring. The system consists of the following
components: - Keypad UI - Alarm sensors
- Alarm Bells (Alarms) - Central control
Introduction
In this lab we’re going to use the architecture flow shown next. The flow start by the system and
peripheral initialization. Then it goes into a continuous loop with a background task handling mainly
the user interface (UI). At the forefront there are 3 interrupt service routines responsible for
monitoring the sensors and firing the alarms when necessary.
Hereafter is the description of the system software components – note that software components
represent low level hardware components at the low (physical) level, then more complex virtual
(software) components handle the control/processing of the system data. - Console Application: this is the main function of the c-program. It initialize the Alarm System, followed by a background task of handling user input. User input is operator login to
Arm/Disarm the system and to quit the application at the end of simulation. - Alarm System Central Control: this is a data structure (class) that include the low level systemcomponents and manages the system state machine
- Sensor: is a structure holding the state of a physical sensor component. The system supports
up to 64 sensors. Sensors can be in one of the following states: {INACTIVE, IDLE, TRIGGERED,
MALFUNCTION}
- Alarm: is a data structure holding the state of a physical alarm bell component. The system
supports up to 64 alarms. Alarms can be in one of the following states: { ALARM_OFF,
ALARM_ON} - User: represent the database record of a system user, including the name, passcode of the
user, and weather it has the privilege of a super user
- Super User: is a class extension of the user class, it contain an instance of the user class that
has the super flag set.
The high level class diagram is shown below:
The User Interface
The user interface has two components: input and output
- UI Output: provide the system logging of all interesting events taking place at all times
- UI Input: is always ready for user login, if a valid passcode is entered the login event triggers an
interrupt (EXTI1). EXTI1 interrupt handler notifies the central control of the login even to take
proper actions
During initialization 8 users are initialized and 8 super-users are initialized. The passcodes are
hardwired for simplicity as follows: - User1: passcode user123
- User2: passcode user234
- etc. - User7: passcode user789
- Super1: passcode super12
- Super2: passcode super23
- etc. - Super 7: passcode super78
State Machine
As explained earlier, the system’s behavior is described/developed using a state machine. The
behavior of the system changes based on the current system state as well as the external events that
takes place and are monitored by the system. The state diagram of the central control is shown
below.
TickCount<50
The external events are listed below: - Sensor triggering an interrupt (EXTI0), it represent an alarm sensor detecting a risk event, e.g.
window or door open, motion detected, etc. - User login: triggers user input like arming and disarming the system
- Time delay: used to adjust the system timing, e.g. in transition from Arming to Armed states
The actions performed by the system (see state diagram) are: - Set the alarm ON when switching from ARMED state to TRIGGERED state
- Set the alarm OFF when moving from TRIGGERED state to IDLE state
- Reset TickCount on exit from Idle state
The SysTick timer
Refer to “The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors”, chapter 9.5: The
SysTick timer.
The Cortex-M processors have a small integrated timer called the SysTick (System Tick) timer. It is
integrated as part of the nested vector interrupt controller (NVIC). It can generate the SysTick
exception (#15). The SysTick timer is a simple decrement 24-bit counter and can run on either
processor clock or a reference clock. The reason for having the timer inside the processor is to help
software portability between Cortex-M processor systems. The SysTick timer can be used as a simple
timer peripheral for periodic interrupt generation, delay generation, or timing measurement.
Using the SysTick timer
If you only want to generate s periodic SysTick interrupt, the easiest way is to use a CMSIS-Core
function: uint32_t SysTick_Config (uint32_t ticks). For example for a 1 millisecond interval, you can use: SysTick_Config ( systemCoreClock / 1000 ). That
means when we divide the core clock frequency in Hz by 1000, we get the number of clocks per
millisecond. The timer interrupt handler: void SysTick_Handler(void), will be invoked every 1
millisecod.
In this lab the SysTick_Handler is used for: - Monitor the signaled sensor triggers and induce EXTI0_IRQn interrupt
- Call system_update_state function
- Induce EXTI2_IRQn periodically to print the ^beep^ message to indicate alarms when the
system is in Alarmed state
Interrupt Vector
Reference startup_stm32f417xx.s the vendor specified interrupt table is as follows. We’ll be using
external interrupt ports 0 & 1 in our development. EXTI0 is connected to the sensors and is ORed,
which means any sensor (or group of sensors) will trigger the interrupt if they are tripped. EXTI1 is
connected to the keypad, which detects a legitimate user login. EXTI2 is used to display “^beep^”
message when the system is in ALARMED state.