I need help
Lab 4 - Traffic Light Controller Preparation · Read Sections 4.4, 6.1, 6.4, 6.5 in the textbook · Go through Lecture again · See http://users.ece.utexas.edu/~valvano/Dainstructorheets/LED_yellow.pdf · See http://users.ece.utexas.edu/~valvano/Dainstructorheets/LED_green.pdf · Download and load into CCS “EGCP_450_Lab_4_Part_1.zip” · Also, in CCS, make a copy of “EGCP_450_Lab_4_Part_1” and rename it “EGCP_450_Lab_4_Part_2” · Watch the related video(s) here Purpose This lab has three major objectives: 1) the understanding and implementation of linked data structures, 2) learning how to create a segmented software system, and 3) the study of real-time synchronization by designing an FSM controller. Software skills you will learn include: advanced indexed addressing, linked data structures, creating fixed-time delays using the SysTick timer, and debugging real-time systems. You will learn to use Multisim for drawing and analyzing electrical circuits. Work Tasks NOTE: all software in this lab must be developed in C. Part 1 Consider a 4-corner intersection as shown in Figure 1. There are two one-way streets labeled North (cars travel North) and East (cars travel East). There are two inputs, representing car sensors, to your MSP432. The North sensor will be true (1) if one or more cars are near the intersection on the North road. Similarly, the East sensor will be true (1) if one or more cars are near the intersection on the East road. You will use 6 outputs from your microcontroller that control the traffic lights. See Example 6.4 from the book (pg. 242) and lectures for more help. Figure 1: Traffic Light Intersection (two inputs and six outputs). Part 2 Now, add to the functionality of Part 1 to include a “walk” light (Figure 2). The “walk” button will be pushed by a pedestrian when he or she wishes to cross in any direction. To request a walk signal, a pedestrian must push and hold the “walk” button for at least 2 seconds, after which the person can release the button, and the walk request will be remembered. In contrast, when a car sensor is released, it means no cars are waiting to enter the intersection. You will use 8 outputs from your microcontroller that control the traffic lights, the “walk” light, and the “don’t walk” light. The “walk” light will be the green LED (P2.1) on the LaunchPad and the “don’t walk” light is the red LED (P2.0) on the LaunchPad. When the “walk” condition is signified, pedestrians are allowed to cross. When the “don’t walk” condition flashes (and the two traffic signals are red), pedestrians should hurry up and finish crossing in any direction. When the “don’t walk” condition is on steady, pedestrians should not enter the intersection. The red and green LED connected to P2.0, and P2.1 respectively must be used. All other inputs and outputs must be built on the proto-board. Figure 2: Traffic Light Intersection (three inputs and eight outputs). System Requirements Traffic should not be allowed to crash (i.e., there should not be only a green, or only a yellow LED on one road at the same time there is only a green or only a yellow LED on the other road). You should exercise common sense when assigning the length of time that the traffic light will spend in each state so that the system changes at a speed convenient for the instructor (stuff changes fast enough so the instructor doesn’t get bored, but not so fast that the instructor can’t see what is happening). Cars should not be allowed to hit the pedestrians. The walk sequence should be realistic, showing three separate conditions: 1) “walk,” 2) “hurry up” using a flashing LED, and 3) “don’t walk.” You may assume the two-car sensors remain active for as long as service is required. However, a request for a walk is signified by a push and release, where the walk button is pushed for at least 2 seconds. There is no single, “best” way to implement your system. However, your scheme must use a linked data structure stored in ROM. There should be a 1-1 mapping from the FSM states and the linked elements. A “good” solution will have about 15 to 30 states in the FSM and provides for input dependence. Try not to focus on the civil engineering issues (i.e., the machine does not have to maximize traffic flow or minimize waiting). On the other hand, if there are multiple requests, the system should cycle through, servicing them all. Build a quality computer engineering solution that is easy to understand and easy to change. I expect your solution to behave reasonably and have 15 to 30 states. It is unacceptable if your machine is less than 15 states. If your machine has more than 30 states, you have made it more complicated than I had in mind. Because I have three inputs, there will be 8 next state arrows. One way to draw the FSM graph to make it easier to read is to use X to signify “don’t care.” For example, compare the Figure 6.9 in the book to the FSM graph in Figure 3 below. Drawing two arrows labeled 01 and 11 is the same as drawing one arrow with the label X1. When I implement the data structure, I will expand the shorthand and explicitly list all possible next states. Figure 3: FSM from the book Figure 6.9 redrawn with a shorthand format. This lab was written in a manner intended to give you a great deal of flexibility in how you draw the FSM graph, while at the same time requiring very specific boundaries on how the FSM controller must be written. This flexibility causes students to question “when am I done?” or “is this enough for an A?” To clarify the distinction between computer engineering, and civil engineering, I restate the computer engineering requirements. In particular, do these 9 requirements well, and you can get a good grade in this lab. 1. The system provides for input dependence. This means each state has 8 arrows such that the next state depends on the current state and the input. This means you cannot solve the problem by simply cycling through all the states regardless of the input. You should not implement a Mealy machine. 2. There must be a 1-1 mapping between the state graph and data structure. For a Moore machine, this means each state in the graph has a name, an output, a time to wait, and 8 next state arrows (one for each input). The data structure has exactly these components: a name, an output, a time to wait, and 8 next state pointers (one for each input). There is no more or no less information in the data structure than the information in the state graph. 3. There can be no conditional branches (do-while, while-loop, if-then, or for-loops) in your system, other than in SysTick_Wait and in SysTick_Wait10ms. See the Example 4.4 in the book. You will have an unconditional while-loop in the main program that runs the FSM controller. 4. The state graph defines what the system does in a clear and unambiguous fashion. 5. Each state has the same format of each state. This means every state has exactly one name, one 8-bit output, one time to wait, and 8 next pointers. 6. Please use good names and labels (easy to understand and easy to change). Examples of bad state names are S0 and S1. 7. Do not allow cars to crash into each other. Do not allow pedestrians to walk in one direction while any cars are allowed to go. Engineers do not want people to get hurt. 8. There should be 15 to 30 states with a Moore FSM. What if I have less than 15 states? Usually, students with less than 15 states did not flash the “don’t walk” light, or they flashed the lights using a counter. Counters and variables violate the “no conditional branch” requirement. If you are less than 15 states, you probably did not handle the 2-second walk button recognition. 9. If the pedestrian pushes the walk button for 2 or more seconds, eventually a walk light must occur. If the pedestrian pushed the walk button for less than 2 seconds, it is ok for the system to generate a walk signal or not to generate a walk signal. One way to handle the 2-second walk button requirement is to add a duplicate set of states. The first set of states means the walk button is not pressed. The second set of states means the walk operation is requested. Go from the first set to the second set whenever the walk is pushed. Go from the second back to the first whenever the walk condition is output. The two sets of states allow you to remember that a walk has been requested. In this way, the request is serviced when appropriate. There are many civil engineering questions that students ask. How you choose to answer these questions will determine how good a civil engineer you are, but will not affect your grade in this lab. For each question, there are many possible answers, and you are free to choose how you want to answer it. It is reasonable, however, for the instructor to ask how you would have implemented other answers to these civil engineering questions using the same FSM structure. 1. How long should I wait in each state? Possible answer: 1 to 2 seconds of real instructor time. 2. What happens if I push 2 or 3 buttons at a time? Possible answer: cycle through the requests servicing them in a round robin fashion. 3. What if I push the walk button, but release it before 2 seconds are up? Possible answer: ignore the request as if it never happened. Possible answer: service it or ignore it depending on exactly when it occurred. 4. What if I push a car button, but release it before it is serviced? Possible answer: ignore the request as if it never happened (e.g., the car came to a red light, came to a full stop, and then made a legal turn). Possible answer: service the request or ignore it depending on when it occurred. 5. Assume there are no cars, and the light is green on the North, what if a car now comes on the East? Do I have to recognize a new input right away or wait until the end of the wait time? Possible answer: no, just wait until the end of the current wait, and then service it. Possible answer: yes; break states with long waits into multiple states with same output but shorter waits. 6. What if the “walk” button is pushed while the “don’t walk” light is