Joseph Tarango
Department of Computer Science and Engineering
Bourns College of Engineering
University of California, Riverside

Home
CS120B | Syllabus
Lab 1 | Lab 2 | Lab 3 | Lab 4 | Lab 5 | Lab 6 | Lab 7 | Game Project

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.

Button0 Button1 Function Output
0 0 The call gets lost by the operator, and you end up connected to Santa Clause. Whatever Santa tells you should be displayed on the LCD for 5 seconds before he hangs up..
0 1 The call gets lost by the operator, and you end up connected to 1-900-PLAY-MUSIC...
You hear a short song on the speaker before it hangs up.
1 0 The line is busy. A busy signal sounds for 5 seconds before hanging up.
1 1 NA NA

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:

void main() {

 

      while (1) {

            SM1_Tick();//execute single state of sm1

            SM2_Tick();//execute single state of sm2

            //...

            ClkTick();//Wait until period expires before executing next state.

      }

}

Download the following files.  You must download io.h and io.c again, because they have been altered for this lab.
io.c
io.h
speaker.h
speaker.c

POST LAB

INDIVIDUALLY prepare and submit a single-spaced half page report with the following information.

I.     Lab Objective
II.   Personal Contributions
III. Skill learned & knowledge gained.

Turnin

INDIVIDUALLY 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