1. Functionality: There are two contact switches that measure the status of your home. Each contact switch is positioned in the frame of a window or a door. If the switch is closed or pressed the window is secure, but if either switch is open it means the window is open and the home is unsecure.
2. Scope: The scope of this design will involve hardware/software prototype design, but will not include legal, marketing, or financial aspects.
3. Prototypes: We will use a breadboard and LaunchPad.
4. Performance: If either sensor shows the window is insecure and the system is activated the alarm should occur. The performance is defined as functionally correct. There is no particular specification for the minimum response time between the arrival of an insecure state and the alarm signal.
5. Usability: There is also a toggle switch with which the user can use to activate or deactivate the alarm. If the alarm is activated, the LED will flash at 5 Hz if either switch is not pressed.
6. Safety: No concerns 7.
3. Deliverables
1. Reports: Videos will be recorded and converted to a design chapter in the MOOC Embedded Systems – Shape the World.
2. Audits: None
3. Outcomes: We will create a prototype system 4.
8.4.2 Components
Before we get into the actual design of the Security system, let’s take stock of the components we will use in building the prototype.
8.4.3 Hardware Design
A data flow graph is a block diagram of the system, showing the flow of information. Arrows point from source to destination. Notice that a data flow graph looks like a block diagram of the system. In fact we draw a data flow graph by showing how the components are connected together. By visualizing the flow of data we are able to identify the components of the system and the nature of the data they work with.
Figure 8.8. Data Flow Graph for Security System
The data-flow diagram gives us a blueprint for both the hardware circuit we are going to build and the software we are going to write. Let’s first build the circuit:
Figure 8.9. Hardware circuit
8.4.4 Software Design
Programs themselves are written in a linear or one-dimensional fashion. In other words, we type one line of software after another in a sequential fashion. Writing programs this way is a natural process, because the computer itself usually executes the program in a top-to-bottom sequential fashion. This one-dimensional format is fine for simple programs, but conditional branching and function calls may create complex behaviors that are not easily observed in a linear fashion. Even the simple systems have multiple software tasks. Furthermore, a complex application will require multiple microcontrollers.
Therefore, we need a multi-dimensional way to visualize software behavior. Flowcharts are one way to describe software in a two-dimensional format, specifically providing convenient mechanisms to visualize multi-tasking, branching, and function calls. Flowcharts are very useful in the initial design stage of a software system to define complex algorithms. As an added benefit, flowcharts can be used in the final documentation stage of a project in order to assist in its use or modification.
Figure 8.10. Flowchart for the Software
The code that implements the flowchart design described above is given below. This solution uses a friendly approach to accessing Port E. Which implies that we could use the other pins in Port E without changing this code.
unsigned long arm,sensor;
void delayms(unsigned long ms);
void EnableInterrupts(void);
int main(void){ unsigned long volatile delay;
TExaS_Init(); // activate multimeter, 80 MHz SYSCTL_RCGC2_R |= 0x10; // Port E clock
delay = SYSCTL_RCGC2_R; // wait 3-5 bus cycles GPIO_PORTE_DIR_R |= 0x10; // PE4 output
GPIO_PORTE_DIR_R &= ~0x07; // PE2,1,0 input GPIO_PORTE_AFSEL_R &= ~0x17; // not alternative GPIO_PORTE_AMSEL_R &= ~0x17; // no analog
GPIO_PORTE_PCTL_R &= ~0x000F0FFF; // bits for PE4,PE2,PE1,PE0 GPIO_PORTE_DEN_R |= 0x17; // enable PE4,PE2,PE1,PE0 EnableInterrupts();
while(1){
arm = GPIO_PORTE_DATA_R&0x04; // arm 0 if deactivated, 1 if activated sensor = GPIO_PORTE_DATA_R&0x03; // 1 means ok, 0 means break in
if((arm==0x04)&&(sensor != 0x03)){
GPIO_PORTE_DATA_R ^= 0x10; // toggle output for alarm delayms(100); // 100ms delay makes a 5Hz period
}else{
GPIO_PORTE_DATA_R &= ~0x10; // LED off if deactivated }
} }
Program 8.3. Software system that flashes the LED if it is armed and if there is an intruder.
8.4.5 Testing
As a general practice embedded systems developers start with first testing their solutions in a simulated environment (if possible) before running it on the real board with real bardware. Note that, just because your testing proves successful in simulation it does not mean it will succeed on the real board. However, failure to run in simulation almost always guarantees that it will fail on the real board.
8.4.6 Conclusion
We have successfully designed, built and tested a Security system. As a last step, we'll look back at the requirements and see if we met the timing specifications. In particular, we will check to see if our calculations used for sizing the resistors in the switch and LED interfaces match actual observations.
Chapter 9: Arrays, Time, and Functional Debugging Embedded Systems - Shape the World Jonathan Valvano and Ramesh Yerraballi
In this chapter, we will illustrate a formal method for testing. Because embedded systems are deployed in safety-critical systems, we need to be rigorous in our methods that evaluate if the deployed system performs its tasks as required. Embedded systems not only need to arrive at the correct answer, they need to arrive at it at the correct time. We will introduce a simple hardware counter that we can use to measure time. The testing method we will develop in this chapter will be to create a data logger to store when and what our system is doing.
Learning Objectives:
Understand the concept of minimally intrusive debugging
Learn how the SysTick counter works
Learn about arrays
Learn how to use indexing to access arrays
Understand precision, length and origin
Learn how to create a debugging dump
Understand that a formal method to verify program correctness
Learn how to use the dump to collect debugging information in real time
9.1. Debugging Theory
Every programmer is faced with the need to debug and verify the correctness of his or her software. A debugging instrument is hardware or software used for the purpose of debugging. In this class, we will study hardware-level probes like the logic analyzer, oscilloscope, and Joint Test Action Group (JTAG standardized as the IEEE 1149.1) interface; software-level tools like simulators, monitors, and profilers;
and manual tools like inspection and print statements. Nonintrusiveness is the characteristic or quality of a debugger that allows the software/hardware system to operate normally as if the debugger did not exist. Intrusiveness is used as a measure of the degree of perturbation caused in system performance by the debugging instrument itself. For example, a print statement added to your source code is very intrusive because it significantly affects the real-time interaction of the hardware and software. It is important to quantify the intrusiveness of an instrument. Let t be the average time it takes to run the software code comprising the debugging instrument. This time t is how much less time the system has, in order to perform its regular duties. Let Δt be the average time between executions of the instrument. A quantitative measure of intrusiveness is t/Δt, which is the fraction of the time consumed by the process of debugging itself. A debugging instrument is classified as minimally intrusive if it has a negligible effect on the system being debugged. In other words, if t/Δt is so small that the debugging activities have a finite but inconsequential effect on the system behavior, we classify it as minimally intrusive. In a real microcomputer system, breakpoints and single-stepping are intrusive, because the real hardware continues to change while the software has stopped. When a program interacts with real-time events, the performance can be significantly altered when using intrusive debugging tools. On the other hand, we will learn later in this chapter that dumps, dumps with filter, and monitors (e.g., which output strategic information on LEDs or an OLED display) are much less intrusive. A logic analyzer that passively monitors the activity of the software is completely nonintrusive. Interestingly, breakpoints and single-stepping on a mixed hardware/software simulator are often nonintrusive, because the simulated hardware and the simulated software are affected together.
For example, the heartbeat code GPIO_PORTF_DATA_R ^= 0x02; requires only 6 bus cycles to execute. If the heartbeat runs every 1ms, and the bus clock is 80 MHz, then is equal to 6/80000.
Normally, if this ratio is less than 1/1000 we classify it minimally intrusive.
Checkpoint 9.1: What does it mean for a debugging instrument to be minimally intrusive? Give both a