Laboratory 8 (team) -- Educational toy

Overview

This lab is the capstone project for the class. Your team will design, implement, and demonstrate a prototype of a microprocessor-based educational toy. Your toy will run as a program on the E100 CPU that you completed in Lab 6. Your toy will interact with the user via the DE2's input devices (keyboard, mouse, microphone, camera, SD card, serial port, switches) and output devices (VGA, LCD, LEDs, serial port), using device drivers like those you wrote in Lab 7.

Each team will design its toy to meet a different educational purpose, so the features and devices used by different teams will vary widely. However, all teams will need to learn about techniques and concepts beyond those taught in lecture. The course web page discusses some of these concepts (e.g., digital audio, binary data files, and bitmapped images for the E100). You will need to learn much more on your own, just as you will throughout your career.

Your program will probably be simultaneously managing multiple devices and tasks. For example, you might want to read keyboard input at the same time as sending sound samples to the speakers. To do this, you'll need to avoid waiting indefinitely for slow input devices. Otherwise, the sound from the speakers will pause while you wait for input. You can avoid waiting for slow input devices by first checking if the input device is ready with input and only reading the device if it is ready. If the input device is not ready, you can continue with other tasks, such as sending sound samples to the speakers. This style of programming is called event-driven programming.

Structuring and managing large projects

When writing large programs, it is essential to have consistent, clear structure. Divide your program into well-defined functions with clearly documented interfaces. Break your program up into multiple files (e.g., each device driver should be in its own file). This will help you work in parallel--different people can work on different parts without needing to understand implementation details from the other parts. Use consistent, meaningful names for variables and functions, e.g., for return addresses, constants, and instruction labels. We suggest you prefix labels with the name of the function or file in which the label occurs.

Document in your program (e.g., at the top of each file) which team member(s) worked on each component.

Git and GitHub

We strongly recommend managing your files with a revision control system. Revision control systems make it easier to coordinate between multiple people and help you manage multiple versions (e.g., if your new version has a bug, you can quickly get back to an old version).

We make it easier for you to use the git revision control system by providing a git repository for each group, hosted on GitHub. To use GitHub, you should have already:

1. Signed up with GitHub
2. Registered your GitHub username with ENGR 100
3. Generated an ssh key for your Linux account and added it your GitHub account

To use the repository we provide, initialize your local repository by cloning the (empty) repository from GitHub:

git clone git@github.com:engr100/uniqnameA.uniqnameB.uniqnameC.uniqnameD

Here is a tutorial on using git for ENGR 100.

Turning in your project

Your project will be evaluated based on your educational toy code, your oral project presentation (which should include a demonstration of your toy), and your final report. After the demonstration, one member of your team should submit a ZIP file that contains the following:

• All assembly-language files used in your program
• Your final .mif file
• The data file that you used to initialize your SD card (if you used one)
• The source code for any other utility programs you used
• Any documentation files for your program

zip -r toy.zip file1 file2 dir1 dir2 ...