lab1 by ashrafp

VIEWS: 13 PAGES: 4

									              CPSC 462 Microprocessor Design Lab

Lab 1: Counting with the EB63 with MMlite and use of the
logic analyzer
Due Date
Feb 9,10 2009, by the end of your lab session.

PreLab
Read Chapter 2, the EB63 section of the Lab Reference Manual, to gain an understanding
of the MMLite OS and EB63 evaluation board.
http://rtds.cs.tamu.edu/web_462/labs/labman_v4.pdf

Description
This lab will be an introduction to embedded system microcontroller development. In this
lab, you will develop device drivers and a client program to use them in the object
oriented operating system MMLite. In addition, you will learn the use of logic analyzer
for debugging purposes. What you learn during this lab will be a foundation for your
work later in the semester.

Objectives
Create your own driver that counts how many times SW1 is pressed and passes that
number back to your client program. This means creating your own COM object file i.e.
Component Object Binary (COB); refer to the Lab Reference Manual. This should be a
very simple driver that does nothing else but take button input.

Then the client program will take this value and input it to a second driver that generates
light patterns on the eight LEDS on the EB63 Evaluation Board selected using the
inputted value. You must have at least four patterns. The EB63 should loop in a
particular pattern until a button is pressed to exit the loop and prepare for a new input.

It is recommended that you provide a way to exit the program when done but this is not
required. The idea is to learn how to make a driver.

You must also create the client program (EXE) that starts the drivers you created and
calls the function to count the button presses and output the light pattern. Even though it
is technically possible to control hardware I/O from a client EXE you will NEVER do so
in this course. All I/O must be handled through driver COBs.
To get started create your own folder in C:\mmlite\base_programs\Lab1TeamX. Create
you files in this directory. The website where you downloaded this PDF has a link to
corresponding sample code. It might be helpful to look at that code when creating your
files.

Before running your program on the EB63 development board it is recommended that
you simulate it first using Microsoft Giano, a embedded system simulator, to ensure it
functions as expected. While not required, simulating your program first is usually a good
idea to ensure it does not perform illegal operations which might damage the hardware,
etc. Finally, similar to many professional development environments, in this lab
simulation is especially important because you will be developing your software before
having access to the physical hardware, which will be issued in the second week of the
lab.

Once you complete your program and verify that it works on the EB63 hardware, use the
logic analyzer to capture the transitions of your patterns. To do this you will need to look
up the pin locations associated with the LEDs. Take a screenshot of one of your patterns
and turn that in with your lab report.

Some good example patterns include:
    Binary Counting
    The Alphabet in ASCII
    Scrolling LED left to right and right to left
    Etc.

Note: Remember to back up you code every time you leave your workstation.
Also, you will probably need to debounce the input from the switch. This is easily done
by telling the process to wait a few milliseconds before capturing the button again.
Deliverables
For the 2nd week of lab, you will be required to bring a combination lock. You will use
this lock to secure the hardware we will issue you in one of the lockers. If you don’t bring
a lock, and we don’t have extras, you won’t get hardware, and hence won’t be able to
complete the lab until you bring one!

Everything else is due at the end of the 2nd week, as indicated at the top of this lab, so you
have 2 weeks to work on this lab. However, it is strongly suggested that you do not wait
until the last minute to start developing your code. A recommended schedule might look
like:
Week 1:
        - Gain understanding of the MMLite operating system, the EB63 hardware
             platform, and the compilation tool chain.
        - Develop lab code to a (mostly) working state using the simulator.
Week 2:
        - Test code on physical EB63 hardware.
        - Gain understanding of the logic analyzer then capture required screenshots.
        - Write lab report.

You will need to turn in:

Source Code –Everything needed to run your program. (*.c,*.h,*.cpp, etc).
       If there is more than one file they need to be put in a zip file LabXTeamY.zip.
       Electronically submit your files using the turn in service on CSNET.
       If you have any difficulties refer to the help document at
       http://helpdesk.cs.tamu.edu/docs/csnet_turnin
Lab Report – Use the template online to write your report.
       The lab report should also be turned in via CSNET. You may also submit a paper
       copy if you want, but it’s not required.
Demo – You must demonstrate that your code runs without error.
       Schedule a time before the deadline to demonstrate the lab to one of the TAs.

Grading
Each lab grade will consist of three items:
Demonstration that your code works to the TA                  = 33 1/3%
Quality of code (well designed and maintainable?)             = 33 1/3%
Written Report (including simulation)                         = 33 1/3%

Penalties
Turned in Late                                = -20% off total grade
Other than the late policy, other problems will be deducted from the relevant section
above according to their severity. A slight problem with the demo won’t result in much of
a deduction. Not trying and showing something barley functional will, and so.
Note: There is a Report template on the course web page. Use it as a guide. If you want to
do something different (i.e., the crazy people who want to write in LaTeX or some such),
that’s ok too.
 Basically, we want:
     First and foremost, professionalism. Check for typos, etc.
     What’s listed in the template:
            o an overview of the design
            o useful design documents (schematics, explanation, etc)
            o basically, enough information that someone could come alone and
               understand what you did, and why you chose to do so.

Obviously not turning in the source code, report, or not doing the demo at all will result
in missing all the points for that section.

								
To top