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.