Joseph Tarango |
|||||||||||||||||||||
Home
|
|||||||||||||||||||||
Lab 6: Concurrent State Machine Design ( iNotSoMuch)Often in embedded system design, we have a complex system that requires interaction with multiple peripherals. Think of your cell phone and how many different operations it has to perform: transmit/recieve cellular network data, get keyboard input from user, display output, play music, store contact information, utilize bluetooth connections, etc...We've seen in the past few weeks that we can model such designs by using state machines. However, when a design becomes sufficiently complex, the size of a state machine can blow up exponentially. Designers often find it much easier to design multiple state machines that each handle a separate task or peripheral, thereby simplifying the design into peices. A drawback is that multiple state machines may require communication between them. Today you will be designing the iNotSoMuch, a much simpler and uglier prototype of today's popular mobile phones. Your iNotSoMuch will have the following circuit design: The iNotSoMuch will have the following features: 1. A keypad input that accepts as input a 7 digit number. 2. A display that shows the dialed number as it is entered 3. A speaker that echoes the tones made while dialing a number. (The speaker will be given to you during lab). We need some method to interact with the iNotSoMuch. Notice in the circuit diagram the two buttons and LEDs connected to PORTD. Pushing and releasing a button toggles the corresponding value. The LEDs should be used to display the current interaction method. The corresponding output of your project for each method is also listed. As a hint, it would probably be easiest to have a separate state machine that is in charge of detecting button presses and setting the correct mode.
We will want to use multiple state machines to complete this design, otherwise we risk having a hugely complex state machine that will be prone to errors. A good first step is to break down exactly what state machines you want to design, and how they will interact. You might have one main state machine that waits for concurrent state machines to do their jobs, such as gather 7 digits from the keypad. The helper state machine can set global variables when it is finished to signal it has completed and has a valid number to use. You can use as many state machines as you think is necessary. Remember that we are to use synchronous state machines. We have two options when it comes to how to choose our periods. Firstly we can assume that all state machines have the same period. Secondly, state machines can have unique periods. In this lab we will focus on maintaining the same period for each state machine. With this in mind, our main code should look something like this: SAMPLE CODE:
Download the following files. You must download io.h and io.c
again, because they have been altered for this lab. POST LABINDIVIDUALLY prepare and submit a single-spaced half page report with the following information.I. Lab Objective II. Personal Contributions III. Skill learned & knowledge gained. TurninINDIVIDUALLY prepare and submit all lab files into a tar ball. All .c files should be included in lab parts, as well as post lab submitted in pdf and txt format. All files should include a header with name, login, email, lab section, assignment, and group associates; also include: "I acknowledge all content is original."For Example Name: John Doe Login: jdoe Email: jdoe@cs.ucr.edu Lab Section: 021 Assignment: Lab 6 Group: John Doe, Jane Doe, and Joe Doe I acknowledge all content is original. Tar ball command: tar -cvzf name.tgz *.c *.pdf *.txt The tar command will compress all files into a .tgz file with all .c .pdf, and .txt files in that directory. Do not include unnecessary files! The .c files be named as follows lab#_part#.c and the postlab#.pdf/postlab#.txt. For Example: lab6.c postlab6.pdf postlab6.txt |