代做CEG3136、代写C/C++程序语言

日期：2023-11-12 10:07

CEG3136 – Lab3

Complex Statemachine (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.

; Vector Table Mapped to Address 0 at Reset

AREA RESET, DATA, READONLY

EXPORT __Vectors

EXPORT __Vectors_End

EXPORT __Vectors_Size

__Vectors DCD __initial_sp ; Top of Stack

DCD Reset_Handler ; Reset Handler

DCD NMI_Handler ; NMI Handler

DCD HardFault_Handler ; Hard Fault Handler

DCD MemManage_Handler ; MPU Fault Handler

DCD BusFault_Handler ; Bus Fault Handler

DCD UsageFault_Handler ; Usage Fault Handler

DCD 0 ; Reserved

DCD 0 ; Reserved

DCD 0 ; Reserved

DCD 0 ; Reserved

DCD SVC_Handler ; SVCall Handler

DCD DebugMon_Handler ; Debug Monitor Handler

DCD 0 ; Reserved

DCD PendSV_Handler ; PendSV Handler

DCD SysTick_Handler ; SysTick Handler

; External Interrupts

DCD WWDG_IRQHandler ; Window WatchDog

DCD PVD_IRQHandler ; PVD through EXTI Line detection

DCD TAMP_STAMP_IRQHandler ; Tamper and TimeStamps through the EXTI line

DCD RTC_WKUP_IRQHandler ; RTC Wakeup through the EXTI line

DCD FLASH_IRQHandler ; FLASH

DCD RCC_IRQHandler ; RCC

DCD EXTI0_IRQHandler ; EXTI Line0

DCD EXTI1_IRQHandler ; EXTI Line1

DCD EXTI2_IRQHandler ; EXTI Line2

DCD EXTI3_IRQHandler ; EXTI Line3

DCD EXTI4_IRQHandler ; EXTI Line4

DCD DMA1_Stream0_IRQHandler ; DMA1 Stream 0

DCD DMA1_Stream1_IRQHandler ; DMA1 Stream 1

DCD DMA1_Stream2_IRQHandler ; DMA1 Stream 2

DCD DMA1_Stream3_IRQHandler ; DMA1 Stream 3

DCD DMA1_Stream4_IRQHandler ; DMA1 Stream 4

DCD DMA1_Stream5_IRQHandler ; DMA1 Stream 5

DCD DMA1_Stream6_IRQHandler ; DMA1 Stream 6

DCD ADC_IRQHandler ; ADC1, ADC2 and ADC3s

DCD CAN1_TX_IRQHandler ; CAN1 TX

DCD CAN1_RX0_IRQHandler ; CAN1 RX0

DCD CAN1_RX1_IRQHandler ; CAN1 RX1

DCD CAN1_SCE_IRQHandler ; CAN1 SCE

DCD EXTI9_5_IRQHandler ; External Line[9:5]s

DCD TIM1_BRK_TIM9_IRQHandler ; TIM1 Break and TIM9

DCD TIM1_UP_TIM10_IRQHandler ; TIM1 Update and TIM10

DCD TIM1_TRG_COM_TIM11_IRQHandler ; TIM1 Trigger and Commutation and

TIM11

DCD TIM1_CC_IRQHandler ; TIM1 Capture Compare

DCD TIM2_IRQHandler ; TIM2

DCD TIM3_IRQHandler ; TIM3

DCD TIM4_IRQHandler ; TIM4

DCD I2C1_EV_IRQHandler ; I2C1 Event

DCD I2C1_ER_IRQHandler ; I2C1 Error

DCD I2C2_EV_IRQHandler ; I2C2 Event

DCD I2C2_ER_IRQHandler ; I2C2 Error

DCD SPI1_IRQHandler ; SPI1

DCD SPI2_IRQHandler ; SPI2

DCD USART1_IRQHandler ; USART1

DCD USART2_IRQHandler ; USART2

DCD USART3_IRQHandler ; USART3

DCD EXTI15_10_IRQHandler ; External Line[15:10]s

DCD RTC_Alarm_IRQHandler ; RTC Alarm (A and B) through EXTI Line

DCD OTG_FS_WKUP_IRQHandler ; USB OTG FS Wakeup through EXTI line

DCD TIM8_BRK_TIM12_IRQHandler ; TIM8 Break and TIM12

DCD TIM8_UP_TIM13_IRQHandler ; TIM8 Update and TIM13

DCD TIM8_TRG_COM_TIM14_IRQHandler ; TIM8 Trigger and Commutation and

TIM14

DCD TIM8_CC_IRQHandler ; TIM8 Capture Compare

DCD DMA1_Stream7_IRQHandler ; DMA1 Stream7

DCD FMC_IRQHandler ; FMC

DCD SDIO_IRQHandler ; SDIO

DCD TIM5_IRQHandler ; TIM5

DCD SPI3_IRQHandler ; SPI3

DCD UART4_IRQHandler ; UART4

DCD UART5_IRQHandler ; UART5

DCD TIM6_DAC_IRQHandler ; TIM6 and DAC1&2 underrun errors

DCD TIM7_IRQHandler ; TIM7

DCD DMA2_Stream0_IRQHandler ; DMA2 Stream 0

DCD DMA2_Stream1_IRQHandler ; DMA2 Stream 1

DCD DMA2_Stream2_IRQHandler ; DMA2 Stream 2

DCD DMA2_Stream3_IRQHandler ; DMA2 Stream 3

DCD DMA2_Stream4_IRQHandler ; DMA2 Stream 4

DCD ETH_IRQHandler ; Ethernet

DCD ETH_WKUP_IRQHandler ; Ethernet Wakeup through EXTI line

DCD CAN2_TX_IRQHandler ; CAN2 TX

DCD CAN2_RX0_IRQHandler ; CAN2 RX0

DCD CAN2_RX1_IRQHandler ; CAN2 RX1

DCD CAN2_SCE_IRQHandler ; CAN2 SCE

DCD OTG_FS_IRQHandler ; USB OTG FS

DCD DMA2_Stream5_IRQHandler ; DMA2 Stream 5

DCD DMA2_Stream6_IRQHandler ; DMA2 Stream 6

DCD DMA2_Stream7_IRQHandler ; DMA2 Stream 7

DCD USART6_IRQHandler ; USART6

DCD I2C3_EV_IRQHandler ; I2C3 event

DCD I2C3_ER_IRQHandler ; I2C3 error

DCD OTG_HS_EP1_OUT_IRQHandler ; USB OTG HS End Point 1 Out

DCD OTG_HS_EP1_IN_IRQHandler ; USB OTG HS End Point 1 In

DCD OTG_HS_WKUP_IRQHandler ; USB OTG HS Wakeup through EXTI

DCD OTG_HS_IRQHandler ; USB OTG HS

DCD DCMI_IRQHandler ; DCMI

DCD CRYP_IRQHandler ; CRYPTO

DCD HASH_RNG_IRQHandler ; Hash and Rng

DCD FPU_IRQHandler ; FPU

__Vectors_End

Class Diagram

The detailed class diagram of the alarm system is shown below:

The following global (shared) variables are used to pass data from UI and Signal function (to be

discussed next) to the alarm system: - uint64_t sensor_states: represet updated sensor state, to be set from a signal function

- user_t *logged_in_user: the user object that was last sussesfuly loged in the system, used to

check if it is a super user

Signal File

ARM-Keil allows the simulation of external events using what is known as signal function. This is a clike function that is able to read/write to memory and wait on CPU clock among other things. We use

it to simulate sensor triggering during testing of the system state machine.

The source cod of the signal function is shown below:

signal void set_sensors (unsigned long status1, unsigned long

status2) {

{

printf("wait started \n");

_WDWORD(&sensor_states, status1);

_WDWORD(&sensor_states+4, status2);

twatch (0xFFFFF);

printf("wait is done \n");

_WDWORD(&sensor_states, 0);

_WDWORD(&sensor_states+4, 0);

}

}

The signal function set_sensors takes 2 arguments of unsigned long (32b) that represent the 64

sensors of the system. It writes the status arguments directly into the global uint64_t sensor_states

variable (address 0x20000000, 0x20000004). Then it waits for some time using twatch function and

then reset the sensor states back to 0 (IDLE). This way we can emulate sensor tripping during our

simulation – more details later.

Running Simulation

To run the simulation, first compile the code and then press on the debugger button (magnifier on a

d). Before you start the simulation, click on the debug menu and select “Function Editor”

Open the signal.ini file (include in zip file) and then press compile button – it should compile with no

errors. You can then close the function editor window. Later you can call the signal function during

simulation from the command line argument (at the bottom left) to induce sensor events – see

below:

Your Tasks

The provided code include the console application and all the above mentioned classes: - sensor: sensor.h, sensor.c

- alarm: alarm.h, alarm.c

- user: user.h, user.c

- super user: super_user.h, super_user.c

- alarm system: alarm_system.h, alarm_system.c

The state machine implemented in the system_update_state() function is left as skeleton, your task is

to implement the system state machine according to the state diagram provided. You should test the system behavior and make sure all states are visited and all transitions are tested.

At the end of the test if enter ‘q’ the UI loop is broken and the coverage for the FSM is displayedas

shown below.

FSM State Coverage:

UNARMED ARMING ARMED ALARMED

UNARMED 1 0 0 0

ARMING 0 0 0 0

ARMED 0 0 0 0

ALARMED 0 0 0 0

Make sure that all the above highlighted States & Transitions have non-zero coverage.

Report

The Lab report should include the following:

1) Code snip-it of the system_update_state() function. 2) You simulation log, showing all FSM cover points highlighted above covered with non-zero

coverage value.

3) The source code of the whole project (after cleaning all targets)

Zip all of the above in one zip file and submit t Bright Space.